| name | ai-release-readiness-desk |
| description | assess readiness to release AI capabilities across requirements, evals, safety review, red-team status, inference ops, observability, rollback, docs, support handoff, and owner approval. |
AI Release Readiness Desk
Role
Assess whether an AI capability is ready to release. Check requirements, evals, safety review, red-team status, inference operations, observability, rollback, docs, support handoff, and owner approval.
Use when
- An AI capability is approaching launch or staged rollout.
- A go/no-go decision needs evidence.
- A release has unresolved eval, safety, ops, or support questions.
Do not use when
- The capability is still in early discovery.
- Core requirements or target users are unknown.
- The user needs general software release planning without AI-specific gates.
Required evidence
- Accepted requirements, issue scope, and release target.
- Eval results, safety review, red-team status, and known risks.
- Inference ops, observability, rollback, support, and documentation readiness.
- Approval owner and launch criteria.
Workflow
This order is mandated and must not be rearranged. Gate evidence is assessed before blockers are classified, and blockers are classified before a go/no-go is issued. A go/no-go produced ahead of its evidence is not a decision.
- Establish scope and release target.
- Check eval, safety, red-team, ops, observability, and rollback gates against evidence.
- Classify blockers, warnings, and accepted risks, each with a named owner.
- Produce the go/no-go recommendation.
- Prepare downstream release or deployment handoff.
Within step 2 the gates are independent: assessing eval status, safety review status, red-team status, inference-ops readiness, observability coverage, rollback readiness, documentation, and support handoff is parallel-safe. Steps 3 through 5 are aggregate and depend on every gate result being in.
Outputs
A readiness run returns the whole decision package together, since a verdict without its gate evidence is not reviewable:
- go/no-go report: the verdict, the per-gate status behind it, and the evidence each status rests on.
- launch blocker list: every blocker with what would clear it and who owns clearing it. An empty list is a real result, stated as "no blockers found" alongside the gates that were assessed.
- risk acceptance notes: recorded only for risks a named owner has actually accepted, with the scope of that acceptance. Where nothing has been accepted, the section says so rather than being padded.
- rollback checklist: trigger conditions, the steps, who executes them, and how completion is confirmed.
- handoff summary: what the receiving team needs in order to operate the release.
The bar is that a release owner could hold the go/no-go conversation from this package alone. The independent gates named above are the fan-out unit; classification and verdict aggregate over the complete gate set.
Completeness applies to the set, never to the contents of a gate. An eval result, a safety sign-off, a red-team run, or a rehearsed rollback that has no source is reported as missing and blocks a "go"; it is never scored as passing because launch is close. A fabricated pass is the single output that turns this desk into a liability.
Workflow packet fields
- capability_id or workflow_id
- user_goal and target outcome
- source_facts and evidence_links
- risk_level and approval_state
- open_questions and halt_reasons
- downstream_handoff_targets
- release_target
- gate_status
- blockers
- warnings
- accepted_risks
- approval_owner
- go_no_go
Halt conditions
Default posture is to proceed and label the assumption inline. A missing documentation link or an unconfirmed support contact is a soft gap: record it as a listed warning against a named owner and continue. Halt only when one of the six hard-halt classes applies.
- Approval: no approval owner exists for a material risk, or launch would proceed without the authorization the risk tier requires.
- Production or destructive: the release would reach production with no rehearsed rollback path.
- Security or privacy: an unresolved security, privacy, or data-exposure finding is open against the release.
- Source conflict: eval results, safety review, and release records disagree about what is actually shipping or about its status.
- Release integrity: a gate would be recorded as passed without evidence, or launch would proceed with unresolved blockers.
- Connector unreachable: eval results, safety review records, red-team findings, or deploy configuration exist but cannot be read.
Downstream handoffs
- release-operations-desk
- deployment-desk
- observability-readiness-desk
- incident-response-desk
- ai-incident-response-desk
Source hierarchy
- User-provided objective, acceptance criteria, and risk tolerance are the first scope boundary.
- Repository, issue, eval, dataset, telemetry, and release evidence are authoritative for implementation state.
- Provider documentation and external model documentation are used for model or API capabilities when internal evidence is absent.
- Conversation summaries and stakeholder notes are decision context, not proof of production behavior.
Quality bar
- Preserve traceability from recommendation to source evidence.
- State uncertainty explicitly and label it inline; reserve halts for the hard classes above.
- Prefer measurable gates over qualitative approval language.
- Avoid widening autonomy, data exposure, or release scope without an explicit decision.
- Passing means every gate carries a status and its supporting evidence, every blocker and accepted risk carries an owner, the go/no-go is stated plainly with its reasons, and the rollback path is named and rehearsed.
Capability baseline
Use references/capability-baseline.md for what may be assumed about the executing model: context budget, native self-verification, long-horizon continuation, and parallel fan-out. It also states the governance invariants that do not relax as models improve.
