What's inside a Court Ready Evidence Bundle?

Section 01 The 30-second version

A Court Ready Evidence Bundle (CREB) is a versioned, sealed, deterministically-built evidence package. It contains every artifact a reviewer needs to evaluate a fraud, denial, billing, payment, or program-integrity matter without having to re-derive any conclusion. The package is produced from a set of deterministic rules executed against immutable source records, packaged in a 19-folder directory standard with Bates-numbered exhibits, SHA-256 hash manifests, chain-of-custody logs, AVA operational notes, and a Dilithium-III post-quantum-signed manifest anchored to CourtChain.

• Who consumes it. MCO Special Investigations Units, payer compliance leads, outside counsel, state Medicaid program-integrity officers, federal Inspectors General, attorneys general, and the regulator or court of competent jurisdiction the CREB is ultimately submitted to.
• Why deterministic findings matter. Every material finding maps to a specific (rule_key, semver, input_hash, output_hash) tuple. A second reviewer can re-run the same rule version against the same input dataset and obtain the same output hash - byte for byte. That is the property that distinguishes CREB from a generative-AI report.
• Why versioned. Cases are not static. New denial, claims, payment, or adjudication data arrives. Rules get reissued. A CREB version V002 supersedes V001 with a delta report explaining what was added, what was removed, and which rule re-execution produced the change.

Section 02 The 19-folder package layout

Every CREB lives at a versioned root directory of the form CREB-YYYY-CASEID-V###/. Inside that root are exactly nineteen numbered folders, in the order below. The ordering is intentional - it is the order in which a reviewer reads the package. Case admin first, executive summary second, narrative third, findings fourth, rule execution fifth, then evidence, then chain of custody, then financial trace, then parties, then timeline, then communications, then citations, then privilege, then hash manifest, then AVA operational notes, then delta, then counsel acknowledgement, then archive.

Reviewers, opposing counsel, and admissibility experts know this layout. It does not change between matters, customers, or verticals. A claims-fraud CREB built for an MCO and a grant-fraud CREB built for a foundation share the exact same directory shape. The contents differ; the structure does not.

A note on the directory ordering

The numbering is part of the design. 00_ through 18_ is not decorative - it controls the order in which the package is read by every operating system's default sort, and by every legal review tool that ingests evidence by directory order. It is also the order in which the JIL creb-builder service writes the package on disk; the build process is deterministic and idempotent against the same case state.

Section 03 The 16-state case lifecycle

A case in the JIL CREB platform moves through sixteen defined lifecycle states. Each transition is governed by a state-machine; only valid transitions are allowed; every transition writes an audit event. The lifecycle covers the entire continuous evidence reinforcement loop - intake, triage, investigation, evidence collection, rule execution, finding proposal, finding review, package build, quality check, counsel review, submission, response receipt, resubmission, and archive.

Transition rules

• Only forward transitions in the main path are auto-permitted. A backward transition (e.g., Submitted -> Findings_Reviewed because a finding needs to be withdrawn) requires counsel sign-off and writes a high-severity audit event.
• The lifecycle is idempotent at the state level: re-entering Rules_Run on the next loop cycle produces a new execution_id without erasing the prior one.
• A case in legal hold cannot enter Archived until the hold is lifted by a hold custodian.
• Any AVA-driven priority shift is purely advisory; the state machine itself only moves on operator action or scheduled-job trigger.

Section 04 Bates numbering & exhibit IDs

Two parallel numbering schemes operate inside every CREB. Bates numbers identify pages of rendered exhibits; exhibit IDs identify logical pieces of evidence (a claim row, an email thread, a denial notice). The two schemes are cross-referenced in 05_EVIDENCE_INDEX/EVIDENCE_INDEX.xlsx.

Bates numbering

Every rendered page in 06_EVIDENCE/rendered/ is stamped with a sequential Bates number in the footer. The format is fixed:

CREB-000001
CREB-000002
CREB-000003
...
CREB-000382

Rules:

