Executive Summary
JIL Sovereign's verdict engine is designed to run across more than one cloud compute substrate - a managed-container service inside a data-cloud tenant, a lakehouse workspace with its own governance catalog, and a hardware-rooted confidential-computing enclave bound to a sovereign jurisdiction. A verdict produced on any of these must be independently verifiable as the product of the canonical verdict logic, regardless of which substrate produced it, while each substrate's own compliance attestation - its deployment manifest, its VPC isolation proof, its hardware attestation - must also remain checkable on its own terms.
The manifest design that makes both possible splits into two layers. An inner hash is computed only from substrate-independent components - the input record's content hash, the verdict-check catalog version, the reference-data manifest hash, the verdict-logic version, and the aggregation-rule version - so it is byte-identical regardless of which substrate produced it. An outer envelope wraps that inner hash with the substrate identifier, the substrate's own compliance attestation evidence, and the substrate's signing-key signature, without modifying the inner hash itself.
Problem Statement
A naive design embeds substrate-specific identifiers - account locators, workspace IDs, enclave IDs - directly into the verdict body's hash. That destroys cross-substrate reproducibility: the identical verdict computed on two different substrates hashes differently purely because of where it ran, not because the underlying logic disagreed. The opposite naive design strips substrate identifiers out of the verdict entirely, which destroys compliance attestation instead - the verdict body no longer carries any proof of which substrate's compliance perimeter it was computed under, or that perimeter's specific guarantees.
Why Existing Approaches Fall Short
- Reproducible-build systems (Bazel, Nix): guarantee byte-identical binaries across build machines - build-time reproducibility, not the output of a compute job run against live data on heterogeneous substrates with different SQL dialects, concurrency semantics, and storage formats.
- Content-addressable storage (IPFS, Git): content hashes identify storage objects, but say nothing about cross-substrate compute attestation.
- Verifiable computation primitives (zkSNARKs, STARKs): cryptographically prove computation correctness, but are substantially heavier-weight than manifest-based replay verification and are not deployed in payment-integrity workloads at this scale.
- Naive substrate-tagged hashing: either pollutes the reproducibility hash with substrate identifiers or discards compliance attestation entirely - the two-layer split is the alternative to both failure modes.
Technical Architecture
The Five-Component Manifest
| Component | Content |
|---|---|
| Input record schema + content hash | The canonical, versioned schema of the input record plus a SHA-256 of its canonicalized contents |
| Verdict-check catalog version | Semantic version plus content hash of the named check catalog (332 checks at time of filing) in force when the verdict was produced |
| Reference-data manifest hash | Hash-of-hashes over every reference-data snapshot consulted during verdict generation |
| Verdict-logic version | Engine semantic version plus git commit hash, with build provenance attested |
| Aggregation-rule version | Version identifier of the rule used to combine per-check results into a verdict aggregate |
Inner Hash Computation
The five components are canonicalized into a deterministic byte sequence - fixed lexicographic component order, deterministic JSON serialization with sorted keys and no whitespace, fixed separator bytes - and the SHA-256 of that sequence is the inner hash. Because none of the five components reference a substrate-specific identifier, the inner hash is identical across substrates for the same underlying computation.
The Outer Envelope
The outer envelope wraps the inner hash without modifying it, and carries the substrate identifier, the substrate-specific compliance attestation evidence appropriate to that substrate, and the substrate's own signing-key signature over the envelope contents. A verifier extracts and checks the inner hash independently of the substrate-specific attestation.
Substrate-Specific Outer Envelopes
| Substrate | Outer-Envelope Attestation Evidence |
|---|---|
| Managed-container service inside a data-cloud tenant | Deployment-manifest hash, customer-account locator, customer-VPC isolation attestation |
| Lakehouse workspace with a governance metadata catalog | Federated-sharing-grant manifest hash, source/recipient workspace service-principal identifiers, compute-permission attribute value |
| Hardware-rooted confidential-computing enclave bound to a sovereign jurisdiction | Hardware attestation signature, proof-of-residency manifest hash, cross-jurisdiction-egress denial hash |
Two Independent Verification Protocols
Cross-substrate replay verification replays a verdict on a second substrate using the manifest as input and compares the resulting inner hash, byte-for-byte, against the original. Compliance attestation verification instead reads the outer envelope and checks the substrate-specific evidence against that substrate's own signing key. The two protocols are independent: replay confirms the verdict logic itself is consistent across substrates; attestation confirms a given deployment honored its own compliance perimeter. Either may be checked, and may succeed, without the other.
Prior Art Differentiation
| Approach | Cross-Substrate Byte-Identical Hash? | Preserves Substrate Attestation? | Compute-Output Reproducibility? |
|---|---|---|---|
| Reproducible-build systems (Bazel, Nix) | N/A - build artifacts, not compute output | N/A | Build-time only |
| Content-addressable storage (IPFS, Git) | Identifies objects, not computations | No | No |
| zkSNARK / STARK verifiable computation | Cryptographic proof, heavyweight | Not inherently | Yes, but not deployed at this scale here |
| JIL Sovereign substrate-independent manifest | Yes - inner hash excludes substrate identifiers | Yes - outer envelope per substrate | Yes - deterministic canonicalized manifest |