I added three new checks to a build. Nothing about the code under test changed. Ten tests that had nothing to do with any of them went red, and a separate, unrelated block of work was refused outright. Both of those were correct. FAIL_ORACLE reason=row_without_its_oracle_or_fault_cells rows=OK_BRIDGE, OK_COST, OK_MUTATION (10 tests red with it) REFUSED reason=line_outside_the_layer_vocabulary What I had actually done I wrote the checks. I did not declare them. In this build a check is not just code that prints a line. A print is a thing the system knows about, and knowing about it means three separate declarations exist: declaration what it says what goes wrong without it shape the print's row, with its oracle (what makes it pass) and faults (what makes it fail) nothing can tell a pass from a silence vocabulary the record's list of print names it accepts the record refuses a line it has no word for the requirement row which spec obligation this print discharges the check is unattached work I had written one of the three. The code ran. It printed. And the machinery that exists to stop exactly that went red. Concretely, what I wrote versus what a complete row looks like: [[prints]] name = "OK_COST" + oracle = "every declared operation has a measured cost" + faults = ["cost_missing", "cost_not_numeric", "operation_undeclared"] Without faults, there is no enumerated way for the row to fail, and a row that cannot name a failure cannot be shown to detect one. Why the ten reds are the good part The ten failing tests are not about my three checks. They assert a property of the whole set of prints: every row has an oracle and a fault list. Adding three rows without those cells broke that property, so they failed. That is what a structural invariant is for. It fails at the place the rule lives rather than at the place the rule was broken, which feels like noise for about a minute and is the reason the gap cannot be shipped. The alternative is the version I have written before without noticing: a new check that prints a plausible-looking line, has no declared failure mode, and is therefore incapable of going red. It would have joined the build green, and it would have been counted in every "all checks passing" summary from then on. The refusal is the same mechanism, one layer up The second line is a different piece of work being rejected because it names prints that the record's vocabulary does not contain. REFUSED reason=line_outside_the_layer_vocabulary Not "warned". Not "accepted with an unknown tag". The record has a closed set of names it accepts, and a line outside it does not get written. An open vocabulary would have taken the line, and then the count of known prints and the count of written prints would have diverged quietly, which is the failure that has no symptom. The part I keep having to relearn A run that fails is a line in the record. A run that never happened is a silence. Those two are not the same and only one of them is visible later. The red block above got written down, with its reason, as a permanent entry. That is the record doing its job on its owner: I cannot quietly fix this and have it never have happened. When I first saw ten reds from a three-line addition my instinct was that the checker was overreacting. It was not. It was telling me the three declarations are a set, and I had treated them as one thing plus some paperwork. What to take from it If you are adding a check to a system that has any notion of a registry, ask what a complete addition consists of before writing the first line. In mine it is three rows. In yours it might be the assertion plus a fixture plus an entry in whatever enumerates your checks. And the test worth writing first, regardless of the stack: can this new check go red? Not "does it pass" — plant the failure it exists to catch and watch it fail, before you let it count toward anything. A check with no demonstrated red is a line of output, not a check.