The Crisis of Personal Digital Evidence

A document not retrievable, an inference not falsifiable, a chain not verifiable — these are not evidence. They are reading material.

The Overture introduced an attorney with fifteen minutes and a phone full of evidence. This chapter names the problem she was facing in language the rest of the book will use, and asks what it would take to fix it.

At a glance

• A modern adult produces between $10^5$ and $10^7$ retained digital records over a decade. No human can read them; no traditional search can find what matters; no current tool can prove the answer is complete.
• Three properties — comprehensiveness, accuracy, verifiability — must hold together. Existing tools achieve at most two.
• Verifiability without issuer cooperation is the load-bearing constraint of this book and the load-bearing innovation of the Meridian-Cannon system you are about to learn.

Learning objectives

By the end of this chapter, you should be able to:

1. Name and distinguish the three required properties — comprehensiveness, accuracy, and verifiability — and explain why achieving any two without the third fails in evidentiary practice.
2. Identify the integration problem, the explanation problem, and the verifiability problem as three independently sufficient failure modes in personal digital evidence.
3. Describe what "verifiable without issuer cooperation" means operationally, and contrast it with conventional signature schemes.
4. Read a Canon Attestation's four blocks — Witness, Findings, Refutation, Seal — and locate, for each block, what it commits the issuer to and how a recipient would detect a failure.
5. Articulate why the three properties require each other, using at least one concrete example from the running case.

The running case

☉ In the Wild — Harrow County, 2026: evidence on a phone, fifteen minutes.

The scene is the Overture's. We return to it throughout the book.

Isabel is on the witness stand in a termination of parental rights proceeding in Harrow County Circuit Court, Wisconsin — matter number 2024JC000099. The State has just produced seventeen "missed" visits. Isabel's attorney has her phone. Ten of the seventeen visits were rescheduled by the agency by text message. The phone holds the proof. The attorney has fifteen minutes.

Isabel's evidence is distributed across at least six private systems: iOS Messages, two Gmail accounts, a Dropbox folder of forwarded screenshots, a Notes app of personal logs, and a calendar the agency itself provided. None of those systems speak to any of the others. None of them index across each other. None of them, presented to the court, can be verified without Isabel's full cooperation.

The truth is on the phone. The phone is functionally unsearchable.

