Stratified Memory

Honest note before the post proper. The framing, the taxonomy, the heuristics, and the trade-off analysis below were worked out with my AI agent (Hermes), who did the design and the draft in response to a specific ask: "come up with an overall strategy for managing memory that incorporates the existing hindsight plus the other storage ideas; give me the heuristics for rapid storage and retrieval, and a way to keep everything in sync; don't gold-plate." The post is written in my voice; the synthesis below is ours, and where I state something as a design decision rather than a citation, that's the honest label.

The accuracy post was theory. This is what the theory says to do with memory on a real machine.

A memory system isn't a storage problem. It's a retrieval-latency versus verification-cost problem, and that's the whole post. Every "kind of memory storage" is really an access pattern — a shape of query — not a product you build. The mistake that makes memory systems gold-plated is treating the patterns as six systems and building six. The fix is to pick one physical store that can host all six access patterns, and treat the six as projections (views) over the same rows.

That's a direct application of the last post. Calibrated depth means: route each recall to the layer whose verification cost matches the cost of being wrong about it. A memory store is the same dial applied to where facts live and how they're looked up. Design for the budget, not for accuracy.

The six access patterns (and what they actually are)

The list I started from is really six ways a query touches memory:

OLTP — point lookups, "what is the current value of X."
OLAP — aggregation, "how often, across what, over what range."
Official versioned document repository — content with a history that must be auditable.
Git-style document storage — content versioned by content, HEAD is current, and hashing gives you dedup and drift detection for free.
Knowledge graph / concept-linked wiki — "how do A and B relate; what is the state of X," answered by structure, not keyword match.
Semantic chunking (vectors) + metadata — relevance recall, "things * about* X."

Now the part that keeps the system from gold-plating: those are not six systems. They are six projections over one canonical store. Postgres gives you all six natively, with no extra infrastructure:

relational tables → OLTP
SQL views + a periodic aggregation job → OLAP (not a data warehouse, just views)
an append-mostly table with a superseded_by chain → the versioned repo and the git-style history, in one
a node/edge table (or recursive CTEs) → the graph; at this scale a dedicated graph DB is gold-plating
pgvector + tsvector + metadata columns → semantic + keyword hybrid

One store, six cheap views. That is the anti-gold-plating move in one sentence.

Five methods you're not on the list

Worth naming, because they're the difference between a pile of tables and a memory system:

Event-sourced / bitemporal versioning. The real "source of truth" primitive. Postgres system-versioned (and bitemporal) tables make valid time (when a fact was true) and transaction time (when we recorded it) first-class. That's what "recency of retrieval" should be built on — not a metadata field you hope is fresh, but a queryable dimension.
Temporal (as-of) queries. Recency becomes as of <t>, so you can ask "what did we believe when?" and "what's current." This is the mechanism the drift audit leans on later.
Compiled projections. The wiki is a build artifact of the store, not a peer store. Derived caches regenerate instead of reconciling. This is the git insight applied to caches: the cache is a compiled thing; if it drifts, rebuild it, don't hand-merge it.
A usage/cost telemetry channel. "Relevance" isn't a static metadata field — it's a measured signal: retrieval count, hit rate, re-verify cost. It's an event stream over the store (a counter cache). This is what closes the loop that lets the cache learn what's worth keeping warm, and it's the piece the wiki has no version of.
Content-addressing + hashing. The consistency primitive. Git already does this; generalized, it's how you check "is everything in sync" — cheap dedup plus drift detection — instead of by eye.

All five are properties of one store, not five more systems.

The layers, and who owns what

This is the answer to "how do you keep everything in sync," so I'm being deliberate about write ownership. The rule that keeps it from becoming distributed-systems hell: one store is the source of truth, and no store is dual-written.

L0 — The Ledger (canonical). The new Postgres instance. One normalized fact schema with provenance and quality columns (below). Append-mostly: facts aren't deleted, they're superseded. This is the only place a fact's authoritative value lives. It is the OLTP layer, the versioned repo, and the audit trail, all at once.

L1 — The Wiki / graph (compiled, derived). The LLM-Wiki pattern (entities/, concepts/, comparisons/) as a projection over the ledger. Pages don't own facts; they reference ledger rows by stable id and cache a human/agent-readable synthesis. Provenance markers point back at the ledger and the raw source. The wiki is a cache, so it's allowed to be wrong — but it can always be re-derived, which is what keeps it honest.

L2 — The Semantic index (vector + metadata). pgvector over chunked records, with the quality side-channel. Fast-recall path. Also derived from the ledger, so it can be rebuilt. This is where "relevance" lives, and where the missing metadata (relevance / authority / recency) finally gets a home — as columns on the ledger rows, so any projection inherits it.

