An Empty Check Has Not Passed

Arithmetic that lies

The check that "no critical component is broken" is implemented as a list of broken components: empty means good. But it can be empty for two reasons: either someone looked and found nothing, or no one looked at all. A logical "all" over an empty set is true; this bit of schoolbook arithmetic quietly turns "we did not look" into "everything is fine."

Measured in our own system: three checks reported "passed" from a machine that could not see any of the items they covered. Three green lights signifying nothing.

The freshest caught specimen: our own site gate failed inside yet exited with a "passed" code - the cleanup at the end was overwriting the verdict. What gave it away was not an alarm but the missing final success line. The rule now: a green exit code without visible proof of success is not "passed".

The narrow fix

An empty set of items still means "passed": if no one promised a daily run, no one can be late with it, and there is no need to look.

Only an empty set of inspected items yields "unset": the items exist, but none were queried. Distinguishing these two kinds of emptiness accounts for half of the system's honesty.

The same defect in people

A paper checklist has the same flaw: a checkmark cannot age toward "still good." Four completed items on our release checklist proved false on the day they were reviewed-and still read as completed. So the checklist is no longer a gate: a machine recalculates release status from scratch against this commit every time.