Production readiness is the evidence that a team can release, understand, recover, support, and improve a system under expected conditions. It is not a final meeting where missing operational work is discovered.
Critical journeys and quality
Define user-visible success, acceptance tests, severe failures, accessibility, performance, and behavior under invalid or incomplete input. For AI, include evaluation slices and fallback.
Security and data
Review identity, authorization, secrets, dependency risk, input validation, encryption, retention, deletion, audit, and incident contacts. Confirm production data is not copied into unsafe debugging channels.
Reliability and change
Set service objectives, dependency timeouts, retries, idempotency, capacity, backups, deployment checks, rollback, feature flags, and disaster assumptions.
Operations and ownership
Instrument critical journeys, create alerts tied to user impact, write runbooks, schedule support, assign owners, and document known limitations and post-launch measures.
Prove readiness with evidence
For reliability, show service objectives, load results, dependency behavior, backup and restore evidence, and tested rollback. For security, show threat review, identity boundaries, secrets handling, dependency scanning, and response ownership. A checked box should link to an artifact or accepted decision.
Include observability that answers user-impact questions: which journey failed, for whom, because of which dependency or release. Logs without correlation and dashboards without response actions are not readiness. Define alert ownership, severity, escalation, and quiet-hour behavior.
Test operational procedures with the people who will use them. A runbook written by the delivery team but never exercised can fail at the first incident.
Control the release and early-life period
Define migration, compatibility, feature flags, staged exposure, rollback, customer communication, and support coverage. Verify analytics and audit events before broad rollout so the team can see whether adoption and behavior match expectations.
Schedule an early-life review using incidents, performance, support, adoption, and quality evidence. Production readiness is not proof that nothing will fail; it is confidence that the organization can detect, contain, recover, and learn.
Executive decision record
The decision is whether the organization can release, observe, support, recover, and change the system inside an accepted service and risk boundary. Write that decision before selecting a model, vendor, framework, or implementation pattern. A written boundary keeps technical exploration connected to the operating outcome and makes it possible to explain why the organization advanced, revised, or stopped the work.
Approval should depend on tested quality attributes, threat review, load and recovery results, observability, migration, rollback, runbooks, ownership, and early-life plan. The evidence does not need to remove every uncertainty, but it should address the uncertainty capable of changing value, architecture, risk, or ownership. Record the baseline, assumptions, unresolved questions, and the person accepting the next stage.
Failure boundary and operating ownership
The central failure to guard against is approving boxes without linked evidence or assuming a successful deployment proves the people and procedures can handle failure. Treat that condition as a testable scenario. Define how the system detects it, what users experience, which action is prevented or reversed, and what evidence reaches the person responsible for recovery.
Long-term accountability sits with the service owner accepting production responsibility, supported by security, platform, support, and business operations. Supporting specialists can provide platforms, research, review, or delivery capacity, but they cannot substitute for an owner who controls policy and operating change. Name that owner before production and include the ownership path in release evidence and incident procedure.
A practical 90-day application plan
During the first 30 days, convert tested quality attributes, threat review, load and recovery results, observability, migration, rollback, runbooks, ownership, and early-life plan into a bounded evidence plan. Assign each artifact to a named contributor, identify the representative inputs required, and agree on the comparison baseline before implementation expands. The objective of this period is to expose the assumption most likely to invalidate the work while the cost of changing direction is still low.
During days 31 through 60, build or instrument the smallest complete workflow that can support the decision about whether the organization can release, observe, support, recover, and change the system inside an accepted service and risk boundary. Include the real data and authorization path where feasible, record exceptions, and review difficult cases with the people who own the underlying process. Resist adding breadth until the team can explain the measured behavior of this narrow slice.
During days 61 through 90, test the boundary represented by approving boxes without linked evidence or assuming a successful deployment proves the people and procedures can handle failure. Exercise degraded dependencies, ambiguous inputs, recovery, and handoff rather than demonstrating only successful cases. End the period with a written advance, revise, or stop decision that cites evidence, residual exposure, expected operating cost, and the next authority boundary.
The review should be accepted by the service owner accepting production responsibility, supported by security, platform, support, and business operations. That group should confirm not only that the system can work, but that ownership, support capacity, monitoring, and change control are credible. If those conditions are absent, the responsible outcome is another bounded learning stage rather than an unsupported production commitment.
Practical checklist
- Acceptance and regression tests
- Security and privacy review
- Data lifecycle and recovery
- Service objectives and capacity
- Observability and actionable alerts
- Deployment, rollback, and feature control
- Runbooks, support, and named owners
- Accessibility and user communication
Continue reading
- [AI pilot to production](/ai-pilot-to-production-roadmap)
- [AI platform observability](/ai-platform-observability-opentelemetry)
Sources and further reading
- [CISA Secure by Design](https://www.cisa.gov/resources-tools/resources/secure-by-design)