Chain of custody for digital writing evidence: what the legal standard requires and how sealed records meet it

What this review covers

Debates about writing evidence in academic integrity cases rarely engage with the legal standard those records may eventually need to meet. When a student appeals to an external ombuds, challenges a finding in court, or contests an employment decision, the question shifts from "what did the instructor believe?" to "what does the evidence actually establish?" At that point, the relevant framework is chain of custody — the legal and forensic doctrine requiring that evidence be traceable from collection to presentation in a way that proves it hasn't been altered.

This review examines what chain of custody requires for digital documents, how the most common forms of writing evidence — version history, screenshots, export PDFs — perform against that standard, and what a cryptographically sealed process record establishes that those alternatives cannot.

---

The legal foundation: FRE Rule 901 and the authentication requirement

The Federal Rules of Evidence set the baseline for US courts, and Rule 901 is the authentication rule. Its core language is precise: "To satisfy the requirement of authenticating or identifying an item of evidence, the proponent must produce evidence sufficient to support a finding that the item is what the proponent claims it is."

For a physical document, authentication typically means a witness who recognizes it. For a digital document, authentication requires more: you must show the file is the file it claims to be, that it hasn't been modified since the event it purports to document. Rule 901(b)(9) explicitly covers "process or system" evidence, requiring a showing that the system "produces an accurate result."

The practical standard in digital forensics is set by NIST SP 800-86, the Guide to Integrating Forensic Techniques into Incident Response. NIST's recommendations for handling digital evidence are built around three principles: preserve the original (use write-blockers during acquisition), document the chain of custody (who handled the evidence and when), and verify integrity using cryptographic hashing — computing the hash of the evidence at acquisition and re-verifying it at every subsequent stage. A hash mismatch at any point is a red flag that the evidence may have been altered.

These requirements were not designed for academic integrity cases, but they define the standard any evidence must meet if it ends up in a formal proceeding. The question is how writing evidence currently collected in education performs against them.

---

How version history fails the standard

The most commonly cited form of writing evidence in academic integrity cases is version history — the revision logs maintained by Google Docs, Microsoft Word, and similar platforms. The appeal is obvious: version history is automatic, always-on, and shows the document changing over time. It looks like a process record.

It is not chain-of-custody-grade evidence for three reasons.

First, version history is mutable. Google Docs does not expose a publicly documented API for inserting or deleting revision history entries, but the DocuSim project (publicly available on GitHub) demonstrates that a functional replica of Google Docs revision history — indistinguishable in appearance from a genuine log — can be generated and presented in a browser. Microsoft Word's revision history lives in the Open XML file format, which is a ZIP archive of structured XML files. Anyone with file system access can modify those XML files, and the modification is not automatically detectable by a reader viewing the document in Word. Neither format computes or stores a cryptographic hash of the revision history itself.

Second, there is no chain of custody. When you present a Google Docs version history, you are presenting a screenshot or export of data that Google controls. There is no verifiable record of who accessed the document between the writing event and the presentation of the evidence. A malicious actor with account access could have modified the document; there is no hash to compare.

Third, screenshots are weaker still. A screenshot of version history is a screenshot — it can be fabricated with a text editor in minutes. This is not a theoretical concern. UK higher-education ombuds casework notes from the OIA explicitly caution institutions not to over-rely on version history as evidence of authentic authorship, noting that such records "may not be sufficient on their own to establish whether AI has or has not been used."

---

What hash-chained sealed records establish

NIST SP 800-86 recommends that digital evidence be hashed at acquisition — that is, at the moment it is collected, before it can be modified. The hash is a mathematical fingerprint of the content: a fixed-length string produced by running the content through a cryptographic function (SHA-256 is current standard). If a single byte of the content changes, the hash changes. Any verifier — not just the original collector — can recompute the hash and compare it to the stored value. If they match, the content is identical to what was collected. If they don't, something changed.

A hash chain extends this further: each record in the chain includes the hash of the previous record. Altering a record in the middle breaks all subsequent hashes in the chain. To forge a hash chain convincingly, an attacker would have to recompute every subsequent record from the point of tampering — and if the chain has been published or anchored in an external system, there is a reference point that cannot be retroactively altered. A timestamp token from an RFC 3161-compliant timestamp authority, or a hash included in a signed document published to a third-party registry, creates a reference tied to real-world time that exists outside the control of the evidence holder — the timestamp authority or registry holds an independent record that cannot be revised even if the original evidence holder wanted to revise it.

