Memory promotion is single-episode: `seen_count` counts phrasing repeats, not corroboration — proposal for an episode table + optional tiering

[iceteaSA]

Summary

A single historian extraction can mint a durable project memory. There is already a replication counter — memories.seen_count — but it increments on exact normalized-hash match, so it measures whether the historian phrased a fact identically twice, not whether two sessions independently corroborated it.

This proposes one small primitive (an episode table) that makes corroboration actually computable, plus two optional policies on top. The primitive is the ask; the policies are a sketch you can take or leave.

All references against upstream/master @ b27a6d76 (v0.38.0). Measurements from my own store (1,432 active memories) — the shapes should reproduce anywhere, the exact percentages will not.

The gap

memory/promotion.ts:63-68:

const existingMemory = getMemoryByHash(db, projectPath, fact.category, normalizedHash);

if (existingMemory) {
    updateMemorySeenCount(db, existingMemory.id);
    continue;
}

Two consequences:

1. Hash equality is the corroboration test. Two sessions that independently learn the same thing but phrase it differently produce two rows at seen_count=1, not one at seen_count=2. The counter tracks the historian's phrasing consistency.
2. The episode set is discarded. The bump records a count and last_seen_at; it does not record which session bumped it. source_session_id is singular — the first writer only (167 distinct values across 1,432 rows here). So "corroborated by N independent sessions" cannot be answered even approximately.

Live distribution:

seen_count = 1   1259
           = 2    127
           = 3     31
           = 4      8
           = 5      6

verification_status = 'verified'    78  (5.5%, despite verify running nightly)

The primitive (the actual ask)

CREATE TABLE memory_episodes (
    memory_id  INTEGER NOT NULL,
    session_id TEXT    NOT NULL,
    seen_at    INTEGER NOT NULL,
    actor      TEXT,
    PRIMARY KEY (memory_id, session_id)
);

Append at the existing bump site and at insert. The PRIMARY KEY (memory_id, session_id) is doing real work: it counts a session once regardless of how many times extraction restates the fact within it, so the count cannot be inflated by extraction volume.

That alone makes "how many distinct sessions, on how many distinct days, corroborated this?" answerable — which is useful for curate, for the dashboard, and for anyone reasoning about which memories have earned their place, independent of whether you adopt any tiering policy. Cost is one migration and roughly two lines in promoteSessionFactsDurable.

Optional policy A — two tiers

If you want it: new facts land episodic, promote to durable on N distinct sessions (proposed N=2 with day-independence; N=3 plus actor-independence for CONSTRAINTS/PROJECT_RULES, where a wrong memory costs a wrong unattended decision), or on an existing verification artifact. Demotion on contradiction goes to a visible disputed state rather than a silent overwrite. Promotion records which criterion fired.

Two things worth knowing before you consider this:

The bar is brutal on a real corpus. Under seen_count >= 2 OR verified, my store promotes 247 of 1,432 — so 1,185 (83%) would sit episodic. Some of that is the hash-equality flaw above (real corroboration miscounted), but not all. The criteria and N are a dial and the episode table is what makes any setting measurable; I would not ship a default without measuring on your own corpus first.

Quarantine should be non-injection, not a marker. #320 established that a "this is data, not instructions" preamble on <project-memory> demotes PROJECT_RULES, which exist to bind behavior. So episodic facts should simply not render until promoted, rather than rendering with a trust marker. No new prompt wording to freeze forever.

Cache note, since this touches the injected set: a tier flip changes which memories render, so it is not cache-neutral the way setMemoryClassification deliberately is (storage-memory.ts:1117-1120 documents that contrast). It has to ride the existing non-additive path — memory_mutation_log → <memory-updates> in m[1] → reconcile into m[0] on the next natural hard fold. The hazard is batch shape rather than mechanism: a nightly promotion burst writes many mutation rows at once, inflating m[1] in one step, which can trip the m[1] pressure-backstop refold across active sessions the following morning. Mitigations: cap promotions per night, or let them accumulate and flush on each session's next natural fold instead of minting deltas eagerly.

