Self-Disclosing Completeness Report Cryptographically Sealed Inside an Evidentiary Bundle

Executive Summary

JIL Sovereign's evidentiary bundle generator computes completeness and exception findings as a pipeline step inside bundle generation itself, not as a separate downstream report. For each requested-record specification, the generator determines a found, not-found, ambiguous, or out-of-scope disposition and a corresponding reason, and writes these findings directly into the same manifest structure that enumerates the located evidentiary items - before that manifest is canonically hashed and signed.

Because the completeness section and the evidence inventory are fields of one signed document rather than two separately-handled artifacts, verification of the bundle's seal necessarily verifies both halves at once. There is no way to check "is the evidence authentic" independent of "is the completeness disclosure authentic," because they are the same signed byte sequence.

Problem Statement

Evidentiary and compliance bundles conventionally seal only the evidence that was successfully collected - a hash or signature over the documents and records gathered. Any statement about what was not found - missing records, incomplete responses, records outside a requested date range - is typically produced separately, if at all, as an unsealed cover memo or transmittal note that travels alongside the sealed evidence rather than inside it.

That separation creates an integrity gap with real procedural consequences: because the gap disclosure was never part of what was signed, a party, or a compromised internal process, can quietly omit, soften, or lose it without leaving any trace that verifying the evidence's own signature would catch. A recipient checking the seal has no cryptographic basis for confirming that the completeness statement they received matches what the generating system actually found.

Why Separated Completeness Reporting Is Insufficient

• Standard eDiscovery/legal-production tools: exception and completeness logs typically exist as separate, unsealed spreadsheets or emails, not bound into the same commitment as the produced documents.
• WORM/records-retention systems: seal stored content but have no completeness-assessment concept at all - there is nothing that says what was searched for but not found.
• Compliance audit-package generators: often include a narrative coverage statement, but as prose outside the cryptographic commitment covering the underlying evidence.

Technical Architecture

Completeness Computation as a Generation-Pipeline Step

For each requested-record specification in a bundle's scope, the generator determines a found / not-found / ambiguous / out-of-scope disposition and records the specific reason - this runs as part of bundle assembly, not as a downstream audit.

Single Manifest, Two Sections, One Hash

Sealing

The manifest - evidence inventory and completeness findings together - is canonically hashed, and a digital signature (consistent with the platform's broader hybrid classical/post-quantum sealing primitive used elsewhere in JIL's attestation stack) is generated over that hash. Verification necessarily checks both halves at once, since they are one signed document.

Relationship to Reproducibility Manifests

This completeness-sealing pattern is a sibling to the broader reproducibility-manifest approach used for compliance-run verdicts elsewhere in JIL's attestation infrastructure, where a signed manifest similarly binds together multiple hash classes covering different aspects of a compliance run. Here the same binding principle is applied specifically to the question of evidentiary completeness - what was requested, what was found, and what was not - rather than computational determinism.

Prior Art Differentiation

Patent Claim