• Sequential. Allocation runs from CREB-000001 to CREB-NNNNNN in left-to-right page order through the rendered exhibits set.
• Never reused within a package version. If V001 assigns CREB-000145 to a particular page, V002 may assign the same page a new number to accommodate added exhibits, but it will not re-use CREB-000145 for a different page in the same version.
• Recorded. The bates_start and bates_end are stored on the creb_package row in the database and rendered in the CASE_MANIFEST.json.
• Footer-applied. Every rendered PDF page footer reads: Page X of Y | Bates: CREB-NNNNNN | SHA256 Ref: [short hash] | Generated UTC: YYYY-MM-DDTHH:MM:SSZ.
• Native files not Bates-numbered. Native originals (a .csv or .eml) cannot be page-numbered - they are referenced by exhibit ID and SHA-256 hash instead.

Exhibit ID prefixes

Exhibit IDs use a typed prefix so a reader can identify the evidence category at a glance. The prefix taxonomy is fixed across the platform.

Naming convention

Native files inside 06_EVIDENCE/native/ follow the canonical naming pattern:

[EXHIBIT_ID]_[TYPE]_[SHORT_DESCRIPTION]_[DATEUTC].[ext]

Examples:
  DEN-000145_DENIAL_RECORD_UNSUPPORTED_CODE_20260518.csv
  EML-000003_EMAIL_PRIOR_AUTH_THREAD_20260201.eml
  PAY-000099_PAYMENT_835_EOB_PROVIDER_FOO_20260512.json

Section 05 The deterministic rule engine

The deterministic rule engine is the evidentiary core of CREB. Every material finding in a CREB is produced by this engine, and only by this engine. AVA may recommend which rules to run, prioritize matches for review, or flag missing inputs - AVA does not produce findings. The engine is explicit, versioned, source-referenced, testable, reproducible, audit-logged, effective-dated, human-readable, and machine-executable, by design.

Rule structure (canonical schema)

{
  "rule_id": "MCO-DENIAL-001",
  "rule_key": "unsupported_denial_after_approved_auth",
  "semver": "1.2.0",
  "rule_source": "MCO Provider Manual sec. 4.2.3; CMS 42 CFR 438.404",
  "effective_date": "2026-01-01",
  "expiration_date": null,
  "logic_type": "deterministic",
  "inputs": ["claim_record", "authorization_record", "denial_record"],
  "conditions": [
    { "field": "authorization_status", "operator": "=", "value": "approved" },
    { "field": "denial_reason_code", "operator": "IN", "value": ["X123", "X456"] },
    { "field": "claim_amount", "operator": ">", "value": "$0.00" }
  ],
  "output": "rule_match",
  "severity": "high",
  "active": true
}

Reproducibility - input_hash and output_hash

