Deleting a fact is not the same as knowing it stopped being true

You took the advice that circulates whenever this comes up, and it is good advice: one document owns each answer, and the superseded one gets deleted rather than dated. A practitioner on r/AI_Agents reported three months of exactly that fixing what better chunking never would have (u/nejcar20, https://old.reddit.com/r/AI_Agents/comments/1vfa9iq/i_dont_think_rag_is_the_default_answer_for/, 4 August 2026). So you deleted the cancelled refund policy your assistant kept quoting, the wrong answer stopped, and that was the correct call.

Two weeks later a customer disputes a refund they were denied in March, and legal asks what the policy said in March. Nobody can answer. The document is gone, the assistant has no memory of it, and the only surviving evidence is in the head of whoever wrote the replacement.

You did not fix the corpus. You traded one class of unanswerable question for another.

Three operations that look the same from outside

There are three distinct things you might mean by "that fact is no longer true", and systems routinely offer one and let you believe you got all three.

Remove it. The fact is gone. Nothing retrieves it, at any point in time, by any route. This is the correct operation for exactly one situation, and we come back to it.

End it. The fact stays and acquires an end date. It is no longer returned by "what is true now" and is still returned by "what was true in March". Nothing is destroyed.

Suppress it. The fact is wrong and keeps coming back, because an upstream system re-sends it every night. It has to stay down even though a source that has never heard of your correction keeps re-asserting it.

Conflating them gives you an assistant that is either confidently stale or amnesiac, with no third option.

Ending is not removing, and the code has to say so

None of this is a new distinction, only a settled one that document stores never adopted. A DELETE against a SQL:2011 system-versioned table "does not actually delete the qualifying rows": it ends them, closing the row's system-time period so the row stays readable in the past (Kulkarni and Michels, both editors of the standard, SIGMOD Record 41(3), 2012). The ontology world standardised the same move separately, with owl:DeprecatedClass a W3C Recommendation since 10 February 2004. Ending has been a first-class database operation for fifteen years, and most document stores still do not have one.

The distinction gets stated in our codebase from an unexpected direction: the erasure path, where getting it wrong is a legal problem rather than an inconvenience. The claim store records it plainly. A valid-time-scoped delete, whether by SQL:2011 FOR PORTION OF or an end-of-validity stamp, closes an interval and is a logical delete: it leaves the fact readable at earlier instants, and it is not Article 17 erasure.

That sentence exists because the confusion is expensive in both directions. Use an interval close where you needed a real delete and you have issued a deletion receipt for data you still hold. Use a real delete where you needed an interval close and you have destroyed your audit trail to fix a ranking bug.

Ending a fact, in our store, is an UPDATE that sets a status, appends to an append-only history chain, and closes the interval with a single coalescing write, so the end date is written once and a later correction cannot rewrite the past. The claim that was true in January and superseded in June is still returned by a valid-time read for February, which is the entire purpose of a valid-time axis.

There are five statuses rather than two, and the fifth is the interesting one. When two asserted claims disagree on a single-valued predicate within a confidence epsilon and neither clearly supersedes, both become contested rather than one being forced into a win. That represents not-knowing instead of manufacturing a winner, and it is not swallowed internally: contested facts render in the customer-success handoff panel.

A domain where deleting destroys the right answer, measured

The delete rule is good advice for a travel policy. There are domains where it is wrong, and two have now been benchmarked.

A May 2026 preprint built 312 expert-validated, time-sensitive German statutory question-answering pairs and named two temporal failure modes (https://arxiv.org/abs/2605.23497). The first is post-cutoff staleness, where a model applies a superseded rule after an amendment. The second, the one this article is about, is recency bias: models "prefer newer provisions even when a historical version governs the fact pattern."

That second mode inverts everything above. In statutory work the superseded provision is frequently the correct answer, because conduct is judged under the law in force when it occurred, so deleting it does not remove a distractor, it removes the answer. The paper concludes that reliable legal question answering "requires treating temporal validity as a hard constraint", not that stale text should be cleared out.

A second benchmark, from 10 August 2026, puts a number on the retrieval half in French tax law, over a versioned corpus of 32,436 article-versions. Static RAG over the current-version corpus "retrieves the date-applicable version 0% of the time, confidently citing a real but inapplicable version", scoring 2.7 percent mean strict accuracy against 98.3 percent for a multi-version retriever (https://arxiv.org/abs/2608.09393). Zero percent is not a tuning problem.

Both benchmarks are European statutory and tax law. The structure is not confined to that, though the extension is ours and neither paper tested any of it: a contract read under terms in force at signing, a claim assessed under the policy at date of loss, a commission under last year's plan. In each the retired version governs some queries and distracts from others, and only the query's date says which. Treat that as the same shape, not the same finding, especially in insurance and compensation where the reasoning is untested.

That is the case "one document owns each answer" cannot express, and why ending must be a different operation rather than a polite word for removing. Caveats: both are preprints, the French one's workshop acceptance is declared on its own arXiv record, and we read the abstracts rather than the full papers.

The third operation, which most systems lack entirely

Suppression is the one nobody plans for and everybody eventually needs. A field in your CRM is wrong. You correct it in the AI's memory. Tonight the sync re-sends the wrong value, and tomorrow it is wrong again. The obvious implementation, blacklisting the offending record by its identifier, does not work.

Our claim ids are hashes that include the identifier of the source record, so the next sync of that stale field mints an id the system has never seen, and ranking the id you did see leaves the wrong value free to walk back in. Suppression therefore ranks the fact itself rather than the claim id, proven by a shared contract test across 50 re-assertions from unseen sources. You cannot delete your way out of a nightly sync.

When you actually do want it gone

There is one situation where removal is the correct and only answer, and it is when a person asks to be forgotten. Here the requirements invert: a logical delete is not merely insufficient, it is a false certification.

So erasure in our store is a hard delete, a real DELETE statement against the claims table rather than an interval close, and the contract is that afterwards time travel at any instant returns nothing for that subject. Adapters verify that before issuing a receipt and raise an incomplete-erasure error rather than attest to a partial erasure, across 12 cases and 6 probe instants. It reaches claims about the person, claims naming them in someone else's claim, and claims extracted from their own messages. Resurrection tombstones stop a replayed write bringing the record back, and store hashes only, so that table never holds a plaintext identifier.

The part we are proudest of is the part that admits failure. An engine that cannot truly erase must say so loudly: the contract asserts such an adapter raises a dedicated not-supported error from both methods, with a non-empty reason, so non-conformance is recorded in code rather than passing as a skipped test. Our Neo4j and Fluree adapters both decline, and both are evaluation prototypes, with Postgres the sole runtime substrate.

What the regulation actually requires today

One correction is worth carrying, since this subject attracts confident claims. EU AI Act Article 50 transparency obligations did apply from 2 August 2026, but Article 12, the automatic event-logging requirement, sits in the high-risk chapter and was deferred by the AI Omnibus, Regulation (EU) 2026/1744, to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I. Anyone telling you the EU now requires automatic AI event logs is wrong on the date. We build the record because it answers the questions in this article, and we make no conformity or compliance claim under any of these instruments.

What this buys, and what is switched off

Ending rather than removing is what lets a system answer "what did we believe in March" after you have corrected March's mistake: the difference between a memory and a cache.

The honest boundary: the store, the supersession path, fact ranking, contested status and erasure are shipped and ungated, erasure reachable through a live route. The extraction that would fill the store from your email and transcripts is not generally available yet, and claim reads into the dossier, chat and next-best-action sit behind flags the deploy config does not set.

The mechanism is real and the intake is not switched on. Both sentences are true, and we would rather you heard them from us.