Launch Readiness: go, no-go, or conditions with names on them

Launches fail at the gate in one recognizable way: the checklist is ticked from memory, the rollback exists on paper, and support learns about the release from a customer. This skill walks Gate 5 one item at a time, demands evidence in the release candidate for each, and turns "mostly ready" into a conditional go whose conditions each have an owner and a close-by date, or into the no-go it actually is.

Files this skill drives

• ../../templates/delivery/release-readiness.md, the working document and the checklist in one place
• Gate 5 in ../../os/STAGE-GATES.md, whose eight items this skill walks in order
• Reads, as evidence: ../../templates/delivery/uat-plan.md, ../../templates/delivery/testing-strategy.md, ../../templates/delivery/edge-cases.md, ../../templates/delivery/failure-scenarios.md, ../../templates/delivery/launch-comms-plan.md, ../../templates/operate/operational-readiness-review.md
• Overlays: ../../templates/ai/guardrails.md for model features; the reg-gap-check skill and ../../templates/operate/compliance-impact-assessment.md for regulated products
• Records: ../../templates/execution/decision-log.md for the decision, ../../templates/execution/risk-register.md for accepted known issues
• See also ../../frameworks/metrics/dora-four-keys.md (Forsgren, Humble, and Kim, 2018) for the rollback and recovery items. "We can roll back" is a belief; a measured time to restore service is a number, and it is also the answer when the fix proposed after a bad launch is to release less often

When to use

• Two weeks before a target date, as the first full run, and again at the gate itself
• After a slip, because evidence that was true a month ago may not be
• When a function wants to sign "with reservations" and nobody has written the reservations down
• Before releasing a product that contains an AI or machine-learning feature and has a financial or data regulator applying to it, where the overlay items are mandatory. Both halves are required by the rule in ../../os/STAGE-GATES.md

Inputs

The filled release readiness document (drafts accepted; the gaps are the point), UAT results, the rollback rehearsal record, comms drafts per audience, and the on-call runbook. Ask for these when missing: the named decider who can say no-go; the Gate 4 misses carried forward and their decisions; the environment and date of the rollback rehearsal; the severity-1 defect list; and, for regulated products, the section 0 answers from Gate 2. Decision rule: if the pre-read was not circulated 48 hours ahead, reschedule the gate rather than walk the room through the document.

Workflow

1. Confirm the frame

Decider named; sign-off owners named per function (a name, not a team); pre-read circulated; every claim to be shown in the release candidate, not on slides. Missing any of these, the gate does not open.

2. Walk the eight items

For each Gate 5 item, record the evidence seen, the verdict (pass, condition, or fail), and, for a condition, the owner and the close-by date:

1. UAT exit criteria met, with real users or named proxies, and every severity-1 defect closed. Evidence: the signed UAT plan and the defect list. Rule: an open severity-1 is a fail, not a condition.
2. Rollback performed in pre-production, with the time to roll back recorded. Evidence: the rehearsal record with date and environment. Rule: a rollback that was designed but never run is a fail; the rehearsal is the cheapest hour of the launch.
3. Known issues listed, each with a workaround or an accepted-risk sign-off. Evidence: the known-issues table. Rule: an empty table on a real product is a question, not a pass.
4. Comms drafted and approved for support, sales or field teams, and customers where applicable. Evidence: the drafts and the approver's name. Rule: unbriefed support is a condition whose close-by date falls before the release, never after.
5. On-call knows, and the runbook exists. Evidence: the runbook link and the on-call acknowledgment. Rule: a runbook nobody on call has read is a condition owned by the on-call lead.
6. Every function signed its own line: engineering, product, QA, support, and any others the readiness document names. Rule: a blank line is a no-go from that function until it is filled.
7. AI overlay, when a model ships: guardrails verified live in the release candidate, and the kill switch tested. Rule: a kill switch that was designed but never tested is a fail.
8. Regulated overlay, where the Gate 2 line fired: the Gate 2 section 0 answers are still true of the artifact that ships; any drift is written up and re-signed by the regulatory owner. Rule: drift without a re-signature is a fail. Where Gate 2 recorded that the shipped overlay did not apply, this item instead re-checks what the regulatory owner used in its place, named; an unnamed substitute is a fail.