L3 — Hindsight (the autonomous fast lane). Keep it exactly as it is. Hindsight is excellent at exactly one thing: autonomous retain/recall/reflect with entity extraction and temporal reasoning, zero curation. The reframe is that it is not the canonical store — it's a high-speed working memory over the same eventual truth, allowed to be lossy because its answers can be re-verified against the ledger.

That re-scoping is what "incorporates the existing hindsight" means. We don't migrate Hindsight into Postgres or vice-versa. We change its role: reflexive recall first, escalate when stakes demand.

The metadata that was missing

The gap in the wiki was relevance, authority, and recency. They're not three separate features; they're columns on the canonical row:

id — stable, content-addressable
subject_id → entity; predicate (controlled vocab); value (typed jsonb)
as_of — when the fact became true (valid time)
verified_at — when it was last confirmed (transaction time)
source — who/what asserted it: user, primary:<url>, tool:curl, agent-inference
authority — tier: 1 user/author, 2 primary, 3 secondary, 4 derived, 5 inference
confidence 0..1, contested flag
superseded_by → the version chain (append-mostly history)
half_life — how fast this fact decays; staleness is now - verified_at against it
last_retrieved, retrieval_count — the measured "relevance"
embedding vector(384) on the chunk, not the fact row

Two choices worth flagging. Facts are atomic; chunks are the retrieval unit, and a chunk maps to one or more facts. And the embedding model should match Hindsight's default (bge-small-en-v1.5, 384-d) so the ledger's vectors and Hindsight's live in a comparable space — which is what lets the drift audit do vector-level comparison, not just string equality.

Heuristics: rapid storage

When a fact arises, route it by cost-of-error × volatility — the calibrated depth dial, made operational:

