"Checksum verified" is not a yes-or-no question
Studios want MHL manifests. DITs want verified copies. But 'verified' means different things depending on when and how you hashed. Here's what each level of evidence actually proves.
The brief says “all media must be checksum verified with ASC MHL manifests.” The DIT nods, runs the copy, gets green checkmarks, and ships the drives. Everyone’s happy.
Six months later, a file is corrupted. The MHL says it was verified. How is that possible?
Because “verified” isn’t one thing. It’s a spectrum, and the difference between “we hashed during copy” and “we independently verified the source, the copy, and the read-back” is the difference between evidence and assumption.
What an MHL manifest actually is
At its core, an MHL is a file that lists other files alongside their cryptographic hashes. If you hash the file now and the result matches the manifest, the file hasn’t changed since someone created that entry.
That’s the entire guarantee. The file you have is identical to the file that existed at hash time. No more.
The generation chain
ASC MHL v2 adds generations. Each transfer or verification creates a new numbered manifest. A chain file links them together with tamper-evident hashes. You can trace the history: hashed on the truck at 14:32, copied to the RAID at 14:35, shipped to post at 09:15 the next morning. Each step matches.
This is genuinely powerful. But it only proves what you checked, when you checked it.
The gaps
Gap 1: you didn’t hash the source independently. Most tools hash during the copy; the hash is computed from bytes as they leave memory. The five-phase copy pipeline exists precisely to close this gap. This proves what left the machine. It doesn’t prove the source card was healthy. If the camera had a firmware bug that wrote corrupted frames, you faithfully copied and verified the corruption. Every checkmark is green. The footage is still broken.
Gap 2: you hashed during write but didn’t read back. A write-hash proves what your software sent to the drive. It doesn’t prove what actually landed on the disk. Silent write errors (bit-rot, firmware bugs, cable faults) happen after the data leaves memory. Only a read-back hash catches them.
Gap 3: you verified once and assumed permanence. An MHL proves a file was good at the time of hashing. Drives degrade. Connectors get bumped during shipping. A verification from three months ago doesn’t mean the file is good today.
The levels
Not all verification is equal. Here’s what each approach actually proves:
- Write hash only: the software wrote the correct bytes into the write buffer. Catches software bugs. Doesn’t catch hardware issues.
- Read-back verification: the destination was re-read and matched the source. Catches write corruption. The strongest single-pass evidence.
- Independent source hash: the source was hashed before copying, establishing a known-good baseline. Catches pre-existing corruption.
- Cascade verification: a verified copy was used as the source for further copies. Extends the chain without re-reading the original.
- Cross-pass verification: a hash from an independent second read of the source matches the first. Catches intermittent read errors.
| Level | Evidence | Proves | Gap |
|---|---|---|---|
| Write hash | Hash computed during write | Software wrote correct bytes to write buffer | Doesn't catch hardware write errors |
| Read-back | Destination re-read, hash matched source | What landed on disk matches what was read from source | Doesn't prove source was good before copy |
| Independent source | Source hashed before copy began | Source was healthy at time of first observation | Doesn't prove source was healthy before that moment |
| Cascade | Verified copy used as source for further copies | Chain extends without re-reading original | Trusts the original verification |
| Cross-pass | Independent second read matched first | Source is consistently readable | Doesn't catch corruption that happened after both reads |
What to actually do
For critical media: hash the source before copying, stream-copy with inline hashing, read back and verify each destination, record everything in the MHL chain. Yes, it’s slower. The source read adds time. But it closes the gap between “we think the copy is good” and “we can prove the source was good, the copy matches, and the destination reads back correctly.”
Your tools should make it clear which level of verification you’ve achieved. Not just a green checkmark, but which phases ran and what evidence they produced. DITs who wrote their own scripts understood this instinctively: trust comes from knowing exactly what the tool did. When you hand off drives with an MHL chain, you should know exactly what you’re claiming.