(The case is fictional in detail and composite in nature. It is not the author's own. The discipline it teaches is general.)

What broke

Three failures, each independently sufficient to produce the lost courtroom afternoon.

Failure 1 — Nothing connects the sources

Isabel's records lived in iOS Messages, two email accounts, a Dropbox of forwarded screenshots, a Notes app of personal logs, and a calendar app she maintained by hand. No tool she had access to could query these jointly. A text message exchanged with a case manager, an email three days later confirming the cancellation, and a calendar entry Isabel updated to reflect the new time all existed, but they could not be retrieved together by any operation any tool would let her perform.

This is the integration problem. Evidence work, viewed naïvely, is the problem of finding documents. In practice it is the problem of assembling correlated sets of documents from heterogeneous sources. The sources rarely share identifiers, schemas, time conventions, or normalization disciplines.

▼ Why It Matters. A judge ruling on a contested visitation record does not have time to reconcile six message systems. The proponent of evidence either presents the reconciliation, intact and verifiable, or proceeds without it. The integration problem is not a back-office inconvenience; it is a front-of-courtroom evidentiary defect.

Failure 2 — Keyword search is inadequate at scale

Isabel's attorney searches the phone: reschedule, moved, can't make it. These are exactly what a careful searcher would think to ask. The cancellations from the agency's caseworkers were phrased as can we push back to, unfortunately we'll have to do, checking on whether, I'm out tomorrow can we do. These are all the same act. None of them share a keyword.

Modern semantic retrieval — embedding-based search — papers over this gap. Systems trained on enough text learn that push back and reschedule live in a similar region of meaning, and a query for "rescheduled visit" can return the push back match. (Chapter 9 walks through how. Chapter 10 explains how to combine semantic search with old-style keyword search to get the strengths of both.)

But there is a price. Once retrieval is mediated by a 137-million-parameter neural network whose decisions cannot be meaningfully introspected, a new question arises: by what right does the attorney offer those retrieved documents into evidence as the documents the parent was asked to produce? What is the basis for the claim that the retrieval captured what mattered — and equally, that it did not silently omit what would have hurt the parent's case?

This is the explanation problem. Conventional retrieval systems return ranked lists with no explanation of why each result was ranked where it was. The lists are useful as suggestions; they are not yet evidence.

◆ Going Deeper — Why a 137M-parameter model resists introspection.

A bi-encoder retrieval model maps each document and each query to a point in high-dimensional space. The model is trained, with millions of (query, relevant-document) pairs, to put relevant pairs close together under cosine similarity. The "decision" that document $d$ is the third-most-relevant for query $q$ is the inner product of two vectors of 768 or 1024 floating-point numbers. There is no human-readable rule the model is following; the rule is the consequence of the training data and the architecture, none of which is itself legible at the per-decision level. Recent work on mechanistic interpretability has begun chipping away at this opacity, but no production retrieval system in 2026 ships with the per-retrieval explanation a court would recognize. (Dossier 03, RAG eval and verifiable retrieval, surveys the state of the art.)

Failure 3 — AI-assisted output is unverifiable

Suppose, generously, that a competent retrieval system could be configured against this corpus, that it would surface the ten relevant cancellations, and that the attorney could place them before the court in the fifteen minutes available. Now place yourself on the other side of the table.

You are opposing counsel. You ask: by what process did this system retrieve these documents? Trained on what data? Tested against what ground truth? What documents in the parent's archive would have matched the query in your client's favor and were excluded? Did the model encode any prior preference about communications between case managers and parents? What was the system's recall on a held-out set of known-relevant items?

A system that cannot answer these questions on the record is not producing evidence. It is producing suggestions.

This is the verifiability problem, and it is the one this book is principally concerned with.

☉ In the Wild — Mata v. Avianca.

In June 2023, attorneys representing a personal-injury plaintiff filed a brief in the Southern District of New York that cited six judicial decisions. None of the six existed. The attorneys had used ChatGPT to research the brief; ChatGPT had hallucinated the citations; counsel had not verified them. The court imposed $5,000 in sanctions under Federal Rule of Civil Procedure 11.

Mata v. Avianca, Inc., 678 F. Supp. 3d 443 (S.D.N.Y. 2023), is the opening of the case-law line that established attorneys are responsible for the AI tools they use. The line continues through Park v. Kim (2d Cir. 2024), which made the rule Second Circuit precedent without any new local rule, and escalates through Johnson v. Dunn (N.D. Ala. July 2025), in which the court declined monetary sanctions in favor of public reprimand, disqualification, state-bar referral, and mandatory client/court notification. "Modest fines have proven insufficient." (See Appendix C and dossier 05.)

The size of the corpus

The parent's example is small. A typical adult in 2026 has accumulated, over a decade:

Source	Order of magnitude
SMS / iMessage	$10^5$
Email (across all accounts)	$10^4$–$10^5$
Photos	$10^4$–$10^5$
Documents (cloud + local)	$10^3$–$10^4$
Voice messages	$10^2$
Calendar entries	$10^4$
Browser history	$10^6$
Financial transactions	$10^4$
Location pings	$10^7$

For an individual involved in long-running litigation, the figures lean to the upper end. The corpus enumerated in the Meridian-Canon specification this book builds toward sits at $2.5 \times 10^5$ to $4 \times 10^5$ primary documents, distributed across the dozen sources listed there. After semantic chunking of long documents, the index covers between half a million and a million retrievable segments.

This is not an unusual corpus. It is a typical corpus.

✻ Try This. Open your phone. Scroll to the oldest text message conversation you have not deleted. Note the date. Estimate, by tens, how many messages have passed through your phone in the years since. Now, without searching: name three messages that, if they were contested in court tomorrow, you would need to find. The three are almost certainly there. You almost certainly cannot find them in fifteen minutes.

The three properties that must hold together

Any system that hopes to address the failures above must achieve three properties at once.

1. Comprehensiveness. The corpus must cover, demonstrably, every source the case turns on. A source not registered cannot be retrieved from. (Chapters 13–16, the procedural-legal substrate.)

2. Accuracy. The system's structured interpretations of what each document says must be correct, in the sense an attorney or auditor can defend on the record. (Chapters 11–12, structured extraction and adversarial validation.)

3. Verifiability. Every output the system produces must be checkable, by an outside party, without trusting the system or the operator. The check must yield a definite verdict, and it must be performable by anyone with ordinary network access. (Chapters 4, 5, 6, 7, 25 — the cryptographic spine.)

Existing tools achieve at most two. Comprehensive ingestion tools (e-discovery suites, forensic acquisition platforms) have weak retrieval and produce no signed output. Strong retrieval tools (vector databases, modern enterprise search) do not reach private personal sources and produce no signed output either. Tools that produce signed output (digital-signature toolkits, document-management systems) do not speak the vocabulary of evidentiary substrate (matters, parties, productions, holds, privilege).

The premise of this book is that the three properties can be achieved together if you accept a particular kind of constraint: every output of the system is structured as a Canon Attestation — a four-part record of Witness, Findings, Refutation, and Seal — designed to be falsified by anyone, without your help.

Why "verifiable without issuer cooperation" matters

The phrase recurs throughout this book; it is worth slowing down on now.

A signed PDF is verifiable in a sense: the recipient can check the signature against the certificate authority's public key. But the recipient is also asked to trust a chain of intermediaries (the certificate authority, the timestamp authority, the issuer's identity-verification process) and, when the document content is challenged, to trust the issuer to produce records of how the document was generated.