Every execution writes a row to the rule_execution table with both an input hash and an output hash. The input hash is computed over the canonicalized JSON-serialized input batch manifest (every input record's SHA-256, in deterministic order, concatenated and re-hashed). The output hash is computed over the JSON-serialized rule_match output set, again in deterministic order.

A second reviewer with a copy of the package, the rule definition at the same semver, and the cited source data can re-run the rule and verify that the recomputed output_hash matches what is stored in the package's 04_RULE_EXECUTION_REPORT/. That is the property that makes CREB findings reproducible at the byte level, and it is the property that distinguishes a CREB from a generative-AI-authored memo.

No silent edits - new (rule_key, semver) rows

Rule definitions are append-only. If the policy team needs to change MCO-DENIAL-001 logic, they do not edit the existing row. They insert a new row with the same rule_key and a new semver (e.g., 1.2.0 -> 1.2.1 for a patch, 1.2.0 -> 1.3.0 for a non-breaking enhancement, 1.2.0 -> 2.0.0 for a breaking change). Prior executions remain pinned to the version that was effective on their claim date.

Effective-date evaluation

The engine evaluates rules against the version that was effective on the event_date of the record being checked, not the version that is effective on the run date. A claim dated 2026-03-01 is evaluated against rule version 1.2.0 if 1.2.0 covers 2026-01-01 through 2026-06-30, even if 1.3.0 took effect on 2026-07-01 before the analyst ran the rule.

Test harness - five required test classes

Every rule definition must have a passing test set covering five classes:

Rule match vs. finding - the distinction

Section 06 Hash manifest & SHA-256 chain of custody

Every byte that enters the CREB platform is hashed. Every access to that byte is logged. Every audit event is hash-chained to the prior event. The result is a tamper-evident package that an external verifier can validate without holding any JIL secret - the whole verification path is open SHA-256.

Per-exhibit hashing at intake

1. A file arrives via upload, SFTP, S3 event, or scheduled ingest job.
2. The intake worker reads the bytes, computes sha256_hash (and optionally sha512_hash for Tier-3 matters), stores the hash on the evidence_item row.
3. The original file is written to the immutable vault with immutable_original = true.
4. An intake audit event is appended to the audit log with event_type = "upload", actor_id, case_id, object_type = "evidence", object_id = evidence_id, details = { sha256, original_filename, file_size_bytes }.
5. Chain of custody log gets a row: custodian = uploader, chain_status = "intake".

Per-access logging

Every read of an evidence item writes an access_log row: actor_id, evidence_id, action (read|render|export), timestamp_utc, source_ip, purpose_code. A reviewer cannot view an exhibit without leaving a footprint. The access log is exported into 07_CHAIN_OF_CUSTODY/ACCESS_LOG.csv at package build time.

Hash-chained audit log

The audit log itself is hash-chained. Each audit event carries a prior_hash (the event_hash of the immediately preceding event for the same case) and an event_hash over its own canonicalized JSON. Tampering with one event invalidates every subsequent event in the chain.

// audit_event row at rest
{
  "audit_id":        "AUD-2026-000145-00482",
  "event_type":      "generate_package",
  "actor_id":        "svc:creb-builder@2026-05-18T03:14:22Z",
  "case_id":         "CREB-2026-000145",
  "object_type":     "creb_package",
  "object_id":       "CREB-2026-000145-V002",
  "event_timestamp": "2026-05-18T03:14:22.451Z",
  "details":         { /* event-specific fields */ },
  "prior_hash":      "e7a4...c819",
  "event_hash":      "f2b1...9d04"
}

Package-level hash

When the builder finishes writing all 19 folders, it computes a package_sha256 over the canonicalized concatenation of every file's hash in stable path order. That single 64-character hex string is recorded in 14_HASH_MANIFEST/PACKAGE_HASH.txt, written into CASE_MANIFEST.json, signed with Dilithium-III, anchored to CourtChain, and printed in the footer of the executive summary. A reviewer can take just that one value and verify the entire package.

External verification workflow

The 14_HASH_MANIFEST/HASH_VERIFICATION_INSTRUCTIONS.txt file explains the standalone verification recipe:

1. Unzip CREB-2026-000145-V002_SUBMISSION.zip
2. Run:   sha256sum -c HASH_MANIFEST_SHA256.txt
3. Verify every file reports "OK"
4. Recompute package-level hash:
     find . -type f -not -name PACKAGE_HASH.txt \
       | sort | xargs sha256sum \
       | sha256sum
5. Compare against PACKAGE_HASH.txt
6. Verify Dilithium-III signature over PACKAGE_HASH.txt
     using the JIL validator public key set
     (published at trust.jilsovereign.com/validators)
7. Resolve the CourtChain anchor TX in step 6 to confirm
   the package hash was notarized at the claimed UTC instant.

Section 07 Post-quantum signing - Dilithium-III (ML-DSA-65, NIST FIPS 204)

The final attestation over every CREB package is signed with Dilithium-III (the NIST-standardized name is ML-DSA-65, formalized in NIST FIPS 204, August 2024). Validator votes are signed with a hybrid Ed25519 + Dilithium-III scheme - both algorithms must verify, both keys must sign. The package's package_sha256 is bound to the signed attestation via SHA3-256.

Why a post-quantum scheme

Classical signatures (ECDSA, Ed25519, RSA) are exposed to "harvest now, decrypt later" risk: an adversary that captures a signed attestation today can wait for a cryptographically-relevant quantum computer (CRQC) to break the signature retroactively. A CREB that ends up in court in 2031 or 2034 needs to survive that exposure. Dilithium-III is currently the leading NIST-standardized lattice-based signature algorithm and is considered secure against both classical and quantum adversaries with the next-decade time horizon CREB targets.

The hybrid scheme on validator votes

Every validator vote on an attestation is signed by both Ed25519 and Dilithium-III. The verifier must successfully verify both. This protects against three categories of failure:

• A classical break. If ECDSA / Ed25519 is broken via classical advances (unlikely, but historically not zero - cf. the 2010 PS3 ECDSA private-key recovery), Dilithium-III still holds.
• A quantum break. If Ed25519 falls to a CRQC, Dilithium-III still holds.
• A bug in one implementation. If a side-channel bug exists in one signature library, the other library must still produce a verifying signature - both keys must sign.

SHA3-256 binding to attestation params

The validator does not sign the package alone. It signs a SHA3-256 commitment over the tuple (package_sha256, attestation_class, case_classification, validator_id, timestamp_utc, courtchain_target_block). That binds the signature to the specific attestation parameters; a signature on one attestation cannot be replayed onto another.

Key custody

Validator signing keys live in hardware security modules (HSMs) in geographically distributed JIL validator facilities. Operator access to the HSM is gated by attestation: a request to sign must come from a JIL validator workload that has presented a current TPM remote attestation quote tied to a known software image. No human operator can extract a signing key, and no software image can sign without first proving it is the published image.

Section 08 Chain of custody log

Every evidence item in a CREB has a chain of custody record. The record names the custodian, the privilege status, and the chain status, and every access to the item is appended to an access-event log that is exported into 07_CHAIN_OF_CUSTODY/ at package build time. This is the artifact the producing party relies on to authenticate evidence at trial under Federal Rules of Evidence 901 and 902(14).

The custodian field

Every evidence_item row carries a non-null custodian field. The custodian is the named individual or system principal under whose authority the item was acquired and is held - a Special Investigations Unit analyst, a payer IT operator, a contracted forensic accountant, a system service principal. The custodian field is the person who would be deposed if the evidence's provenance were challenged.

privilege_status

chain_status

Access-event log

Every read, render, or export of an evidence item appends to the access log:

access_event = {
  access_id,
  evidence_id,
  case_id,
  actor_id,           // user or service principal
  action,             // "read", "render", "export", "redact"
  purpose_code,       // "review", "deposition_prep", "production", "qc"
  source_ip,
  user_agent,
  timestamp_utc,
  prior_hash,
  event_hash
}

At package build time, all access events scoped to the case are exported to 07_CHAIN_OF_CUSTODY/ACCESS_LOG.csv. Counsel reviewing the package sees the full read history of every exhibit.

Section 09 PDF/A-2b conformance

Every generated PDF in a CREB is PDF/A-2b conformant. PDF/A-2b (ISO 19005-2, conformance level B for "basic visual reproduction") is the long-term archival profile recognized by Federal courts, state regulators, and ISO-aligned recordkeeping standards as the format that will remain renderable in twenty years.

What PDF/A-2b requires

• Embedded fonts. Every glyph used in the document must have its font subset embedded. No reliance on a reader's font catalog.
• Self-contained color. No external color profile lookups. ICC profiles for any color spaces are embedded.
• No JavaScript. No active content. The document is a static rendering.
• No external references. No hyperlinks to external resources required for the document to be understood.
• No encryption. The package as a whole is encrypted at the ZIP layer; individual PDF/A files are not password-protected so that a reviewer can open them with any conforming reader.
• XMP metadata. Document metadata embedded in XMP, including the PDF/A conformance declaration.

OCR on scanned content

Every scanned exhibit in IMG- or 06_EVIDENCE/rendered/ carries a hidden OCR text layer. The visual representation is faithful to the scan; the hidden layer makes the document searchable. The OCR engine is recorded in the file's XMP metadata (jil:ocr_engine, jil:ocr_version, jil:ocr_confidence_min).

Why this matters for 20-year retention

Healthcare program integrity matters, False Claims Act qui tam actions, and grant recovery cases routinely take five to ten years from packaging to final resolution. The recordkeeping obligation on top of that can run twenty years or longer. A CREB submitted today must still be openable, renderable, searchable, and visually faithful in 2046. PDF/A-2b is the format the National Archives and Records Administration, the U.S. Federal Judicial Center, the Library of Congress, and every state records management authority have adopted for exactly that horizon.

Conformance verification

During Quality_Check (lifecycle state 10), the builder runs every generated PDF through a PDF/A validator (veraPDF or equivalent). Any non-conformance fails the QC pass and the package cannot move to Counsel_Reviewed. The conformance report is itself a PDF/A file written to 00_CASE_ADMIN/PDFA_CONFORMANCE_REPORT.pdf.

Section 10 AVA - the operational boundary

AVA stands for Adversarial Validation and Assessment (alternative gloss in operational materials: Adaptive Validation Aid). AVA is JIL's AI-assisted operational orchestration layer. AVA recommends, prioritizes, summarizes, and flags. AVA never produces findings. Every AVA call is audited at the schema level. The schema-level constraint creb_ava_cannot_be_finding physically prevents AVA-authored content from being inserted into the finding table.

What AVA may do

• Recommend which deterministic rules to run next given the current evidence state.
• Identify likely-missing evidence categories (gap analysis).
• Prioritize the human review queue.
• Compare current and prior CREB versions and summarize what is new.
• Recommend resubmission timing.
• Detect stale unresolved cases and surface them.
• Draft non-authoritative operational summaries clearly labeled as such.
• Flag inconsistencies in source data for human review.
• Recommend additional source systems to query.
• Compute an internal Operational CREB Readiness Score (not a legal conclusion).

What AVA must not do

Per-call audit log - what is recorded

ava_call = {
  ava_event_id,
  case_id,
  recommendation_type,        // gap | rule_suggestion | priority | resubmission | summary
  input_context_ids,          // array of evidence_ids, finding_ids, rule_ids
  generated_at_utc,
  model_version,              // pinned model identifier
  prompt_template_version,    // pinned prompt template hash
  output_hash,                // SHA-256 of canonicalized output
  output_text,                // the recommendation itself
  accepted_by_user,
  user_action_taken,
  prior_hash,
  event_hash
}

Every AVA recommendation accompanying a CREB is exported into 15_AVA_OPERATIONAL_LOG/AVA_RECOMMENDATION_LOG.jsonl. A reviewer can audit exactly what AVA suggested, when, on what input, with what model version, and what the human did with the recommendation.

The schema-level constraint

The constraint creb_ava_cannot_be_finding is enforced at the database layer. The finding table requires that finding.rule_match_ids be non-empty - in other words, every finding must point to at least one deterministic rule match. AVA does not create rule matches. Therefore AVA cannot create a finding. The constraint is the architectural commitment that the boundary cannot be silently crossed by a future code change.

Section 11 The 14-of-20 BFT validator quorum

Every attestation produced by the JIL platform - including every CREB attestation - is approved by a 14-of-20 Byzantine-Fault-Tolerant validator quorum. Twenty validator nodes are geographically and legally distributed across thirteen-plus jurisdictions; fourteen must independently vote to approve before the attestation is sealed.

Why 14-of-20

A standard BFT safety threshold is n - f where n = 3f + 1 and f is the maximum number of faulty validators tolerated. With n = 20 and f = 6, the safety threshold is n - f = 14. The system can tolerate up to six simultaneously faulty (Byzantine, offline, or compromised) validators and still produce a valid attestation. Below that threshold, the attestation cannot be sealed.

Jurisdictional diversity

The twenty validator slots are allocated across thirteen-plus legal jurisdictions, with no single jurisdiction holding more than four validators. The objective is twofold:

• Legal diversity. No single sovereign can compel the full quorum. Compelled disclosure or compelled signing in one jurisdiction does not bring the attestation within reach of an attacker.
• Operational diversity. Validators run in distinct cloud and bare-metal facilities, distinct timezones, distinct power grids. Correlated failure across the quorum is structurally hard.

Hybrid post-quantum signatures on each vote

Each of the fourteen approving votes is itself a hybrid Ed25519 + Dilithium-III signature over the attestation commitment. The aggregate attestation - what is anchored to CourtChain - is the SHA3-256 commitment plus the fourteen-or-more validator signatures. A verifier can independently re-check every signature without trusting JIL.

Section 12 CREB versioning - V001 -> V002 -> V_n

A CREB is never a one-time artifact. The whole point of the continuous evidence reinforcement loop is that more data arrives, more rule matches surface, and a stronger version supersedes the prior one. CREBs are versioned V001, V002, V003, and each new version carries a delta report explaining what changed.

Version naming

CREB-YYYY-CASEID-V###

Examples:
  CREB-2026-000145-V001   // initial package
  CREB-2026-000145-V002   // supersedes V001
  CREB-2026-000145-V003   // supersedes V002

When a new version is built

A new CREB version is generated when at least one of the following becomes true:

• A new validated finding has been added.
• New source evidence has been attached.
• The recipient has requested more evidence (more_evidence_requested response).
• The amount-at-issue has changed materially.
• A new entity, person, or provider has been linked.
• A new rule version has triggered against prior data.
• The case has moved from a weak corroboration posture to a corroborated posture.
• A reviewer has manually requested a new package.

prior_package_id linkage

Every creb_package row carries a prior_package_id column. V002's prior_package_id points to V001's creb_package_id. The linkage is auditable in the database and printed in 00_CASE_ADMIN/CASE_MANIFEST.json. The chain of versions for any case can be walked backward to the original V001.

The delta report

Every version from V002 onward includes 16_DELTA_REPORT/DELTA_REPORT.pdf. The delta report carries:

The resubmission auto-flag

The continuous loop engine runs on a scheduled cadence - daily for high-volume operational refresh, weekly for formal CREB reinforcement review. For each active case, it pulls new source data in the configured lookback window, re-runs the deterministic ruleset, compares the new rule matches against the existing findings, and auto-flags the case for resubmission if any of the trigger conditions are met. The flagged case enters lifecycle state Resubmission_Queued and waits for human review before package build.

Section 13 Submission tracking

Every CREB submission is a tracked, audited delivery event. The submission record captures who received it, how, when, what they said back, and what follow-up is required.

Submission record fields

Response taxonomy

Section 14 Legal hold & retention

Two complementary controls govern how long a case and its evidence live in the system: legal hold pins a case in place and overrides every other retention setting, and a retention policy expires data on a defined schedule once the hold is released. Privilege flags layered on top prevent accidental disclosure during both phases.

Legal hold

• A legal hold can be applied at the case level, the evidence-item level, or by entity (every case touching a specific provider, member, or contract).
• While a hold is active, the case cannot enter lifecycle state Archived, and no evidence item can be expired or purged by retention.
• Hold actions are themselves audited: hold_applied, hold_extended, hold_released are all separate audit event types with named hold custodians.
• Releasing a hold requires a named hold custodian with the compliance_lead or outside_counsel role, plus a logged reason.

Retention policy

Each case carries a retention policy reference recorded in 00_CASE_ADMIN/RETENTION_POLICY.txt. Healthcare program-integrity matters typically inherit a twenty-year retention horizon from CMS recordkeeping rules; commercial fraud matters typically inherit a seven-year retention horizon from the applicable statute of limitations plus discovery tail. The retention clock starts at the transition to Archived. If a hold is active when the clock would have triggered expiry, the clock pauses until the hold is released.

Privilege flags as a disclosure guard

Privilege flags (attorney_client, work_product, medical_record, pii_protected) carry forward through every version of a case. When a CREB is built, the builder cross-checks each candidate exhibit against its privilege flag and the matter's protective order; items flagged for exclusion appear only in 13_PRIVILEGE_LOG/ with their basis-for-withholding entry. They never appear in the production exhibits set.

Section 15 Two-party export approval

Every CREB package download from the platform requires two-party authorization: a named requester plus a named approver, with a logged reason, an explicit acknowledgement of the export's purpose, and a twenty-four-hour expiry on the approval token.

The two-party flow

1. Requester opens an export request. The requester is an authenticated user with the platform role investigator, compliance_analyst, compliance_lead, outside_counsel, or service_principal.
2. Reason recorded. The requester selects a purpose code (production, deposition_prep, expert_review, internal_qc, regulatory_submission) and writes a free-text reason. Both fields are required.
3. Approver named. The platform routes the request to an approver. The approver must hold the role compliance_lead or outside_counsel and must be distinct from the requester. The requester cannot approve their own request.
4. Acknowledgement. The approver must affirmatively acknowledge that the export is consistent with the matter's protective order and applicable privacy obligations. The acknowledgement language is fixed by the platform.
5. Token issued, 24-hour expiry. A single-use download token is issued, scoped to the specific creb_package_id. The token expires after twenty-four hours regardless of whether the download has occurred.
6. Download logged. The actual download event writes an audit row with the source IP, user agent, and timestamp. Counsel reviewing later can see exactly which approval authorized which download.

Section 16 CourtChain anchoring

Every CREB attestation - the Dilithium-III-signed commitment over the package_sha256 - is anchored to CourtChain, JIL's purpose-built Layer 1 tamper-evident audit ledger. Anchoring writes the attestation hash as a transaction on CourtChain at a notarized UTC instant. External parties can verify the package's pre-clearance chain after the fact without holding any JIL secret.

What gets anchored

• The package attestation hash. SHA3-256 over (package_sha256, attestation_class, case_classification, validator_id_set, timestamp_utc, courtchain_target_block).
• The fourteen-plus validator signatures. Each Ed25519 + Dilithium-III hybrid signature.
• The validator quorum identifier. Which twenty-validator slot set was active at the time of anchoring.
• The lifecycle state transition that produced it. Typically Package_Built -> Counsel_Reviewed for V001-and-later attestations.

What CourtChain is

CourtChain is a JIL-operated Layer 1 ledger with public read access, BFT consensus, and a purpose-built schema for attestation transactions. It is not Ethereum, it is not Bitcoin, it is not a generic enterprise blockchain. It is engineered for one workload: append-only attestation notarization with sovereign jurisdictional replication.

External verification path

1. The reviewer receives the CREB ZIP. They open 14_HASH_MANIFEST/PACKAGE_HASH.txt and recompute the package-level hash.
2. They open 00_CASE_ADMIN/CASE_MANIFEST.json and read the courtchain_anchor object: { tx_hash, block_height, anchored_at_utc, validator_quorum_id }.
3. They visit the public CourtChain explorer (courtchain.jilsovereign.com/tx/<tx_hash>) and confirm the transaction exists at the claimed block height with the claimed payload.
4. They cross-check that the timestamp the package claims is the timestamp at which CourtChain recorded the anchor.
5. If all four match, the package is verified pre-clearance: the package contents existed in their current state at the recorded UTC instant, and any later edit would have to be re-signed by the validator quorum and re-anchored.

Section 17 Conformance posture - the disclaimers that ship with every CREB

A CREB is a deterministic evidentiary packaging artifact. It is not legal advice, it is not an attorney-client relationship, it is not a guarantee of any outcome. Every CREB carries the following conformance posture in 01_EXECUTIVE_SUMMARY/ and 00_CASE_ADMIN/, and counsel acknowledges them in 17_COUNSEL_ACKNOWLEDGEMENT/.

MCO program-integrity conformance

Wording boundaries

Section 18 What is NOT inside a CREB

Just as important as what a CREB contains is what it does not contain. A CREB excludes several categories of artifact by design. The exclusions are architectural commitments enforced at the schema, build, and review layers.

The CREB design is documented across eleven internal specifications (00_README through 11_Developer_Backlog). This page is the institutional summary of those specifications, intended to give a buyer or reviewer enough technical depth to evaluate the platform before signing a master services agreement. The full specifications are available under NDA upon request via /connect.

JIL Sovereign Technologies, Inc. - Platform Spec JIL-CREB-001 - Revision 1.0 - 2026.05 - Confidential, Institutional Distribution