Two-Point Legal-Hold Interdiction of Data-Subject Erasure with Race-Window Closure

Executive Summary

JIL Sovereign enforces legal-hold supremacy over a data-subject erasure request by checking hold status twice, at two temporally distinct points: once at initial eligibility determination when the erasure request is received, and again immediately before the suppression operation actually executes. Each check unions two independently-recorded hold-attachment mechanisms - a hold attached directly to the subject or record, and a hold attached to a matter the record is associated with - so a hold recorded through either mechanism, at either check point, is sufficient to interdict the erasure.

The erasure proceeds only if both check points, each independently querying both attachment mechanisms, return "no hold applies."

Problem Statement

A naive erasure-rights implementation checks whether a legal hold applies exactly once - typically at the moment the erasure request is evaluated for eligibility - and executes the suppression sometime later, after queueing, approval workflow, or batch processing. Any gap between that check and actual execution is a race window: if a legal hold is attached to the record during that window - a not-infrequent real-world event, since erasure requests and new litigation holds are handled by different teams operating on different timelines - a single-check system will erase data that, by the time of execution, is actually subject to a hold. This is a spoliation-adjacent failure mode that no single point-in-time check, however well implemented, can prevent.

Why Single-Check Erasure Workflows Fall Short

• Single-check DSAR/consent-management tooling: checks hold eligibility once, executes later, leaving the race window open.
• Matter-only or record-only hold attachment: tooling that checks only one attachment path misses holds recorded through the other.
• Manual legal/compliance review gates: mitigate the race by adding human-review latency, which does not scale and introduces its own delay-based risk.

Technical Architecture

Check Point 1 - Eligibility

Upon receiving an erasure request, the system determines whether the record is currently subject to a legal hold by querying, in union, the hold status attached directly to the subject/record identifier and the hold status of any matter the record is currently associated with.

Check Point 2 - Immediately Pre-Execution

Immediately before the suppression operation is actually carried out - as close to the point of execution as the code path allows, after any intervening queueing or approval delay - the identical union check is re-run against current hold state.

Interdiction

If either check point finds a hold via either attachment mechanism, the erasure is blocked or deferred rather than executed. Only if both check points independently return "no hold" does suppression proceed - closing the race window structurally, since even a hold attached in the interval between the two checks is caught by the second.

Consistency with the Dual-Layer Legal-Hold Mechanism

This claim addresses the erasure-request consumer side of legal-hold enforcement - when a data-subject request is itself blocked by a hold - distinct from but consistent with the application/storage dual-enforcement mechanism described elsewhere in this portfolio that governs ordinary delete operations. Both mechanisms share the same underlying principle: hold status must be re-derived at the moment of consequence, never trusted from an earlier check.

Prior Art Differentiation

Patent Claim