Release Readiness Review¶
Readiness review — instantiates Stage-Gate Progression
Aggregates readiness evidence across tests, monitoring, rollback, security, and support before a release, permitting a staged or conditional rollout rather than an all-or-nothing ship.
A Release Readiness Review aggregates readiness across many operational dimensions before a system goes live and, crucially, can permit a staged or conditional rollout instead of a single binary ship-or-don't. Its defining idea is breadth plus gradation: a release is not judged on whether the code works but on whether the whole surrounding system is ready to operate it — tests passed, monitoring and alerting in place, a rollback path proven, security reviewed, on-call staffed, dependencies and capacity confirmed, documentation and comms prepared — and when some of those are only partially met, the review can still let the release proceed behind guardrails: to a small canary population, behind a feature flag, or with a named condition and owner. It converts "is it done?" into "is it safe to run in production, and if so, how far and how fast?"
Example¶
A payments team is ready to launch a new checkout flow. The readiness review walks a broad checklist: automated tests green, load test to 2× peak passed, dashboards and alerts wired, a one-click rollback rehearsed in staging, a security review of the new card-handling path signed, on-call briefed, and a customer-support runbook written. Two items are soft: the capacity headroom is confirmed only to 1.5× peak, and the fraud-monitoring model is new and unproven at scale. Rather than block the launch or ship it to everyone, the review issues a conditional go: release to 5% of traffic behind a feature flag, hold there for 48 hours while the fraud model and capacity are watched against explicit thresholds, and auto-halt the rollout if error rate or fraud signal crosses a set line. The condition has an owner and an expiry. The checkout ships — narrowly, watchfully, reversibly — instead of waiting weeks for certainty it could gather live.
How it works¶
What distinguishes a readiness review from a single go decision is its breadth and its graded outcome:
- Assemble readiness across dimensions. The review is a checklist spanning functionality, operability, reliability, security, and support — the point being that a release fails in production for operational reasons, not just code reasons.
- Read evidence, not intentions. Each dimension must present proof — a green test run, a rehearsed rollback, a signed security review — rather than a promise it will be handled.
- Grade the outcome, don't just gate it. The distinctive move: where readiness is partial but the residual risk is bounded and reversible, the review authorizes a conditional rollout — a canary, a flag, a percentage — with the unmet items named, owned, watched, and set to auto-halt.
- Attach conditions with teeth. A conditional go carries explicit watch thresholds, an owner, and an expiry, so "ship with conditions" cannot silently become "shipped and forgotten."
Tuning parameters¶
- Checklist breadth — how many operational dimensions the review covers. Broader checklists catch more production failure modes but slow the release and can ossify into ritual.
- Conditional-go appetite — how readily partial readiness earns a staged rollout rather than a block. Liberal use keeps delivery flowing but risks accumulating unresolved conditions; strict use is safe but slow.
- Rollout increment — canary size and the schedule of stages (1% → 10% → 100%). Small early stages limit blast radius but lengthen exposure to the change; large stages are fast but riskier.
- Auto-halt sensitivity — the thresholds that automatically stop or roll back a staged release. Tight thresholds catch trouble early but abort on noise; loose ones let real regressions spread.
- Condition expiry — how long an unmet item may ride as a live condition before it must be resolved or the release reconsidered.
When it helps, and when it misleads¶
Its strength is treating a release as an operational event, not a code event, and giving the decision a middle gear: instead of forcing a binary between "block until perfect" and "ship and pray," it can ship narrowly and reversibly and gather the last evidence live under guardrails. Staging behind flags and canaries turns an uncertain launch into a bounded experiment with a working undo — the operational readiness discipline formalized in modern site-reliability practice.[n1]
Its failure mode is the conditional go as a loophole: unmet items get waved through as "conditions" that no one tracks, expiry dates slide, and the review accumulates a backlog of never-resolved risks while pretending each release was ready. A related misuse is a checklist so broad it becomes theater — signed for form, not read for substance. The discipline that guards against it is to give every condition an owner, a watch threshold, and a hard expiry; to wire staged rollouts to automatic halt-and-rollback rather than human vigilance; and to audit whether conditional releases actually resolved their conditions, so the middle gear stays honest instead of becoming a permanent bypass.
How it implements the components¶
Release Readiness Review fills the multi-dimensional-readiness and graded-progression side of the archetype:
readiness_criteria— the broad operational checklist (tests, monitoring, rollback, security, support, capacity) defines what "ready to run in production" means.evidence_packet— each dimension must present proof (a green run, a rehearsed rollback, a signed review), not an intention.conditional_progression_clause— the review can authorize a staged or conditional rollout with named, owned, expiring conditions and auto-halt guardrails; the mechanism's anchor.
It does not reduce the decision to a single synchronized authority verdict at one instant (progression_decision_rule, gate_authority — that is Go / No-Go Review), and it does not keep the durable signed compliance record (audit_trail — that is Compliance Signoff); a readiness review aggregates broad evidence and grades the rollout.
Related¶
- Instantiates: Stage-Gate Progression — the review is the readiness gate specialized to a production release, with a graded rather than binary outcome.
- Consumes: Go / No-Go Review — where a release culminates in a committing moment, the readiness review's evidence feeds the final poll.
- Sibling mechanisms: Clinical Clearance Protocol · Compliance Signoff · Educational Mastery Assessment · Go / No-Go Review · Manufacturing Inspection Point · Quality Gate · Approval Workflow
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Release Readiness Review operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it aggregates readiness evidence across tests, monitoring, rollback, security, and support before a release, permitting a staged or conditional rollout rather than an all-or-nothing ship.
Independent corroboration: The frozen evidence defines Release Readiness Review as 'Aggregates readiness evidence across tests, monitoring, rollback, security, and support before a release, permitting a staged or conditional rollout rather than an all-or-nothing ship', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Aggregating test, monitoring, rollback, security, and support evidence before deployment is a software-release practice.
Related originating lineages:
- Engineering & Design — Engineering design reviews supplied readiness gates and safety evidence.
- Organizational & Management Science — Operational management shaped cross-functional conditional authorization.
Review resolution: Both blind reviewers agree that computer_science is the primary historical origin. Explicit reconciliation of alternate origin disagreement, origin mode disagreement, encyclopedia synthesis disagreement adopts reviewer_a's evidence: Aggregating test, monitoring, rollback, security, and support evidence before deployment is a software-release practice. The selected record uses alternates=engineering_design, organizational_management, origin_mode=cross_disciplinary_synthesis, and domain_reach=multi_domain; the other review proposed alternates=engineering_design, origin_mode=single_lineage, and domain_reach=multi_domain. The selected combination better preserves the mechanism-specific formative lineages and calibrated scope; broader present-day use is not treated as proof of additional historical origin.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
This review and Go / No-Go Review are the pair most likely to blur, since both guard a launch. The one-sentence separation: a go/no-go review is a synchronized poll that renders one binary verdict at a fixed instant, whereas a release readiness review is a broad, evidence-based checklist whose signature move is the conditional, staged rollout — the graded middle outcome the binary poll deliberately refuses. The plain Quality Gate, by contrast, is a single automated internal-bar checkpoint under a different archetype; the readiness review is the human, multi-dimensional aggregation around such checks.
[n1] The Production Readiness Review, formalized in Google's site-reliability engineering practice, evaluates whether a service is operationally ready to run in production across reliability, monitoring, and on-call dimensions — the discipline behind treating a release as an operational rather than merely a code event. ↩