# Cascade Forget

*Delete derivatives along lineage, handle history by retention class, and report what it could not do.*

> **Cascade Forget** is deletion along lineage: when a source is deleted, or someone asks to be forgotten, the NAS finds everything derived from it, including summaries, embeddings, notes that cite it, caches and share links, deletes it or re-derives it without that source, and issues a **report**: what was done, and what could not be.

**AN-09** · Conformance level: L3 Guard · Cluster: Knowledge

## 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](https://agentnas.com/concepts/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-report.json*

```json
{
  "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](https://openlineage.io)
- [GDPR Article 17](https://gdpr-info.eu/art-17-gdpr/)
- [Long-term memory security survey (forget and rollback)](https://arxiv.org/abs/2604.16548)

## 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

### Can it make a model forget?

No, and it will not claim to. What it can do is delete files and derivatives inside the NAS and, for the `sensitive` class, history and keys; model-provider logs and model weights are out of scope, and the report says so explicitly.

### Why choose a retention class at write time?

Because history is hard to rewrite afterwards: what has already entered backups and history can only be rewritten or wait to expire. Deciding at write time whether something is `scratch`, `normal` or `sensitive` is the precondition for being able to delete cleanly later.

### Can an agent ask to forget something by itself?

It can raise a request but not execute it. Forgetting is irreversible and must go through a person or a pre-authorizing policy, and a legal hold can block it.

## Related concepts

- [Agent Memory](https://agentnas.com/concepts/agent-memory/): Notes you can read and edit are the truth. Indexes are a cache you can throw away.
- [Flight Recorder](https://agentnas.com/concepts/flight-recorder/): A per-run, hash-linked record that includes what the run read.
- [Agent Branch](https://agentnas.com/concepts/agent-branch/): Each run works on a copy-on-write branch. Only a reviewed merge reaches the main line.

---

Canonical URL: https://agentnas.com/concepts/cascade-forget/
Updated: 2026-11-11 · Draft specification v0.2 · CC BY 4.0