← Back to Patent Claims
Patent Claim 024 All Patents →

Civil-Admissible Cryptographically-Sealed Verdict Record

Multi-jurisdiction BFT-quorum-signed verdict records purpose-engineered to satisfy Federal Rules of Evidence 901 and 902(14), verifiable by any third party without issuer cooperation.

Patent Claim JIL Sovereign July 2026 Claim 24 of 157

Executive Summary

Institutional settlement and compliance decisions increasingly need to survive scrutiny in a courtroom, not just an audit. A verdict that only the issuing platform can vouch for is a liability the moment a fraud claim, False Claims Act action, or regulatory investigation turns on whether that verdict is genuine. JIL Sovereign's sealed verdict record is a compliance-verdict architecture engineered from the ground up around two specific evidentiary standards - Federal Rule of Evidence 901 (authentication) and Rule 902(14) (self-authenticating certified electronic records) - rather than treated as a byproduct of a signature or a blockchain timestamp.

A verdict generation engine produces a verdict code from a fixed, predetermined set. A composition module assembles a sealed record from at least six structural elements: a human-readable executive summary, a structured subject/counterparty/amount/asset section, a cryptographic attestation block carrying a Byzantine Fault-Tolerant quorum signature from validators spread across multiple legal jurisdictions, a timestamped distributed-ledger anchor, a machine-readable verification manifest, and a scannable verification-link code. A sealing module renders the whole thing as an archival-grade document artifact. A public verifier service, hosted at a domain distinct from the issuer, checks the quorum signature against nothing but the validators' published public keys.

Core Innovation: A verdict-record structure and public-verifier architecture chosen specifically to satisfy FRE 901 and 902(14) - independent cryptographic verifiability, timestamped ledger anchoring, and multi-jurisdictional quorum signing combined into one archival document, verifiable by a third party without ever contacting the issuer.

Problem Statement

Digital settlement and compliance records fall into two camps, and neither is engineered for the courtroom. Single-signer e-signature platforms (DocuSign, Adobe Sign) authenticate that a specific party signed a document, which satisfies FRE 901 for that one signer, but they depend on trusting that platform's key custody and offer no independent third-party verification path. Blockchain-notarization services (OriginStamp, NotaryChain, Stampery) anchor a document hash to a public chain to prove the document existed at a point in time, but they are not archival-format artifacts, carry no multi-jurisdiction quorum signature, and ship no machine-readable verification manifest a third party can programmatically check.

No prior approach combines all of the elements a 902(14) self-authenticating record actually needs: multi-jurisdiction Byzantine Fault-Tolerant quorum signing, timestamped distributed-ledger anchoring, an open-source reference verifier running at a domain the issuer does not control, an archival document format with an embedded cryptographic manifest, and explicit configuration to the specific text of FRE 901 and 902(14) rather than a general claim of "tamper-evidence."

6
Required structural elements per sealed record
2
Federal Rules of Evidence explicitly targeted (901, 902(14))
0
Issuer-controlled private keys needed to verify a record

Why Existing Approaches Fall Short

  • DocuSign / Adobe Sign: single-signer authentication only; no independent multi-party verification; no embedded verification manifest.
  • OriginStamp / NotaryChain / Stampery: proof-of-existence anchoring only; not an archival-format artifact; no multi-jurisdiction quorum; not built for FRE 902(14).
  • Raw blockchain transaction receipts: Merkle inclusion proofs establish existence, not evidentiary trustworthiness for a non-technical fact-finder; no human-readable summary; no embedded verifier link.
  • EU eIDAS qualified electronic signatures: a solid regulatory framework for single-party digital signatures, but it does not address multi-party BFT quorum architectures or an issuer-independent verifier.

Technical Architecture

Sealed Record Structure

The composition module assembles every sealed verdict record from the same fixed set of sections, so a reviewer - technical or not - always knows where to look.