3. Check the rollback trigger

The trigger is a condition a dashboard can show (an error rate, a latency, a failed reconciliation count), with an owner and the time to roll back. A trigger written as a feeling ("if things look bad") is a condition owned by the release owner, closed before release.

4. Decide

Apply the rules in order. Any fail: NO-GO, with the fails listed and the re-run date set. No fails and one or more conditions: CONDITIONAL GO, valid only while every condition has an owner and a close-by date; a condition missing either converts the verdict to NO-GO. No fails and no conditions: GO. The decider records the decision and the one-paragraph reason on the readiness document and on the gate form.

5. Record and follow through

Decision log entry with the decider named. Accepted known issues become risk register rows with the signer as risk owner. Each condition gets a check on its close-by date; an open condition at that check is a launch stop, not a re-date.

Output format

1. Item table: | # | Gate 5 item | Evidence seen | Verdict (pass / condition / fail) | Condition owner | Close-by date |
2. Rollback line: trigger, owner, time to roll back, rehearsal date and environment
3. Recommendation for the decider: GO / NO-GO / CONDITIONAL GO from the step 4 rules, the reason paragraph, and for a conditional go the numbered conditions with owners and dates; the decision line is left blank for the named decider
4. Sign-off table copied from the readiness document, every row named and dated
5. The decision log entry and any risk register rows

Failure modes this skill guards against

• The checklist ticked from memory. Every item needs evidence you can point at, shown in the release candidate.
• Rollback on paper. The industry's incident write-ups repeat this line; the rehearsal is not optional.
• The conditional go with no owners. A no-go wearing a smile; the conversion rule above removes it.
• Support learns from customers. Comms to support close before release, not after.
• Team names on sign-off lines. "Engineering" cannot be paged; a person can.
• Overlay items skipped as not applicable, with no reason. Write the reason, or run the overlay.
• Re-dating conditions. An open condition at its close-by date stops the launch.

Exit gate

This skill walks Gate 5 in ../../os/STAGE-GATES.md, feeding OPERATE once DELIVER closes. It is done when every item has a verdict with evidence, the recommendation follows the step 4 rules, every condition has an owner and a date, and the decision line is left for the named decider; the decision log entry is written after they record it.

What checks this

Some checks on this skill run automatically and some depend on a person. This section says which is which. It is generated by python3 tools/what_checks.py from the declarations it links to, and CI fails when it falls out of date.

• Checked by CI on every commit. This file must carry the seven sections every prose skill carries: python3 tools/skill_rubric.py --min 7 fails the skill-rubric gate in python3 tools/ci_gate.py when one is missing. That checks structure, not whether the advice is right.
• Checked by the runtime. This skill is declared against Gate 5 in SKILL.graph.yml. Gate 5 is recorded with pmos gate --bank-id deliver, which refuses the proof unless every question in that bank has been accepted and the bank is the current one, requires the proof to name its source, source_sha256, actor_id, requester_id, decision and approved_at, and rejects self-approval and any approver the bank does not pin. Approver ids are typed, not authenticated, so a recorded approval is a local attestation, not proof of who signed. If the proof's source changes after approval the gate goes stale and nothing later completes until it is proved again. The journey run shows all six gates and a stale gate being proved again.
• Checked by a person. The runtime checks who approved and that the evidence has not changed. It does not check whether the reasoning in this skill's Workflow was followed well; that judgment belongs to the people who sign the gate. Gate 5 is signed by the release owner, the product owner, the operations or support lead and the regulatory owner (regulated products only), per the sign-off tables in os/STAGE-GATES.md.