A speaker withdraws consent after three published models trained on their recordings - how do you honour the erasure?

## The impossible triangle Three things are wanted at once and only two are achievable together: 1. The withdrawn recordings are **actually gone**, everywhere they were copied. 2. Every published snapshot id remains **byte-exactly rebuildable**. 3. Published models are **left as they are**. The right to erasure (GDPR Article 17, and its analogues elsewhere) makes the first non-negotiable, so the design question is which of the other two you give up and how you record the loss. The answer that reads as senior engineering and as a defensible position is: keep (1) and (3) by default, degrade (2) deliberately, and make the degradation itself a recorded, counted, auditable fact rather than a silent one. ## Consent as an indirection, not as data The structural move is to stop storing consent state inside the immutable corpus. Every utterance carries a **subject id**; a separate, mutable registry holds each subject's current consent state and the date it changed. Then: - The corpus stays immutable and content-addressed, as versioning requires. - A withdrawal is a single write to a mutable registry, which is the only place it can be handled in near real time. - Every reader - training jobs, evaluation, exports, ad-hoc analysis - applies the **current suppression list** as it resolves a snapshot, so no path can accidentally read withdrawn data, including a rebuild of a two-year-old id. This is what makes the erasure hold going forward. It does not delete the bytes, which is a separate, physical step. ## Deleting the bytes without rewriting history Shards are content-addressed, so a shard cannot be edited: the affected shards are **re-cut without the withdrawn utterances**, producing new hashes and a new snapshot id. The old manifest is kept as a **tombstone** rather than deleted, because destroying it destroys the ability to explain what the old model was trained on. The tombstone records the original manifest, the suppressed subject ids or row ids, the reason class, the timestamp and the approver, and it counts the removals. Rebuilding an old id then produces **the recorded set minus a counted exclusion list**, and the rebuild reports that difference instead of pretending to be identical. One alternative worth naming because architectures genuinely differ here: some platforms store each subject's raw audio under a per-subject key and destroy the key on withdrawal, leaving the shard bytes in place but unreadable. It is cheaper than re-cutting terabytes, and whether it counts as erasure at all is a question for counsel in your jurisdiction, not an engineering preference. ## What happens to the three models Nothing about a content hash tells you whether a model 'contains' a withdrawn speaker's data - that is a policy position, and organisations take different ones. What a lead owes is a **decision rule written in advance**, applied per model: | situation | usual position | |---|---| | model retrains on a short cycle and the contribution is diffuse | erase the data now, let the next scheduled refresh drop it out | | model is long-lived, rarely refreshed, or the withdrawal is contractually load-bearing | rebuild the model explicitly, on a stated deadline | | model is archived and not serving | erase the data; archive the model with the tombstone attached | Commit to a **latency** for each path, because 'eventually' is not an answer an erasure request accepts. ## Do not forget the copies Erasure applies to everything derived, not just the row in the corpus: exported analysis extracts, evaluation sets, cached transcripts, quality-review samples, backups and any downstream dataset built from the corpus. Each needs either the same suppression path or a stated expiry that bounds how long a copy can survive the request. A deletion that misses the copies is not a deletion. ## Retention expiry is the same machinery on a clock Retention is foreseeable erasure: on its schedule it removes shards that published models depend on. Because it is foreseeable, it is planned - the retention clock and the 'how long must this model stay rebuildable' clock are reconciled when both are set, not discovered in conflict during an audit. When they cannot be reconciled, the honest outcome is a documented statement of which models are explainable but no longer rebuildable, and from what date.