Wrong Facts Don't Die on Their Own

There's a fixed value in our system called TOMBSTONE_NULL, and it starts with a character no fact is allowed to contain.

\u0000 is the null character, the one character our database refuses to store in a text field, which is exactly why we picked it. This value exists so that when a fact was retired with no replacement value, the system can compare "nothing" against "nothing" without a real value ever colliding with it. We needed a value that no truth could ever equal, so we could safely talk about the dead.

I want to explain why a brand-knowledge system needs a reserved placeholder for comparing dead facts, because the reason changed how I think about knowledge in any system that learns automatically, including the loose federation of tools, agencies, and AI engines that "learns" your brand. The short version: adding a right fact took us one new row. Keeping a wrong fact deleted took a reserved placeholder value, two automatic checks built into the store itself, a comparison against every value the system has ever held, and a rule that only humans may kill.

Every fact knows where it learned itself

Some context. Everything we build runs on structured knowledge of a brand, and all of it converges into one canonical store. Facts earn their way in (only human-confirmed facts reach verified status, which is its own essay), but the part that matters here is that nothing enters anonymously. Every fact carries a stamp naming which product brought it home, and an evidence snapshot pinning what it rests on: for an ingested fact, that's the source document, the excerpt, the exact position of the passage.

The provenance vocabulary is enforced, not decorative. Each new way the system learns needed its own marker registered with the store before the store would accept its facts. We know the enforcement is real because one bridge shipped without registering its marker, and the store refused every single fact it tried to write until we registered it. Annoying night. Correct behavior. A fact with unregistered provenance is not a fact we want.

So the system never forgets where it learned something — which sounds like the achievement. It's actually the setup for the harder problem.

Deletion is harder than addition

Nobody warned me about the asymmetry. When you add a right fact, you're done: it sits there being right. When you retire a wrong fact, you are not done, because the wrong fact is still out there in the sources: the stale page that asserted it, the pipeline that extracted it once and will happily extract it again.

The failure mode has a name in our notes: resurrection. Picture it mechanically.

And if you run a brand, you've already lived the unautomated version of this. The old address that keeps reappearing in directory listings. The discontinued flavor a retailer feed keeps reviving. The wrong founding story that resurfaces every time some engine re-reads a stale press hit. You corrected it once; the sources didn't get the memo; the correction lost. Wrong facts don't die on their own — something has to keep them dead.

The rules we ended up needing

So deletion became governed. The contract rule reads:

"Retirement is human-only, and a retired claim key never resurrects."

Both halves are enforced by the store itself, not by a document.

Humans retire, machines never. The same rule that says machines can't confirm a fact into the store also says they can't kill one out of it. The retirement step literally refuses if a machine tries it. And a human can't drive-by delete either: retiring a fact requires a written reason: the store rejects a retirement with the reason left blank. Every kill has a name and a why attached.

Dead is dead — and the error message tells you what to do instead. A retired fact is terminal. There is no un-retire. The check that enforces this on every single fact is my favorite piece of the whole mechanism, because the refusal carries its own cure:

deprecated_terminal: fact % is deprecated (terminal); its status cannot change — propose a fresh fact instead

That's the correction path in one error string. You don't revive the dead row. If the truth changed, you propose a fresh fact, with fresh provenance, that earns its way in through the same front door as everything else. The note above that check says why it exists: it "closes the bridge race that could silently resurrect a retired fact."

The mirror checks the graveyard before it writes. This is where the tombstone value comes in. When the bridge syncs, it loads the retired facts for each claim and compares values — using TOMBSTONE_NULL so a fact retired with no value compares safely. The rule, in our own notes:

"Same-value deprecated-fama tombstone → do not resurrect (silent no-write, correct back-off). A different value bridges fresh."

The precision is the design. The tombstone blocks the value, not the topic. The question stays open; the specific wrong answer stays dead.

And the front door checks too. Proposing a fact runs a no-resurface check: if any prior entry for that claim (any status, including retired and rejected) already carries the same value, the proposal is refused. "A re-propose is only allowed when the asserted value DIFFERS from every prior row's value." There's even a double comparison under it, because a human can edit a value at confirm time, so the check compares against both the value as proposed and the value as confirmed, or a rejected fact could slip back in at exactly its edited value. That hole was found and closed before it bit. It's the kind of hole you only find if you're actively hunting resurrection paths.

One more receipt, my favorite for what it says about load-bearing rules. Across the document that governs all of this, the same clause is stamped onto row after row of the contract's ledger, seven times, near-verbatim:

"a promote into a deprecated claim key lands a fresh proposal, never a resurrect."

When a sentence has to be restated on every surface that could possibly violate it, the system is telling you where the bodies tried to climb out.

What this costs

This machinery is not free.

Correction is slower by design. A wrong fact can't be swept away by the next import run: a human has to show up, state a reason, and kill it. The human is the bottleneck, on purpose, and on a bad week the queue of things awaiting human judgment is the least glamorous backlog in the company. We chose that over the alternative (a system that can un-decide human decisions), but it is a choice with a bill attached.

And the back-offs are silent by policy. When the bridge declines to resurrect a dead fact, that's a quiet no-write, not an alarm; the skip is correct behavior. That took discipline to accept. Engineers want failure to be loud; but a graveyard that alerts you every time it correctly stays a graveyard would train everyone to ignore it.

Design for tombstones

The naive mental model treats a knowledge base like a whiteboard — wrong thing on it, erase it, gone. But erasure only works when nothing is refilling the board. The moment you have import loops, mirrors, or re-reads of old sources (the moment your system learns), an erased fact is just a vacancy the stale sources will re-fill. What actually protects the correction is a tombstone: a durable record that says this specific claim, at this specific value, was examined by a human and killed, for this written reason, on this date.

The unautomated version for a brand team is a kill list: a standing record of the specific wrong claims about your brand you've already corrected (the wrong founder, the stale price) so that when one resurfaces, whoever meets it knows it's a zombie and not news.

The tombstone is itself knowledge — arguably the most expensive knowledge in the store, because a human judgment call is the one thing the pipelines can't manufacture. Knowing where a fact came from is table stakes. Knowing where a fact died, and refusing to let the sources argue with the coroner, is the part you have to design for, and almost nobody does until a zombie fact outvotes a human three syncs in a row.

We gave our system a character no truth can contain, so it could keep track of the things it's not allowed to believe again. Adding knowledge is one new row. Unlearning is architecture.