Stale, Misattributed, or Late: Where Personal Memory Fails Before Generation

What it claims

Most of the stale-fact problem is decided at write time, not at retrieval. With correct slot keys, serving only the active value per key produced zero stale exposure across 1,200 controlled queries (Wilson upper bound 0.005). With identical fact drafts but keys ignored, 70.3% of prompts exposed a superseded value. Once the store is right, the ranker barely matters: participant-aware BM25 with a validity filter reaches 0.873 clean retrieval against PFM's 0.877, equivalent within a ±0.02 margin fixed in advance and tested with TOST. Dense retrieval does not beat it.

The failure moves to key assignment. Four LLM key assigners reach key recall above 0.980 on paraphrased text but get lower clean retrieval than a lower-recall rule extractor, because they occasionally merge across slots. A false merge silently deletes a current value. A missed merge leaves a stale value active.

How it works

PFM is presented as a reference layer, not a new mechanism. The authors say the transaction-time supersession rule is established, and Proposition 1 is only a state invariant.

• Write path: an extractor emits fact drafts with text, entities and an optional slot key.
• Keyed drafts: a draft that repeats the active value is a re-observation. A different value closes the predecessor, which stays as history but leaves the index.
• Keyless drafts: these are absorbed only if an active fact sharing an entity has token Jaccard ≥0.8 and the same value-bearing tokens.
• No model call is involved in the update decision.
• Under out-of-order arrival, the last value to arrive wins, not the latest in event time.
• Serving: BM25F over text, entity and participant fields, plus recency, usage and a one-hop association term. Selection is greedy until k=6 facts or B=800 characters. No embedding model or LLM runs on this path.
• Identity: a softmax posterior over candidate entities, with T=0.5 and weights (1, 1, 0.25) on:
• is the current interlocutor,
• is graph-associated with the interlocutor,
• recency (exponential decay).

Retrieval keeps facts about the argmax entity and facts that mention no candidate. A hard participant filter is the limiting case, and it discards third-party facts.

• Abstention:
• a slot gate needs a known schema and returns an empty block unless a retrieved fact states the slot for an entity with posterior ≥τ;
• a margin gate needs no schema. It requires the top score to be ≥τ × the shortlist mean and to share a third of the request's content terms.

Evidence

The controlled benchmark has 5 seeds. Each seed has 160 revision chains (0–4 revisions each) and 1,000 filler messages, giving 1,200 queries in total, of which 40–50 per 240 are same-first-name ambiguous. Settings are k=6, B=800.

Other results:

• Co-injection: in the keyless store at B=800, 0.701 of prompts contain both the current and the stale value. Final-answer metrics cannot see this.
• Revision rate: the benchmark revises 80% of chains. Reweighting to a store where 70% of facts are never revised leaves keyed PFM at 0.877 and raises keyless to 0.603.
• Prompt budget: at B=240, keyed clean drops to 0.869 and wrong-person exposure falls to 0.000.
• Open-domain keying: on LongMemEval, merge recall stays ≤0.062 even when existing store keys are shown to the assigner.
• Generation: two frozen LMs reproduce prompt-level errors in their generated text.

Limits

• The slot gate abstains reliably on controlled data, but the schema-free margin gate does not transfer.
• The entity posterior cannot separate identically named speakers in LoCoMo.
• Equivalence of BM25 and PFM holds only once the store and participant info are shared. Without participant names, BM25 + validity drops to 0.774.
• Prefill dominating latency is measured on the authors' hardware only.
• The fetched text stops partway through Section 7.1. Per-assigner LLM numbers, the abstention results, the prefill latency figures and the generation results are not shown here.
• This is a preprint under review. No code or release is mentioned in the fetched text.