Every team has a release gate. On most teams, it's a person. Somewhere in the deploy path there's someone whose gut feeling is the real approval — and everything blocks on their availability, their memory, and their mood. Gut feelings don't scale, don't transfer, and don't survive vacations. Verdicts do. The difference between the two is whether ready is something a system computed or something a human felt.
Readiness is a generated artifact
A real gate doesn't answer can we ship? in a chat thread. It emits a machine-readable report — the checks that ran, the result of each, and a single verdict — attached to the exact build it describes. That file is the contract. Anyone can open it: the engineer who wrote the change, the stakeholder deciding the launch, the person doing archaeology on an incident months later. Because the verdict travels with the artifact, was this release ready? has an answer that doesn't depend on who you ask or how well they remember.
What belongs in the gate
Only checks with a crisp fail state. Typecheck and the test suite are the floor. Accessibility scans, performance budgets, and migration safety belong there too — each one owning a clear pass condition: within budget, zero violations above an agreed severity, reversible with no destructive operations. A check without a crisp fail state is a vibe. Vibes don't belong in a gate; they belong in review, where a human can weigh them. The gate is for questions a machine can answer identically every single time.
// readiness-report.json — the verdict is a file, not a feeling
{
"commit": "3f2c91a",
"generated_at": "2026-07-08T14:00:00Z",
"checks": [
{ "name": "typecheck", "status": "pass" },
{ "name": "test_suite", "status": "pass" },
{ "name": "a11y_scan", "status": "pass" },
{ "name": "perf_budget", "status": "pass" },
{ "name": "migration_safety", "status": "pass" }
],
"verdict": "SHIP"
}
Fail loudly, ship boringly
The gate's job is to make shipping uneventful. A deploy should be the most boring moment of the week — every interesting question was asked and answered before the artifact got near production. So when the gate goes red, that's not the process failing; that's the system working. The drama happened in CI instead of in front of users, which is the entire point. The failure mode to fear is the quiet one: a gate so soft it always passes. That isn't a gate. It's a rubber stamp with YAML syntax.
Gates guard the gate-keepers
The gate runs in CI, not on a laptop. That one decision does more for integrity than any policy document: nobody can skip it quietly, forget a step, or run a friendlier local version — and nobody includes me. This site eats its own cooking: its release gate runs on the build and writes the readiness report you can read in the hero. If I could route around my own gate, every claim on this page would be worth exactly nothing. A gate you can bypass is a suggestion. A gate in the pipeline is a contract.
THE CHECKLIST
- The gate emits a machine-readable report, attached to the build it describes
- Every check owns a crisp pass condition — no vibes in the gate
- Floor: typecheck, tests, a11y, perf budgets, migration safety
- One verdict a non-engineer can read and act on without a meeting
- The gate runs in CI — no laptop runs, no quiet skips, no exceptions
- A red gate is the system succeeding, not the process failing
A checklist asks a person to remember. A contract lets anyone verify. Ship the second one.