MAP · CONTROL · RECONCILE
Privacy controls: scope, minimization and recovery
Follow actual fictional records through primary storage, a backup, an export and a restore.
Scroll the diagram horizontally to inspect every label. The panels below give the same state as text.
Your experiment
Change one control at a time: verification, tenant, export fields, retention, backup purge and tombstone protection. Explain the distinct boundary each control enforces.
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.
Separate scoped access, exported fields and recovery safety
Privacy-related controls act at different points in a data lifecycle. This fixture tracks six fictional records by identifier through primary storage, an independent backup and an export snapshot. Identity and tenant switches gate the request, field minimization changes the exported shape, and tombstone enforcement protects restoration. None replaces the others. The visible inventories let you compare actual records rather than an opaque evidence score or a generic checklist. There is no collection of real personal information.
Choose the actor and request scope
Requested tenant selects alpha or beta; Actor tenant identifies the caller. Identity verified by the fixture must be enabled and those tenants must match before export or requested deletion is allowed. Requested subject selects s1 or s2. Request scope chooses that subject or the whole selected tenant; tenant scope also offboards the tenant after the requested deletion. Personalization purpose consent affects only the simulated purpose-use decision on day one. It does not grant cross-tenant access or prevent an otherwise authorized export. Minimize export fields removes tenant, subject and age metadata while retaining id, kind and the fictional value; it does not redact the value text itself.
Control retention and restoration
Retention window is compared with each record’s initial age plus the modeled day during the day-nine and day-twenty sweeps. Those sweeps are a system-wide background policy, separate from the actor’s scoped request. Backup purge after deletion schedules requested-deletion cleanup after day three; zero performs it on day three. Block restoration of deleted IDs controls whether restoring a backup may reintroduce previously erased IDs. Hold billing records against deletion keeps the billing fixture out of deletion and retention erasure. A tombstone records an erased identity even when restoration enforcement is disabled, allowing the later check to detect its resurrection.
Test authorization and field minimization independently
Start with requested tenant alpha, actor alpha, subject s1 and subject scope. Step to Export request: a1, a2 and a4 are copied. Minimize export fields removes tenant, subject and age metadata but preserves each value, so it is not content redaction or anonymization. Disable minimization and inspect the additional keys. Change actor tenant to beta and replay: export is denied and requested deletion does not erase alpha records. Background retention still runs later because it is a separate system policy, not an action authorized by the mismatched actor.
Compare subject deletion with offboarding
Set both tenants to alpha, enable identity verification and choose Whole tenant scope. Export includes a1, a2, a3 and a4. Requested deletion removes the non-held alpha records and marks the tenant offboarded; the day-twelve late write is denied. Switch back to One subject and keep s1: a3 is outside the requested deletion, and the active tenant may receive a fresh late record. A past subject deletion in this fixture is not a permanent prohibition on collecting new data. Keep the billing hold enabled to observe a4 surviving the deletion.
Reproduce resurrection and the purge boundary
Disable tombstone enforcement, disable the billing hold and set retention to ninety days so later age-based removal does not obscure the experiment. Keep backup delay fourteen. At day ten, the deleted alpha/s1 records return from backup and the day-eleven check reports the failure. Change delay to seven: purge occurs on day ten before restore under this fixture’s explicit same-day event order, so those requested-deletion records cannot be resurrected. Retention-expired backup records are not generally purged by this requested-deletion cleanup; that is a limitation, not a promise that all copies disappear.
Inspect snapshots and avoid broader guarantees
Play reveals the ordered event snapshots across sixty inspection seconds. Pause holds a snapshot; Next event advances; Restart rewinds; Speed changes inspection pace; Inspection scrubs. Parameter edits rebuild the trace and pause it. Events are ordered by modeled day, not uniformly spaced real days. The source records, export, tombstones and audit entries are fictional, and no database or cloud service is contacted. There is no encryption, real secret detection, legal retention determination, export recall or propagation across arbitrary storage systems. Subject deletion does not ban future collection: the active tenant can receive a new record on day twelve. Tenant offboarding blocks that late write in this model.