The Ship-or-Hold Gate: Turning Evidence Into a Decision In short: Four gates produce evidence. One rule turns that evidence into a binary decision and a version number. The point is not automation for its own sake — it is that the same evidence produces the same answer on a Friday afternoon as on a Tuesday morning. We have gates for logic, pixels, accessibility, and the public API. Each reports independently. Somebody still has to decide whether to release. If that decision is a conversation between tired people looking at a diff, it will be inconsistent — and inconsistency is what teaches consumers not to trust your releases. Hold conditions The build stops, no discussion, if any of these fail: Gate Hold when --- --- Build The library or any affected consumer fails to compile Lint A boundary rule, vocabulary rule, or stale-API rule fails Unit tests Any test fails Visual A pixel diff exceeds threshold and is not explicitly approved Accessibility Violation counts exceed the baseline API A breaking change without the label and a migration Security reports a high or critical advisory in a runtime dependency Two of those have escape hatches, and both are deliberate. Visual can be approved by labelling the pull request , which regenerates baselines in CI. The change is not blocked; it is made explicit and reviewed as images. API can be approved by labelling , which requires the migration schematic from Chapter 9 and a platform-team review via CODEOWNERS. The others have no override. An escape hatch that gets used weekly is not a gate. Deriving the version If nothing holds, the pipeline calculates the release from the same evidence: Evidence Release --- --- No API change, no visual change Patch No API change, approved visual change Patch Additive optional inputs, new components Minor A CSS custom property added Minor Any breaking API change Major — requires the label and a migration A CSS custom property removed or renamed Major The API diff script from the previous lesson already sorts changes into breaking and additive, so it can emit the answer directly: Every pull request now says what it will do to consumers, before anyone merges it. Conventional commits are not enough on their own Tools like derive the version from commit messages. That is useful for the changelog and useless as a safety mechanism, because the commit message is written by the person making the change and reflects what they believe they did. is a prefix and a major breaking change. The commit message cannot know that; the API diff does. So: commit messages describe intent; the API diff establishes fact. When they disagree, the diff wins. What still needs a person Being explicit about what the gate does not decide, because a gate that oversells itself gets over-trusted: The pipeline decides A person decides --- --- Did anything break? Is this the right change? Is the API contract intact? Is this the right API? Do the pixels match the baseline? Is the new design good? Are there new a11y violations? Is the label meaningful? Which version number? Should we release this week? The gate makes the release decision safe . It does not make it wise . Chapter 7's lesson holds: automate what is objective, and spend human attention on judgement. "But I thought a release should be a human decision" This objection comes from a good place. Releases have consequences, twenty teams depend on them, and handing that to a script feels like abdicating responsibility. The confusion is about which decision is being automated. The pipeline does not decide whether the change is worth shipping — a person already made that call by approving the pull request. What it decides is the narrow, mechanical question: given this evidence, is it safe to publish, and what number does it get? That question has a correct answer that does not vary by who is asking. And humans are measurably poor at it, not through carelessness but because it requires holding several independent reports in mind and applying rules consistently across hundreds of releases. Watch what "human decision" looks like in practice: It is Friday at 17:40. Two gates are green, one shows a 0.3% pixel diff on a card. Nobody can immediately tell whether that is a font-rendering artefact or a real shift. Someone says "it's tiny, ship it." The same diff on a Tuesday morning gets investigated and turns out to be a clipped label. Same evidence, different answer, because of the time of day. Consumers experience that as a library that is sometimes reliable — which is the trust failure from Chapter 4. There is also a subtler problem: a human release decision is usually made by reading a diff , and the changes that matter most here are invisible in a diff. A renamed input is one word. A removed CSS custom property is one line in a stylesheet. Reviewers are looking for logic errors, which is where their attention should go. Human judgement Automated gate --- --- --- Same evidence, same answer No Yes Catches a renamed input i…