part six · release gate

Release Gate

The named conditions the chain must satisfy before the flag can be enabled.

The release gate is not a meeting. It is a state. It is the moment the chain steps from building to watching, and it is gated by a checklist that is satisfied or not — no debate.

The checklist

RELEASE GATE — Grading Flow v2 (cycle 17)

Code
  [ ] Pipeline green on main, latest commit
  [ ] Visual regression baselines current
  [ ] Accessibility checks passing
  [ ] Security scan no high/critical findings

Scope
  [ ] All required-for-prediction stories merged
  [ ] All Gherkin scenarios from amigos passing
  [ ] Pre-merge QA reports filed for each PR
  [ ] Story map shows release slice complete

Operations
  [ ] Monitor / alert rules updated for new flow
  [ ] Runbook for new failure modes written and reviewed
  [ ] On-call rotation confirmed for next 48 hours
  [ ] Status page entry drafted for graceful failure communication

Release machinery
  [ ] Feature flag created and tested in staging (both paths)
  [ ] Rollout plan named (pilot, percentage, full)
  [ ] Rollback procedure documented
  [ ] Migration plan signed off (if applicable)

Comms
  [ ] CS handoff document written and shared
  [ ] Client release brief written and reviewed
  [ ] Help text and empty states reviewed for domain language
  [ ] Internal team has read the brief

Prediction
  [ ] Baseline numbers captured pre-flag
  [ ] Check date in the calendar
  [ ] Check method instrumentation in place
  [ ] Owner of the check named (and available on the date)

The checklist is owned by the PO. The PO holds the gate. Held means the PO does not approve enablement until every item is checked, with the relevant owner named.

Why a checklist

Three reasons.

1. It surfaces the gaps in advance. Two days before the release, the team realises the runbook hasn't been written. Two days is enough to write it. Two minutes before enablement is not.
2. It distributes ownership. Each line has an owner. The PO is not personally writing the runbook; the on-call is. The PO is verifying that it exists.
3. It produces the artifact for postmortem. When something goes wrong, the postmortem reads the gate. Was the failure mode in the runbook? If yes, the runbook didn't catch it; structural fix elsewhere. If no, the runbook should have had it; structural fix in the runbook template.

The gate is honest about scope

The gate is satisfied for this slice. Not for the whole product. A walking skeleton release goes through the gate. A richness release goes through the gate. Each release has its own gate.

The corpus pattern: even small features have gates. The gate scales with the release — a tiny copy fix has a tiny gate (pipeline green, story merged, no comms needed). A new flow has the full gate.

Soft items vs hard items

The gate has two kinds of items.

• Hard items — pipeline green, scenarios passing, runbook exists. These are binary. They are or they aren't.
• Soft items — runbook is good, brief is clear. These have judgment. They are signed off by name.

Soft items are reviewed by their owner. The runbook is reviewed by an on-call who hasn't seen the feature before — can you act on this at 3am? — and signs yes or not yet.

When an item won't satisfy

Sometimes the gate cannot be satisfied. The honest options:

1. Delay the release. The most common right answer. The cycle was ambitious; the gate's missing item is real; ship next week.
2. Reduce scope. Drop the slice that requires the unmet item. Ship what is ready.
3. Document a known limitation. Some items are we know this is incomplete; we are accepting it for now. The acceptance is named, the remediation is dated, and the documentation goes to CS so they know.

What the corpus does not allow: enabling the flag with an unmet item that has not been documented as accepted. That is the chain operating outside its own discipline, and it is the source of the postmortems that have to teach the same lesson twice.

Who can hold the gate

The PO holds the gate. The Tech Lead can pause it. The QA can pause it. The on-call who reads the runbook and finds it inadequate can pause it. Anyone in the trio can hold the gate; only the PO can release it.

A gate that the PO releases without the trio's agreement is a gate that has lost its meaning. The corpus pattern: gate disagreements are surfaced and named, not papered over.

Where the gate sits in time

The gate review is the last act of Volume IV. The flag enable is the first act of Volume V.

Part 7 — Gradual Rollout →