MAP · CONTROL · RECONCILE
Deletion: primary storage is only one copy
Follow actual fictional records through primary storage, a backup, an export and a restore.
Scroll the diagram left or right to inspect every label.
Your experiment
Request subject deletion, then inspect primary storage and backup separately. The export created earlier is a separate snapshot. Explain why deleting a source does not retract an already-created copy.
Play takes one minute at 1×. Pause, step or scrub the computed history. Input changes reset the experiment without autoplay. Red cards identify a previously deleted record that returned from backup.
Export snapshot
An export already copied to another destination is not automatically revoked by erasing the source.
Decision trace
Complete record and tombstone inventory
Technical teaching fixture, not legal advice, a GDPR/DPDP compliance assessment or an operational data-deletion service. All records and identities are fictional. The modeled policies are explicit choices, not statutory deadlines or legal bases. Verification and consent are switches, not identity checks or valid consent collection. Retention runs at days 9 and 20. Requested deletions schedule one backup purge; retention-expired backup copies remain visible and require a separate real-world policy. Tombstones block restoration; they are not anonymization. Holds are a fixture exception, not a legal determination. Real systems also need authorization roles, downstream deletion, backup lifecycle, notices, audit protection and jurisdiction-specific review. No personal information or external service is accessed. Official AICassindra learning resources.
Primary erasure and backup cleanup are separate
Six fictional records begin in both primary storage and backup. The default verified alpha actor requests deletion for alpha subject s1. A prior export on day two contains a1, a2 and a4. Requested deletion on day three removes a1 and a2 while the billing hold retains a4. The export is a separate snapshot and still contains the records. Counting only primary rows would therefore conceal surviving copies.
Scope the requester and the copied records
Requested tenant selects alpha or beta and Actor tenant identifies the caller. Identity verified by the fixture must be enabled and both tenants must match before export or requested deletion is allowed. Requested subject selects s1 or s2; Request scope chooses one subject or the whole selected tenant. Tenant scope also offboards that tenant. Personalization purpose consent controls only the day-one use decision, not export authorization. Minimize export fields removes tenant, subject and age metadata while preserving id, kind and the fictional value; it does not redact that value.
Understand retention and restoration controls
Retention window compares each record’s initial age plus the modeled day against the selected limit at the day-nine and day-twenty sweeps. These sweeps are system-wide background operations, independent of the requesting actor. Backup purge after deletion schedules cleanup after day-three requested deletion. Block restoration of deleted IDs enforces the tombstones; tombstones are still recorded when enforcement is off. Hold billing records against deletion prevents erasure of the billing fixture by both requested deletion and retention sweeps. A retained export remains independent of all these later storage changes.
Inspect ordered snapshots
Play reveals the event snapshots over sixty inspection seconds; Pause holds one, Next event advances, Restart rewinds, Speed changes viewing pace and Inspection scrubs directly. Input changes rebuild and pause the trace. Events are sorted by modeled day, but viewing intervals are uniformly assigned to snapshots rather than elapsed days. No database, personal data or external account is accessed. This is a technical lifecycle policy fixture, not a legal compliance assessment, statutory retention rule or a promise that every copy can be erased.
Reproduce deleted-record resurrection
Set retention to ninety days and disable the billing hold to remove unrelated age and hold effects. Keep backup delay fourteen days and disable tombstone enforcement. At day ten the backup restores the three erased alpha/s1 records; the day-eleven check identifies them as revived. Enable tombstone enforcement and repeat: none of those records return. Alternatively set delay seven so requested-deletion purge occurs on day ten before restore, under this fixture’s same-day ordering.
Distinguish deletion from offboarding
Subject deletion permits a new late record on day twelve because the tenant remains active. Whole-tenant scope marks it offboarded and rejects that write. Changing Actor tenant to beta denies the alpha request but does not suspend the background retention sweeps. Requested-deletion backup purge does not generally purge every retention-expired record. The simulation makes those boundaries visible; it does not implement propagation across arbitrary databases, export recall or permanent prevention of future collection.