Readiness Review¶
Gate review — instantiates Summative Certification
Aggregates heterogeneous endpoint evidence into a single go / no-go release gate, scoped to who will rely on the launch.
Readiness Review certifies that a person, team, system, or deliverable is ready to go live by aggregating many heterogeneous signals at the boundary and rendering one gate decision. Its defining move is holistic synthesis under accountability: no single test decides readiness, so the review pulls together test results, operational metrics, sign-offs, risk assessments, and open-issue lists, and weighs them against who will rely on the launch and what happens if it fails. It only counts as certification when it is evidence-based rather than a status meeting. The question is not "did this one thing pass?" but "taken together, is it responsible to release this to the people downstream?"
Example¶
A SaaS team is a week from launching a major new billing service that other internal teams and thousands of customers will depend on. The launch is gated by a production readiness review. Instead of one exam, the reviewers assemble a dossier: load-test results, error budgets and latency percentiles, the on-call rotation and runbook coverage, a rollback plan, the security review status, and the list of open bugs by severity. Against explicit exit criteria, most items are green — but the rollback plan is untested and two severity-2 bugs are open.
Because the accountability context is high — a billing failure means real financial harm to customers — the reviewers do not wave it through. They issue go for a staged rollout: launch to 5% of traffic behind a feature flag, with a tested rollback and the sev-2 bugs fixed as conditions before ramping. That scoped go/no-go is the certification. It could not have come from any single signal; it came from weighing the whole picture against the stakes for the people who will rely on it.
How it works¶
- Define exit criteria up front. The review declares, before the boundary, what evidence must be present and green to release.
- Aggregate heterogeneous signals. Test results, ops metrics, sign-offs, risk items, and open issues are gathered into one dossier rather than judged in isolation.
- Weigh against the stakes. How strict the gate is scales with who relies on the launch and the cost of failure — the accountability context sets the bar.
- Render a scoped gate decision. Go / no-go / go-with-conditions (staged rollout, blocking fixes), tied to the aggregated evidence and re-checkable as issues close.
Tuning parameters¶
- Exit-criteria strictness — how many and how green the required signals must be. Stricter gates cut launch risk but delay release and can breed checklist theater.
- Evidence breadth — how many signal types are aggregated. Broader dossiers catch more failure modes but cost more to assemble and read.
- Stakes calibration — how strongly downstream reliance raises the bar. Tight coupling to stakes focuses scrutiny where harm is greatest.
- Conditional-go latitude — whether staged rollout / go-with-conditions is available and how large a gap it can bridge.
- Reviewer independence — how separate the gatekeepers are from the delivery team, trading friction against candor.
When it helps, and when it misleads¶
Its strength is catching failure modes that no single check sees — the launch that passes every isolated test yet is unready because the pieces don't hold together, or because operability, rollback, and on-call coverage were never in scope for any one test. Weighing readiness against downstream reliance is what makes a review a gate rather than a formality.[n1]
Its failure modes are the status-meeting trap and scope overclaim. A readiness review degrades into theater when the gate is a slide deck of green checkmarks nobody scrutinizes — a decision by vibes, not evidence — which the archetype explicitly warns is not certification. And a go-decision for a limited rollout can be misread as blanket "it's ready" if its conditions and scope are not carried forward. The classic misuse is the rubber-stamp review that ratifies a launch the team already decided to ship. The guarding discipline is to require real, inspectable evidence against pre-declared exit criteria and to keep the decision's scope and conditions attached to the go.
How it implements the components¶
outcome_standard— the explicit release/exit criteria the launch must satisfy to be certified ready.endpoint_evidence— the aggregated heterogeneous signals (test results, ops metrics, sign-offs, risk and issue lists) gathered at the boundary.certification_decision— the go / no-go / go-with-conditions gate decision.accountability_use_context— who relies on the launch downstream and the cost of failure, which sets how strict the gate is.
It weighs many signals holistically rather than checking one deliverable criterion-by-criterion against an evidence_alignment_map (that's Acceptance Test); and it issues a gate decision, not the durable evidence_integrity_record or validity_limit_note of the credential artifact (that's Certification Record).
Related¶
- Instantiates: Summative Certification — Readiness Review is the aggregate-evidence go/no-go form of endpoint certification.
- Consumes: Acceptance Test — a passed acceptance test is one of the many signals the review aggregates.
- Sibling mechanisms: Acceptance Test · Capstone Demonstration · Certification Record · Competency Signoff · Final Exam · Portfolio Review · Practical Checkout · Rubric Review · Standardized Credentialing Exam
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Readiness Review operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it aggregates heterogeneous endpoint evidence into a single go / no-go release gate, scoped to who will rely on the launch.
Independent corroboration: The frozen evidence defines Readiness Review as 'Aggregates heterogeneous endpoint evidence into a single go / no-go release gate, scoped to who will rely on the launch', so its operative form is Assessment, Review & Assurance.
Nearest alternative: Decision, Gate & Allocation — Readiness Review includes features of a case-specific gate, selection, routing, prioritization, or resource disposition, but its defining operation is a bounded evaluation of existing evidence or work that produces a finding or disposition.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: NASA lifecycle practice explicitly defines readiness reviews over hardware, software, personnel, procedures, and user documentation; software production-readiness reviews and managerial ownership are later domain adaptations.
Related originating lineages:
- Computer Science & Software Engineering — The computer_science lineage materially shaped Readiness Review through algorithms, software architecture, and formal verification.
- Organizational & Management Science — Program governance materially shapes aggregation of evidence into an accountable go/no-go decision.
Review resolution: The blind reviewers disagreed on primary lineage. Light authoritative research resolves the defining form in favor of engineering_design: NASA lifecycle practice explicitly defines readiness reviews over hardware, software, personnel, procedures, and user documentation; software production-readiness reviews and managerial ownership are later domain adaptations. The rejected primary is retained only when it materially shaped the mechanism, and present-day breadth is recorded separately as domain_reach=multi_domain.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
[n1] A production readiness review — as practiced in site-reliability engineering — gates a launch on aggregated operational evidence (load tests, monitoring, on-call readiness, rollback) rather than any single functional test, and is the direct inspiration for treating readiness as an evidence-weighted gate scoped to operational stakes. ↩