What an Erasure Has to Reach, and What It Has to Admit

Every memory system can delete a row. Almost none can erase a person. Once an AI system has embedded what someone said, drawn facts out of it, answered questions with it, cited it, and logged the questions people asked about it, the person is in a dozen places, and a delete button that reaches one of them is a promise the system cannot keep. This is what we built instead, what it found when we proved it, and the one thing it tells you it did not do.

Retire first, destroy rarely

Yohanun does not destroy anything in ordinary operation. A wrong memory is superseded by its correction; a finished one is closed; both stay readable by identifier with their history, and neither ever surfaces in retrieval again. That is retirement, and it is continued processing under the law, so it is treated as such: it removes something from every answer while keeping the record complete. Most of what a business calls deletion is this.

Destruction is the exception, and because it is irreversible it is an act with a permission check and a receipt. We call it a purge, and it is the only way a point ever leaves the vector store. The store's own delete is a no-op by design. Nothing in the platform can destroy memory except this one path, which is what makes the path worth examining.

A plan that names nothing

A purge begins with a selector: one memory, one document, one principal (everything a person contributed, owns, or that a summary drew on), one matter (a whole compartment, at the end of its retention), or the whole tenant, for a customer leaving. The platform resolves the selector to a plan: how many items, in which stores, under which labels. The plan carries identifiers and counts and never content. The operator who fulfils an erasure request never has to read what they are erasing, and cannot: resolution is scoped to the tenant, not to what that operator is cleared to see.

Then the plan meets a mandate. A clerk may authorise a purge up to a line; above it the request goes to a queue, where a second person decides it by name. Since this month the platform enforces that it is a second person: it refuses a decision from whoever asked, and from anyone whose own authority would not have covered the request. An approval is bound to the exact plan and amount and is consumed once. If what is held has changed between approval and execution, the approval no longer fits and nothing is erased. Commits fail closed.

What it has to reach

The list is longer than anyone expects the first time. A memory in Yohanun lives in the vector store as text and as an embedding, and an embedding derived from personal data is personal data. It lives in the graph as a node with its entity mentions and its document. It leaves traces in the relational side-channels: reconciliation proposals that compared it to its neighbours, retrieval events that recorded it as a candidate, outcome events that scored it. It may sit in a cache. The purge reaches all of them, in both of the store's implementations, and a parity test holds the two identical, because the access gate compiles into the same filters and a store that erased differently would be a security defect.

Then there is what was made from it. A document's facts are cascaded with the document, and a session's summary with the session, because their provenance is explicit. Answers are the hard case. An answer grounded on a purged memory has usually paraphrased it, and a paraphrase of someone's personal data still holds it after the source is gone. So by default the purge takes those answers too. A deployment that must keep the turn as a record, and has a lawful basis to, can elect to close it instead, and the receipt says which happened.

What we found by reading the export

Polycarp, the website agent built on Yohanun, gives visitors a button to erase their own conversation. We proved it the way we prove everything: run the erasure, then take the tenant's full export and read it. The conversation was gone. The questions the visitor had asked were still there, in two places: the audit log's preview of each gated read, and the retrieval events that record what a question was and what it was shown. That a read happened is the audit and must stay. What was asked is content, and it had to go.

The purge now scrubs the asker's words from both logs: the rows stay, the text becomes an erasure marker. The scope is exact. A principal's erasure scrubs that principal's rows; a tenant's scrubs the tenant's; a matter's scrubs the rows on which that compartment surfaced; and, since this month, one erased question inside a conversation that otherwise stays takes its own words out and leaves the other questions' words in. Every purge proof we run now ends the same way: by reading the export back.

What survives, and why it should

What survives is the tombstone. One ledger row per erased memory, holding the identifier, the selector it was erased under, the approving mandate or escalation, which stores were scrubbed, and the recorded reason, which should be a request reference and never a name. A successor's lineage still shows that a predecessor existed and was purged; it shows nothing of what the predecessor said. The audit of the erasure is itself durable, because an erasure that leaves no record is a leak of a different kind.

The one thing it admits

Backups. A purge does not rewrite them; nothing responsible does, because a backup you can edit is not a backup. They expire on a window fixed for the deployment, and an erased item leaves them within that window. What the platform can do is say so. Since this month the purge report, and every tombstone, states that backups were not rewritten and how many days at most until they expire. The customer who receives the receipt receives the whole truth, including the part the system could not reach.

This came out of writing the paper for Irenaeus, our deployment for a set of chambers. The draft said "the erasure record says so" about backups, and the record said nothing. The paper was not allowed to say it until the platform did, and now a check holds the papers to the product. A claim a platform cannot back should not be in its prose, and the surest way to keep it out is to make the prose fail a test.

What this is for

A right to erasure is only a right if the system can perform it, and an AI system that has remembered someone properly is exactly the system that finds it hardest. We think the answer is to make erasure a governed act like any other: planned without reading, authorised under a mandate, decided by a named second person above a line, executed across every store, proven by reading the export, and honest about backups. The full account, with every store and every selector, is in the platform's documentation, and a purge with a receipt is what Polycarp's visitors and Irenaeus's clerks are shown when they ask.