Cascade Forget

The problem #

Deleting a file does not delete its embeddings, its summaries or the facts memory inferred from it; snapshots and backups remain; and the content is still in version history.

“Recoverable” and “forgettable” are two ends of one axis, and most systems do not hand that choice to a person. If you only think about forgetting after the write, it is usually too late.

How it works #

• Lineage. Every derivative records its inputs; a reverse index answers “everything that depends on X”; a note’s sources field is lineage too.
• Retention class, decided at write time (because history cannot be rewritten afterwards): scratch (short TTL, not in backups, can be cleaned when the run ends), normal (versioned, recoverable) and sensitive (its own key domain, which can be shredded by destroying the key).
• The tension between recovery and forgetting. Recoverable inside the soft-delete window; hard-deleted only after it; a forget request may skip the window.
• Process. A request (raised by a person or an operator; an agent can only ask, not execute), lineage traversal, deleting derivatives and re-deriving facts of mixed origin, rewriting the history of affected paths and cleaning snapshots for the normal class, destroying keys for the sensitive class, and finally the report.
• The report: the number of files deleted, derivatives removed, whether history was rewritten, keys destroyed, snapshots not yet expired, and an explicit list of what it does not cover: copies outside the NAS, model-provider logs and model weights.
• It always goes through a Human Gate (or a pre-authorizing policy); a legal hold blocks forgetting and is recorded.

Start small #

• Start with retention classes and soft delete, and record the inputs of every derivative.
• First reach “when a source file is deleted, list and delete all of its derivatives”.
• Leave crypto-shredding for the sensitive class; it need not be done everywhere at the start.

Interface sketch #

Illustrative only. Field names may change before specification v0.3.

{
  "forget_id": "fgt_3b7c",
  "selector": { "paths": ["/shared/crm/acme/**"], "subject": "customer/acme" },
  "retention_class": "sensitive",
  "report": {
    "files_removed": 142,
    "derived_removed": { "embeddings": 3621, "summaries": 210, "notes_rewritten": 6 },
    "history": "rewritten (3 commits)",
    "keys_destroyed": ["key_acme"],
    "snapshots_pending": ["nightly-2026-11-10 (expires 2026-11-17)"],
    "not_covered": ["copies outside the NAS", "model provider logs", "model weights"]
  },
  "state": "pending_expiry"
}

What the specification asks for #

• Forgetting MUST propagate along lineage from the source to every derivative.
• The retention class MUST be assigned at write time (normal by default).
• A forget report MUST list what it does not cover: copies outside the NAS, provider logs and model weights.
• A legal hold MUST block forgetting and MUST be recorded.
• An agent MAY request forgetting but MUST NOT execute it.
• A report MUST NOT claim that a model has “forgotten” anything.

Borrowed, and what is new #

What follows is all established. What is new: treating the retention class as an explicit property of storage, and admitting that “recoverable” and “forgettable” are a trade-off on one axis.

• OpenLineage
• GDPR Article 17
• Long-term memory security survey (forget and rollback)

Honest limits #

• Backups, copies outside the NAS and model-provider logs are out of scope.
• For facts inferred from several sources, the “affected scope” is hard to define.
• Rewriting history is expensive and carries risk.

Open questions #

• How is the affected scope of a mixed-origin fact defined?
• What should the process be when a legal hold conflicts with a forget request?

Questions #

Related concepts #

• Agent Memory Notes you can read and edit are the truth. Indexes are a cache you can throw away.
• Flight Recorder A per-run, hash-linked record that includes what the run read.
• Agent Branch Each run works on a copy-on-write branch. Only a reviewed merge reaches the main line.