The Original File Problem: What FRE 1002 Actually Requires When Digital Evidence Is Disputed

Picture this: an adjuster photographs storm damage on day one. Three months later, those photos live on a carrier's cloud backup. At deposition, opposing counsel asks whether the photos produced in discovery are the originals or backup copies. The adjuster can't say with certainty. The phone was replaced. The cloud platform may have applied compression. Opposing counsel moves to exclude on best-evidence grounds.

This is the FRE 1002 problem for digital evidence. It comes up more than practitioners expect.

What the Best Evidence Rule Requires

FRE 1002 states that to prove the content of a writing, recording, or photograph, the original is required.

FRE 1001(d) defines "original" for electronic evidence: the recording itself, or any counterpart intended to have the same effect. A digital photograph is its original byte sequence. A compressed copy, a re-encoded version, or a file that passed through a platform's processing pipeline may or may not be the same item.

FRE 1003 provides practical relief: a duplicate is admissible to the same extent as an original unless a genuine question is raised about the original's authenticity, or admission would be unfair. Courts don't exclude duplicates automatically. But once opposing counsel raises a credible authenticity question, the burden shifts to the proponent to answer it.

FRE 1004 allows other evidence when the original has been lost without bad faith, is unobtainable through judicial process, or is in an opponent's possession. None of these provisions resolve the core problem: when the proponent can't establish that the file they're offering is byte-for-byte identical to what they originally captured, the authentication question stays open.

Where Digital Evidence Creates the Gap

The gap isn't usually fraud. It's workflow.

A claims professional photographs a flooded warehouse. The photos go from camera roll to email to a shared drive to a claims management system. Each step is an opportunity for platform compression, automatic re-encoding, or metadata stripping. By the time litigation starts two years later, the "original" may not exist on any accessible device. What's available is a cascade of copies.

Under FRE 1003, any of those copies can be attacked. Opposing counsel doesn't need to prove the copies were tampered with. They need to raise a genuine question. That question is easy to raise when the chain between device and courtroom has several unmonitored steps.

And most claims workflows have no point where anyone asks: is this still the file we started with?

The file doesn't remember.

What a Hash Establishes

A SHA-256 hash is deterministic. The same file always produces the same hash. A file that has changed by even one byte produces a completely different hash. This is not metadata. It's not a field someone typed into the file's header. A hash is a mathematical output derived from the entire byte sequence of the file.

When a file is hashed and that hash is anchored to a public blockchain, two things become independently verifiable later: the exact byte content of the file at the time of anchoring, and when that hash was committed to the chain.

When the file is produced in discovery, hash it again. If the output matches the on-chain record, the authenticity question under FRE 1003 has an answer. The file hasn't changed. Not one byte. That's math, not testimony.

I built ProofLedger to anchor hashes to both Polygon and Bitcoin because single-chain verification leaves the process-reliability argument on a single foundation. Two independent public ledgers, both recording the same hash, make the FRE 901(b)(9) case considerably stronger. The public verify endpoint at proofledger.io/verify.html is accessible to any third party without authentication, which matters when opposing counsel or a court-appointed examiner wants to check the hash independently.

Laying the Authentication Foundation

Introducing a hash comparison at trial requires its own evidentiary foundation. FRE 901(b)(9) is the mechanism: authentication via evidence produced by a process or system that generates an accurate result. The blockchain anchoring process, with deterministic cryptographic operations and a public ledger record, fits that framework.

FRE 902(13) allows self-authentication of machine-generated records via written certification, eliminating the need for live expert testimony. That matters in budget-constrained litigation where an expert deposition is a real cost.

This isn't automatic. The proponent still needs to establish what SHA-256 does, what the blockchain record represents, and how the verification process works. But that foundation is available and defensible. EXIF metadata doesn't have an equivalent foundation. It can be changed after the fact. The on-chain hash record cannot.

What This Means Monday Morning

Three practical steps:

Hash and anchor at capture. The gap between file creation and anchoring is the gap opposing counsel will attack. Don't wait until the claim is filed.

Keep the original file. The hash proves the file hasn't changed, but only if the original still exists to re-hash. Platform compression shouldn't be the only surviving copy.

Brief your documentation team on the FRE 1003 attack surface. The question "is this the original file?" should have a reliable answer at every stage of a claim. In most workflows right now, it doesn't.

The best evidence rule was designed for paper. Digital files have properties paper doesn't: they copy silently, platforms alter them without notice, and the chain between capture and courtroom is long. An on-chain hash is the one thing that can answer the original-versus-copy question with something other than "I think so."