When the Gate Bends

## The four states, and the one nobody records When you go back to a commit months later and ask what the gate did, there are four possible answers: it ran and passed, it ran and blocked, it ran and was overridden, or **it never ran at all**. Continuous integration systems are built to surface the second one loudly and are indifferent to the difference between the first and the fourth. A build result is an aggregation of failures. If nothing failed, the build is green — and *nothing ran* is a perfectly good way for nothing to fail. That fourth state deserves its own name. Call it **indeterminate**: the evidence you hold cannot distinguish a passing evaluation from an evaluation that never happened. Indeterminate is not a rare pathology; it is the default state of most pipelines, because almost nothing in a normal setup writes down the positive fact that a rule was applied. ## Concrete ways a check goes green without checking anything - **The job was skipped.** A path filter says the job only runs when files under `infra/` change; the datastore was created by a module bump elsewhere, so the job never started. A skipped job contributes no failure. - **A condition excluded it.** The job runs only on the default branch, or only when a label is present, or was disabled for a release freeze and never re-enabled. - **The check was never required.** The job ran and failed, but nothing was configured to block the merge on it, so the change went in with a red check that no one was watching. - **The gate was removed in the same change.** Pipeline definitions usually live in the repository they gate, so the change that introduces a violation can also be the change that stops the violation being checked. - **The engine loaded no rules.** A moved directory, a bad path, a rule bundle that failed to download and was skipped with a warning: the engine evaluates the input against an empty rule set, finds nothing to complain about, and exits zero. - **No rule matched.** The rule set is fine, but nothing in it selects the resource type in front of it. An unmatched rule produces no result, and an absence of results is not a pass. That last one is the subtle one, and it is where policy engines differ from tests. A test that does not run is usually reported as skipped. A rule that does not match is usually reported as nothing at all. ## Why this matters to someone reading the record later Suppose an unencrypted datastore turns up in production and the encryption-at-rest rule has existed for a year. The post-incident question is narrow: on the commit that created that datastore, did the rule run? If the only artifact is a green build, the honest answer is that you do not know. You cannot credit the gate, you cannot blame it, and you cannot say whether the same hole is open on the other four hundred changes that shipped that quarter. The gate might be working perfectly and simply not have covered this path; it might have been silently inert since February. Both stories fit the evidence equally well. The same applies to a minimum retention rule on an audit log. A year of green builds is consistent with a year of enforcement and equally consistent with a rule that stopped being invoked in week three. ## What turns green into evidence The fix is to stop *inferring* outcomes from build history and start *asserting* them. In practice that means three things. 1. **Emit a decision, not a status.** Every evaluation writes a record keyed to the change it judged, stating which rules were evaluated, against which input, and what the outcome was. Passed becomes a positive statement rather than the absence of a complaint. 2. **Make absence loud.** Something downstream — the merge check, the deploy step, a reconciliation job that walks merged commits — requires that record to exist. The moment a missing record fails something, unevaluated changes stop being invisible. 3. **Fail closed on a degenerate run.** If the engine loaded zero rules, or evaluated zero resources, that is an error, not a pass. A gate that cannot detect its own emptiness will report green forever. None of this requires a heavyweight system; it requires that the evaluation say what it did rather than leaving a reader to guess from the colour of a build. ## The replay trap A tempting shortcut is to re-run the check on the old commit today. That answers a different question. A replay evaluates that code against today's rules, today's engine version and today's surrounding data, and tells you whether the change would pass **now**. It cannot tell you whether anything was applied then. Reconstruction has to come from a record made at the time; anything else is a new decision wearing an old commit's clothes.