When facts conflict
Your project changes its mind. The hard part was never recording the new decision — it's making sure the old one stops being followed.
Why memory gets this wrong
Six months ago you chose DynamoDB for the event store. Last month you moved to Postgres. Both facts are written down. Today an agent asks itself what the event store runs on.
If memory is a pile of text searched by similarity, both facts come back — they're about the same subject, in nearly the same words — and nothing in the result says which one is still true. The agent picks one. Sometimes it picks the old one, because it was phrased more confidently, or it appeared first, or the question happened to be worded the way the old fact was. Then it writes DynamoDB code.
Similarity has no opinion about what's still true. That's not a tuning problem you can fix with better embeddings; a search engine ranks by likeness, and the stale fact is every bit as like your question as the current one. Something has to actually know the decision was reversed.
Superseding: retire the fact, keep the story
When a decision replaces an earlier one, your agent draws a supersedes link between them. The old fact is retired: it stops being served as truth and ranks below live facts.
It is not deleted. It stays in the record, clearly marked, pointing at whatever replaced it. Two reasons that matters:
- The history is the point. "What did we decide before, and why did we change?" is one of the most valuable questions a record can answer, and it's the one a codebase can never answer on its own — the rejected option leaves no trace in the code.
- A mistake stays recoverable. If a fact is retired in error, that's a wrong label on something you can still see and correct — not a fact you've lost.
Every retirement states its reason
Retiring a fact is a claim: someone is asserting the world changed. So Stele won't record it bare. A supersedes link has to carry two things:
- a reason — what standing state actually ended, in your agent's own words;
- evidence — the verbatim line from the source showing it ended.
This isn't bookkeeping. Constructing the proof is the test. A fact that merely got newer has not been superseded, and the difference is easy to miss in the moment:
| The new fact says | Did the old state end? |
|---|---|
| "We've moved off DynamoDB entirely." | Yes. A termination. Supersede it. |
| "We also added a read replica." | No — that's additive. Nothing was retired. |
| "We're still on Postgres." | No — that's a continuation. |
| "We were planning the migration; now it's running." | No — that's the same story developing. Grow the fact instead. |
You can't quote a source saying a state ended when the source only says something new was added. Demanding the quote at the moment the claim is made is what stops the three rows above from being mistaken for the first one.
relates-to instead — which keeps the connection between the two facts and asserts nothing. Nothing is lost, and nothing true gets buried.The replacement always arrives with it
Marking a fact stale is only half an answer. Told "don't trust this" and handed nothing else, an agent has to guess.
So a retired fact never surfaces alone. Whenever one is recalled, the fact that replaced it is pulled in alongside — ranked above it, carrying the reason for the change. This matters most in exactly the case you'd expect to go wrong: when you ask a question using the old decision's vocabulary, and the stale fact is the closest match to your words.
What your agent sees is not a bare warning but a complete picture: the old fact, the new one, the date it changed, and why.
When you genuinely don't know
Sometimes two facts conflict and neither is obviously wrong — two people remember a decision differently, or a document and the code disagree. That is a real finding, and flattening it into a guess is the worst thing a record can do.
For that there's contradicts. Both facts stay live, both stay served, and the conflict itself is surfaced to your agent with a note that it must be reconciled, not resolved by picking one. A record that reports a consensus that never existed is worse than one that reports nothing.
Auditing what's been retired
A wrong retirement is quiet. The fact is still true, still there — just labelled stale and ranked low, so agents skim past it. Nothing breaks; things merely get subtly worse.
Two things catch it. The health check surfaces every claim-bearing link drawn without a reason, so unaudited retirements show up as work rather than sitting invisible. And the verification sweep re-tests them: for each one, does the two-part rule still hold — was it a standing state, and did it actually end?
Run a Stele review over the links that retire facts. For each one, check whether the retired fact was a standing state that actually ended — not just an older fact. Demote the ones that fail and bring back what they wrongly buried.
An edge that fails gets demoted to relates-to, and the fact it wrongly retired comes back.
Where this leaves you
The reason a graph is worth the extra structure over a pile of notes is precisely this: it can hold an opinion about what is still true, and defend it. A retired decision doesn't vanish and doesn't mislead — it sits behind the one that replaced it, explaining itself. See KNOW-45? Then see what replaced it, and why.