Engineering Context¶
Purpose¶
This page explains how ETIS treats release readiness.
A release decision is an engineering judgment based on evidence. It is not simply the next step after testing, and it is not justified by optimism, schedule pressure, or fatigue.
Release readiness must consider requirements satisfaction, verification evidence, defect severity, guardrail status, AI-control status, operational constraints, governance concerns, release scope, accepted risks, unresolved issues, and readiness for operation.
Release is not binary¶
A baseline may be ready for one kind of release and not another.
Examples include:
- not ready for release;
- ready for classroom demonstration;
- ready for internal pilot;
- ready for limited pilot with exclusions;
- ready for operational trial with monitoring;
- ready only after specific defects are fixed.
The release decision should state the release type clearly. “Ready” without a release type is not release readiness.
Release evidence index¶
A release reviewer should not have to search the repository to find evidence.
ES-110 requires a release evidence index that points to requirements evidence, architecture and design evidence, implementation evidence, integration evidence, testing evidence, defect logs, guardrail verification, AI verification, risk records, and release decision records.
The index turns the repository into a reviewable engineering record.
Defects and risks¶
Not all defects are equal.
A minor wording defect may not block a limited pilot. An unverified evidence-write path, access-control gap, or AI-review bypass may block release or require severe scope limitation.
Release readiness requires explicit classification:
- must fix before release;
- may release with condition;
- accepted risk;
- deferred outside scope;
- not applicable.
Do not bury difficult decisions.
Guardrail release review¶
Guardrails are release-sensitive.
A release candidate should not proceed if trustworthiness guardrails are unverified or failing unless the release scope explicitly excludes the affected behavior and the risk is accepted.
Guardrails often matter more than feature completeness.
AI release review¶
If AI functionality is active, release readiness must review AI controls.
If AI functionality is deferred, release readiness must verify that no partial or hidden AI path is active.
AI review should consider active AI capabilities, human review, output status, labeling, rejection path, fallback path, prohibited data, and AI-use evidence.
Release conditions¶
A conditional release must state conditions.
Examples include limited users only, limited incident categories only, AI disabled, manual monitoring required, unresolved defects documented, rollback path defined, and post-release review required.
Conditions are part of the release decision, not footnotes.
Release as accountability¶
A release decision transfers responsibility from engineering evidence review into operational preparation.
That does not mean engineering work ends. It means the evidence must be strong enough that operations, governance, and stakeholders can understand what they are being asked to support.
Do not call something pilot-ready unless the pilot boundary is explicit. A vague pilot is an uncontrolled release with softer language.
A mature engineering organization is willing to say not ready when the evidence says not ready.