Self-Verifying Legal-Production Export

Executive Summary

Legal-production exports package Bates-numbered native documents together with an industry-standard load file - a Concordance-compatible delimited .DAT/.OPT pair or a Relativity-compatible .CSV - for delivery to opposing counsel, a court, or another party outside the producing organization's systems entirely. JIL Sovereign's export pipeline adds two files to that same delivered package: MANIFEST.json, a per-document cryptographic hash manifest, and MANIFEST.sig, an Ed25519 signature over that manifest. Both travel inside the same ZIP as the natives and load files - not as a separate delivery, not behind a verification portal, not contingent on any ongoing relationship with the issuing system.

Because the proof of integrity is embedded in the delivered artifact itself, a recipient with no access whatsoever to the producing organization's infrastructure - opposing counsel years into litigation, a court reviewing a production on appeal, a second reviewing firm - can independently confirm that every produced document matches its recorded hash and that the manifest itself was signed by the claimed issuer, using generic, widely available cryptographic tooling. No callback to the issuing platform is required at any point in the verification process.

Problem Statement

The load-file formats that govern how legal productions are exchanged - Concordance's delimited .DAT load file paired with an .OPT image cross-reference file, and Relativity's .CSV-based export - predate modern cryptographic tooling by decades and were never designed with document-integrity verification in mind. When a receiving party wants to confirm that a produced document has not been altered since production, or that a Bates range genuinely corresponds to the documents the producing party claims it does, the available options are unsatisfying: take the producing party's certification on faith, request a custodian's sworn re-certification (slow, expensive, and dependent on the original custodian remaining available and cooperative), or rely on a vendor-hosted verification portal that ceases to be useful the moment that vendor relationship ends, the litigation outlives the vendor contract, or the matter is later reviewed by a party with no login to that portal at all.

This gap is not hypothetical. Productions are routinely forwarded to co-counsel, produced to courts on motions practice, re-reviewed years later during appeal, or handed to a testifying expert who has no relationship with the producing organization's systems whatsoever. In each case, the party doing the verifying is, by definition, entirely outside the producing organization's custody chain - and a verification mechanism that depends on contacting that organization's live systems is unavailable exactly when independent verification matters most.

Why Existing Production Workflows Are Insufficient

• Custodian sworn certification: authoritative but slow, expensive, and unavailable if the custodian is unreachable, has left the organization, or the matter is adversarial.
• Vendor-hosted verification portals (typical e-discovery platform "verify online" features): require the recipient to trust and access a live, ongoing service; provide no verification path once the vendor relationship or hosting ends.
• Load files alone, with no integrity layer: the overwhelming majority of Concordance/Relativity exports today carry no cryptographic integrity proof at all - the load file describes the production, it does not attest to its own unaltered state.

Technical Architecture

Delivered Package Contents

Deterministic Cross-Format Bates Stability

Bates numbers are derived deterministically from the production's bundle_id rather than assigned independently per export run. The practical effect: the same underlying document set exported once as a Concordance load file and again as a Relativity export - or re-exported for a supplemental production - receives identical Bates numbers in both, closing a common and practically significant e-discovery failure mode where parallel or repeated exports drift into inconsistent numbering and citations stop lining up across copies of "the same" production.

Independent, Callback-Free Verification

A recipient verifies the production entirely offline, using only the delivered archive and the issuer's published public key: compute the SHA-256 hash of each native file and compare it against the corresponding entry in MANIFEST.json; then verify MANIFEST.sig against MANIFEST.json using any standard Ed25519 verification tool. Both steps use generic, widely available cryptographic tooling - no proprietary client, no API access to the issuing platform, and no dependency on that platform remaining online or available at all.

Verification Workflow

Because every step from Step 3 onward requires nothing beyond the archive itself and a previously obtained public key, the verification remains fully available for as long as the archive exists - independent of whether the issuing platform, or the issuing organization, still does.

Prior Art Differentiation

Patent Claim