The Admissibility Auditor

"The auditor does not declare admissibility. It organizes the record so a court can."

ℹPrerequisites▼

Before reading this chapter, you should be comfortable with: Chapters 3, 16, 25 (FRE Primer, Primitives, Reference Verifier). The auditor applies legal standards (FRE 901) to technically verified attestations.

A circuit judge in chambers reads a Canon Enrichment Attestation admitted at a pretrial hearing. Forty-three pages of JSON. Twelve claims, six challenge outcomes, four declined-coverage entries. The judge has thirty minutes between the morning calendar and the next hearing. The judge does not have time to walk seven verification steps by hand, cross-reference the Daubert factors, and decide what NIST AI RMF says about a qwen2.5:7b-instruct-q6_K extractor's "general acceptance in the relevant scientific community." The judge picks up a second document. Two pages. An audit attestation that itself is Canon-conformant — same four blocks, same seal — produced by the Admissibility Auditor. The audit lists every authentication factor a court must satisfy under FRE 901(b)(9), every reliability factor surfaced by Daubert, every gap the issuer disclosed, every challenge declined and why. It does not say the exhibit is admissible. It says: here is what is in the artifact and what isn't, and here is how each thing maps to a question the doctrine asks. Now the judge has thirty minutes' worth of work to do. This chapter is about that two-page document. > ▼ Why It Matters — When no audit attestation exists. > > The admissibility auditor produces an AuditAttestation — but the auditor is not yet widely deployed. In current practice, most Canon attestations will be presented without an accompanying audit. When no AuditAttestation was produced, counsel and the bench should apply the auditor's checklist manually: (1) Does the attestation pass meridian-canon verify? (2) Is the issued_at timestamp plausibly contemporaneous with the described event? (3) Does the witness.custody_chain show a complete acquisition path from source to attestation? (4) For each claim in findings, is the inference_type consistent with the nature of the claim — or does a speculative inference appear where only observed facts are warranted? (5) Does the refutation.coverage object show that challenges were attempted, or is it empty? These five questions substitute for the auditor in the absence of an AuditAttestation. ## At a glance - The Admissibility Auditor consumes a sealed Canon attestation and produces a Canon-conformant audit attestation — kind = audit.

