Memory benchmarks mostly ask whether a system can find something that was said. This one asks whether it can tell you what is still true. Across 234 multi-session scenarios where budgets get raised, rules get overridden and commitments get retracted, every memory system, retrieval baseline and long-context model tested answers with the current state under 37% of the time — and the errors are not random, they land on the specific value that was superseded. The fix that moves the number furthest is not a new memory store: making the model write out each fact's revision history before it commits to an answer lifts six existing backends by 32 to 67 points, in the same single call.
A scenario in this benchmark is generated as a program of typed state operations — a rule is declared, a value is updated, a scoped exception is granted and later lapses, a commitment is made and retracted. Every fact in it has a history, and only the end of that history is correct. The paper names five shapes this goes wrong in. Step through them and watch what a system built for recall hands back.
Note where full history in context lands: 0.149 on both backbones, the same as the weakest memory system. Having every turn available is not the constraint. Deciding which of two values a fact currently holds is.
The measurement trick that makes the rest of the paper legible is closed-pool grading. At generation time each probe gets a fixed set of plausible answers, one of which is the current state and one of which is the exact value a reader who missed the revision would anchor on. An answer is then scored as gold, as drift, or as neither — so "wrong because it tracked the wrong version" is separated from "wrong for any other reason" by construction rather than by a judge's opinion afterwards.
The number to sit with: on the weaker backbone the state-first method raises accuracy and the drift rate barely moves — it gets more answers right without changing what its mistakes look like. On the stronger backbone the drift rate falls 15 points, 64.3% to 49.1%, and correct answers rise from 75 to 117. Fixing state tracking and simply being a better model are separable, and both are needed.
The full method parses each turn with one model call into state units — a piece of content, a hard-or-soft priority, its source turn, and typed links to the units it was derived from or is coupled with. When a unit is superseded the store flips its status and adds the replacement; a deterministic pass then walks the dependency graph and flags everything downstream as needing a recheck, which costs no model calls at all. At question time the store assembles only the live units and one call recomputes the answer over them. Step through the paper's own ablation and watch which of those parts is load-bearing.
Two honest results in there. Supersession marking alone is the single biggest step on the stronger backbone — 0.174 to 0.298 — which is most of the method's gain for the least machinery. And dependency propagation is not free: removing it raises accuracy on that backbone to 0.373, because flagging everything downstream as stale also invalidates facts that were still fine. It pays on the weaker backbone and costs on the stronger one.
The result worth stealing is the last one. Strip the method down to a prompt-level transformation of the answer call — no store, no graph, no extra model calls — and it still works. The instruction has two halves: first trace, writing out the value chain of every fact the question touches (initial value, each revision with its turn number, current operative value, plus the latest stated inputs of any standing rule) in at most 250 words; then resolve, committing under four precedence rules — later supersedes earlier, standing rules outrank one-off instances, derived quantities get recomputed rather than quoted, and a fact is retired only by an explicit supersession or expiry. Total overhead: a fixed 155-token instruction and that trace, inside the one call you were already making.
The control arm is what makes this believable: a matched prompt of the same length and cost, without the state structure, gets some of the way there — sometimes most of it, as on the stronger backbone where the matched control alone takes one backend from 28.3 to 56.7. Attributing the rest to structure rather than to extra tokens leaves +15 to +32 points, which is the number to plan around, not the headline.
The production shape: a long-lived assistant holding a profile of user facts, some of which get revised over months — a changed address, a raised limit, a preference that had an exception granted and then dropped. Set your own profile size and revision rate below. The per-backend accuracies applied are the paper's frozen 60-scenario numbers; the traffic is yours.
The lever that matters is the middle slider, not the first. A profile of 400 facts none of which ever change has no state-tracking problem at all; a profile of 20 where half get revised has a large one. Count revisions, not memories.