MAP · CONTROL · RECONCILE
Subject export: verify identity and scope
Follow actual fictional records through primary storage, a backup, an export and a restore.
Scroll the diagram left or right to inspect every label.
Your experiment
The opening request is verified for tenant alpha and subject s1, so the day-two snapshot holds a1, a2 and a4. Untick the identity check: no export should exist. Tick it again, then change the requested tenant while keeping the actor tenant fixed. Cross-tenant exports must stay blocked.
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.
Inspect the exact export snapshot
An export is a point-in-time copy selected by tenant and subject. In the default verified alpha/s1 request, day two captures a1, a2 and a4, including the held billing record. The hold protects against deletion and does not exclude a record from this export. Later requested deletion removes primary records but does not mutate the already captured export. The JSON panel shows the actual local copy rather than a fabricated download or a remote data-access request.
Scope the requester and the copied records
Requested tenant selects alpha or beta and Actor tenant identifies the caller. Identity verified by the fixture must be enabled and both tenants must match before export or requested deletion is allowed. Requested subject selects s1 or s2; Request scope chooses one subject or the whole selected tenant. Tenant scope also offboards that tenant. Personalization purpose consent controls only the day-one use decision, not export authorization. Minimize export fields removes tenant, subject and age metadata while preserving id, kind and the fictional value; it does not redact that value.
Understand retention and restoration controls
Retention window compares each record’s initial age plus the modeled day against the selected limit at the day-nine and day-twenty sweeps. These sweeps are system-wide background operations, independent of the requesting actor. Backup purge after deletion schedules cleanup after day-three requested deletion. Block restoration of deleted IDs enforces the tombstones; tombstones are still recorded when enforcement is off. Hold billing records against deletion prevents erasure of the billing fixture by both requested deletion and retention sweeps. A retained export remains independent of all these later storage changes.
Inspect ordered snapshots
Play reveals the event snapshots over sixty inspection seconds; Pause holds one, Next event advances, Restart rewinds, Speed changes viewing pace and Inspection scrubs directly. Input changes rebuild and pause the trace. Events are sorted by modeled day, but viewing intervals are uniformly assigned to snapshots rather than elapsed days. No database, personal data or external account is accessed. This is a technical lifecycle policy fixture, not a legal compliance assessment, statutory retention rule or a promise that every copy can be erased.
Test minimization without confusing it with redaction
Keep the default subject request and inspect the day-two snapshot. With Minimize export fields enabled, each row contains id, kind and value. Disable it: tenant, subject and age reappear, while record membership stays the same. Switch subject to s2: only a3 belongs to alpha/s2. Change Requested tenant to beta while leaving Actor tenant alpha; export is denied and the snapshot stays empty. Matching both tenants to beta allows the beta subject request.
Explain the policy limits
A tenant-wide request expands export membership and also triggers offboarding later in this combined lifecycle fixture. Consent is only an input to its fictional personalization purpose and is not a universal authorization requirement. Exported values can remain identifying even when metadata fields are removed. The lesson implements no identity-verification service, encryption, portable schema standard, legal deadline or determination of applicable rights. Use its record-level evidence to reason about copy boundaries, without interpreting the historical GDPR URL as a compliance certification.