Skip to content

Soft-Delete Quarantine Window

A reversible-deletion workflow — instantiates Layer Decay and Expiration Management

Makes deletion reversible by first marking a layer deleted and holding it, recoverable, for a grace period sized to how much its loss would hurt — before anything is destroyed for real.

Every other mechanism here decides what to remove; Soft-Delete Quarantine Window makes the act of removing survivable. Its defining move is to split deletion into two steps separated by time: a layer is first only marked deleted — hidden from normal use but physically intact — and held in a recoverable quarantine for a grace window, and only when that window expires is it actually destroyed. This turns the most dangerous, irreversible operation in the lifecycle into a reversible one for as long as the window lasts, so an accidental deletion, a bad rule, or a malicious purge can be caught and undone. Crucially, the window's length is sized to the estimated impact of being wrong: high-blast-radius layers get long quarantines, trivial ones get short.

Example

A SaaS product lets an admin delete a user account. Instead of wiping it, the system soft-deletes: the account is flagged deleted, vanishes from the UI, stops billing — but its data sits intact in quarantine for 30 days, with an audit entry recording who deleted it, when, and why. Two weeks later the admin realises they removed the wrong account; a single "restore" brings it fully back, because nothing was actually destroyed. Contrast a temporary cache entry the same system soft-deletes with a 24-hour window — low impact, short quarantine. A bulk-delete bug that soft-deletes 5,000 accounts is caught by an alert the next morning and rolled back wholesale before the window closes; the same bug against a hard delete would have been an unrecoverable catastrophe. The window's length, set by estimated harm, is what makes each case proportionate.

How it works

Its substance is the two-phase, time-boxed reversibility, with window length tied to impact:

  • On delete, mark, don't destroy — flag the layer deleted, remove it from active use, but retain the bytes.
  • Record a deletion audit entry (who, when, why) so the removal is accountable and a restore is traceable.
  • Size the quarantine window from a deletion-impact estimate — how hard would recovery be, how many dependents, how sensitive — so blast radius sets grace period rather than a flat timer.
  • Offer a first-class restore during the window; on expiry, hand the layer to actual destruction.

Tuning parameters

  • Window length — how long recovery stays possible. Longer catches slow-to-notice mistakes but retains data (and its cost and exposure) longer; this is the core safety-vs-tidiness dial.
  • Impact-to-window mapping — how strongly estimated blast radius stretches the window. Steep mapping protects the crown jewels hard; flat mapping is simpler but under-protects the important and over-holds the trivial.
  • Visibility in quarantine — whether soft-deleted layers are fully hidden, or discoverable to admins/audits. Hidden is cleaner; discoverable aids recovery and forensics.
  • Restore scope — single-item versus bulk rollback of a whole erroneous purge. Bulk restore is what saves you from a runaway rule.
  • Purge trigger — whether the window closes on a fixed timer, on space pressure, or only on explicit confirmation for high-impact layers.

When it helps, and when it misleads

Its strength is that it removes the terror from deletion: it is the safety net that lets aggressive cleanup, automated expiry, and human admins operate without every mistake being fatal, and it is the specific antidote to bulk-delete accidents and malicious wipes. Recoverability, bounded in time, is its whole gift.

Its tensions are real, though. A quarantine window is data that still exists, so it is in direct conflict with hard-delete promises made for privacy or compliance — "we deleted your data" is not true while it sits recoverable, and an over-long window can violate the very obligation the deletion was meant to satisfy. The window also carries cost and attack surface for its whole duration. Its classic misuse is treating soft-delete as disposal — layers pile up in quarantine, never actually purged, so the mechanism meant to bound accumulation becomes a second hoard. The discipline is to guarantee the window truly closes (real destruction on expiry), keep windows no longer than the impact warrants, and reconcile lengths with any hard-delete compliance duty.

How it implements the components

Soft-Delete Quarantine Window realises the recoverability side of the archetype — making removal reversible and accountable for a bounded time:

  • deletion_audit_and_rollback_window — its core: the recorded, time-boxed state from which a deletion can be audited and undone before it becomes permanent.
  • deletion_impact_estimate — it estimates the blast radius of losing a layer and uses that estimate to size the quarantine window proportionately.

It does not certify that nothing depends on the layer in the first place (that gate is Dependency-Safe Delete Check) or leave the permanent post-deletion marker and reference resolution (Tombstone or Deletion Marker); this workflow only holds the recovery window open.

Notes

The window must genuinely close. A soft-delete whose purge step never runs isn't a safety net, it's a leak — every "deleted" layer lives forever in quarantine, and the mechanism defeats the accumulation it was meant to bound. Reversibility is valuable precisely because it is temporary.