What happens to a sealed bundle when the finding inside it is overturned on appeal?

Nothing happens to the sealed bundle itself - it is never altered, deleted, or regenerated. Instead, a supersession-flag entry is appended to a separate append-only table identifying the overturned finding and every previously-generated bundle whose scope covered it.

How does a reader know a bundle is out of date?

Every request to access a sealed evidence bundle is evaluated against the supersession table at read time. If the bundle is flagged, the response includes a superseded annotation and a pointer to the appeal decision, alongside the original, unaltered sealed content.

Why not simply regenerate the affected bundles?

Regenerating or altering a sealed bundle would break the cryptographic seal and any external timestamp or court reliance already placed on the original artifact. Supersession-flag propagation preserves the original bundle's immutability while still making its current legal status discoverable at read time.

Retroactive Appeal-Supersession Propagation Without Mutating Sealed Records

Q: How does this relate to Claim 39's recovery ledger?

The appeal-decision event that triggers a supersession flag is itself one of the lifecycle events already sealed into Claim 39's hash-chained recovery ledger. Claim 40 is the mechanism that fans that single ledger event out to every previously-generated sealed bundle it affects.

Executive Summary

Claim 39 describes a hash-chained ledger of recovery-lifecycle events, including appeal decisions, and an automatic throttle on any detection rule whose findings are overturned too often. Claim 40 addresses a distinct but closely related problem that arises the moment a single appeal decision is recorded: what happens to the - possibly numerous - sealed evidence bundles that were already generated and that included the now-overturned finding, either directly or as part of an aggregated exposure or reporting artifact.

JIL Sovereign's answer is to leave every such sealed bundle completely untouched. When an appeal overturns a finding, the system identifies every previously-generated sealed bundle whose scope covered that finding, and appends a supersession-flag entry to a separate append-only table naming the overturned finding and each affected bundle. Every subsequent read of any sealed bundle checks this table, so a bundle can be permanently immutable and legally current at the same time.

Core Innovation: Propagating the legal effect of an overturned finding across every downstream sealed evidence bundle it touches - via a checked-on-every-read supersession flag - without ever altering, deleting, or regenerating a single one of those sealed bundles.

Problem Statement

Sealed evidentiary records derive their value specifically from being immutable and independently verifiable against their original cryptographic seal and timestamp - the same property that makes them court-admissible also means they cannot simply be edited when new facts emerge. But compliance findings are legally provisional until any applicable appeal window closes, and a single finding is frequently included, directly or through aggregation, in numerous downstream artifacts: individual audit bundles, rolled-up exposure estimates, and reports already delivered to counterparties.

A system that "fixes" an overturned finding by mutating or regenerating those artifacts destroys the very immutability that made them reliable evidence in the first place. A system that does nothing about it leaves stale, legally incorrect sealed bundles circulating indefinitely, with no mechanism connecting the appeal outcome back to everything that already relied on the overturned finding.

Sealed bundles ever mutated, deleted, or regenerated

Supersession table checked on every bundle read

Downstream bundles flagged by one appeal event

Why Existing Approaches Are Insufficient

Document version control: Replaces or versions the document in place - incompatible with a sealed artifact whose evidentiary value depends on its original hash never changing.
Blockchain-anchored document systems generally: Typically anchor a document's integrity but do not maintain a downstream-fan-out index connecting one underlying fact to every artifact that incorporated it.
Manual errata notices: Depend on a person remembering to issue and distribute a correction to every affected recipient - not systematically enforced at read time.

Technical Architecture

Bundle-Lineage Index

Each sealed evidence bundle is registered in a bundle-lineage index at creation time, recording the cluster of findings its scope covers. This index makes it possible to answer, for any given finding, "which already-generated bundles included this."

Supersession Table

Field	Purpose
`overturned_finding_id`	The finding that was reversed on appeal
`affected_bundle_ids[]`	Every previously-generated sealed bundle whose lineage covered the finding
`appeal_decision_ref`	Reference to the appeal-decision event in the Claim 39 recovery ledger
`flagged_at`	Timestamp the supersession entry was appended

Read-Time Evaluation

On any request to fetch a sealed bundle, the system joins against the supersession table. If the requested bundle is flagged, the response includes a superseded annotation and a pointer to the appeal decision, presented alongside the original sealed content - which itself remains byte-for-byte unaltered and independently verifiable against its original seal.

Relationship to Claim 39's Recovery Ledger

The appeal-decision event that triggers a supersession-flag write is itself one of the lifecycle event types already sealed into Claim 39's hash-chained recovery ledger. Claim 40 is the mechanism that fans that single event out to every previously-generated sealed bundle it touches, closing the loop between the ledger of what happened to a finding and the corpus of sealed documents generated along the way that referenced it.

Claim	What It Governs
Claim 39	The tamper-evident record of lifecycle events, and the automatic throttle on a detection rule whose findings lose too often on appeal.
Claim 40	What happens, downstream, to every already-sealed evidence bundle that incorporated a finding once that finding is overturned.

Prior Art Differentiation

Approach	Original Seal Preserved?	Systematic Downstream Fan-Out?	Checked at Every Read?
Document version control systems	No - document replaced	N/A	N/A
Generic blockchain-anchored documents	Yes, per document	No fan-out index	Not typically
Manual errata / correction notices	Yes	Manual, human-dependent	No systematic enforcement
JIL Sovereign Supersession Propagation	Yes, always	Yes, automatic via lineage index	Yes, every read

Patent Claim

Independent Claim 40: A computer-implemented method for propagating the legal effect of an overturned compliance finding without mutating sealed evidence records, comprising: maintaining a plurality of sealed evidence bundles, each cryptographically sealed at creation and thereafter immutable; receiving notice that a specific compliance finding has been overturned on appeal; identifying, from a bundle-lineage index, every previously-generated sealed evidence bundle whose scope included the overturned finding, without altering, deleting, or re-sealing any identified bundle; appending a supersession-flag entry to a separate append-only supersession table, the entry identifying the overturned finding and each affected bundle; and evaluating the supersession table at read time for any request to access a sealed evidence bundle, such that the response reflects the finding's current legal status while the underlying sealed bundle and its original cryptographic seal remain permanently unaltered.