A File Existed but the Content Was Wrong. That’s the Bug Class No Test Catches.
A file can exist, ship, and still be wrong — the defect that no existence check will ever catch, because every “did it ship?” log says yes.
The worker shipped the file. The folder contained the file. The filename matched the brief. Every check I had at the time said the dispatch was clean.
The downstream stage that consumed the file rendered it as empty.
Not missing. Empty. The artifact existed and had the right name, but the actual content inside it was a placeholder. The consuming stage picked it up, treated it as authoritative, and embedded an empty version into the next-stage output. By the time I noticed, the empty content had already shipped two stages downstream.
There was no error. No failed check. Nothing to grep for in a log. Every “does the file exist?” check passed, all the way through.
This is the most expensive defect class in an AI workflow. ICM § 6.2 names it and gives the pattern that catches it. The fix is small. Skipping it is what makes the bug exist.
Why file-existence checks miss this
Every reasonable check at the end of a dispatch asks: did the artifact ship? The answer is yes or no. A boolean. The check is cheap, easy to write, and easy to automate.
The question it doesn’t ask: does the artifact carry the right content for the next stage to consume? That’s a different question and it requires opening the file, reading the content, and matching it to what the brief said the artifact should contain.
The two questions look similar. They are not the same question. A file can exist with the wrong content, the wrong format, an empty body, a stale version, or content that was correct yesterday and is wrong today because the brief upstream changed. None of those failures show up at the file-existence check.
The defect lands in the gap between “shipped” and “correct.” Downstream stages live in that gap.
Cross-stage trace verification (ICM § 6.2)
Van Clief’s ICM names this directly. A workflow has stages. Each stage produces artifacts. Each downstream stage consumes the upstream artifacts. The question that catches the silent-rot defect is whether the content makes it across each transition cleanly, not just whether the file shows up.
The pattern is small. For each shipped artifact: read the brief’s stated expected outputs; read the actual artifact (the content, not just confirm the file); read the downstream stage’s reference to the artifact and confirm it picked the content up as intended.
Three reads. One trace. The trace either holds or it breaks at a specific arrow between stages, which is what makes the defect locatable.
The point isn’t extra checks for their own sake. The point is that the silent rot only happens in the unverified content transition. Verify the transition, the rot has nowhere to hide.
What the verify step actually does
In practice, a verify-handoff step is a small procedure that runs after a dispatch ships and before the next stage starts. It reads the brief’s expected outputs as the contract, opens the artifact and reads enough of the content to confirm it matches the brief, opens the downstream consumer (the file or stage that will pick this up) and confirms the reference points to a real piece of the artifact’s actual content, not just its filename, and appends a one-line breadcrumb stating what was verified, not just that the artifact shipped.
The first three are the trace. The fourth is the audit trail, which matters when a defect appears later and you need to know which transition went unchecked.
This step doesn’t catch every defect class. It catches the specific class where the artifact exists, ships, and silently carries wrong content. That class is the most expensive to debug because every “did it ship?” log says yes. Verify-handoff replaces “did it ship?” with “did the content land where the next stage expected it?”
Markers — your handoff is fragile
Four signs the verify step is missing or shallow.
Your verify step is “ls the folder.” File presence is not content correctness. If you’ve never opened an artifact between worker ship and consumer use, you can’t catch the rot.
Downstream stages reference output by filename only. When the next stage’s only check is “the file with this name exists,” content drift will pass through unnoticed. Every consumer should anchor on a content slice, not the filename.
Nobody opens the artifact between ship and consume. If the artifact’s first reader is the downstream consumer, there’s no human or worker that would notice empty content before it propagates.
Breadcrumbs say “shipped” but not “verified what.” A log line that records “artifact X shipped” doesn’t tell you whether the content was inspected. A log line that records “verified X.content matches brief outputs Y, Z” does.
Each marker on its own is a fragile point. Multiple markers stacked means the workflow has no real handoff verification. It has file-existence checks dressed up as verification.
What I’m giving you, and what I’m not
You have everything you need to apply this: the trace-verification pattern from ICM § 6.2.
The three-read procedure (brief, artifact content, downstream reference).
The four fragility markers.
The breadcrumb pattern that records what was verified.
The brief defines what verify checks against. Article 8 unpacks the brief-as-contract side of that pairing. Verify-handoff and brief-as-contract are companions, not standalone steps.
What I’m not giving you: the script I run, the prompt that drives it, the specific artifact-shape rules I check for in my own workflow. Those are tied to the artifact types I ship. Your artifacts are different. The pattern is the same.
A handoff you can verify is a handoff you can trust. Most workflows don’t have that. They have file existence and good intentions.