Failure catalogue · The wrapper betrays the numbers · 46 of 51
OBSERVED FAILURE MODE
The stack trace deliverable.
A build that stops on a defect owes its reader a report, not an exception. One unparseable date ended a run with a raw traceback, zero artifacts, and 537 rows of already-proven verdicts discarded alongside it. The customer gets a stack trace where a page saying what the file still proves should have been.
What we saw
In our own audits a single ambiguous date in an appended row crashed a build outright. The other 537 rows had already earned passing verdicts: the anchors tied, the identity was confirmed, the screen had run. All of it went out with the exception. What shipped was a traceback, no artifacts, and no way for the operator to tell whether the file was broken or the engine was. A refusal that leaves nothing behind teaches the reader to distrust the tool rather than the row.
Why it passes a glance
An abort feels like the safe outcome, because nothing wrong was published. Exit codes look like the whole contract until you notice that a person reads artifacts, not codes, and no output at all is easy to mistake for a clean stop. The verdicts earned before the stop live in memory and are never written, so the loss is invisible in the code and total in the folder.
What addresses it
The provenance-reproducibility skill keeps the states distinct in its exit-code contract: reproduced, diverged and could not run are three different claims, and no output produced must never exit clean. Doctrine principle 5, Fail closed and stale, makes the refusal an artifact: the build writes a BLOCKED page and machine summary carrying every verdict earned before the stop, the named reason, and no certified figure, then exits non-zero.
Check your own file in two minutes
- Feed the build one unparseable date and read what lands in the output folder.
- Confirm a BLOCKED page exists, names the row and the reason, and lists every verdict earned before the stop.
- Confirm the run exits non-zero, and that a broken harness carries a different code than broken data.
What this does not catch
A BLOCKED page publishes what the file proved, not a substitute for the missing figure. It cannot say whether the blocking row is a vendor error or a real change, which is why the refusal ends with a triage the operator can run without the person who wrote the check.
Quick answers
- Is exiting non-zero not enough?
- A pipeline reads codes and a person reads artifacts, and both are owed something. The code says the run stopped. The BLOCKED page says what the file still proves and exactly why the stop happened.
- What goes on a BLOCKED page?
- Every check verdict earned before the stop, the named reason, the row or field that caused it, and no certified figure. It is a report of partial knowledge rather than a certificate with a hole in it.
- Should a blocking row ever be skipped to finish the run?
- No. Guessing past ambiguity is how wrong numbers get published. The row is named, the build stops, and the last known-good pack stays live and marked while the question is open.
Nearby failures
Last updated 2026-09-02 · Dylan, founder · one of 51 observed failure modes, every one seen in a real build or in our own audits, none invented.