MAP · CONTROL · RECONCILE
Processing inventory: identify purpose and 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
Build a processing inventory for tenant alpha: which purpose used which records, which recipient received an export, and where copies remain after the tenant is offboarded on day 3.
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.
An inventory of processing, not of tables
A record of processing lists, for each purpose, which categories of data are used, who receives copies and where they are kept. In this fixture tenant alpha has profile, prompt and billing records in primary storage and in a backup; one purpose, personalization, uses them; an export sends copies to a recipient; and an offboarding request removes them. The trace is the raw material for each inventory line.
The opening run: consented use and offboarding
Personalization purpose consent is checked and Request scope is Whole tenant / offboarding. On day 1 the purpose check permits use of four alpha records. On day 2 the export copies a1, a2, a3 and a4 to the export snapshot, a recipient outside the system. On day 3 offboarding removes a1, a2 and a3, the billing record a4 stays under Hold billing records against deletion, and the tenant is marked offboarded, so the day 12 late write is denied. On day 17 the backup purge removes a1, a2 and a3 from the backup.
Copies an inventory must still list
After offboarding, primary storage still holds a4 (held) and beta’s b1; the backup still holds a4, b1 and b2; and the export still holds all four alpha records, because erasing the source never recalls a copy already sent. An honest inventory names the export recipient and the hold as remaining locations, rather than stating that the tenant’s data was deleted.
Scope, purpose and authorization
Choose One subject as Request scope: use covers three records, the export copies a1, a2 and a4, the deletion removes a1 and a2, and because the tenant is not offboarded the day 12 late write creates late-1. Requested subject only matters in this subject scope. Clear consent and only the day 1 purpose entry changes to use denied. Set Actor tenant to Beta, so it no longer matches Requested tenant, and use, export and deletion are all denied with no record IDs; clearing Identity verified by the fixture denies them the same way. Retention window, Backup purge after deletion, Block restoration of deleted IDs and Minimize export fields change the same stores as in the other lifecycle lessons.
Reading the replay and its limits
Play, Pause, Next event, Restart, Speed and the Inspection slider replay ten scheduled days in sixty seconds; edits recompute and rewind. The fixture has one purpose, one export recipient and three stores. A real record of processing also documents legal bases, processors, transfers, retention periods and security measures, and must be maintained by people accountable for it. This is a teaching model, not a compliance template or legal advice.