Evidentiary verification needs more than this. The recipient must be able to:

• Re-hash the underlying source bytes and confirm they match the hash recorded in the artifact.
• Resolve every claim the artifact makes back to a specific observation of those bytes.
• Confirm that the issuer's adversarial-validation harness was actually run, by checking the inventory of applied and declined challenges built into the artifact.
• Verify the cryptographic signature using only the issuer's public key, fetched from a stable URL, without requiring the issuer to log in to anything.

A protocol that supports this sequence end to end — and that, at every step, is designed so the recipient can either succeed or catch the issuer in a falsehood — is what we mean by verifiable without issuer cooperation.

§ For the Record — The seven-step protocol (Canon §14).

1. Fetch the issuer's public key; verify its SHA-256 fingerprint.
2. Verify the Ed25519 signature over PAE(payload_type, JCS(attestation)). > 3. Recompute the chain hash via RFC 8785 canonicalization; confirm it matches chain_hash. > 4. Re-hash every Witness entry's content. > 5. Resolve every Claim's supports. > 6. Resolve every Challenge's targets. > 7. Review the coverage.declined inventory (informational).

A recipient possessing an attestation and ordinary network access can reach a definitive valid/invalid verdict on steps 1–6 without any cooperation from the issuer. Step 7 is the recipient's substantive review.

The Canon specification (Chapter 4) is one such protocol. There are others, surveyed in Appendix E: Sigstore Rekor for software artifacts, in-toto for build provenance, C2PA for media authenticity, the W3C Verifiable Credentials family for issuer-signed claims. They share a structural approach: signed artifact, recoverable hashes, deterministic verification protocol, the issuer never in the verification loop.

What is novel about Canon, and what makes it the focus of this book, is the addition of epistemic structure — typed claims, declared gaps, applied-and-declined adversarial challenges — to the cryptographic envelope. Sigstore can tell you a binary was signed; it cannot tell you what the signer believed about the binary, nor what they tried and failed to disprove. Canon can.

▼ Why It Matters — for the Receiver. The four blocks of a Canon attestation map cleanly onto the questions admissibility doctrine asks. Witness handles authentication (FRE 901). Content_ref handles best evidence (FRE 1002). Findings + supports handles hearsay analysis (FRE 803/804). Refutation handles reliability (FRE 702 and proposed 707). Coverage.declined handles disclosure (FRCP 26, ABA Formal Op. 512). Chapter 26 (Admissibility Auditor) walks each of these.

