Executive Summary
A compliance verdict is only as evidentiary as an opposing party's ability to challenge it. Most compliance vendors issue verdicts as platform-controlled records - if you dispute the result, you either take the vendor's word for it or pay the vendor to re-run its own analysis. That dependency is exactly what undermines a verdict's value in a genuine dispute. The Court Ready Evidence Bundle (CREB) reproducibility manifest removes the dependency entirely: it publishes everything an adversarial third party needs to independently recompute the verdict from scratch.
The manifest comprises seven distinct hash classes: input-data hashes (one per input record class), a processing-graph hash (encoding every check executed and the order of execution as a canonicalized, hashed directed acyclic graph), a resolved-parameter-set hash, deterministic-floor hashes (one per numeric finding), a language-model invocation gate-log hash, model-card hashes (one per language-model invocation), and a coverage-manifest hash. All seven are canonicalized and signed together by a Byzantine Fault-Tolerant quorum into a sealed receipt. A standalone, open-source replay verifier program then takes the manifest plus independently obtained input data and deterministically reproduces the verdict.
Problem Statement
Reproducible-research practices from academia - archive the input data, the analysis code, and the result manifest - offer a starting template, but applying that template directly to compliance verdicts runs into three obstacles the academic case does not have: the input data is often confidential and cannot simply be published, the analysis logic is proprietary and cannot simply be open-sourced in full, and the verdict-issuance pipeline may itself incorporate non-deterministic components, chiefly language models, whose exact output cannot always be replayed months or years later.
Supply-chain provenance frameworks solve an adjacent but different problem. SLSA and in-toto attest to how a software build artifact was produced; the Reproducible Builds project targets bit-for-bit identical builds from source. None of the three is built to certify that a compliance verdict - a judgment call over confidential records, sometimes mediated by a probabilistic model - can be independently reproduced by a party the issuer does not control.
Why Existing Approaches Fall Short
- SLSA / in-toto: build-provenance frameworks for software artifacts; not designed for compliance verdicts and carry no replay-verifier concept for a judgment call over confidential records.
- Reproducible Builds: targets bit-identical software builds, not verdicts that may legitimately incorporate a probabilistic model.
- Academic reproducibility manifests (e.g., Code Ocean): archive input, code, and output, but include no Byzantine Fault-Tolerant signing, no adversarial-replay design, and no handling for language-model-mediated results.
- Claim 24's sealed verdict record establishes the civil-admissible record concept; this claim narrows specifically to the manifest's seven hash classes and the standalone replay verifier program that consumes them.
Technical Architecture
The Seven Hash Classes
| # | Hash Class | Covers |
|---|---|---|
| 1 | Input-data hashes | One hash per input record class (e.g., claim records, transaction records, entity records). |
| 2 | Processing-graph hash | Canonicalized directed acyclic graph of every check executed and its execution order (topological order, lexicographic tiebreak). |
| 3 | Resolved-parameter-set hash | The exact parameter values the engagement resolved to at run time. |
| 4 | Deterministic-floor hashes | One hash per numeric finding, over the non-LLM floor computation (see Claim 31). |
| 5 | Language-model gate-log hash | Record of every language-model invocation gate decision. |
| 6 | Model-card hashes | One hash per language-model invocation (see Claim 32). |
| 7 | Coverage-manifest hash | Record of the compliance check canon applied to the engagement. |
Each hash is computed as a SHA-256 digest; the aggregate manifest is signed by the Byzantine Fault-Tolerant quorum as part of the sealed receipt. Neither the manifest nor the sealed receipt contains confidential data directly - only hashes of it.
Replay Verifier Flow
A standalone executable is loaded with the manifest, the kernel's quorum public-key set, the regulatory-basis registry, and the remediation-template registry. It obtains the input data independently (from issuer cooperation, a discovery order, or independent acquisition), confirms the input-data hashes match, reconstructs the processing graph, re-executes it under the recorded parameters, recomputes the deterministic floors, checks the language-model gate log and model-cards, and produces a recomputed verdict. It then compares that recomputed verdict to the one recorded in the issuer's sealed receipt and emits either a signed CONFIRMED result or a DISCREPANCY report with a per-finding diff.
Partial Replay and Redacted Inputs
If the verifying party holds only a subset of the input data - for example, transaction records but not entity records - the verifier replays only the checks whose inputs are available and emits a partial-confirmation result identifying exactly which checks were and were not replayed. Sensitive input records may also be replaced by their hashes alone; the verifier confirms the hash match without requiring disclosure of the underlying content unless a specific finding is directly and materially contested.
Prior Art Differentiation
| Approach | Covers LLM-mediated output | Adversarial replay by design | Partial-replay support | BFT-signed manifest |
|---|---|---|---|---|
| SLSA / in-toto | No | No | No | No |
| Reproducible Builds | No | No | No | No |
| Academic manifests (Code Ocean) | No | No | No | No |
| JIL Sovereign CREB manifest | Yes, via gate log + model-card + floor | Yes, no issuer cooperation needed | Yes | Yes |
The defensible combination is the seven specific hash classes covering both deterministic and language-model-mediated aspects of a verdict, paired with a standalone open-source replay verifier that executes entirely outside the issuer's infrastructure and against the issuer's own manifest.