Mechanisms

The Vacuous Green

Why checks pass when they never ran

A vacuous green is a check that reports PASS because it never actually ran. The fix is not a better check — it is a verdict vocabulary in which “could not run” is a distinct, legal outcome. Unreachable, timed out and skipped must all resolve to INCONCLUSIVE, and INCONCLUSIVE must never be rendered as green.

Most monitoring answers the question “did the check pass?” when the question that matters is “did the check execute, and against what?” Those come apart constantly: a probe whose target was unreachable, a test whose fixture silently matched nothing, a guard that ran against an empty directory. Each one returns success. None of them looked at anything.

The failure is structural, not accidental. If a system has only two verdicts, every non-failure collapses into the pass bucket, including the non-events. Adding a third verdict is what makes the distinction representable at all — and it has to be load-bearing: an INCONCLUSIVE that gets aggregated into a green dashboard is just a vacuous green with extra steps.

The design test is simple. Ask of any check: what state of the world would make this report success without having examined anything? If you can name one, the check has a vacuous-green path and needs a verdict it can return instead.

Where this is worked

• Issue 6: The Vacuous Green — Why Your Checks Pass When They Never Ran
• Issue 12: The Vacuous Green Returns
• Issue 11: The Guard Nothing Reaches

The tool

No runnable tool ships with this one yet. When one does, it appears here and in the tool library at /tools.