What this means for your practice

The system you are about to build ingests email, indexes embeddings, runs a hybrid retrieval, prompts a local language model. None of those operations are novel. What is novel is the composition. At every layer boundary, the system emits a Canon Attestation: an immutable, signed record of what was done, by what method, supporting what claims, with what gaps acknowledged, and what challenges applied or refused. That composition transforms a routine engineering exercise into something with a different epistemic status.

By the end of Part V, the operative question — for any of the five readers (Overture) — when reviewing any AI-assisted system, will not be "does it work" but rather:

• Could a recipient who does not trust me verify its outputs?
• Could a recipient who does not trust me catch me lying?

Most systems you will encounter in your career will fail this test. You will know one — built it, audited it, used it, regulated it, or been the subject of it — that passes.

Working example — what a Canon Attestation looks like

We will not unpack this fully until Chapter 4. For now, the structure is the point.

{
  "canon_version": "0.2.0",
  "attestation_id": "01JABC...",
  "kind": "enrichment",
  "issued_at": "2026-05-01T12:34:56.789012Z",
  "issuer": "did:example:meridian/J.P.White",
  "matter_id": "2024JC000099",
  "subject": "Rescheduling text from case manager 2024-03-14",
  "witness": [{
    "observation_id": "obs-01JAB...",
    "source": "imessage://chat.db/handle:+16125551212/2024-03-14T19:21:00Z",
    "received_at": "2026-04-30T18:00:00.000000Z",
    "content_hash": "sha256:f4c9...a2b3",
    "content_ref": "file:///vault/2026/04/30/obs-01JAB.txt"
  }],
  "findings": {
    "method": "imessage_extractor.py v0.4.2",
    "claims": [{
      "claim_id": "claim-01",
      "statement": "The message rescheduled the visit from 2024-03-14 to 2024-03-21 with under 24h notice.",
      "supports": ["obs-01JAB..."],
      "inference_type": "deduction",
      "gaps": ["Sender identity verified only by phone number; could be a pool number reassigned."]
    }]
  },
  "refutation": {
    "challenges": [
      {"challenge_id": "chal-01", "type": "adversarial_prompt",
       "targets": ["claim-01"], "input": "...",
       "outcome": "survived",
       "model_outcomes": {"M1": "survived", "M2": "survived", "M3": "revised"},
       "consensus_outcome": "survived"}
    ],
    "coverage": {
      "applied": ["adversarial_prompt", "consistency_check", "replay"],
      "declined": [
        {"type": "counter_evidence", "reason": "no_negation_search_implemented_for_imessage_extractor"},
        {"type": "coverage_audit", "reason": "deferred_to_batch_pass"}
      ]
    }
  },
  "seal": {
    "payload_type": "application/vnd.nora.canon.attestation+json; version=0.2.0",
    "payload": "<base64url-encoded JCS bytes>",
    "signatures": [{
      "keyid": "sha256:7c11...8901",
      "sig": "MEQCIQ...",
      "public_key_url": "https://keys.example.org/acme-corp-2026/ed25519.pem"
    }],
    "chain_hash": "sha256:09a1...d2ef"
  }
}

(The did:example:... format is a placeholder for a Decentralized Identifier — a globally unique URI for the issuer. In practice, meridian-canon keygen produces the issuer string from the custodian name and public key fingerprint. The DID format is not required by the Canon spec.) Spend a moment on the four blocks. The Witness block names the message and binds it to a specific byte-stream by hash. The Findings block makes a single claim and explicitly declares its assumption. The Refutation block records what was tested, what wasn't tested, and why what wasn't tested wasn't. The Seal block commits the issuer to all of the above, in a form anyone can verify with the public key at the listed URL. This is the artifact this book teaches you to produce, to read, to audit, to regulate, and to recognize when it is missing.