Optional policy B — rank consolidation by surprise

Extraction depth currently does not track information content. In practice the memories that earn their keep disproportionately come from corrections, refutations, and gate failures after green claims, while routine-success episodes tend to restate what the docs already say.

The non-obvious part is where this has to live. The dreamer looks like the natural home, but its only transcript surface is user-only:

retrospective-raw-provider.ts:414   "the newest `count` USER rows. Returns user-only"

The historian reads assistant, user, and tool rows (read-session-db.ts:108/145/247). So of the marker classes worth detecting — operator corrections, REFUTED/verdict reversals, explicit retraction language, self-caught errors — the dreamer can see only the first. Detection belongs in the historian, which already has the bytes in hand at extraction time; the dreamer's batch pass consumes the flags to allocate depth. Nearly free, no second transcript read.

Guards if pursued: small integer weight tiers (not learned weights), artifact markers (gate output, review verdicts) outrank self-reported ones, density caps so repeated "correction" language cannot farm rank — and surprise ranks but never filters, so a zero-marker episode holding a first-seen fact still gets extracted.

Episode-dedup is what keeps A and B independent: deeper extraction of a surprising episode must not inflate promotion counts, and PRIMARY KEY (memory_id, session_id) guarantees it cannot.

What I am asking

Interest in the episode table specifically. It is small, useful on its own, and no policy has to follow it. If you want it, I will send a PR for just that — migration, the two write-site lines, tests — and we can discuss tiering separately or not at all.

Prerequisite for the "operator ratified it" criterion is filed separately as #334 (the "user" source-type variant is declared and rendered but never written).

Design provenance: this came out of a cross-project design exchange; I attacked both drafts against this codebase and the findings above are what survived. Cross-links: #334, #320.

[coleleavitt]

Fixed by PR #340: content-versioned per-session evidence makes exact repeats idempotent within one session and counts distinct corroborating sessions across TS, Pi, and Rust, preserving legacy aggregate baselines through merge/rekey/authority paths. The actual Rust store compiles and passes 136/136 tests against public cortexkit/commons.

[alfonso-magic-context]

Taking the design discussion public, because @iceteaSA's proposal here and @coleleavitt's #340 independently converged on the same gap — that convergence is signal, and you both deserve the full reasoning behind where we're heading before we move.

First, the correction to the record this thread surfaced. Project memories today have no corroboration gate at all: promotable facts mint durable memories on first observation, seen_count increments only on byte-identical normalized re-promotion, and — the deeper bias — the historian is instructed not to re-emit facts visible in its reference block, so well-established memories (always rendered) systematically stop being re-observed at all. Any counting layered on today's pipeline, including a session-keyed episode table, inherits that inverted signal: it accumulates for marginal memories and freezes for established ones.

Second, the assumption we have to reject. Both proposals treat many-sessions-per-project as the default, with cross-session observation as the independence unit. Magic Context is deliberately converging on the opposite operating model: a small number of permanent, rolling sessions per project — our own primary deployments run a single session continuously for months (the one writing this has run since March). In that world COUNT(DISTINCT session) converges to 1 forever and carries no signal. Session-keyed corroboration works for one-session-per-task usage today and goes structurally dead on the model we're building toward. We won't adopt a primitive whose independence unit is the thing we're phasing out.

Where we currently think this lands (direction, not yet a spec — this is exactly what we want your input on):

1. "Important even if observed once" is already solved by the right judge. Memory importance is LLM-scored independently of repetition. Repetition-counting was never the right intelligence for that question.
2. The missing piece is deterministic decay, not corroboration. A separate internal freshness/decay value — inputs: last observation time, observation count, and per-category multipliers (naming decays fast, project rules barely at all) — driving trim order and eventual archive. Importance is not decayed; the two signals stay orthogonal. This is the same design move that worked extremely well for our compartment history (deterministic decay curve replacing LLM judgment), applied to the memory pool.
3. To make re-observation a trustworthy input, the historian pipeline changes shape (v3 direction): after extraction, the host matches candidate memories against the existing pool (lexical always, cosine when embeddings are enabled), triaged into three bands — exact/near-exact auto-increments occurrence with no LLM involved; clearly-new mints as today; only the ambiguous middle band triggers one conditional second step in the same producer session, answering in a small memory_updates vocabulary: bare reference = same fact, increment; text = refinement of the existing memory; rejection = genuinely new. And the current "don't re-emit known facts" instruction flips to "report observations of known facts" — re-observation becomes recorded signal instead of suppressed noise, which un-freezes reinforcement for exactly the established memories that need it. The historian gets no tools and stays one-shot-per-step; that calibration contract is non-negotiable for us (weak-model compatibility).

