Memory Tombstones and Deletion Lineage

Deleting a memory should prevent its content from returning through a summary, cached retrieval result, or rebuilt index. We would treat deletion as a dependency operation with a minimal receipt. Removing the original text row is only the beginning when other artifacts were derived from it.

The provenance model in our state and memory article provides the necessary source links. Our trace feedback method supplies a reason to preserve a narrow deletion receipt: an investigator may need to understand why an earlier decision references a record that is now unavailable.

Follow the derivatives

Imagine a hypothetical research note M containing a private operational detail. A summarizer creates S from M, an embedding index creates V from S, and a retrieval cache stores result R containing S. A delete operation removes M. If S remains retrievable, the user-visible deletion has failed to remove the information from the decision path.

We would identify M by a stable opaque identifier and record dependency edges M to S, S to V, and S to R. The deletion worker traverses those edges, removing or regenerating affected artifacts. A summary combining M with an unrelated public note can be rebuilt from the surviving public input, provided its regenerated version excludes the removed content.

The W3C PROV data model distinguishes derivation and invalidation. Those concepts are useful for expressing the lineage; the specification does not itself guarantee physical erasure. Storage systems still need their own handling for replicas, backups, and index persistence.

A tombstone without the secret

A proposed tombstone records the deleted identifier, scope, deletion time, and completed cleanup version. It omits the removed text. Copying the sensitive text into a deletion log would create another artifact requiring cleanup. Even a content hash can create unnecessary linkability, so we would justify each retained field by the operational question it answers.

The acceptance fixture first verifies that direct lookup returns a typed deleted result. It then queries the old summary, repeats the old semantic search, and restores a pre-deletion index into an isolated test environment. That restored index must consume the tombstone before becoming eligible for use. This last case exposes resurrection during recovery, which an ordinary live lookup test misses.

We would report cleanup completion per storage surface. A vector deletion acknowledgement establishes that one operation completed; it says little about a cached prompt or an offline export. An incomplete surface should remain named in the receipt rather than being absorbed into a single successful status.

Earlier decision artifacts may have separate retention permissions and obligations. Their treatment needs an explicit policy, including what information remains visible and why. The engineering protocol cannot infer that authority from the desire for a better audit trail. The operational endpoint is a deletion test that survives recovery, with enough lineage to explain the result and as little retained content as the task requires. This proposal makes no claim about DXAP's current deletion implementation.