MAP · CONTROL · RECONCILE
Audit trail: reconcile actions with record effects
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
Pause after each event. Reconcile record IDs in the audit with the primary, backup and export panels. A denied request must leave a denial entry without creating the requested export or deletion.
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.
Read the audit trail as claims about records
Each audit entry names an action, a modeled day, a sentence and the record IDs it says were affected. The experiment is to reconcile those claims with the primary store, the backup and the export snapshot shown at the same moment. Six fictional records exist on day 0: a1, a2, a3 and a4 belong to tenant alpha, b1 and b2 to beta. With the opening settings the day 2 export entry lists a1, a2 and a4, the day 3 requested-deletion entry lists only a1 and a2, and its sentence states that one held record was retained. That held record is a4, the billing record kept by Hold billing records against deletion.
Every control changes what the trail must explain
Requested tenant and Requested subject choose whose records the request names; Request scope widens it from one subject to whole-tenant offboarding. Actor tenant and Identity verified by the fixture decide authorization: a beta actor asking about alpha produces export-denied and delete-denied entries with no record IDs and no store change. Personalization purpose consent only changes the day 1 purpose check. Minimize export fields removes tenant and subject fields from exported copies. Retention window and Backup purge after deletion move the sweep and purge outcomes; Block restoration of deleted IDs and the billing hold change what the day 10 restore may bring back.
Make the trail record a failure
Clear Block restoration of deleted IDs and keep the other defaults. The day 10 restore entry now lists a1, a2 and b2 as restored, and the day 11 resurrection check reports that three deleted records are back in primary storage. The deletion entries are still true statements about day 3; the later entries show that they are no longer the current state. At the end a1 is still present because its age plus twenty days stays below the thirty-day window, while a2 and b2 are swept again on day 20. Re-enable blocking and the restore entry instead reports three deleted records blocked.
Inspect the backup window
With a fourteen-day purge delay, a1 and a2 leave primary storage on day 3 but remain in the backup until the day 17 backup-purge entry. Set the delay to zero: the purge entry moves to day 3. Then also clear restoration blocking. The retention-expired b2 has no purge rule, so the day 10 restore still returns it and the day 11 check flags one revived record. The purge rule here only covers requested deletions, which is why the trail and the stores must be compared rather than trusted separately.
Limits of this audit model
Play, Pause, Next event, Restart, Speed and the Inspection slider replay ten scheduled days over sixty seconds; edits recompute and rewind. The trail is an in-memory list written by the same code that changes the stores. It is not tamper-evident: there is no hash chain, signature, write-once storage, clock source or separate verifier, and nothing stops a faulty process from omitting an entry. Records, tenants and policies are fictional and this is not legal advice about privacy or retention law.