How does the system prevent double-spending a prepaid unit under concurrent load?

The claim and the decrement of remaining capacity happen as a single atomic database update, so concurrent verdict requests cannot both successfully claim the same unit.

What happens if billing succeeds but a downstream step, like signing, later fails?

A narrow compensating-release path exists specifically for that case: it increments the customer's remaining capacity back up by one, restoring the unit that was claimed but never actually consumed by a completed, signed verdict.

Billing-Lineage-and-Compliance Unified Attestation

Q: What does it mean for billing and compliance to share one attestation?

The vendor ID, purchase-order number, billing reference, and the specific prepaid-grant unit consumed for a transaction are folded into the exact same JSON payload that gets SHA-256 hashed and cryptographically signed alongside the fraud-compliance verdict itself. Any alteration to the billing fields after the fact invalidates the same signature that protects the verdict data - they cannot be tampered with independently.

Q: What happens if a customer's prepaid billing pool is exhausted?

The engine atomically claims one unit from the customer's prepaid grant before running any checks. If no active grant has remaining capacity, the request fails closed with a 402 Payment Required response rather than issuing a verdict on credit - a verdict is never generated without a successfully claimed billing unit (or an explicit open-evaluation mode for legacy/dev calls carrying no billing context at all).

Executive Summary

JIL Sovereign's fraud-attestation engine treats billing integrity and compliance-verdict integrity as one problem rather than two. Before evaluating any check against a transaction, the engine atomically claims one unit from the requesting vendor's prepaid-grant billing pool via a single database update that cannot be double-spent under concurrent load; if no active grant has remaining capacity, the engine fails closed with a payment-required response rather than issuing a verdict on credit.

Once a unit is successfully claimed, the resulting billing lineage - vendor ID, purchase-order number, billing reference, and the specific grant ID consumed - is folded directly into the same canonical JSON payload that gets hashed and cryptographically signed alongside the fraud-compliance verdict itself. There is no separate billing record and separate compliance signature to independently tamper with; a single signature covers both.

Core Innovation: Billing lineage is not merely logged alongside the verdict - it is a signed field inside the same attestation payload, so any post-hoc alteration of which purchase order or grant paid for a given verdict breaks the identical cryptographic signature that protects the fraud-finding data.

Problem Statement

Payment-integrity platforms that bill per-check or per-verdict face a quiet but real risk: the billing record (which purchase order paid for which evaluation) and the compliance record (what the evaluation found) typically live in separate systems, secured by separate mechanisms, if secured cryptographically at all. That separation creates two failure modes - a customer or an internal actor could dispute which contract a verdict was billed against without any cryptographic way to prove the pairing, and in a chargeback or audit scenario there is no single artifact that simultaneously proves both "this specific PO paid for this specific check" and "this specific check produced this specific result."

Why Separate Billing and Compliance Records Fall Short

Independently mutable records: a billing database row and a compliance-verdict row, signed or logged separately, can drift or be altered independently without breaking each other's integrity guarantee.
Credit-based billing on compliance platforms: issuing a verdict before confirming payment capacity risks a customer consuming compliance services the platform cannot later collect for, and complicates audit trails.
No atomic double-spend protection: a naive "check remaining balance, then decrement" pattern is vulnerable to a race condition under concurrent requests, allowing more units to be consumed than a grant actually authorizes.

Technical Architecture

Atomic Grant Claim, Fail-Closed on Exhaustion

Step	Behavior
1	Resolve vendor ID and purchase-order number (or billing reference) from the request
2	Atomically claim one unit from the matching active prepaid grant via a single SQL update - concurrent requests cannot double-claim the same unit
3	If no active grant has remaining capacity, fail closed with a 402 Payment Required response naming the exhausted vendor/PO, without evaluating any checks
4	If neither a vendor ID nor a PO number is supplied, operate in an explicit open-evaluation mode reserved for legacy/development calls that carry no billing context
5	On an infrastructure error during the billing lookup itself, fail closed with a distinct billing-lookup-error response rather than silently proceeding without billing verification

Billing Lineage Bound Into the Signed Attestation

The claimed grant ID, vendor ID, purchase-order number, billing reference, and billing mode (claimed vs. open-evaluation) are assembled into a billing-lineage object that is embedded directly in the same canonical payload used to compute the verdict's attestation hash - alongside the verdict outcome, aggregate and per-category scores, hard blocks, and per-signal evidence hashes. That combined payload is what gets SHA-256 hashed and cryptographically signed. Because the billing fields are inside the hashed and signed structure rather than appended afterward, any post-hoc edit to the recorded PO number or grant ID invalidates the signature over the entire attestation, not just a separate billing checksum.

Compensating Rollback

If a downstream step after a successful claim - most notably cryptographic signing - fails, a narrow compensating-release path restores the claimed unit to the grant's available capacity, ensuring a customer is never billed for a verdict that was never actually completed and signed.

Prior Art Differentiation

Approach	Billing and Verdict Cryptographically Linked?	Fail-Closed on Exhausted Billing?	Atomic Double-Spend Protection?
Separate billing system + separate compliance log	No	Varies	Varies
Post-hoc billing reconciliation against a compliance log	No - reconciled after the fact, not cryptographically bound	N/A	N/A
JIL unified attestation	Yes - one signature covers both	Yes - 402 before any check runs	Yes - single atomic SQL claim

Patent Claim

Independent Claim 124: A computer-implemented method for cryptographically unifying billing provenance with a compliance verdict comprising: prior to evaluating a set of compliance checks against a transaction, atomically claiming a single unit of capacity from a prepaid billing grant associated with a requesting vendor via a single database write operation that prevents concurrent requests from claiming the same unit; upon successful claim, generating billing-lineage data comprising a grant identifier, a vendor identifier, and a purchase-order or billing reference; assembling the billing-lineage data and a set of compliance-check evaluation results into a single canonical payload; computing a cryptographic hash of the canonical payload and generating a digital signature over that hash, such that the billing-lineage data and the compliance-check evaluation results are protected by one signature; and, when no prepaid grant has remaining capacity, declining to evaluate the compliance checks and returning a payment-required response prior to generating any compliance verdict.