Evidence
Manifest & Chain of Custody: Auditable Records Control

Category: Evidence Preservation, Records Control
& Auditability

When an investigation, audit, or consolidation effort touches more
than a handful of files, “we collected everything” is a claim that needs
to be provable, not just stated. This case study covers a real
evidence-consolidation effort spanning over a thousand files pulled from
more than a dozen separate sources, and the manifest discipline that
made every one of those files independently verifiable.

The Problem Being Solved

A multi-source log and document consolidation effort needed to answer
three questions for every single file it touched, at any point in the
future:

1. Where did this file originally come from?
2. Has it changed since it was collected?
3. Can someone else, given only the manifest, verify they have an
   exact, unaltered copy?

The Manifest Structure

Every file collected was recorded in a single flat manifest with five
fields:

Field	Purpose
source	Which original source location the file came from
relative_path	The file’s path within that source
size_bytes	File size, as a first-pass integrity check
sha256	A cryptographic hash - the actual proof that a copy is byte-for-byte identical to the original
note	Free-text annotation (e.g., flagging a naming collision or an unusual finding about that specific file)

Illustrative sample (not the real manifest rows -
fictional filenames used for demonstration):

source,relative_path,size_bytes,sha256,note
"instance-a","catalina.2020-04-13.log",197437,86fdc03a...,""
"instance-a","tomcat8-stderr.2020-04-13.log",197510,a72bd48e...,""
"instance-b","access_log.2019-09-24.log",19532,f1c9a2d4...,"genuine log bundle - see note on naming collision"
"instance-c","access_log.2019-09-24.log",10485000,3b7e91aa...,"same filename as instance-b but NOT a duplicate - this is a data export misnamed with a log-style filename"

Across the real effort, this manifest catalogued 1,043
files, and the governing rule was strict: every file was
copied, never moved, from its original location, so the source
location itself remained untouched as an independent point of
verification.

The
Naming-Collision Finding Is the Best Argument for Doing This

During consolidation, two files from different sources were found to
share an identical filename - the kind of coincidence that,
without a manifest, could easily cause someone to grab the wrong file
during a future incident and never know it. Because every file was
hashed, the collision was caught immediately: same name, same apparent
file type, completely different hash, different size, and - on
inspection - different content entirely (one was a genuine log bundle;
the other was an unrelated data export that happened to have been named
in the same style). Without the hash, this would have been invisible.
With it, it became a one-line footnote instead of a future incident.

Why This Is a Reusable
Control

1. Hashing turns “we have a copy” into “we can prove it’s the
   same file.” Size alone catches gross corruption; a
   cryptographic hash catches everything else, including the far more
   common case of two files that merely look alike.
2. A manifest should travel with the evidence, not be an
   afterthought. Any time a bundle of files is shared externally -
   for support, for audit, for a handoff to another team - attaching the
   manifest alongside it means the recipient can independently verify what
   they actually received, rather than trusting the sender’s word.
3. Copy-only preservation keeps the original as a
   fallback. Because nothing was deleted or modified at its
   original location, the manifest’s hashes could always be independently
   re-verified against the source, even after consolidation was
   complete.

Takeaway for Clients

Any organization handling evidence, records, or files that may need
to be defended later - audit findings, legal holds, incident response
artifacts, compliance documentation - benefits from the same discipline:
a flat manifest with source, path, size, and a cryptographic hash for
every file, generated at the moment of collection rather than
reconstructed after the fact.