MAP · CONTROL · RECONCILE
Data map: trace primary, backup and export copies
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
Map where every copy of every record lives on each modeled day. The opening run exports full records, so watch the export panel keep copies that primary storage and, later, the backup have deleted.
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.
Three stores, one inventory
Six fictional records start in primary storage and in a backup: a1, a2 and a4 belong to subject s1 of tenant alpha (a4 is billing), a3 to subject s2, and b1 and b2 to tenant beta. A data map answers one question for every record on every day: where do copies exist? The three panels show primary storage, the backup and an export snapshot, and the inventory below lists all of them as text.
Exports copy whole records unless minimized
On day 2 the verified alpha request exports a1, a2 and a4. Minimize export fields is cleared in the opening run, so each exported copy carries id, tenant, subject, kind, age and value. Check it and the copies keep only id, kind and value. Choose Whole tenant / offboarding as Request scope and the export also copies a3, four records in all. The export panel is a copy that has left the system; nothing later in the run revokes it.
Deletion leaves copies behind
The day 3 deletion removes a1 and a2 from primary storage, but both remain in the backup until the day 17 purge and in the export to the end of the run. On day 9 the retention sweep removes b2 from primary storage; no purge rule covers retention expiry, so b2 is still in the backup at day 20. At the end a1 and a2 survive only in the export and b2 only in the backup: copies the primary store no longer shows.
Purge timing and restores
Backup purge after deletion sets when deleted records leave the backup. At 30 days the purge moves to day 33, after the last retention recheck, so a1 and a2 sit in the backup for the whole sweep cycle. At 0 days they leave on day 3. Clear Block restoration of deleted IDs with a 0-day purge: the day 10 restore can only bring back b2, the retention-deleted copy, and the day 11 check flags one revived record. The backup copy that the data map forgot to purge is the one that returns.
Reading the replay and its limits
Play, Pause, Next event, Restart, Speed and the Inspection slider replay ten scheduled days over sixty seconds, one every six seconds; any edit recomputes and rewinds. Requested tenant, Actor tenant, Requested subject and Identity verified by the fixture gate the day 2 export and day 3 deletion: an Actor tenant of Beta or a cleared Identity verified by the fixture denies both, so no export copy exists, and Subject s2 exports only a3. Personalization purpose consent, cleared here, changes only the day 1 use decision. Hold billing records against deletion keeps a4 in primary storage, and Retention window (modeled days) sets the age at which the day 9 and day 20 sweeps remove records; at 30 days the day 9 sweep removes only b2. The model has three stores and one export; real data maps also cover logs, caches, search indexes, model memory, analytics copies and processors. Records, tenants and policies are fictional, and the run is a teaching model, not a compliance assessment.