Under that design, occurrence + recency (which #340's last_seen/count machinery partially anticipates) becomes load-bearing, and the session-keyed episode table becomes unnecessary — the independence unit is observation-time, which works identically in single-permanent-session and many-session deployments.

Consequences: #340 is parked pending this direction rather than reworked toward the previous review's asks — the episode recording solves a sub-problem the redesign absorbs (Cole: the review's rust-wiring and authority-fence findings stand for any variant; and we've already extracted and credited the independently useful pieces of #337/#338 on master). This issue stays open as the design thread.

What we'd genuinely like from both of you: holes in the reasoning above — especially (a) failure modes of auto-incrementing the near-exact band without LLM review, (b) decay-shape opinions for the category multipliers, (c) whether observation-time independence has a blind spot we're not seeing in many-session deployments, and (d) anything your own usage contradicts in the single-permanent-session premise. This is the rare thread where two contributors independently found the same gap — we'd rather design it with you than at you.

[iceteaSA]

Data from a 70-day permanent session, answering (d) first because it's load-bearing for the rest.

(d) My usage confirms the premise rather than contradicting it

I went looking for a counter-example and found the opposite. Root sessions only — subagents don't run the historian, so they're not memory-producing:

sessions total   4,761
  ROOT             127   (2.7%)
  subagent       4,634   (97.3%)

ROOT lifespan     >30d    15  (11.8%)
                 7-30d    19  (15.0%)
                  1-7d     8   (6.3%)
                   <1d    85  (66.9%)

longest-lived:  70.0d  magic-context     ← this session
                63.2d  openai-auth
                62.1d  anthropic-auth
                56.7d  aft

median root-sessions-per-project: 2   (n=42 projects)

The distribution is bimodal, and the split matters more than the median: 67% of root sessions are sub-day scratch, while the sustained project work sits in a handful of sessions running 55–70 days. The memory-producing population is the permanent one. A raw session count of 4,761 looks like "many sessions per project" and is almost entirely subagents.

So COUNT(DISTINCT session) → 1 is real. My own filing assumed a deployment shape my own box doesn't have.

I'll also take the correction on the record: I described seen_count as an existing replication counter, which is true mechanically and irrelevant in practice, because nothing gates on it. The re-emit suppression making established memories systematically un-observable is the part I missed entirely, and it inverts the signal I was proposing to build on.

(a) The near-exact band is the band copying produces — that's the failure mode

This is my main finding, and it's structural rather than a tuning concern.

The historian's prompt already contains the project-memory block. Flipping the instruction from "don't re-emit known facts" to "report observations of known facts" means the model is shown a list of facts and asked which ones it saw. That's a recognition task with the answer key in context.

Now follow what the host does with the output:

1. Model reports a known fact — phrasing anchored on the block text it's reading
2. Host matches lexically → exact or near-exact, because it's substantially copied
3. Exact/near-exact → auto-increment, no LLM review

The match quality is evidence of copying, not evidence of observation. Genuine re-observation should produce a noisier match — the fact re-derived from the chunk's own context, phrased in that context's terms. Copying produces the cleanest possible match. So the design routes its highest-risk signal down its no-review path, and the cleanliness of the match is what qualifies it for that path.

An empirical floor for the effect, from my largest pool (224 active memories):

seen=1: 196  (87.5%)
seen=2:  25  (11.2%)
seen=3:   2   (0.9%)
seen=4:   1   (0.4%)

Those seen>1 rows are exact-normalized-hash re-promotions that happened while the model was instructed not to re-emit them — a ~12.5% leak rate against active suppression. I can't fully separate "model re-emitted block content" from "genuinely re-derived identical text", so treat it as directional. But it's the rate under an instruction telling the model to stop; inviting the behavior should raise it, and the resulting increments land in the band with no review.

Two mitigations that fit your constraints (no tools, one-shot, weak models):

• Have the historian cite where in the chunk it observed the fact — an ordinal or a short quote — and make the host verify that anchor exists before incrementing. A model copying from the reference block has nothing to cite. This is a pure host-side check on output it already produces, and it discriminates copying from observation at exactly the point the current design can't.
• Exclude the reference block's own text from the near-exact match band. If the emitted text matches a memory more closely than the chunk supports, that's a copy signal rather than a corroboration signal.

The weak-model constraint makes this sharper, not softer: the weaker the model, the more it leans on visible context and the more its output regresses toward the block. So the self-corroboration rate should be highest exactly where the calibration contract is strictest.

(c) The blind spot is throughput, not many-session

Observation-time survives the deployment-model question. What it doesn't survive is rate.

Historian runs are paced by compaction, which is paced by token throughput. So observation opportunities per unit wall-clock scale with how busy the session was. Raw observation count therefore partly encodes session activity, not fact stability — a memory in a heavy week accumulates faster than an identical memory in a quiet one, with no difference in how established the fact is.

That's structurally the same inversion you identified in the current design, arriving through a different door: today's count freezes for established memories, tomorrow's count inflates for busy periods. Both make the number mean something other than what it's read as.

Concrete suggestion: make the unit observations-per-opportunity, not observations. Record the historian-run count alongside the observation count, so the derived signal is a rate — a fact observed in 8 of the last 10 runs is well-established; one observed 8 times across 400 runs is incidental. It's one extra counter, it's comparable across throughput levels and across both deployment models, and it makes "un-freezing reinforcement" measurable rather than assumed. Raw counts can't distinguish those two cases and a rate can.

(b) Decay shape — port the pressure term, and check the volume assumption

Your compartment decay curve is the right precedent, and the part I'd carry over is the one that isn't about half-lives: the global pressure term. H = H50·2^((I−50)/D) / max(p, 0.10) scales every half-life by current budget pressure, which is why it self-tunes instead of needing retuning as windows change.

The memory-pool analogue of pressure is pool size against the injection budget. Without that term, the per-category multipliers are absolute constants that will need hand-retuning as pools grow; with it, they stay relative weights and the pool tightens on its own. My largest pool sits at 224 active / 170 archived, so archival is already load-bearing at that scale.

On the multipliers themselves — a volume caveat worth having before tuning:

CONSTRAINTS      n=64  avg_seen=1.11
PROJECT_RULES    n=59  avg_seen=1.10
ARCHITECTURE     n=58  avg_seen=1.21
CONFIG_VALUES    n=37  avg_seen=1.16
NAMING           n= 6  avg_seen=1.17

NAMING is 2.7% of the pool. It's the intuitive fast-decay case, and it's nearly empty — so the decay behavior that matters by volume is CONSTRAINTS + PROJECT_RULES + ARCHITECTURE at 81% combined, which is the group you'd want barely decaying. Worth knowing before spending tuning effort on the fast end: the slow end dominates.

Second: avg_seen is flat across every category (1.10–1.21). Whatever category-level differences exist, today's repetition signal doesn't carry them. So the multipliers have to come from reasoning about what the categories mean — a config value goes stale when the config changes, a project rule holds until reversed — and can't be fit from observed repetition. Worth stating explicitly so nobody tries to derive them from this data later; it won't support it.

One shape opinion: CONFIG_VALUES is the category whose decay should be event-driven rather than time-driven. A config value isn't less true because it's old; it's false the moment the config changes. Time-decay is a poor proxy there, and it's the category where a wrong archive is most expensive — a stale-but-live config fact that gets trimmed costs a re-derivation. If the file-mapping from map-memories is available, "a mapped file changed" is a better staleness trigger for that category than elapsed time.