Memory Deletion

What it is

Removing specific remembered content on request and being able to demonstrate afterwards that it is gone — not only from the primary store but from the indexes, caches, derived summaries, provenance records, replicas, snapshots, and backups that copied it. This is the mechanics and the evidence: how an erasure request is turned into a computable set, executed across every system that holds a copy, and recorded. How long things are kept in the first place is a retention-policy question decided elsewhere and arrives here as an input.

Why it matters

An erasure request arrives as an obligation with a deadline, and it is satisfied only if every derivative is reached. Memory systems make this unusually hard because copying content into new forms is their entire purpose: a fact erased from the belief store may survive in a consolidated profile written last month, in a vector index that was never rebuilt, in the episodic record of the conversation it came from, and in a checkpoint of a run that used it. Discovering that during an audit costs far more than designing for it, and a completion report that is wrong is worse than no report.

Key decisions

• The unit: one memory, everything derived from one conversation, or everything about one subject. The second and third are what is usually being asked for, and only a derivation graph makes either computable.
• Hard removal versus tombstone. A tombstone keeps references consistent and keeps a record that something existed; whether that is acceptable depends entirely on what the tombstone retains.
• What happens to derived items: removed with the source, regenerated from what remains, or flagged for review. Regeneration is the only option that preserves utility and it is a job, not a transaction.
• How embeddings and search indexes are purged, given that a vector is a lossy encoding of the deleted text and that removing a row does not always remove it from an index segment.
• Whether backups, snapshots, and replicas are inside the erasure boundary, and what the externally stated commitment says about restore.
• What evidence is produced — a per-request record of what was located and removed, across which systems — and how long that evidence is itself retained.

Failure modes

• The row is removed and its vector remains in an index segment until the next full rebuild, so retrieval still surfaces the deleted content.
• Erasure covers the memory store and misses the conversation transcript the memory was extracted from, which is the larger copy.
• A consolidated profile written last month contains the deleted fact in paraphrase and is never touched, because nothing linked it to the source.
• The operation is asynchronous and completion is reported when the job is enqueued rather than when it finished, so the report is routinely false by hours or days.
• A restore from backup silently resurrects erased memories and no reconciliation step removes them again.
• The item is removed and its provenance record, which retained a verbatim copy of the source utterance, is not.
• Per-item erasure is supported and "everything about this person" is not, because the store has no subject index and the content is distributed across free text.
• Erasure runs correctly against production and not against the analytics warehouse, the observability traces, or the evaluation dataset built from real conversations.
• A deletion job is partially completed, is never retried, and nothing tracks per-system completion, so there is no way to tell which systems are done.

Related capabilities

• Memory Expiration and TTL — the automatic lapse that looks similar and carries no obligation
• Memory Provenance — the derivation graph that makes the set computable
• Memory Consolidation — the process that scatters content into derived copies
• State Checkpointing — snapshots as a copy an erasure has to reach
• Conversation Memory — the transcript that is usually the largest remaining copy

Applies: Production readiness · Design questions