ES-110 — Release Readiness¶
You are here¶
ES-109 produced testing and verification evidence.
ES-110 decides what that evidence means for release.
This stage is not a celebration checkpoint and it is not an automatic promotion after testing. It is a disciplined release judgment about whether a verified baseline should be released, piloted, deferred, or rejected.
A release candidate may be ready for one release type and not another. It may be ready for a classroom demonstration, a limited internal pilot, an operational trial with monitoring, or no release at all.
Release readiness is evidence-backed accountability.
Why this stage exists¶
Teams often confuse “tested” with “ready.”
A system can pass important tests and still be unready because defects remain unresolved, guardrails are only partially verified, AI boundaries are unclear, access-control testing is incomplete, operational ownership is undefined, release scope is too broad, or the evidence does not support the release claim.
ES-110 prevents premature release by forcing the team to answer a harder question:
What kind of release is justified by the evidence we actually have?
The engineering question¶
Should this system baseline be released, piloted, deferred, or rejected based on the available engineering evidence and remaining risk?
What you will produce¶
ES-110 produces release readiness artifacts under:
docs/release/
Required artifacts:
release_candidate_summary.md
release_evidence_index.md
defect_and_risk_assessment.md
guardrail_release_review.md
ai_release_review.md
release_scope.md
release_decision_record.md
release_conditions.md
release_readiness_review.md
release_readiness_summary.md
Templates should be copied from:
template-library/release/
Completed reference examples, when available, should be reviewed under:
examples/lmu-coicp/release/
What good looks like¶
Good ES-110 evidence shows what baseline is being considered, what kind of release is proposed, what evidence supports that decision, what defects remain, what risks are accepted, what guardrails passed or failed, what AI capabilities are active or disabled, what conditions apply, who made the release decision, and why ES-111 can begin.
A responsible release decision may say not yet.
That is not failure. That is engineering judgment.
Release readiness is scoped¶
Release readiness is not binary.
The correct question is not simply whether the system is ready. The correct question is:
Ready for what release, under what scope, with what conditions, and with what accepted risk?
A baseline may be unsuitable for broad production but acceptable for a limited pilot. It may be acceptable only with AI disabled, only for selected users, only with manual monitoring, or only after specific defects are fixed.
Scope is part of the release decision.
Relationship to ES-109¶
ES-109 verifies.
ES-110 judges release readiness.
If ES-110 finds verification gaps that block readiness, return to ES-109.
If ES-110 finds implementation defects, return to ES-107 and ES-108.
If ES-110 finds operational concerns, carry them forward explicitly into ES-111.
Relationship to ES-111¶
ES-111 should not have to guess what it is preparing to operate.
ES-110 gives ES-111 a release baseline, release scope, release conditions, accepted risks, unresolved issues, guardrail status, AI status, and decision record.
Operational readiness begins only when release readiness defines what operations must support.
Lifecycle chain¶
ES-110 continues the ETIS lifecycle chain:
Question
↓
Evidence
↓
Decision
↓
Repository Artifact
↓
Next Stage
For ES-110, the question is whether release is justified. The evidence is the release readiness package. The decision is release, pilot, defer, or reject. The repository artifact is stored under docs/release/. The next stage is ES-111.
AI may help summarize evidence, identify release risks, compare defects against guardrails, draft decision records, and critique readiness rationale. AI must not make the release decision.
Do not convert open defects into accepted risks just to preserve momentum. Risk acceptance is a real decision that requires rationale and accountability.
Release readiness is where engineering evidence becomes operational accountability.