Crossley et al. (2024) demonstrated that keystroke-log data can distinguish authentic writing from transcribed text with 99% accuracy. That result depends on the keystroke log being trustworthy — on there being a reliable record of how the text came into being. A hash-chained process record is the infrastructure that makes such a log trustworthy as evidence, not merely as a research dataset.

---

The three requirements for chain-of-custody-grade writing evidence

Drawing on FRE 901, NIST SP 800-86, and the OIA's casework guidance, three requirements emerge for writing evidence that can withstand challenge in a formal proceeding:

1. Integrity: There must be a cryptographic proof that the content hasn't changed since collection. This means a hash computed at capture time and verifiable by any party. Version history and screenshots do not meet this requirement. A sealed record with a published hash does.

2. Attribution: The record must document who captured it, on what system, at what time. This is the chain of custody element: not just that the evidence exists, but that its provenance is traceable and any handling is documented. A record sealed inside a cloud platform with no external anchor is weaker than one with a signed certificate or third-party timestamp.

3. Continuity: The record must cover the claimed period without unexplained gaps. A process record that shows ten minutes of writing for a 3,000-word essay is not a continuous record; it's a fragment. Chain of custody requires not just that the evidence is authentic, but that it covers what it purports to cover.

---

Why this matters beyond academic cases

The chain of custody standard applies wherever document origin is contested. Employment disputes over who wrote a deliverable, IP ownership claims in collaborative software projects, contract authorship in partnership disputes — all involve digital documents whose integrity and provenance are contested. Courts applying FRE 901 (or its counterparts in UK civil procedure, EU member-state law, and arbitration rules) will ask the same three questions: is this record authentic, who held it, and does it cover the claimed period?

Writing that matters — not just student assignments, but research, code, contracts, and creative work — benefits from evidence that was built to meet this standard before any dispute arose.

---

What the literature does and does not establish

Claim	What it rests on	Status
FRE 901 requires digital evidence to be authenticated	Rule 901 text (Cornell LII)	Established
Authentication requires showing content hasn't been modified	Rule 901(b)(9); NIST SP 800-86	Established
NIST recommends cryptographic hashing for digital forensic evidence	NIST SP 800-86	Established
Version history can be fabricated or modified	DocuSim demonstration; Word Open XML analysis	Demonstrated (proof of concept)
OIA cautions against over-reliance on version history	OIA casework note	Established (regulatory guidance)
Process data can distinguish authentic writing with high accuracy	Crossley et al. 2024, 99% accuracy	Established (experimental)
Sealed process records have been tested in actual court proceedings	Not yet found in literature	Gap — not yet established
Hash-chained records meet FRE 901 authentication requirements	Logical extension of NIST standards	Well-founded but not yet litigated

The most important gap is the last two rows. The cryptographic argument for sealed process records is well-founded — it is a direct application of NIST-recommended forensic practice to writing capture. But controlled tests of sealed writing records in actual judicial or formal tribunal proceedings have not yet been published. The standard that such records are designed to meet is clear; the litigation track record is still being built.

---

Authmarks is designed to produce chain-of-custody-grade writing evidence from the capture event through verification — sealed with a cryptographic hash at submission time, verifiable by any party without access to the original system.

It is worth acknowledging that chain of custody for writing evidence is a developing area of practice. NIST SP 800-86 and FRE Rule 901 provide the closest applicable standards, but both were designed for different evidence types — incident-response artifacts and physical documents respectively — and neither addresses writing-process records specifically. Institutions evaluating tools in this space should assess each system against the three concrete requirements set out above (integrity, attribution, continuity) rather than accepting a vendor's characterization at face value. A sealed record that meets all three provides a defensible evidentiary foundation; a record that meets only one or two may still be useful as corroborating context while falling short of chain-of-custody-grade authentication.

Related reading:

• Tamper-evident vs. tamper-proof: what actually protects a writing record
• What is C2PA content credentials?
• Google Docs version history as proof — what it shows and doesn't
• Keystroke logging and writing-process research
• How to read a process record
• Process data in integrity cases