Why UNKNOWN is not a pass

Most checks have two colours. Green means go; red means stop. Everything that is neither tends to drift towards green, because a red that is not a real problem costs someone an afternoon, and a green that should have been red costs nobody anything, until it does.

Bracel has a third answer, UNKNOWN, and it is deliberate. It means the check could not establish the result. The application did not start. A dependency would not install. The scenario could not be set up. A response was neither a success nor a refusal. Or the pull request changes the rules that are supposed to judge it.

In each of those cases, nothing was verified. Reporting PASS would turn “we did not look” into “we looked and it was fine”. That is the single most expensive mistake a verification tool can make, because it is the one nobody goes back to check.

The refund template shows the idea in miniature. Before it tries a refund that should be refused, it makes a small refund that should succeed. If that control refund is rejected too, the template cannot tell a correct cap from a service that refuses every refund, so the answer is UNKNOWN. A service that rejects everything should not be able to pass a rule about rejecting the right thing.

UNKNOWN is not a polite FAIL either. It does not claim the rule is broken. It claims something narrower and more useful: here is exactly why we could not tell, and here is what to change so that we can.

There is a fourth answer, too. NOT_APPLICABLE means no approved rule applies to the files a pull request changes. Zero checks executed, and the result says so. It is not a green light for the rest of the code.

We think this is what proof, not opinions, has to mean in practice. A verdict is only worth something if every word in it is earned: PASS for what ran and held, FAIL for what ran and broke, UNKNOWN for what could not be shown, and nothing implied beyond that.