Most systems keep only the current belief.
A model that changes its mind about a decision has, in most memory systems, one of three things happen to the record. It can be overwritten: the new text replaces the old, and the system keeps only the most recent state, the way a cache prioritizes recency. It can be merged: an LLM call blends the old and new into a single updated fact, and the specific disagreement that prompted the update is folded into prose. Or it can be annotated: both states persist inside one record’s text, with a timestamp or a phrase marking which is newer, leaving a later reader to parse a paragraph to reconstruct what changed and when.
Vendor writeups from 2026 describe the same problem from several directions. Hindsight resolves memory conflicts by prioritizing recency and merging duplicates through an LLM procedure, so the losing version is folded away rather than kept. 0Latency frames the same problem as contradiction detection, noting that preferences evolve and users self-correct, though the handling it proposes is still detection followed by resolution. AWS has published its own long-term-memory guidance wrestling with the same conflict case. Academic work is starting to argue for the opposite default: a 2026 paper on deterministic conflict-preserving memory for multi-agent systems proposes keeping conflicting states rather than resolving them, on the grounds that resolution destroys information a reasoner might need later.
Vinculum’s substrate memory takes conflict preservation as a structural default rather than a proposal under discussion: superseding an entry never deletes it, and the replaced entry stays in the graph.
Append-only. Supersede, never overwrite.
The rule is stated directly in the Vinculum Standard, as the second of its founding axioms.
Append-only. Supersede, never overwrite. A decision that changes is never edited or deleted. The old entry is kept, and a new entry supersedes it, with the link between them preserved. The changed mind is the record, and the lineage between old and new is the product.
The Standard names the mechanism that carries this out the SUPERSEDE operation, and marks it as the operation the rest of the specification turns on.
Mark an entry replaced by a newer one, and keep both, with the edge between them intact. This is the operation the whole standard turns on. An implementation that overwrites instead of superseding satisfies none of the axioms and conforms to nothing here.
The constraint has an analogue in database design outside Vinculum. A 2026 survey on data foundations for long-term agent memory, “Is Agent Memory a Database?”, independently describes versioned rows superseding prior ones through a partial unique index as a workable schema for the same requirement.
One entry, replaced, both kept.
The Standard illustrates the operation with a representative example.
One entry records a decision to use SQLite: a single file, zero operations. A later entry records the reversal once concurrent writers needed to write at once and SQLite’s file lock became the bottleneck. Neither entry is edited. The new entry supersedes the old, and the edge between them is typed and queryable.
The model reading the graph months later sees not just the current decision but the decision it replaced and why, which is exactly the context that stops it from re-deriving, or re-making, a mistake already settled.
Supersede links accumulate the same way in an ordinary project’s own graph — a byproduct of routine reversals, not a count curated for this page.
A superseded decision is not an error.
A superseded decision isn’t an error to erase. The disagreement between old and new is signal. Real reasoning is born from contradiction, and the graph keeps it available rather than smoothing it away.
The same structure reads differently depending on what it is used for. One internal framing treats each supersede link as a labeled preference pair rather than only an audit trail: every row in vinculum.links with relation=‘supersedes’ is a labeled preference pair. Pre-supersede is the choice that was rejected. Post-supersede is the choice that was accepted.
A supersede link is also a causal claim: this decision exists because the one it replaced turned out to be wrong. See what caused what for how the graph represents causal claims more generally.
What happens when a memory block is edited instead of superseded.
Traced against the alternative's own public documentation, rather than asserted.
Holds under concurrent writers, too.
Vinculum's own federation design shows the same axiom holds even in a genuine merge-conflict case: two separate instances superseding the same entry differently.
| Case | What happens |
|---|---|
| single-writer supersession | One instance supersedes one entry. The new entry links to the old with a single supersedes edge, and there is one lineage to read back. |
| cross-instance conflict | Two federated instances each supersede the same entry with a different replacement. Rather than picking a winner, the federation layer keeps both sibling pointers and raises a local note flagging the conflict, the same conflict-as-siblings handling CouchDB uses for concurrent document edits. |
The precision matters: the guarantee is that nothing is silently dropped, not that conflicting writes cannot happen. Two sessions can still disagree; a supersede that overwrites a correction without a trace is what the design rules out. The mechanics of the link itself, what a typed entry and a typed edge are, and what relations exist beside supersedes, are covered on their own page.
Overwriting is not a lighter version of this.
A system that overwrites, or strips lineage, isn’t a lighter version of substrate memory. It’s an older kind of record wearing the name.
The Standard treats supersession as a conformance requirement rather than an optional feature. An implementation that edits entries in place, or drops the link between an entry and what replaced it, does not meet the specification regardless of what else it does correctly.
Common questions.
Is a superseded entry deleted?
No. It stays in the graph, marked as superseded and linked to the entry that replaced it. Nothing about the operation removes a row or clears its content.
What happens when two sessions supersede the same entry at the same time?
Both replacements are kept as sibling pointers rather than one silently overwriting the other, and a note is raised flagging the conflict for a person or a later session to resolve. See the federation case above.
Isn't this just version history?
Version history is usually a debugging aid: a log a person consults to see what changed. Supersession is a typed, queryable edge in the graph itself, and the Standard treats the disagreement between versions as reasoning content in its own right, not only as an audit trail.