ADR-0025: Disposal & Erasure Mechanics (Storage, Index, Backups)¶
- Status: accepted
- Refined by: ADR-0043 (blob deletion post-commit), ADR-0044 (search-index purge realized), ADR-0042 (disposal execution realized — document tombstoning, single-actor hard-gated destruction)
- Date: 2026-06-18
- Deciders: Nicolas Burri
- Extends: ADR-0001, ADR-0006, ADR-0016, ADR-0017, ADR-0018; review findings RV-07, RV-08, RV-11
Context¶
ADR-0016 requires disposal at end of retention and (narrow) erasure, but the mechanics
across the content-addressed blob store (ADR-0001/0017), the search index (ADR-0006), and
backups (ADR-0018) were undefined. The storage interface sketch (put/get/exists) had no
delete; index purge on disposal was unspecified; and the backup-erasure problem ADR-0016
flagged was deferred to crypto-shredding, which ADR-0018 then deferred — leaving erasure
incomplete (RV-07, RV-08). Manifest persistence for multi-part versions was also unstated
(RV-11).
Decision¶
- Blob deletion: the storage interface gains
delete(hash). Disposal deletes a version's content-part blobs and its manifest blob via the interface — distinct from orphan garbage collection (which remains for unreferenced blobs). Because cross-scope deduplication is deliberately off (ADR-0001), derived copies in other scopes are independent blobs with their own retention and are disposed independently. - Manifest as a blob (RV-11): the canonical manifest serialization (ADR-0017) is persisted as a blob, so the signed manifest hash is verifiable independently of DB representation; GC and disposal are manifest-aware (a part blob is live while any live manifest references it).
- Index purge: disposal and erasure synchronously delete/invalidate the corresponding FTS and pgvector rows (not waiting for a rebuild), because the index participates in retrieval and LLM disclosure (ADR-0006).
- Backups (RV-08): erasure/disposal is forward-only with respect to existing backups. Backups are retained for a bounded, configurable window (set per the operator's data-protection policy) after which they age out, so disposed/erased data does not persist indefinitely. Crypto-shredding remains the documented future option for stronger backup erasure. This reconciles ADR-0016 and ADR-0018.
- All disposals are audited and produce a disposal record (ADR-0016, REQ-DPR-005).
Consequences¶
storagemodule interface: adddelete(hash); disposal path coordinates blob deletion- DB tombstoning + index purge as one audited operation.
- A bounded backup-retention window becomes an operational requirement; document the residual that data lives in backups until the window elapses.
- Erasure of a person/record is "effective immediately in the live system, and in backups within the backup-retention window."
Requirements¶
Adds REQ-DOC-018 (storage delete/disposal), REQ-SRCH-011 (index purge), REQ-DPR-011 (backup window); refines REQ-DOC-015 (manifest as blob). Pending requirements baseline v1.3.