Re-derivable for ~free, and changes faster than a week? (session state, a tool's current version, transient context.) → working memory only: keep it in-context / in Hindsight, TTL it. Don't touch the ledger. High write cost + high staleness + low stakes → don't pay for permanence.
Stable and load-bearing about the user's world? (who the user is, standing conventions, environment facts.) → canonical: write the ledger row with provenance, authority, as_of, confidence. Mirror to Hindsight for fast recall, and into the every-context memory if it's one of the handful that must always load. This is the high-verification tier — pay for it.
A synthesis / comparison over 2+ sources? → a wiki page, referencing ledger rows and raw sources, with confidence and contested.
A document / deliverable / official record? → the versioned / git-style layer: content with a history, versioned by hash, HEAD is current. Not a vector chunk.

The unifying test: high-stakes + stable → durable (ledger); low-stakes + volatile → ephemeral (working memory); high-stakes + volatile → monitored (ledger + an alert, the stormwatch pattern); synthesis → wiki; official content → versioned docs. Same decision, one test.

Heuristics: rapid retrieval (the cascade)

In-context — free, already loaded. Check first.
Hindsight recall — fast, autonomous, possibly lossy. The reflex.
Escalate to the ledger when the claim is load-bearing, Hindsight's recency/confidence is low, or the answer must be auditable. Ledger point lookups are millisecond OLTP and authoritative.
Vector / semantic for relevance recall ("things about X") — use it to find candidates, then verify the candidates against the ledger. This is speculative decoding: cheap model proposes, verifier checks.
Wiki / graph for structural questions ("how do A and B relate") where the compiled synthesis beats raw retrieval.
Never answer a load-bearing fact from a cache alone. The verifier (the ledger) is the last hop.

Bias the default toward verify. That's just "accuracy is not free" applied to the read path: certainty costs, so spend the cost exactly where the mistake would cost more.

Keeping everything in sync (without gold-plating)

This is where most multi-store designs die, so the design refuses the trap up front: you do not keep N stores in sync. Continuous, row-for-row, bidirectional sync across Hindsight and the ledger is (a) impossible to get exactly right, (b) exactly the accuracy tax you're trying to afford, and (c) distributed-systems correctness with none of the payoff. Instead:

Source of truth = the ledger. One place. Nothing dual-writes it. The agent writes it through a thin API; nothing else does.
Derived caches regenerate, never reconcile-by-hand. The wiki and the vector index are generated from the ledger, like a build. Drift is fixed by rebuilding, not by hand-merging.
Hindsight is a peer cache, not a derived cache (it does its own autonomous extraction). So: no forced row-sync. A periodic drift audit (the OLAP job) samples the authoritative keys, recalls Hindsight's value, and produces a drift report — disagreements, fresh-in-ledger-not-in- Hindsight, stale-in-Hindsight. A review queue. Cheap and sampled, not continuous and full.
Conflicts resolve toward authority, then recency. Higher authority wins; tie → more recent verified_at wins; still open → contested flag into the review queue. No silent overwrite.
Append-mostly + supersede chain gives you the git-style history and the audit trail for free, and is what makes the drift audit possible in the first place (you can see when a fact was true).

The whole consistency model, stated plainly: one anchor, derived caches that rebuild, a sampled drift report for the autonomous store, and a one-directional mirror (ledger → Hindsight) to keep the fast lane warm.

What I'm explicitly not doing

Not building six systems. One store + projections.
Not auto-syncing Hindsight ↔ ledger continuously. Sampled drift audit instead.
Not embedding every row. Chunk-level embeddings on retrieval units only.
Not a dedicated graph DB. Edges table + recursive CTE; a graph DB is gold-plating at this scale.
Not a real-time OLAP cube. A few SQL views + a periodic job.
Not bidirectional wiki ↔ ledger writes. The wiki is derived; the ledger is written by the agent only.

Each "not" is a line of cost and a line of correctness risk that a memory system at this size doesn't need.

Data dictionary and standards (the boring part that earns its keep)

Two artifacts, both small, both load-bearing:

Data dictionary — a generated DATA_DICTIONARY.md plus a column_meta table: for every column in the ledger — name, type, domain, unit where applicable, source system, semantics, retention class. Auditable by a human in five minutes.
STANDARDS.md — the written rules: what goes where, the authority tier meanings, the confidence scale, how provenance is recorded, and the four retention classes (ephemeral TTL in working memory, durable append-mostly in the ledger, archived superseded-but-kept-for-audit, content versioned-by-hash docs).

The authority tiers are a fixed small vocab, not freeform, on purpose: the moment provenance is a drop-down of five, recording it stops being a tax. And provenance is NOT NULL in the schema — a fact without a source is schema- invalid, which is the only way the confidence metadata isn't fiction.

Pros, cons, trade-offs

Pro: one source of truth ends multi-store drift; every feature on the original list is present as a view, so the marginal cost of each is low.

Pro: the cascade is calibrated depth — fast by default, expensive only where the stakes demand. That's the thesis, made a retrieval path.

Pro: Hindsight stays autonomous — no retraining, no loss of its good behavior. It's just re-scoped as a warm cache.

Con / cost: it's more moving parts than "just use hindsight." The ledger + dictionary + standards + audit job are real work. Mitigation: phase it ( below); each phase is independently useful, so you're never paying for the whole thing before you get value.

Con: two stores both do recall (Hindsight + ledger), so the agent must follow the routing heuristic or it'll answer from the lossy one. Mitigation: make escalation the default for load-bearing claims — bias toward verify.

Con: provenance discipline is a tax. Mitigation: required in the schema, fixed vocab, NOT NULL. You can't skip what the table rejects.

The trade in one line: you trade upfront schema + one small periodic job for a single auditable truth and cheap recall. That's the same trade as paying for verification up front instead of paying for re-derivation at query time. If you accept the premise of the last post, this is the cheaper side of the trade.

How I'd roll it out (so it's reviewable tomorrow)

P0 — this post. The design, the taxonomy-as-projections, the heuristics, the sync model.
P1 — the bare minimum. Stand up the Postgres ledger with the core fact schema + provenance, the data dictionary table, and STANDARDS.md. Migrate the handful of canonical facts (the current every-context memory entries: who the user is, the standing environment facts, the conventions) as the seed. This alone is the single source of truth for "who the user is / what the box is."
P2 — the projections. Generate the wiki (entities/concepts) from the ledger; wire the pgvector chunk embeddings and the metadata side-channel. This is where "all the features" land cheaply, because they're views.
P3 — the consistency job. The periodic drift audit (ledger vs Hindsight, sampled) + the wiki/vector regeneration job + the drift-report review loop.

Integration point with Hindsight: a thin one-way push (ledger → Hindsight mirror of authoritative facts, to keep fast recall warm) and a thin pull (the escalation hop). Both through a small API, not auto-sync.

Where this leaves things

The taxonomy question ("are there other major methods?") has an honest answer that deflates the problem: yes — event-sourced bitemporal versioning, temporal as-of queries, compiled projections, a usage/cost telemetry channel, and content-addressing — but all five are properties of one canonical store, not five more systems. So the design is: one ledger as the source of truth, six access patterns as views, one measured side-channel, Hindsight re-scoped as the reflex layer, and a sampled drift report in place of the sync you thought you needed.

The budget, again, is the thing.