• Three sections: Authentication (FRE 901(b)(9)), Reliability (Daubert / proposed FRE 707), Caveats (the issuer's gaps and declined-coverage entries surfaced verbatim).
• The Auditor is deliberately narrow. It does not opine on hearsay, best evidence, jurisdictional doctrine, strategy, or admissibility. It mechanizes the part of a court's analysis that can be mechanized; the rest is the court's substantive work.

Learning objectives

• Read an audit attestation as a court would, mapping each claim to a legal authority.
• Run the Auditor against any sealed Canon attestation and interpret the output.
• Explain to a judge, in three sentences, what the Auditor does and what it does not do.
• Implement an Auditor section appropriate for a domain Canon doesn't natively cover (medical-evidence overlay, journalistic-FOIA overlay, EU AI Act overlay).

Why the Auditor exists

▼ Why It Matters. A judge who has never seen a Canon attestation before is in roughly the position of a 1990s judge who had never seen a digital photograph. The technology is unfamiliar; the doctrinal hooks are still being worked out; the judge's instinct, reasonably, is to defer the question to expert testimony. The Auditor's purpose is to give the judge — and the auditor, the regulator, the opposing counsel — a standardized first-pass map from the unfamiliar artifact to the familiar doctrine.

Without this map, every Canon attestation requires bespoke expert witness work to be admitted. With it, the threshold inquiry can be done in chambers, in minutes. Substantive challenges remain available; what changes is the cost of the threshold.

The proposed Federal Rule of Evidence 707 (Chapter 3, Appendix C), if it takes effect (earliest: December 1, 2027), will require proponents of machine-generated evidence offered without an expert sponsor to satisfy FRE 702(a)–(d) — the Daubert factors. The Auditor's Reliability section is structured around exactly those factors: a Canon attestation accompanied by an audit attestation enters a 2027 courtroom carrying its FRE 707 showing pre-built.

This does not guarantee admission. It does what an engineering tool can do: presents the proponent's evidence, with explicit disclosures, in the structure the rule expects.

The three sections

Section 1 — Authentication record (FRE 901(b)(9))

§ For the Record — FRE 901(b)(9).

"Evidence describing a process or system and showing that it produces an accurate result."

Authentication is the threshold question: is this exhibit what its proponent claims it is? For a Canon attestation, the answer decomposes into the seven verification steps (Chapter 25). Each step is a fact the Auditor can determine and report.

The Auditor's Section 1 emits one Claim per authentication question:

# meridian/canon/admissibility_auditor.py
def _authentication_record(target, walker):
    claims = []

    # Public-key fetch + fingerprint match (R8).
    s1 = walker.steps["step1_public_key_fetch"]
    claims.append({
        "claim_id": "claim-AUTH-PK-...",
        "statement": (
            f"Public-key URL fetch and SHA-256 fingerprint comparison: {s1}. "
            "FRE 901(b)(9) authentication: process producing a result; here, "
            "the issuer's published key matches the key declared in the seal."
        ),
        "supports": [f"obs-target-{target_id}"],
        "inference_type": "deduction" if s1 == "pass" else "observation",
        "gaps": ["URL availability verified at audit time only", ...]
    })
    # ... and so on for each of the seven steps

Each authentication Claim names the step (public-key fetch, signature verify, DSSE envelope verify, chain-hash recompute, witness re-hash, supports closure, refutation targets, declined-coverage review), reports its outcome (pass/fail/numeric), and discloses its gaps in the same machine-readable form Canon requires of the underlying findings.

◆ Going Deeper — Why is the Auditor itself a Canon attestation?

R9 (falsifiability without issuer cooperation) applies to the Auditor as much as to anything else it audits. An audit report that was not itself Canon-conformant would be a black box judging another black box — exactly the failure mode Canon was designed to defeat.

By emitting the audit as a kind = "audit" attestation with the > standard four blocks, the Auditor commits the auditor to its own > findings. The court that wants to verify the audit can run the > seven-step protocol against it. The audit's witness block inlines > the canonical bytes of the target attestation, so the audit's > integrity is bound to the target's integrity: tampering with the > target after audit invalidates both seals. > > This is recursive falsifiability. It is the design point. ### Section 2 — Reliability factors (Daubert / proposed FRE 707) > § For the Record — FRE 702 (as amended December 1, 2023). > > "(a) the expert's scientific, technical, or other specialized > knowledge will help the trier of fact to understand the evidence or > to determine a fact in issue; (b) the testimony is based on > sufficient facts or data; (c) the testimony is the product of > reliable principles and methods; and (d) the expert has reliably > applied the principles and methods to the facts of the case." The Daubert factors (Chapter 3) are non-exhaustive but conventional: testability, peer review, error rate, controlling standards, general acceptance. Post-Loomis ML case law (dossier 05) refines them into four ML-specific questions: independent testing, quantified error rate, acceptable error rate, reliable application to the specific facts. A Canon attestation has hooks for each: | Daubert factor | Canon hook | Audited as | |---|---|---| | Testability | The standalone verifier runs against any emitted attestation; the conformance suite is publicly published. | Section 2 cites the verifier's existence and the conformance test results. | | Quantified error rate | The Refutation block's replay challenge variance and model-eval results in findings.method. | Section 2 emits a Claim summarizing replay outcomes and citing the method line. | | Acceptable error rate | The recipient evaluates this against the substantive context — Step 7 of the protocol. | Section 2 surfaces the Tri-Model Consensus outcomes (survived / contested) without judging acceptability. | | Reliable application to facts | Per-Claim inference_type, supports, gaps. | Section 2 emits a Claim summarizing the inference-type distribution and gap-disclosure rate. | The Auditor produces, for each factor, a single Claim that states the fact, names the supporting Canon field, and discloses its own gaps. The judge does not have to learn what qwen2.5:7b-instruct-q6_K is; the judge has to decide whether the Auditor's structured report of what was tested, how, and with what variance is sufficient under Daubert. That is a familiar question.

☉ In the Wild — State v. Loomis and the question Loomis didn't decide.

State v. Loomis, 881 N.W.2d 749 (Wis. 2016), is the Wisconsin Supreme Court's encounter with algorithmic risk assessment. The court held that a sentencing judge may consider a COMPAS risk score but cannot make it determinative; that defendants have no constitutional right to inspect proprietary source code; and that the gatekeeping question — whether the risk score is reliable — remains open. The court did not say what reliability would look like for an opaque ML system. It said the question matters and deferred it.

The Auditor is one answer to the question Loomis left open. It does not produce reliability findings; it produces a record the court can use to make reliability findings. The decision remains the court's. The change is the structure of the inquiry.

Section 3 — Caveats and open questions

The Auditor's third section appears redundant. It aggregates every gap declared by the issuer and every challenge declined, and surfaces them verbatim as part of the audit's own Claims.

The redundancy is the point. The audit's seal commits the auditor to the existence of those gaps and declines. A court reading the audit cannot miss them; opposing counsel cannot fail to cite them; the issuer cannot retract them.

The Auditor explicitly acknowledges what it does not do. The third section's third Claim names the doctrinal questions out of scope:

claims.append({
    "claim_id": "claim-CAV-DOCT-...",
    "statement": (
        "Doctrinal scope: hearsay (FRE 801-807), best-evidence "
        "(FRE 1001-1008), state Frye-jurisdiction variations, and "
        "FRE 902 self-authentication procedural requirements are out "
        "of scope at this layer. Counsel must analyze them separately."
    ),
    "supports": [f"obs-target-{target_id}"],
    "inference_type": "observation",
    "gaps": [
        "Hearsay exceptions/exclusions are not flagged by this auditor",
        "FRE 902(13)/(14) certifications would require additional procedural steps",
        "Frye-jurisdiction reliability factors may differ from Daubert factors used here",
    ],
})

▼ Why It Matters — for the Affected reader. If you are the subject of a proceeding in which a Canon attestation is offered as evidence against you, your counsel should ask three questions first:

1. Was an audit attestation produced? If yes, read it.
2. Which challenge types were declined, and why? The reasons are in coverage.declined. Each is a place where the issuer admits > the system did not test something. > 3. Which gaps did the issuer disclose on the load-bearing claims? > These are admissions; they cannot be retracted; they are > available to your counsel without subpoena. > > The Auditor is structured so this list is the same list a judge > would consult, in the same order. The book makes no promise about > the outcome of those questions in your matter; the book promises > the questions are visible, and that is itself a substantial change. ## The auditor's recursive structure, walked The audit attestation, as Canon attestation, has its own four blocks. This is not aesthetic; it is a load-bearing design choice. | Audit block | Contents | |---|---| | Witness | One entry. The content_inline is the base64 of the canonical bytes of the target attestation (seal excluded). The content_hash is the target's chain_hash. A verifier of the audit re-hashes the inlined bytes; the audit is bound to a specific target by hash. | | Findings | The three sections above, ~10–15 Claims total. Each Claim has its own inference type and gaps. | | Refutation | A single replay challenge applied to all audit Claims; coverage applied = [replay]; declined = [adversarial_prompt, consistency_check, coverage_audit, counter_evidence] with reasons (auditor_is_structural_not_adversarial, auditor_findings_are_per_target_not_corpus_wide, applies_to_corpus_not_to_audit_artifact, auditor_findings_are_structural_not_inferential). | | Seal | Standard Ed25519 over RFC 8785 chain hash. The audit's signing key may be different from the target's signing key; this is a feature — different custodians can independently audit each others' work. | > ✻ Try This. Pick any sealed attestation from meridian/canon/tests/. Run:

python -m meridian.canon.admissibility_auditor \
  path/to/attestation.json \
  --custodian "your_keychain_account" \
  --pubkey-url "https://example.org/keys/auditor.pem" \
  --out audit.json

The output is itself a Canon attestation. Walk it with meridian-canon walk audit.json and observe that it passes its own > seven-step verification. ## The EU AI Act overlay > ◆ Going Deeper — When the EU AI Act applies. > > Annex III, Point 8 of EU Regulation 2024/1689 designates AI in > "administration of justice and democratic processes" as a high-risk > category. A Meridian-Cannon-style system used in EU litigation > almost certainly qualifies. Compliance with Articles 11 (technical > documentation), 12 (logs and audit trail), 13 (transparency to > affected individuals), 14 (human oversight), 15 (accuracy and > robustness), and 27 (fundamental rights impact assessment) is > required by August 2, 2026. > > The Auditor can be extended with an optional EU AI Act overlay > section. Each Article maps cleanly to a Canon field: > > | EU AI Act Article | Canon field | Audit hook | > |---|---|---| > | Art. 11 (technical documentation) | findings.method, training-data provenance | Section 2's method-line claim | > | Art. 12 (logs and audit trail) | audit_log table; per-attestation custody chain | New Section 2 claim | | Art. 13 (transparency to affected individuals) | Whether disclosure is in the attestation's metadata | New Section 3 claim | | Art. 14 (human oversight) | Custody chain entries; manual-review markers | New Section 3 claim | | Art. 15 (accuracy/robustness) | Replay variance; cross-encoder eval | Section 2's reliability claim | | Art. 27 (FRIA) | Out-of-scope; flagged in Section 3 | Section 3 caveat |

The overlay is implementation-specific and not part of Canon. Lab 26.1 (below) walks the implementation. EU readers should pursue it; US readers may skip it.

A worked audit, walked

Take the Chapter 1 example attestation. Run the Auditor against it. The (abbreviated) output:

{
  "kind": "audit",
  "subject": "Admissibility audit of 01JABC...",
  "witness": [{
    "observation_id": "obs-target-01JABC...",
    "source": "attestation://01JABC...",
    "content_hash": "sha256:09a1...d2ef",
    "content_inline": "<base64 of target's canonical bytes>"
  }],
  "findings": {
    "method": "Admissibility Auditor v0.1.1: deterministic inspection ...",
    "claims": [
      {
        "claim_id": "claim-AUTH-PK-...",
        "statement": "Public-key URL fetch and SHA-256 fingerprint comparison: pass. FRE 901(b)(9) ...",
        "inference_type": "deduction",
        "gaps": ["URL availability verified at audit time only", "Notarization not checked"]
      },
      {
        "claim_id": "claim-AUTH-SIG-...",
        "statement": "Ed25519 signature over chain_hash bytes: pass. ...",
        "inference_type": "deduction",
        "gaps": ["Signing-host private-key compromise out of scope at this layer"]
      },
      {
        "claim_id": "claim-REL-IT-...",
        "statement": "Inference-type distribution: {'deduction': 1}. ...",
        "inference_type": "observation",
        "gaps": ["Distribution is structural, not a quality measure"]
      },
      {
        "claim_id": "claim-REL-CV-...",
        "statement": "Refutation coverage: 3 applied, 2 declined with reasons, 0 unaccounted-for. ...",
        "inference_type": "observation",
        "gaps": ["Declined-challenge reasons are machine-readable but their adequacy is for the recipient"]
      }
      // ... ~12 more
    ]
  },
  "refutation": { "challenges": [...replay...], "coverage": {"applied": ["replay"], "declined": [...]} },
  "seal": { "chain_hash": "sha256:b22e...77c1", "signature": "..." }
}

A judge reading this audits in five minutes what would otherwise take five hours of expert testimony. The judge does not learn cryptography; the judge learns whether the artifact was self-disclosed honestly — the actual question evidentiary review requires.

v0.2.0 audit criteria

Canon v0.2.0 attestations carry additional structural properties. The Auditor checks for each automatically when the target's canon_version is 0.2.0 or later. For v0.1.x targets the checks are skipped (noted as "not_applicable" in the audit's claims). 1. DSSE envelope present. attestation.dsse_envelope must be non-null. An audit claim flags its absence as a gap. For v0.2.0 attestations, a missing DSSE envelope is a structural deficiency that the proponent must explain. 2. DSSE verifiable. The Ed25519 signature over PAE(payload_type, canonical_bytes) must verify against the public key at public_key_url. The verifier reports this as step2_dsse_verify. The audit claim surfaces both the verification outcome and the payload_type string, which encodes the Canon version. 3. chain_hash consistent. SHA-256(base64url_decode(dsse_envelope.payload)) must equal chain_hash. This check is independent of the DSSE signature: it detects field-level tampering even if the signature is not checked. An attestation where chain_hash does not match the decoded payload has been modified after sealing — the audit claim reports this as a hard failure regardless of the DSSE outcome. 4. Rekor log entry (if applicable). When MERIDIAN_REKOR_ENABLED=1, a rekor_entries row must exist for the attestation's seal. The audit claim reports the entry_uuid and log_index, and notes whether the entry is independently verifiable against the Rekor public instance. If no Rekor entry exists and the deployment is configured for transparency logging, this is a gap the audit surfaces but does not treat as a hard failure — Rekor availability is an operational concern outside the attestation's seal. 5. element_type present (if applicable). For attestations over chunked documents, ChunkRecord.metadata.element_type must be present and non-null on each chunk cited in the witness block. Presence proves the document was section-partitioned by a structured partitioner (such as Unstructured.io) rather than naively byte-split. The audit claim notes the element_type distribution across cited chunks. A chunk set where every element is NarrativeText is not a deficiency; a chunk set with no element_type field at all is evidence of naive chunking and should be flagged. 6. C2PA manifest (if media exhibit). For attestations over image or video exhibits, the manifest_hash in the witness entry must be verifiable and the agentId or certificate_pem must be traceable to the capturing device. The Auditor flags absence as a gap; it does not attempt to verify the device certificate chain (that requires out-of-band device records). Custodian identifier. In both the Seal and the DSSEEnvelope, the custodian field identifies the key used to sign the attestation. The Auditor verifies that custodian is a stable institutional identifier — not a personal name. A custodian like "acme-corp-2026" or "meridian-pipeline" is stable across key rotations and personnel changes; a personal name is not. The audit flags personal-name custodians as a gap in the reliability section: if the individual leaves the organization, key-rotation continuity and the audit trail may become difficult to maintain. > ▼ Why It Matters — The custodian field at a key-rotation hearing. > > If a party challenges whether a key-rotation attestation (Chapter 23) > connects the old and new fingerprints, the custodian field is the > stable identifier that links them. An institutional custodian name > survives personnel turnover; a personal name does not. If the original > signer is unavailable and the custodian name was their personal account, > there may be no way to demonstrate organizational continuity. Use > institutional identifiers. Document the mapping between custodian names > and the individuals or roles authorized to hold the corresponding keys. ## What the auditor does not do The Auditor's narrowness is its discipline. Three categories of question are deliberately out of scope: 1. Hearsay analysis. Whether the Witness content qualifies as a business record under FRE 803(6), whether the Findings are an issuer's "statement" for FRE 801(c) purposes — these are doctrinal determinations the court makes after reviewing the artifact, not facts the artifact discloses. 2. Strategic considerations. Whether to admit, exclude, redact, or limit the use of an attestation is the court's call informed by counsel's argument. The Auditor presents; it does not advocate. 3. Substantive truth. Whether the case manager actually rescheduled the visit — the underlying historical fact — is not in the Auditor's scope. Canon proves the issuer's record of what they examined; the meaning of that record is a question for the court. The Auditor's seal commits the auditor to what is in the artifact. The court remains the trier of fact. ## Lab 26 — Stand up the Auditor The lab is in labs/ch26_auditor/. Three deliverables: ### Lab 26.1 — Run the Auditor Take any sealed attestation produced in earlier labs (Lab 7's worked example, or one you produced in your capstone). Run the Auditor against it. Verify the audit attestation itself passes the seven-step walker. ### Lab 26.2 — Read an audit as a court would Given an audit attestation produced by the lab harness, write a one-page memo answering: 1. Did all seven verification steps pass? 2. Which Daubert factors does the audit support, and which does it leave open? 3. Which declined-coverage entries would you, as opposing counsel, raise on cross-examination? 4. What information would you ask the issuer to provide that the audit alone does not contain? ### Lab 26.3 (optional) — Implement the EU AI Act overlay Extend the Auditor with the optional EU AI Act overlay sketched above. For each of Articles 11–15 and 27, emit a Claim that maps the Article to a Canon field, names whether the requirement is satisfied, and discloses gaps. The overlay must remain optional: a US-only deployment must be able to run the Auditor without it.

