RECORD LINEAGE · ERASURE · RESTORE
Observe the complete record lifecycle
Follow one customer record through primary storage, a search index, an analytics export and nightly backups, and compare what lineage reports with what exists.
Your experiment
Record R2 belongs to alice, who asks for erasure on day 10. It was written to primary and the search index on day 1, captured by nightly backups from day 2 to day 9 and copied to an analytics export on day 5. Start with lineage and erasure on primary only, then widen each, shorten retention and add the restore.
Play replays the computed run over sixty inspection seconds; Next event steps, Restart rewinds, Speed changes the pace and Inspection time scrubs. Any input change recomputes the run and rewinds it without autoplay.
Event trace
Computed data
Final metrics
Teaching model of one record across four stores; days are whole steps. A backup is assumed to expire exactly retention days after it was taken, the restore uses only the clean day-9 backup and is aborted if that backup has expired, and replaying the erasure log removes R2 again. Real systems add replicas, caches, logs and third-party processors. All data is fictional.
Lineage that only sees primary
Record R2 belongs to alice. It is written to the primary database and the search index on day 1, nightly backups from day 2 to day 9 contain it, and an analytics export copies it on day 5. Alice asks for erasure on day 10. With the opening settings only primary emits lineage events and the erasure job deletes only from primary. On audit day 24 lineage reports R2 nowhere, but it still exists in the index, the export and the backups: BLIND SPOT. An erasure dashboard built from incomplete lineage reports success.
Instrument every store, then erase from every live store
Set Stores that emit lineage events to All stores. The same copies are now visible and the verdict becomes COPY REMAINS: the audit is truthful, but the index and export were never erased. Set Erasure job deletes from to All live stores as well: on day 24 only the backups still hold R2, lineage shows them, and the verdict is ERASED with the last backup expiring on day 44. With lineage and erasure both on primary and index only, the export copy and the backups remain blind spots.
Backups expire on a schedule
Backup retention decides how long R2 survives in backups after the last one that captured it, on day 9. At 35 days the day-9 backup expires on day 44; set Audit day to 44 or 48 and no copy remains. At 7 days it expires on day 16, so by day 24 R2 is gone everywhere. Backups that are visible in lineage and expire on a stated date are an accepted state; backups nobody can see are not.
A restore can undo the erasure
With all stores instrumented and erased and 14-day retention, choose Restore day-9 backup, no erasure replay. The day-20 restore brings R2 back into primary: RESURRECTED. Replaying the erasure log after the restore keeps it erased. With 7-day retention the clean day-9 backup has already expired on day 16, so the restore is aborted and primary keeps its data. Day-20 restore has no effect for audit days before 20.
Reading the run and its limits
Play, Next event, Restart, Speed and Inspection time step through each dated action and the audit across sixty seconds; the store lanes mark copies red when lineage cannot see them. The table compares, per store, whether R2 exists and whether lineage says it does. The model follows one record in four stores with whole days and fixed backup timing; it omits replicas, caches, logs, vector indexes and processors outside the system. It does not decide what a regulation requires.