Memory Deletion — Patterns

Compute the set from the derivation graph

Problem. An erasure request names a conversation, a document, or a person, not a list of rows. Translating it into the actual set of affected items by searching for matching content finds the literal copies and misses every paraphrase, summary, and inference, which are the ones that will still be answering questions afterwards.

Approach. Make the request a traversal rather than a search. Starting from the named source, follow derivation edges forward to every item that descended from it, and include the source's own record, its index entries, and its provenance rows. The output is an explicit, countable set that can be reviewed before execution and recorded afterwards. Anything in the store with no derivation edges is a known gap in coverage, which is far better than an unknown one.

Trade-off. The traversal is only as complete as the provenance, so this pattern exports the problem to a capability that may have been built later or less rigorously, and a missing edge is invisible at exactly the moment it matters. Broad traversals also pull in items with several sources, where removing them destroys content belonging to people who did not ask for anything.

Regenerate derived items rather than deleting them

Problem. A consolidated profile built from fifty memories, one of which must be erased, is either kept — asserting the erased content in paraphrase — or deleted, destroying the other forty-nine contributions. Neither is acceptable as a standing policy.

Approach. Mark the derived item as pending rather than removing it, exclude it from retrieval while pending, and queue a regeneration from the inputs that remain. The regenerated item replaces the original and names the reduced input set. Where regeneration is impossible because too many inputs are gone, the item is removed rather than left pending indefinitely, and that outcome is recorded as part of the request's evidence.

Trade-off. Regeneration is a model workload triggered by an external request with a deadline, so erasure volume becomes an unbounded cost that arrives unpredictably. There is also a window during which the agent has visibly lost knowledge it is about to recover, and users experience it as a regression.

Crypto-shredding for what cannot be rewritten

Problem. Immutable logs, append-only event stores, and backups are the places content is most likely to survive erasure, and they are specifically designed to make rewriting impossible. A policy that requires rewriting them either fails or destroys the properties they exist for.

Approach. Encrypt per-subject content under a per-subject key held in a key store, and make erasure the destruction of that key. The ciphertext remains in logs and backups, structurally intact, and is no longer content. This requires the scheme to have been in place from the first write, with no path that stored plaintext, and with the key boundary matching the erasure unit the product has committed to.

Trade-off. The guarantee is only as good as the key management and the completeness of encryption coverage, and one plaintext copy anywhere defeats it entirely. Per-subject keys also complicate every read path and any cross-subject processing, and whether key destruction satisfies a given legal obligation is a judgement that should be made with counsel rather than assumed.

Evidence as a first-class output

Problem. Erasure is asserted rather than demonstrated. A job ran, a count was logged, and when somebody later asks whether a specific item is gone from a specific system, the only available answer is that the job reported success.

Approach. Produce a per-request record listing each system in scope, the set of identifiers targeted in it, the completion time, and the result of an independent verification query run afterwards against that system. Systems that cannot be verified are listed as such rather than assumed complete. Completion is reported to the requester only when every system in scope has a recorded outcome, not when the work was enqueued.

Trade-off. The evidence record is itself a durable list of who asked for what to be removed, which is sensitive and needs its own retention and access rules. Verification queries also cost real work against production systems and can only confirm absence through the interfaces they expose, which is weaker than proving the bytes are gone.