Retention: expire records at the policy boundary

Separate expiry eligibility from a sweep

Retention window is an inclusive age cutoff in modeled days. The fixture compares original age plus the current modeled day against that cutoff, but only removes eligible primary records during scheduled sweeps on days nine and twenty. It does not continuously delete records at the instant they become old enough. At day zero, a1 is five days old, a2 fifteen, a3 three, a4 forty-five, b1 six and b2 fifty. Alpha owns the a records; beta owns the b records. These are fictional data values. The same scheduled retention policy runs across both tenants independently of whether a particular export or deletion request is authorized.

Compare ten and thirty modeled days

Keep the opening alpha identities, subject s1, verified identity, tombstones, billing hold and backup delay fourteen. Requested deletion removes a1 and a2 on day three. With Retention window ten, inspect twenty-four seconds, the day-nine sweep: a3, b1 and b2 expire, leaving only held billing record a4 in primary storage. With window thirty, the same sweep removes only b2; a3 and b1 are still young enough to remain. At the end of either run the subject-scoped tenant accepts late-1 on day twelve. Its age at day twenty is eight days, so it remains under either window. The ten-day final primary IDs are a4 and late-1; thirty days additionally retains a3 and b1.

Test the exact cutoff and a held exception

Choose window twelve and keep the opening policies. At day nine a3 reaches exactly twelve days and expires. Increase the window to thirteen: the day-nine sweep now retains a3. Do not compare only final counts, because by day twenty a3 is twenty-three days old and eligible under both settings. Hold billing records against deletion exempts a4 from requested deletion and both retention sweeps. Disable it to remove a4 at the authorized day-three deletion. To isolate scheduled expiry from that request, disable Identity verified by the fixture: requested deletion and export are denied, but the global sweeps still run. A hold is a deliberate fixture exception, not a legal determination or a production policy recommendation.

Choose the request boundary

Requested tenant identifies the data owner. Actor tenant must match, and Identity verified by the fixture must be enabled, before export or requested deletion can occur. Requested subject selects s1 or s2 only when Request scope is One subject. Whole tenant ignores that selector and assumes a tenant operator; the fixture does not implement role validation. Personalization purpose consent gates the day-one use decision independently of deletion and export. Minimize export fields removes tenant, subject and age from the copied fields, but does not anonymize the record value. Disable it to inspect the full exported records.

Make a deleted record return

Select Whole tenant, matching alpha identities, retention ninety and disable the billing hold. Disable Block restoration of deleted IDs and leave backup delay fourteen. Four alpha records are deleted on day three, return at the day-ten restore, and appear in the day-eleven failure check. Offboarding still blocks late-1: denying new writes does not remove restored old records. Set backup delay seven: the purge occurs on day ten before restore, so these records cannot return. At delay eight the purge is day eleven, too late to prevent the day-ten restore. Enabling tombstones blocks restoration even while backup copies remain. These exact event-order choices are declared fixture assumptions.

Track copies independently

The backup begins with the same six records. Backup purge after deletion applies only to requested deletions, so expiration in primary storage does not purge retention-expired backup records. The export is a separate day-two snapshot that is never retracted by later deletion. Block restoration of deleted IDs uses tombstones to prevent an old backup from returning erased records. The learner inventory intentionally exposes all fictional stores, not an authorized client response. A real retention design needs separate rules for exports, backups and downstream stores; this experiment does not implement a database TTL engine, legal deadlines, authentication or remote deletion. Actual cleanup scheduling and failure recovery can delay physical removal.

Control the replay and record evidence

Play reveals ten precomputed events over sixty inspection seconds, equally spaced by event rather than proportional to modeled days. Pause freezes elapsed time; Next event pauses at the next operation; Restart returns to the opening inventory while preserving policy and speed. Inspection scrubs the sequence. Speed selects quarter, half, normal or double pace and settles the previous interval before changing rate. Editing a policy restarts without autoplay, and a hidden tab pauses. Read the modeled day in the caption before comparing outcomes; backup-delay changes can reorder events and therefore change their inspection positions.

Inspect and record the evidence

The diagram keeps readable labels inside a keyboard-scrollable region on narrow screens. The caption, decision trace and expandable complete inventory expose the same records as text. Capture baseline saves the visible comparison; Replace baseline refreshes it and Clear baseline removes it. The notebook persists your observations locally; Export notes downloads them. Expand experiment enters fullscreen and Exit full screen returns. Compare the record IDs at the requested deletion, restore and late-write steps rather than relying on the final count alone. Real offboarding must also handle credentials, in-flight jobs, downstream stores and failure recovery; this deterministic single-process fixture models none of those mechanisms.