Passed at Build Time Is Not Passed at Send Time

2026-10-05 · Philip Choo · AI9OS

A delivery pack is built. Every check runs: the branding is right, the citations resolve, the counts reconcile, somebody looks at every page. It passes. A folder of finished documents sits ready to attach to an email.

Then time passes. A day, perhaps three.

In that time somebody opens a PDF to check something and re-saves it. A late document gets dropped into one recipient's folder. A typo in a spreadsheet gets corrected. Something that looked redundant gets deleted. The file sync client quietly resolves a conflict between two versions.

The folder still looks exactly like the folder that passed. Nothing checks it again, because the check has already been done.

The assurance was about a moment, not a folder

This is the whole problem, stated plainly: the checks covered a particular set of bytes at one instant. What ships is whatever is in the folder at a different instant. The two are joined only by the assumption that nothing changed in between.

Every record in the process reports on the build. The build log says the pack was clean, and it was, when the log was written. The reviewer looked at thumbnails generated from the version that passed. The recipient gets the version that exists on the day it is sent.

If those two versions differ, nothing anywhere says so. And the practice's word that the material was checked, consistent and properly branded now attaches to a pack that was never checked in the form it actually went out.

It fails quietly, and it fails through good intentions

This is not a failure of carelessness. The most likely change between build and send is a small, well-meant one, made under deadline pressure by someone who did not think a minor tweak needed the whole pack rebuilding.

That is what makes it hard to catch by asking people to be careful. The person making the change is being careful. They are fixing something. They just do not experience a one-character correction as an event that invalidates a set of checks.

Make the pass a property of the files

The fix is to stop treating "it passed" as a fact about a moment, and to make it a fact about the files themselves.

1. Seal the pack when it passes. Record a fingerprint of every file that passed (a cryptographic hash, plus its size), which checks ran, and when. Put that record somewhere inside the delivery folder that is never itself attached, so it stays internal by construction.

2. Cover what actually ships. If the files are zipped before sending, the zips do not exist when the checks run. Seal again after zipping, so the record covers the thing attached to the email rather than the things that went into it.

3. Verify at the moment of sending, as a separate step, and treat three findings as equally serious:

• a file changed since it passed;
• a file missing that was there when it passed;
• a file present that was never checked, because it appeared afterwards and would ship with the rest.

4. No seal, no send. A pack with no seal record is refused, not assumed clean. A missing record means either the checks never ran or the record was removed, and neither is a reason to proceed.

5. Version what "passed" means. If a check changes what it tests, a pack sealed under the old version should be reported as such rather than silently accepted. "It passed" has to mean the same thing on the day it is verified as on the day it was built.

How to tell it works

The test is simple and slightly brutal: change one byte of one file in a sealed pack and run the verification. It should name that exact file. If it names the file, the control is real. If it reports clean, you have been relying on a moment rather than a check.

The same family

This belongs with a group of failures that share one shape: assurance recorded somewhere other than on the thing being assured. A filename asserts what a file contains without anyone opening it. A build log asserts what a pack contains without anyone checking it on the day it leaves. The next step along the same line is what happens once the pack is sent, where the record of the delivery itself is the gap.

If you are the one receiving the pack

"Was this pack checked in the form you sent it, or in the form it was built?"

Most of the time the honest answer is "the form it was built", and most of the time nothing changed. The question is worth asking because on the occasions something did change, the practice itself may not know.