Production Readiness Review
A principal-level, evidence-driven production decision record that adapts launch gates to workload criticality, state, data sensitivity and review type. It separates maturity from evidence confidence and prevents an aggregate score from overriding missing operational controls.
Who this Lab is for
Designed for
- Principal, staff, platform and SRE reviewers
- Service owners accountable for production risk
- Engineering leaders approving critical launches or migrations
Use it when
- Before a new production launch or material architecture change
- Before a stateful migration or high-risk cutover
- During periodic operational recertification
- When an accountable risk decision and audit trail are required
A complete run, step by step
Define workload context
Record criticality, review trigger, state profile, data classification, SLO, RTO, RPO, forecast load, dependencies and the largest correlated failure domain.
Assess domain maturity
Evaluate sixteen controls across reliability, capacity, delivery, observability, incident response, security, data recovery and dependencies.
Attach reviewable evidence
Support tested and production-proven claims with current dashboards, specifications, test results, runbooks, threat models and recovery records.
Resolve hard gates and waivers
Close context-specific blockers or record an approved waiver with rationale, compensating control, accountable approver and expiry.
Record the decision
Preserve the decision, owners, dissent, evidence gaps and validity period as a versioned private engineering record.
What you will need
Prepare the following information before starting. Use measured evidence where possible; defaults are examples and should not be treated as recommendations.
Service or workload
Use the accountable production service name and describe its customer purpose.
Criticality tier
Tier 1 is customer-critical with material business impact; Tier 3 is lower-impact or internal.
Choices: Tier 1 — customer or business critical · Tier 2 — important production workload · Tier 3 — lower-impact or internal
Review trigger
The event that makes this readiness decision necessary.
Choices: New production launch · Material architecture change · Migration or cutover · Periodic recertification
State profile
Stateful and hybrid workloads receive mandatory recovery and integrity gates.
Choices: Stateful · Hybrid · Stateless
Highest data classification
Confidential and restricted workloads receive stronger security gates.
Choices: Restricted / credentials · Confidential · Internal · Public
Availability SLO
Use the approved customer-facing objective, not an aspirational target.
Recovery time objective
Maximum approved restoration time.
Recovery point objective
Maximum approved data-loss window.
Forecast peak throughput
Measured or forecast peak used by the capacity evidence.
Forecast growth
Expected change over the review horizon.
Largest correlated failure domain
Name the zone, region, tenant, datastore or dependency whose loss creates the largest impact.
Critical dependencies
List upstream and downstream systems whose guarantees affect this decision.
Customer SLI, SLO and ownership
The indicator, objective, exclusions and accountable owner are defined.
Choices: Production-proven — validated under real operating conditions · Tested — exercised with representative failure or load · Documented — defined and independently reviewable · Planned — owner identified but evidence incomplete · Not implemented · Approved waiver — accepted risk with owner and expiry · Not applicable — explain in domain evidence
Error-budget policy and release response
Budget consumption changes release and reliability priorities through an agreed policy.
Choices: Production-proven — validated under real operating conditions · Tested — exercised with representative failure or load · Documented — defined and independently reviewable · Planned — owner identified but evidence incomplete · Not implemented · Approved waiver — accepted risk with owner and expiry · Not applicable — explain in domain evidence
Reliability evidence
Link the SLO specification, dashboard, alert policy and recent budget history.
Evidence owner
Accountable owner who can explain and refresh this evidence.
Evidence observation date
When the test, measurement or review actually occurred.
Evidence environment
Where the evidence was produced; this must match the maturity claim.
Choices: Production · Production-representative · Staging · Test / development
Evidence result
Outcome against explicit acceptance criteria, not a subjective confidence statement.
Choices: Passed against acceptance criteria · Partially passed / exceptions · Failed · Not reviewed
Evidence expiry
After this date the evidence cannot support approval without refresh.
Verification source
System of record used for automated or independent verification.
Choices: Repository / pull request · Automated test result · Monitoring dashboard · Runbook / controlled document · Incident / postmortem · Other evidence
Representative sustained-load test
Safe throughput and saturation limits are measured with production-like behaviour.
Choices: Production-proven — validated under real operating conditions · Tested — exercised with representative failure or load · Documented — defined and independently reviewable · Planned — owner identified but evidence incomplete · Not implemented · Approved waiver — accepted risk with owner and expiry · Not applicable — explain in domain evidence
Failure-domain capacity
The workload meets its objective after loss of the largest relevant failure domain.
Choices: Production-proven — validated under real operating conditions · Tested — exercised with representative failure or load · Documented — defined and independently reviewable · Planned — owner identified but evidence incomplete · Not implemented · Approved waiver — accepted risk with owner and expiry · Not applicable — explain in domain evidence
Capacity evidence
Link load-test results, capacity calculations, autoscaling limits and the failure test.
Evidence owner
Accountable owner who can explain and refresh this evidence.
Evidence observation date
When the test, measurement or review actually occurred.
Evidence environment
Where the evidence was produced; this must match the maturity claim.
Choices: Production · Production-representative · Staging · Test / development
Evidence result
Outcome against explicit acceptance criteria, not a subjective confidence statement.
Choices: Passed against acceptance criteria · Partially passed / exceptions · Failed · Not reviewed
Evidence expiry
After this date the evidence cannot support approval without refresh.
Verification source
System of record used for automated or independent verification.
Choices: Repository / pull request · Automated test result · Monitoring dashboard · Runbook / controlled document · Incident / postmortem · Other evidence
Progressive delivery and health gates
Changes limit blast radius and stop automatically when customer or system health degrades.
Choices: Production-proven — validated under real operating conditions · Tested — exercised with representative failure or load · Documented — defined and independently reviewable · Planned — owner identified but evidence incomplete · Not implemented · Approved waiver — accepted risk with owner and expiry · Not applicable — explain in domain evidence
Rollback or roll-forward recovery
Operators have tested recovery for application, configuration, infrastructure and schema changes.
Choices: Production-proven — validated under real operating conditions · Tested — exercised with representative failure or load · Documented — defined and independently reviewable · Planned — owner identified but evidence incomplete · Not implemented · Approved waiver — accepted risk with owner and expiry · Not applicable — explain in domain evidence
Delivery evidence
Link pipeline gates, deployment policy, rollback exercise and schema-change strategy.
Evidence owner
Accountable owner who can explain and refresh this evidence.
Evidence observation date
When the test, measurement or review actually occurred.
Evidence environment
Where the evidence was produced; this must match the maturity claim.
Choices: Production · Production-representative · Staging · Test / development
Evidence result
Outcome against explicit acceptance criteria, not a subjective confidence statement.
Choices: Passed against acceptance criteria · Partially passed / exceptions · Failed · Not reviewed
Evidence expiry
After this date the evidence cannot support approval without refresh.
Verification source
System of record used for automated or independent verification.
Choices: Repository / pull request · Automated test result · Monitoring dashboard · Runbook / controlled document · Incident / postmortem · Other evidence
Customer-impact health model
Alerts and release gates use customer-facing signals with owned thresholds.
Choices: Production-proven — validated under real operating conditions · Tested — exercised with representative failure or load · Documented — defined and independently reviewable · Planned — owner identified but evidence incomplete · Not implemented · Approved waiver — accepted risk with owner and expiry · Not applicable — explain in domain evidence
Dependency and saturation telemetry
Operators can distinguish local, dependency, quota and resource failure modes.
Choices: Production-proven — validated under real operating conditions · Tested — exercised with representative failure or load · Documented — defined and independently reviewable · Planned — owner identified but evidence incomplete · Not implemented · Approved waiver — accepted risk with owner and expiry · Not applicable — explain in domain evidence
Observability evidence
Link dashboards, alerts, traces, synthetic checks and diagnostic coverage.
Evidence owner
Accountable owner who can explain and refresh this evidence.
Evidence observation date
When the test, measurement or review actually occurred.
Evidence environment
Where the evidence was produced; this must match the maturity claim.
Choices: Production · Production-representative · Staging · Test / development
Evidence result
Outcome against explicit acceptance criteria, not a subjective confidence statement.
Choices: Passed against acceptance criteria · Partially passed / exceptions · Failed · Not reviewed
Evidence expiry
After this date the evidence cannot support approval without refresh.
Verification source
System of record used for automated or independent verification.
Choices: Repository / pull request · Automated test result · Monitoring dashboard · Runbook / controlled document · Incident / postmortem · Other evidence
Accountable ownership and support coverage
A named team owns delivery, operations, escalation and dependency relationships.
Choices: Production-proven — validated under real operating conditions · Tested — exercised with representative failure or load · Documented — defined and independently reviewable · Planned — owner identified but evidence incomplete · Not implemented · Approved waiver — accepted risk with owner and expiry · Not applicable — explain in domain evidence
Runbooks, playbooks and incident command
Operators can diagnose, contain and recover common and severe failure modes.
Choices: Production-proven — validated under real operating conditions · Tested — exercised with representative failure or load · Documented — defined and independently reviewable · Planned — owner identified but evidence incomplete · Not implemented · Approved waiver — accepted risk with owner and expiry · Not applicable — explain in domain evidence
Operational evidence
Link the ownership record, rota, runbooks, game-day results and escalation path.
Evidence owner
Accountable owner who can explain and refresh this evidence.
Evidence observation date
When the test, measurement or review actually occurred.
Evidence environment
Where the evidence was produced; this must match the maturity claim.
Choices: Production · Production-representative · Staging · Test / development
Evidence result
Outcome against explicit acceptance criteria, not a subjective confidence statement.
Choices: Passed against acceptance criteria · Partially passed / exceptions · Failed · Not reviewed
Evidence expiry
After this date the evidence cannot support approval without refresh.
Verification source
System of record used for automated or independent verification.
Choices: Repository / pull request · Automated test result · Monitoring dashboard · Runbook / controlled document · Incident / postmortem · Other evidence
Threat model and trust-boundary review
Material abuse cases, identity paths and data flows have controls and owners.
Choices: Production-proven — validated under real operating conditions · Tested — exercised with representative failure or load · Documented — defined and independently reviewable · Planned — owner identified but evidence incomplete · Not implemented · Approved waiver — accepted risk with owner and expiry · Not applicable — explain in domain evidence
Build, dependency and secret provenance
Build integrity, dependency risk, secrets and release provenance are verified.
Choices: Production-proven — validated under real operating conditions · Tested — exercised with representative failure or load · Documented — defined and independently reviewable · Planned — owner identified but evidence incomplete · Not implemented · Approved waiver — accepted risk with owner and expiry · Not applicable — explain in domain evidence
Security evidence
Link threat model, security review, scanning evidence, provenance and residual-risk register.
Evidence owner
Accountable owner who can explain and refresh this evidence.
Evidence observation date
When the test, measurement or review actually occurred.
Evidence environment
Where the evidence was produced; this must match the maturity claim.
Choices: Production · Production-representative · Staging · Test / development
Evidence result
Outcome against explicit acceptance criteria, not a subjective confidence statement.
Choices: Passed against acceptance criteria · Partially passed / exceptions · Failed · Not reviewed
Evidence expiry
After this date the evidence cannot support approval without refresh.
Verification source
System of record used for automated or independent verification.
Choices: Repository / pull request · Automated test result · Monitoring dashboard · Runbook / controlled document · Incident / postmortem · Other evidence
Backup, restore and disaster-recovery exercise
Recovery meets RTO and RPO with production-representative data and dependencies.
Choices: Production-proven — validated under real operating conditions · Tested — exercised with representative failure or load · Documented — defined and independently reviewable · Planned — owner identified but evidence incomplete · Not implemented · Approved waiver — accepted risk with owner and expiry · Not applicable — explain in domain evidence
Data consistency and reconciliation
Partial failure, retry, migration and rollback cannot silently corrupt business state.
Choices: Production-proven — validated under real operating conditions · Tested — exercised with representative failure or load · Documented — defined and independently reviewable · Planned — owner identified but evidence incomplete · Not implemented · Approved waiver — accepted risk with owner and expiry · Not applicable — explain in domain evidence
Data-recovery evidence
Link restore results, reconciliation checks, recovery timing and data-loss verification.
Evidence owner
Accountable owner who can explain and refresh this evidence.
Evidence observation date
When the test, measurement or review actually occurred.
Evidence environment
Where the evidence was produced; this must match the maturity claim.
Choices: Production · Production-representative · Staging · Test / development
Evidence result
Outcome against explicit acceptance criteria, not a subjective confidence statement.
Choices: Passed against acceptance criteria · Partially passed / exceptions · Failed · Not reviewed
Evidence expiry
After this date the evidence cannot support approval without refresh.
Verification source
System of record used for automated or independent verification.
Choices: Repository / pull request · Automated test result · Monitoring dashboard · Runbook / controlled document · Incident / postmortem · Other evidence
Dependency guarantees and ownership
Quotas, SLOs, failure semantics, contacts and fallback behaviour are documented.
Choices: Production-proven — validated under real operating conditions · Tested — exercised with representative failure or load · Documented — defined and independently reviewable · Planned — owner identified but evidence incomplete · Not implemented · Approved waiver — accepted risk with owner and expiry · Not applicable — explain in domain evidence
Dependency failure and degradation testing
Timeouts, retries, fallback and recovery have been exercised without amplification.
Choices: Production-proven — validated under real operating conditions · Tested — exercised with representative failure or load · Documented — defined and independently reviewable · Planned — owner identified but evidence incomplete · Not implemented · Approved waiver — accepted risk with owner and expiry · Not applicable — explain in domain evidence
Dependency evidence
Link dependency inventory, failure tests, quota review and fallback behaviour.
Evidence owner
Accountable owner who can explain and refresh this evidence.
Evidence observation date
When the test, measurement or review actually occurred.
Evidence environment
Where the evidence was produced; this must match the maturity claim.
Choices: Production · Production-representative · Staging · Test / development
Evidence result
Outcome against explicit acceptance criteria, not a subjective confidence statement.
Choices: Passed against acceptance criteria · Partially passed / exceptions · Failed · Not reviewed
Evidence expiry
After this date the evidence cannot support approval without refresh.
Verification source
System of record used for automated or independent verification.
Choices: Repository / pull request · Automated test result · Monitoring dashboard · Runbook / controlled document · Incident / postmortem · Other evidence
Organisation policy profile
Select the approved control profile. Non-waivable controls remain hard gates even when marked as waived.
Choices: Engineering baseline · Critical production · Regulated / high assurance · Organisation-specific profile
Organisation policy name / version
Record the organisation-specific policy or standard that authorises this profile.
Additional non-waivable control IDs
Comma-separated control IDs mandated by your organisation, for example: backupRestore, threatModel, supplyChain. These can only strengthen the selected profile.
Prepared by
Person completing the review and accountable for evidence quality and follow-through.
Independent reviewer
A different person who challenges the evidence and signs the review independently.
Independent reviewer decision
Approval is only possible after explicit independent sign-off.
Choices: Pending review · Approved · Changes requested
Independent review date
Date the independent reviewer examined this evidence set.
Accountable approver
Senior owner authorised to accept the launch decision and residual risk.
Review validity
Re-run after this period or immediately after a material architecture, dependency or risk change.
Approved waivers and compensating controls
For every control marked Approved waiver, record scope, rationale, owner, compensating control and expiry.
Reviewer dissent or unresolved uncertainty
Preserve material disagreement and unknowns instead of forcing consensus.
SRE / security / platform calibration date
Most recent review of this rubric or decision by experienced practitioners.
Practitioner panel and findings
Name the SRE, security and platform reviewers, their roles, and material findings.
What the result tells you
Your report includes
- Proceed, Conditional or Hold decision with explicit hard gates
- Maturity and evidence coverage across eight engineering domains
- Recorded owners, approver, waivers, dissent and review validity
- A versioned decision record and PDF suitable for peer review
How it is determined
The readiness index is the average maturity of applicable controls, but it is secondary to policy gates. Tier 1, stateful and sensitive-data contexts activate stronger minimums. Tested claims without domain evidence fail their gate. Valid approved waivers can remove a blocker but cap the decision at Conditional. Proceed additionally requires sufficient maturity, evidence coverage and accountable governance.
The model enforces structured evidence quality, policy-specific non-waivable gates, independent sign-off and cross-field consistency, but it is not yet calibrated against enough real outcomes for an empirical accuracy claim. External claims remain unverified unless a configured integration confirms them.
Model assumptions
- • Evidence owners and reviewers are represented by stable organisation identities.
- • Observation and expiry dates reflect the underlying artefact, not the review form.
- • Context fields correctly represent criticality, state and data sensitivity.
- • Configured verification integrations authenticate their source systems.
Tier 1 stateful identity launch
Situation
The service has customer-facing SLOs and observability, but failure-domain capacity and restore performance have not been demonstrated against the approved RTO and RPO.
Result
The decision remains Hold regardless of the aggregate readiness index. Capacity and stateful-recovery evidence become explicit hard gates with owners and verification criteria.
Use the result with engineering judgement
- The tool cannot independently verify submitted evidence or production behaviour.
- The policy is a defensible baseline, not a substitute for organisation-specific regulatory, security or change controls.
- Maturity labels require consistent reviewer calibration.
- A Proceed result still requires accountable human review and approval.
Questions before you begin
What score means a service is ready?
No score alone grants approval. Open hard gates always produce Hold; approved waivers cap the result at Conditional; Proceed requires maturity, evidence coverage and accountable approval.
Can a control be marked not applicable?
Yes, but context-specific hard gates cannot be bypassed with N/A. Explain every exclusion in the relevant domain evidence.
How are waivers handled?
Mark the specific control Approved waiver and record rationale, compensating controls, approver and expiry. A valid waiver cannot produce an unconditional Proceed decision.
Can I rerun the review?
Yes. Re-run when conditions close, the review expires, or architecture, dependencies, traffic or risk changes materially.
Readiness Review is under review
This legacy judgement-based Lab has been retired. Existing saved reports remain available, but new execution is disabled.
Open deterministic utilities