## Exercises ### Warm-up 1. List five categories of personal digital records you produce that no employer-managed or agency-managed system has access to. For each, name the format the records are in and the size of your archive. 2. Pick a recent factual disagreement you've had with someone — anything from a missed meeting to a dispute about who said what. List the digital artifacts that, if collected and presented coherently, would have settled it. List the steps you would have had to take to assemble them. ### Core 3. Re-read the worked example above. For each of the four blocks (Witness, Findings, Refutation, Seal), name one thing it would mean for the block to be "wrong." Then name one way the recipient could detect that wrongness without contacting the issuer. 4. Find a recent news story about an AI system being used as evidence in a court proceeding (start with the case law in research/05_fre707_and_ai_evidence_law.md). Identify, from the reporting, which of the three properties (comprehensiveness, accuracy, verifiability) the system in question achieved and which it did not. Write 200 words. 5. Open docs/textbook/appendices/B_worked_attestation.md. Identify which of the four admissibility doctrines (authentication, hearsay, best evidence, privilege) the seal block addresses and which the witness block addresses. Write one sentence for each doctrine explaining which Canon field provides the evidentiary foundation.

Stretch

5. The Canon Attestation above declines two challenge types. Suppose you are opposing counsel cross-examining Isabel's technical expert. Draft three questions the declines invite. For each, identify which specific field in the JSON gives you standing to ask it. (You will return to this exercise in Chapter 26.)
6. The ▼ sidebar above notes that the four Canon blocks map onto four areas of admissibility doctrine (authentication, best evidence, hearsay, reliability). Pick one of the four mappings and argue the other way: identify a scenario in which the block's presence would not satisfy the doctrine it is claimed to address. What would the issuer need to add to close the gap?

Lab 1

There is no lab for Chapter 1. The labs begin in Chapter 5, where the cryptographic primitives begin. For now, install the reference repository and confirm the test suite passes:

git clone https://github.com/<TBD>/Meridian-Cannon.git
cd Meridian-Cannon
pip install -e ".[test]"
pytest -m "not db"

If the test suite passes, you are ready for the rest of the book.

Build-your-own prompt

What corpus, in your life or your work, would you want to make Canon-conformant first? Write a paragraph naming it, the harm that arises from the fact that it currently isn't, and the recipient who would care if it were. Save the paragraph; you will return to it in Chapter 27.

▼ Why It Matters — Three questions for the bench.

A judge who receives a Canon attestation as an exhibit can apply three questions before ruling on admissibility: (1) Does it verify? Ask the proponent to run meridian-canon verify in open court or provide the verifier output as a declaration. A valid result with seven green steps is the threshold requirement. (2) Is the acquisition date plausible? The witness.received_at field records when the source was ingested. Cross-reference it against the timeline of the case. (3) What does the system claim it cannot prove? The findings.claims[*].gaps array and refutation.coverage.declined count show what the system explicitly did not determine. Empty gaps and zero declined challenges are a signal to probe further. Chapter 26 provides a systematic checklist. ## Further reading - Meridian-Canon v0.2.0 §1 (Executive Overview) and §2 (Reading Guide). Both written for the same audience as this book. - Federal Rules of Evidence 901, 902, 803/804, 702. Cornell Legal Information Institute has them online; read the text before reading commentary. - Mata v. Avianca, Inc., 678 F. Supp. 3d 443 (S.D.N.Y. 2023). The opinion is short and worth reading directly. - Park v. Kim, 91 F.4th 610 (2d Cir. 2024). The Second Circuit's terse extension of Mata: attorney sanctions for AI-fabricated citations are Rule 11 sanctions, no local rule required. - RFC 8785, "JSON Canonicalization Scheme (JCS)." The IETF standard Canon uses to produce byte-identical serializations for signing. Short enough to read in full; important enough to read before Chapter 5. - In re Best Evidence, FRE 1001–1008 generally, and in particular the Advisory Committee Notes to FRE 1001(c) on electronically stored information. These notes describe what "an original" means for digital records — the question Isabel's case turns on. - The dossier research/05_fre707_and_ai_evidence_law.md — the rest of the legal landscape, with citations.

---

Next: Chapter 2 — Falsifiability as a Design Principle.