ComponentFunction
Executive summaryPlain-English description of the verdict and its basis, written for a non-technical reader (judge, arbitrator, auditor).
Subject / counterparty / amount / asset sectionStructured facts of the transaction under verdict.
Cryptographic attestation blockByzantine Fault-Tolerant quorum signature from validators distributed across a plurality of legal jurisdictions; each signature carries validator ID, signature value, and public-key fingerprint.
Timestamped ledger anchorChain identifier, block number, transaction hash, and timestamp for the anchoring transaction.
Machine-readable verification manifestStructured (JSON) record of hashes, signature sets, and ledger references enabling programmatic verification.
Scannable verification-link codeA code sized for reliable optical scanning that encodes the public verification URL.

Sealing and Archival Format

The sealing module renders the assembled record as an archival-grade document artifact - the preferred embodiment uses PDF/A (ISO 19005), which guarantees long-term preservation properties: no external dependencies, embedded fonts, no interactive elements, no executable content. The cryptographic manifest is embedded directly as structured metadata inside the file, and the document itself carries a digital signature covering all content.

Public Verifier Service

Verification runs at a domain distinct from the issuing platform - an architectural separation that removes the issuer from its own verification loop. Given a scan of the verification code, the service retrieves the anchored attestation from the distributed ledger, checks each quorum signature against the signing validators' registered public keys, verifies the document's archival integrity, confirms the ledger anchor, and returns a result showing authenticity, the signing set, and the timestamp. The verifier's source is open for independent audit, and it never touches issuer-held key material - every check runs against public keys alone.

Quorum Design

The cryptographic attestation block is designed around a Byzantine Fault-Tolerant quorum threshold - the target topology calls for signatures from at least 14 of a 20-validator set, distributed across a target of 13 or more legal jurisdictions, so that no single legal system can compel the signing of a false verdict. This is the network's design target for the quorum architecture, not a representation of the validator set's current live size.

Composable with Claim 25: for high-volume retroactive audits, a single sealed verdict record of this type can serve as the parent record in the inherited-quorum architecture, letting one quorum signature cover thousands of independently verifiable child findings.

Prior Art Differentiation

ApproachMulti-jurisdiction quorumArchival formatIssuer-independent verifierConfigured for FRE 902(14)
DocuSign / Adobe SignNo (single signer)NoNoNo
OriginStamp / NotaryChain / StamperyNoNoPartialNo
Raw blockchain receiptsNoNoYesNo
EU eIDAS qualified signaturesNo (single signer)VariesNoNo (EU framework)
JIL SovereignYes, target 14-of-20 (planned Q4 2026 target) across 10 policy zonesYes, PDF/AYes, distinct domainYes, by design

The differentiating move is not any single element - PDF/A, digital signatures, and blockchain anchoring are each individually well known - but their combination chosen specifically around the text of FRE 901 and 902(14), plus an eight-section preferred structure sized for rapid review by both machines and non-technical readers, plus a verification-link code sized for reliable optical scanning at typical print sizes.

Patent Claim

Independent Claim 24: A computer-implemented system for generating a cryptographically-sealed settlement verdict record usable as civil-admissible evidence, comprising: a verdict generation engine configured to receive a payment-authorization or compliance-determination request and produce a verdict code from a predetermined set of verdict codes; a composition module configured to assemble a sealed verdict record comprising at least a human-readable executive summary, a structured section enumerating subject, counterparty, amount, and asset, a cryptographic attestation block comprising a Byzantine Fault-Tolerant quorum signature from validators distributed across a plurality of legal jurisdictions, a timestamped anchor to a distributed ledger, a machine-readable verification manifest, and a scannable verification-link code encoding a public verification URL; a sealing module configured to render the sealed verdict record as an archival-grade document artifact with the verification manifest embedded as structured metadata; and a public verifier service, hosted at a domain distinct from the issuer, configured to retrieve the anchored attestation and independently verify the quorum signature using only the signing validators' public keys, without requiring issuer-controlled private key material; wherein the sealed verdict record is thereby configured to satisfy Federal Rule of Evidence 901 and Federal Rule of Evidence 902(14).