THE USEFUL ANSWER
Store a memory's source and version, the interval it describes, and the claims that depend on it. When evidence changes, update eligibility for future use and inspect the dependent claims. Preserve historical facts when they remain true about the past. Deleting one vector or adding a newer paragraph is not a complete correction policy.
01Version the claim, not just the document
Consider an invented project record: a release is planned for June, so an agent creates a preparation checklist. The release then moves to August. The old plan is still evidence of what was planned at the time, but it should not answer 'when is the release?' today. The checklist may need revision; an unrelated fact in the same document may remain valid. This is why corrections need more structure than newest-document-wins.
Our proposed record separates source evidence, a claim extracted from it, and an action or conclusion derived from that claim. That is a policy choice for an application, not a requirement to install a graph database. A relational table with explicit dependency records can be enough to make the first correction path inspectable.
Swipe or scroll to compare
| Record field | Question it answers | Practical rule |
|---|---|---|
| claim_id + revision | Which statement is this? | Keep immutable versions instead of replacing the only record of a past claim. |
| source_id + source_version + passage | Where did it come from? | Retain a stable evidence pointer and the checked version. |
| observed_at + valid_from + valid_to | When was it learned, and when does it apply? | Keep observation time separate from the period described. |
| status + status_reason | May a current answer rely on it? | Use explicit states such as current, superseded, disputed, or unsupported. |
| depends_on + relation_type | What conclusions may need review? | Distinguish direct support, optional context, and derivation. |
| scope + access_policy | Who may use this evidence? | Recheck access at retrieval and action boundaries, including cached summaries. |
02Borrow a vocabulary without borrowing false guarantees
W3C's PROV data model distinguishes entities, activities, and responsible agents so that provenance can describe how a result was produced. PROV-O provides relationships for derivation and revision, and a way to describe an entity's invalidation. [1][2] These are useful reference concepts. They do not decide whether a disputed business claim is true, or automatically propagate a correction through an agent's memory.
Keep your application status separate from the ontology's definition of invalidation. A source becoming unavailable is not proof that every statement it supported is false. A replacement source does not necessarily invalidate an historical statement. Record the reason for each transition and the policy that made the decision; avoid treating one ambiguous 'stale' bit as a complete explanation.
03Make correction a transaction with follow-through
- Append the new source version and extract the specific changed claim. Compare the assertion and effective period, not just embedding similarity.
- Mark the previous claim's current-use status and link its replacement, conflict, or missing support. Retain permitted historical evidence.
- Find direct dependents. Re-evaluate those whose support actually changed, then continue only when their own status or conclusion changes.
- Invalidate or recompute affected answer caches and summaries. A corrected store with an obsolete cached answer still serves the old claim.
- Record a correction receipt: changed records, examined dependencies, revised outputs, unresolved conflicts, and any required human decision.
04Check both kinds of persistence
LangGraph's documentation distinguishes thread-scoped checkpoints from stores for durable information across threads. [3] Use that distinction as a review prompt even with another framework: a corrected long-term store may coexist with an earlier conversation checkpoint. Decide whether a resumed run must revalidate its evidence before acting, and store the version it actually used.
Test four cases before expanding the memory system: a future plan changes; a historical event gains a correction; two credible sources disagree; and a principal loses access to a source. Ask both a current-state question and an explicitly historical question. Inspect retrieved evidence, final assertions, dependent summaries, and any resumed action.
Success means the system can explain which evidence is eligible and why, while preserving useful history within its retention policy. It does not mean every conflict has been resolved. This guide proposes a design and evaluation recipe; it reports no benchmark gain and makes no claim that a provenance graph alone prevents stale answers.
FOLLOW THE EVIDENCE
Sources & checks
- W3C: PROV-DM, the PROV Data Model ↗
[1] Entity, activity, agent, derivation, and provenance concepts; foundational standard rather than a new agent-memory release.
CHECKED 2026-10-09 - W3C: PROV-O, the PROV Ontology ↗
[2] Derivation, revision, generation, and invalidation vocabulary; application validity policy is explicitly this guide's proposal.
CHECKED 2026-10-09 - LangGraph: Persistence ↗
[3] Distinction between thread-state checkpointers and stores for durable cross-thread information.
CHECKED 2026-10-09
Sources are linked above so the argument can be checked independently. Editorial revisions retain the same public address.