MAP · CONTROL · RECONCILE
Purpose notice versus enforced behavior
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
A declared purpose alone does not enable the personalization operation. Toggle the explicit fixture consent and compare the use decision. Notice drafting, consent collection and legal validity are outside this simulation.
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.
Compare a declared purpose with enforced behavior
A statement that data is used for personalization is not itself an enforcement mechanism. This page lets you test the fixture policy that decides whether that use is permitted. The operation requires a verified actor from the requested tenant plus the explicit personalization-consent switch. The exercise does not draft a notice, prove that a user understood it or determine legal validity. Its contribution is concrete: inspect whether the modeled operation follows the selected technical policy and distinguish that decision from export or deletion.
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.
Make the purpose decision change for one reason
Keep requested tenant alpha, actor alpha and subject s1. With Personalization purpose consent disabled, step to Check purpose: use is denied. Enable consent, step again and inspect the audit: the fixture permits use of three scoped records. Disable identity verification while leaving consent enabled and the use is denied again. Restore verification but select actor beta; the tenant mismatch still denies use. A consent flag cannot override the identity or tenant gate. Change scope to the whole alpha tenant with a verified alpha actor to see the selected inventory grow to four records.
Do not confuse purpose consent with every data operation
Return to a verified alpha actor and subject s1, turn consent off and step to Export request. The same three scoped records can still be exported: this fixture defines export authorization independently from the personalization-use flag. Requested deletion is also independent of that flag. Compare this deliberate distinction with a design that incorrectly uses one global consent boolean for unrelated operations. The model does not represent multiple purposes, notice versions, withdrawal timestamps or a lawful-basis engine, so those questions cannot be answered by a green result here.
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.