## Exercises ### Warm-up 1. Read the Auditor's source: meridian/canon/admissibility_auditor.py. Identify the three section-builder functions and the role each plays. 2. The Auditor declines four of the five challenge types (adversarial_prompt, consistency_check, coverage_audit, counter_evidence). Are these declines structurally correct, or could a determined adversary argue otherwise? Defend your answer in 100 words. ### Core 3. Construct a deliberately deficient target attestation that passes R1–R7 syntactically but should be flagged by the Auditor's reliability section. Run the Auditor. Confirm that the relevant gap or claim surfaces the deficiency. 4. The Auditor's _custody_breaks heuristic is intentionally simple. Read its definition, identify a real custody scenario it misses, and propose a refinement. (Cite a specific case if you can.) 5. Run the admissibility auditor on a minimally valid ObservationAttestation (use labs/ch25_verifier/fixtures/01_valid.json as a base). Record all passing and failing checks. Then remove the inference_type field from one claim and run the auditor again. Identify which auditor rule catches the missing field and which FRE provision it maps to. ### Stretch 5. Sketch an Auditor for a different doctrine. Pick a regulatory regime (HIPAA, GDPR Art. 22, ASVS for security audits) and design a section-builder that maps Canon fields to that regime's requirements. What new gaps would the section need to acknowledge? 6. The Auditor today is deterministic — the same target produces the same audit. Suppose the target contained replay-variance data showing partial non-determinism in the original enrichment. How should the Auditor present this? Write the Claim text. ## Build-your-own prompt For your capstone matter: write the audit attestation you would want a court to read first. Which authentication factors are most critical for your domain? Which Daubert factors carry the most weight? Which doctrinal questions are explicitly out of scope? The answer is one page; the page lives in your capstone's audit/ directory. ## Further reading - Meridian-Canon v0.2.0 §6.11 (the Admissibility Auditor module, including v0.2.0 audit criteria). - Daubert v. Merrell Dow Pharmaceuticals, Inc., 509 U.S. 579 (1993); Kumho Tire Co. v. Carmichael, 526 U.S. 137 (1999); FRE 702 (2023 amendment). - State v. Loomis, 881 N.W.2d 749 (Wis. 2016). - The Sedona Conference, "Navigating AI in the Judiciary" (Feb 2025). - NIST AI Risk Management Framework (AI RMF 1.0), https://www.nist.gov/itl/ai-risk-management-framework. - ABA Formal Opinion 512 (July 29, 2024) — controlling ethics authority for attorneys using generative AI. - The dossier research/05_fre707_and_ai_evidence_law.md for the rest of the legal landscape, including EU AI Act citations. - The repository's meridian/canon/admissibility_auditor.py — ~530 lines; reading it in full is itself worthwhile.

---

Next: Chapter 27 — Capstone. Build your own.