RememberStackremember.dev/docs

Architecture

RememberStack is a DAG across three planes, not a single ladder. The plane a component lives in fixes its rules: triggers, authority, mutability, rebuild semantics.

At a glance

Three planes

  inputs (files, mail, web, audio, video, images)
      │
      ▼
  E0 files ─→ E1 chunks ─→ E2 claims ─→ E3 facts     Plane E — evidence spine
      │                                    │           (Postgres + object storage)
      │              ┌─────────────────────┤
      ▼              ▼                     ▼
  P3 corpus fs    P1 search             live graph   Read models
                  indexes               (Postgres)

                  K knowledge pages (git)             Plane K — compiled + authored
PlaneTriggerSource of truthMutabilityRebuild
EPer-document chainPostgres (+ object bytes)Append-only; windows closen/a — is truth
KDebounced evidence changeGitCompiled rewrite / authored editRecompile (semantic)
P / read modelsInline or scheduledNoneP1 and graph are live; P3 is immutableP1 maintenance / P3 rebuild

Hard rule: validity and invalidation live only in PostgreSQL. P1 search indexes are derived state beside the authority rows; SQL/PGQ and recursive graph helpers read live PostgreSQL rows. Neither can become independent truth.

Plane E — evidence spine

Every input walks one durable, inspectable pipeline. Stages are idempotent workers on a work ledger (retries, dead-letter, budgets).

StageNameJob
E0FilesStore raw bytes; convert to Markdown via registered routes (smoke profile: Markdown passthrough; OCR/ASR/VLM when those routes are composed); structure sections; preserve locators
E1ChunksDeterministic blocks → retrieval-sized chunks with context prefixes
E2ClaimsAtomic grounded assertions (immutable)
E3FactsEntity resolution + relation/observation adjudication, supersession, contradictions

Postgres holds metadata, claims, entities, facts, evidence links, processing state. Object storage holds raw originals and converted representations.

Exhaustive write path: Ingestion · Pipeline stages · Lifecycle.

Plane K — compiled and authored knowledge

Git repository of knowledge pages:

  • Compiled — LLM writers produce citation-bearing prose; a deterministic driver owns staleness, routing, and commits.
  • Authored — human/agent commitments (principles, plans). Evidence changes flag them; nothing rewrites them silently.

K is never a structural input to P1 or graph reads. K pages and P3 cross-link as consumers of each other.

Agent contract and scopes: Knowledge (Plane K).

Plane P — projections agents use for speed

ProjectionStoreServes
P1PostgreSQL 19 (pgvector + pg_textsearch)Vector + BM25 over chunks and claims; semantic search over fact labels and entities
Live graphPostgreSQL 19 SQL/PGQ + recursive SQLImmediate neighborhood / path / as-of graph served directly from committed entity and relation authority
P3Object tree / mountBrowsable corpus filesystem (ls / cat / grep)

P1 can be repaired from authority and P3 can be rebuilt. The graph is a live relational view plus catalog metadata, so there is no graph snapshot to rebuild.

Stores and authority

StoreRoleAuthority
PostgreSQLSpine plus derived P1 vectors and BM25 indexesE source of truth for natural rows; P1 state is rebuildable
Object storage — rawOriginal bytesByte authority
Object storage — artifactsConverted Markdown, structure, media sidecarsRepresentation authority (replay, not regenerate-in-place)
PostgreSQL SQL/PGQ graphLive views over the E authorityDerived read model; no copied rows
GitPlane KK source of truth (authored + compile history)

Write path vs read path

Ingestion pipeline

Writes may call models (conversion helpers, claim extraction, adjudication, K compilation). Work is ledgered, versioned, and replayable.

Retrieval flow

Reads use no LLM completion (semantic paths may still embed the query). Projections nominate; Postgres confirms; the envelope accounts for grain, freshness, contradictions, truncation, and typed negatives.

Exhaustive read path: Retrieval.

Consumption architecture

Four surfaces, one precedence rule:

  1. Mounts (when available) — prefer for navigate/read/grep
  2. API — enforcement point for query-engine reads; open SQL + assured ops
  3. CLI — same operations for shell agents
  4. MCP — same operations for tool-using harnesses

Deployment-rendered consumption skill teaches the two-layer model and is checked by cold-agent evals. See Mounts and skill.

Registries (shared control data)

RegistryWhy it exists
EntitiesCanonical IDs + aliases; merge transcripts
PredicatesGoverned vocabulary with escape values
Operations / saved queriesVersioned query compositions; MCP renders from registry
Ontology packsDomain extensions without forking the core

Adding a operation is inserting a row — surfaces stay in lockstep.

Scale posture

  • Content-addressed reuse: identical bytes paid once.
  • Edit-proportional reprocessing: unchanged chunks reuse claims/vectors.
  • P3 builds are whole-corpus; P1 updates incrementally and graph reads are live.
  • Spike-tested search and hub pagination at large row/edge counts (see project status / design spikes) — not a hosted SLA.

Where deeper design lives

This site documents what ships. Extended architecture notes for implementers live in the repository under plan/designs/ (optional reading — not required to use the product).

Next

  • Concepts if vocabulary is still fuzzy
  • Ingestion to follow a document through the spine
  • Retrieval to follow a query through nominate → confirm → account