What events go into the hash-chained recovery ledger?

Every lifecycle event associated with a compliance finding - finding issuance, demand, appeal filing, appeal decision, payment, and write-off - is appended as its own hash-chained, hybrid-signed ledger entry, forming a tamper-evident record of the entire recovery lifecycle.

Is the throttling decision itself auditable?

Yes. The throttling determination and the overturn rate that triggered it are appended to the same hash-chained ledger as every other lifecycle event, so the correction is as tamper-evident and reviewable as the findings it was triggered by.

Does this claim make any clinical or medical-necessity determination?

No. The claim describes a ledger and rule-management architecture for the administrative recovery lifecycle - it records events and manages which detection rules remain in production, without making any clinical judgment.

Hash-Chained Sealed Recovery Ledger with Appeal-Overturn Rule Throttling

Q: How does appeal-overturn rule throttling work?

The system continuously computes, for each detection rule, the proportion of that rule's findings that are reversed on appeal. If a rule's overturn rate crosses a predetermined threshold, the rule is automatically suspended from generating new findings and routed to human review - a feedback loop from real-world appeal outcomes back into the detection system.

Executive Summary

Compliance-finding recovery - the process by which a finding becomes a demand, is appealed, decided, and either paid or written off - generates a long paper trail across multiple parties over months or years. JIL Sovereign's recovery ledger appends every lifecycle event as its own entry in a hash chain, each entry cryptographically linked to the one before it and signed with a hybrid classical/post-quantum signature, producing a tamper-evident record of the entire lifecycle.

Layered on top of that ledger is a self-correcting feedback loop: the system continuously computes, per detection rule, the rate at which that rule's findings are subsequently overturned on appeal. A rule whose overturn rate crosses a predetermined threshold is automatically throttled - suspended from generating new findings and routed to human review - before it can keep producing findings a real adjudicator keeps rejecting. The throttling decision itself is appended to the same hash chain, so the correction is as auditable as the findings that triggered it.

Core Innovation: A tamper-evident, hash-chained ledger of the entire recovery lifecycle, paired with an automatic per-rule appeal-overturn throttle that pulls a poorly calibrated detection rule from production the moment its real-world appeal record crosses a threshold - with the correction itself sealed into the ledger.

Problem Statement

Overpayment recovery programs operate at meaningful scale and duration - Medicare's Recovery Audit Program alone has been publicly reported by CMS and the HHS Office of Inspector General to have identified and corrected well over ten billion dollars in improper payments since the program's inception. Case lifecycles for individual findings, especially those that reach an Administrative Law Judge, have historically been reported to run into years of pendency due to appeals backlogs.

Conventional case-management systems store this lifecycle in ordinary, mutable database rows: if a record is altered after the fact, whether by accident, a bug, or bad intent, there is no cryptographic way to detect that it happened. Separately, most detection systems have no automatic feedback loop from appeal outcomes back to the rule that generated the original finding - a poorly calibrated rule can keep generating findings that lose on appeal indefinitely, with no structural mechanism forcing a review.

$10B+

Improper Medicare payments identified by Recovery Audit Contractors since program inception (CMS / OIG)

3+ yrs

Historically reported median pendency for Medicare ALJ-level appeals

Hash chain covering the full lifecycle, per finding

Why Existing Approaches Are Insufficient

Ordinary case-management databases: Rows can be edited or deleted without leaving a cryptographically detectable trace.
Manual quality-review cycles: Reviewing rule performance is typically a periodic, human-scheduled process rather than a continuous, automatic one - by the time a bad rule is caught manually, it may have generated many more losing findings.
Detection systems with no appeal feedback loop: Most fraud/audit rule engines have no structural connection between an appeal's outcome and the future behavior of the rule that produced the original finding.

Technical Architecture

Hash-Chained Ledger Entries

Field	Purpose
`event_payload`	The lifecycle event itself (finding issued, demand sent, appeal filed, appeal decided, payment recorded, write-off recorded)
`prev_hash`	Hash of the immediately preceding ledger entry
`entry_hash`	`H(prev_hash \|\| event_payload)` - links this entry into the chain
`signature`	Hybrid classical + post-quantum signature over the entry

Per-Rule Appeal-Overturn Rate

For each detection rule, the system computes overturn_rate = overturned_findings / total_appealed_findings. When a rule's overturn rate crosses a predetermined threshold, the rule is automatically suspended from generating new findings and routed to a human review queue. The throttle event - including the rule identifier and the rate that triggered it - is appended to the same hash-chained ledger.

Self-Correcting Detection Loop

Step	Action
1	Detection rule generates a finding; finding enters the recovery lifecycle.
2	Finding may be appealed by the affected party.
3	Appeal outcome is recorded as a lifecycle event in the hash-chained ledger.
4	The originating rule's appeal-overturn rate is recalculated.
5	If the rate crosses the threshold, the rule is automatically throttled and routed for human review.
6	The throttle event is itself sealed into the ledger.

Because every step - including the correction - lives in the same tamper-evident chain, the system produces an auditable record not only of what the detection rules found, but of how the system caught and corrected its own miscalibration.

Prior Art Differentiation

Approach	Tamper-Evident Ledger?	Automatic Appeal Feedback?	Correction Itself Auditable?
Generic case-management / CRM systems	No (mutable rows)	No	N/A
Periodic manual rule-quality review	Depends on system	Manual, delayed	Rarely formalized
General ML model drift monitoring	No inherent ledger	Statistical, not appeal-specific	Not typically legally-admissible
JIL Sovereign Recovery Ledger	Yes, hash-chained, hybrid-signed	Yes, automatic per-rule	Yes, sealed into the same chain

Patent Claim

Independent Claim 39: A computer-implemented method for maintaining a tamper-evident record of a compliance-finding recovery lifecycle, comprising: appending, for each lifecycle event associated with a compliance finding, an entry to an append-only ledger, each entry comprising an event payload, a cryptographic hash of the immediately preceding entry, and a hybrid cryptographic signature, such that the entries form a verifiable hash chain; computing, for each rule in a set of detection rules, an appeal-overturn rate representing the proportion of that rule's findings reversed on appeal; and automatically throttling a rule whose computed appeal-overturn rate crosses a predetermined threshold by suspending the rule from generating new findings pending human review, wherein the throttling determination and its triggering rate are themselves appended to the hash-chained ledger.