Operational Readiness Review¶
Operational readiness review (procedure) — instantiates Transition Readiness Assessment
Checks whether the receiving operation can actually run, support, watch, and recover the new state in production — staffing, runbooks, monitoring, and a tested rollback — before it is switched on.
An Operational Readiness Review asks a narrower and harder question than "is the thing built?" — it asks whether the operation that will run the new state after crossing can actually sustain it. Its distinctive subject is day-2 capability in the receiving environment: is the on-call rota staffed and trained, are runbooks and escalation paths written, is monitoring live so failures are seen, and is a rehearsed rollback standing by so a bad crossing can be reversed? Taking the correctness of the new state as given, it fails a transition not because the destination is wrong but because nobody could operate, observe, or recover it once live.
Example¶
A metro rail authority is bringing a new line extension into revenue service. The track and trains are built and tested — a separate gate settled that. The operational readiness review asks whether operations can run it from day one: are drivers certified on the new signaling section, is the control room staffed for the extended timetable, are depot spares and maintenance crews in place, are the degraded-mode procedures (single-track working, traction-power failure, evacuation) written and rehearsed, is the control-room monitoring wired so controllers can see the new section, and can the extension be isolated and trains turned back if something fails on opening day.
The review finds the trains and track pass, but two of the new section's signal aspects show as "unknown state" on the control-room display, and the single-track degraded-mode procedure has never been drilled with the new crews. Both are day-2 gaps, not build defects. Outcome: revenue service is held until the monitoring is corrected and the degraded-mode drill is run — because a line controllers cannot watch, and crews cannot safely degrade, has no business carrying passengers, however finished the rails are.
How it works¶
- Review the operation, not the artifact. The subject is the run/support/monitor/recover capability of the receiving team, with the new state's correctness assumed settled elsewhere.
- Demand the day-2 capabilities exist and are shown. Staffing and training present, runbooks and escalation written, spares and support in place — each demonstrated rather than asserted.
- Require observability before crossing. The monitoring that will watch the new state has to be live and verified against known signals, or the operation is flying blind from the first minute.
- Require a proven reversal. The crossing is releasable only if the rollback has been rehearsed end-to-end, not merely documented.
Tuning parameters¶
- Day-2 scope — which operational domains are in scope (staffing, monitoring, incident response, spares, documentation). Wider catches more ways to be un-runnable; narrower is faster but blinder.
- Evidence bar for "can operate" — a paperwork sign-off versus a live drill or game-day. Drills catch the gaps paperwork hides but cost time and can't always be staged.
- Rollback stringency — how thoroughly reversal must be proven: documented, tested in staging, or rehearsed end-to-end. Higher is safer but slower, and impossible for genuine one-way doors.
- Monitoring completeness threshold — how much of the new state must be observable before go — critical signals only, or full coverage. Too low ships a blind spot; too high stalls on nice-to-have telemetry.
- Re-review trigger — what change to the operation (staffing turnover, a procedure edit) forces a re-run rather than trusting a stale sign-off.
When it helps, and when it misleads¶
Its strength is catching the transition that is technically complete but operationally unsupportable — the system that goes live and then cannot be watched as it fails or turned back once it does. It forces observability and reversibility to exist before crossing, when they are cheap, rather than being improvised during an incident.
Its failure mode is sign-off theater: criteria ticked from confidence rather than demonstration, so the runbook "exists" but is stale and the rollback "works" but was never run. The classic misuse is scope-narrowing to pass — quietly dropping the domain that is not ready ("monitoring is a fast-follow") so the review clears on paper while the real gap ships. The discipline that guards against this is to demonstrate rather than assert (a game-day over a checkbox), to treat any un-demonstrated critical capability as a hold, and to log every scope waiver rather than let it vanish.[n1]
How it implements the components¶
preparation_path— it defines and verifies the concrete day-2 preparation (staffing, training, runbooks, escalation, spares) that moves the receiving operation from not-ready to able-to-run.post_transition_monitor— it requires the monitoring that will watch the new state after crossing to be live and verified before crossing, closing the observation loop from day one.rollback_precondition_check— it makes a tested, rehearsed reversal a precondition of release, so a bad crossing can be undone.
It does not name what the transition is entering or coordinate the customer-facing functions — that is the Launch Readiness Review; it does not codify the compact go/no-go conditions (the Preflight Checklist) or aggregate graded evidence into a status (the Readiness Scorecard). The proceed / delay / abort authority sits with the Go / No-Go Meeting.
Related¶
- Instantiates: Transition Readiness Assessment — the deep operability gate that asks whether the receiving operation can sustain the new state.
- Sibling mechanisms: Launch Readiness Review · Preflight Checklist · Readiness Scorecard · Go / No-Go Meeting · Phase-Gate Review · Gap Remediation Plan · Disaster Reentry Check · Clinical Discharge Readiness Check
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: The review evaluates demonstrated staffing, runbooks, monitoring, support, and rollback capability and returns a production-readiness disposition.
Nearest alternative: Decision, Gate & Allocation — The finding gates activation, but it is produced by evidence-based readiness assurance.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Operational Readiness Review is most directly rooted in engineering and design's traditions of specification, testing, reliability, control, and physical-system construction. The lineage fits its defining practice: Checks whether the receiving operation can actually run, support, watch, and recover the new state in production — staffing, runbooks, monitoring, and a tested rollback — before it is switched on.
Related originating lineages:
- Aviation & Aeronautics — Aerospace programs, especially launch and mission operations, materially standardized formal readiness reviews.
- Military & Strategic Studies — Operational Readiness Review also draws materially on military and strategic studies' traditions of initiative, adversarial response, contingency planning, and operational rehearsal, which shaped this mechanism rather than merely adopting it as an application.
- Organizational & Management Science — Operational Readiness Review also draws materially on organizational and management science's practice of coordinating people, authority, strategy, knowledge, and work, which shaped this mechanism rather than merely adopting it as an application.
Review resolution: Both independent reviews agree on primary origin engineering_design; reconciliation resolves alternate_origin_disagreement, origin_mode_disagreement. Formative alternate lineages retained: military_strategic_studies, organizational_management, aviation_aeronautics. The broader reach of later applications is kept separate as domain_reach=multi_domain; origin_mode=cross_disciplinary_synthesis records how the formative lineages relate. Confidence is conservatively reconciled to high, and encyclopedia_synthesis=false preserves the reviewers' boundary judgment.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
The review checks the operation, presupposing the new state itself has been validated by a separate gate. Confusing "is it built right" with "can we run it" lets a team pass a beautiful, correct system into an operation that cannot hold it — the two questions fail in different ways, and only this gate asks the second one.
[n1] The Operational Readiness Review is an established milestone in large-program management — NASA runs an ORR before committing a system to operations, and cloud-operations practice (for example, the operational-readiness reviews described in the AWS Well-Architected Framework) checks that a workload can be run and supported in production. The name is used here in that standard sense. ↩