# AI release-readiness checklist

Use with a scoped evaluation report. A checked box must link to evidence; this checklist alone does not establish production readiness.

Release / system version:
Evaluation report and dataset version:
Decision owner:
Engineering and domain reviewers:
Review date:

## Scope and evidence
- [ ] Intended users, workflows and excluded tasks are documented.
- [ ] Acceptance criteria and critical-failure rules were agreed before grading.
- [ ] Input permissions, reference provenance and versions are recorded.
- [ ] Ordinary, difficult, missing-evidence and restricted-action cases are covered.
- [ ] Protected evaluation splits and contamination checks are documented.
- [ ] Coverage gaps and reviewer disagreements are visible in the report.

## Reproducibility and quality
- [ ] Model, prompt, retrieval, tool and dependency versions are pinned or recorded.
- [ ] Results include task counts, repeated-trial counts and exclusions.
- [ ] Infrastructure errors are distinguished from task failures.
- [ ] Material findings include reproducible inputs and expected outcomes.
- [ ] Candidate changes are compared against the same baseline tasks.
- [ ] Latency and cost assumptions are stated with measurement boundaries.
- [ ] Fixes have passed affected-case and broader regression checks.

## Runtime operations
- [ ] Timeouts, retry limits and duplicate-action prevention are tested.
- [ ] Permissions and human approval gates are enforced at the action boundary.
- [ ] Unsupported answers and unavailable tools have useful fallback behaviour.
- [ ] Logging avoids unnecessary private inputs and secrets.
- [ ] Monitoring, incident ownership and escalation contacts are assigned.
- [ ] Rollback or feature-disable procedures have been reviewed.
- [ ] Dependencies, configuration and deployment environment have been verified.

## Ownership and decision
- [ ] Remaining failures have named owners and documented consequences.
- [ ] Accepted risks and untested criteria have explicit owner decisions.
- [ ] Rerun triggers are defined for model, prompt, source and workflow changes.
- [ ] Dataset, grader and suite maintenance ownership is assigned.
- [ ] Retention, deletion and access-removal actions are scheduled as agreed.

| Criterion / risk | Evidence | Status: met / unmet / untested | Owner | Required action |
| --- | --- | --- | --- | --- |

Decision: release / limited rollout / hold
Conditions and rationale:
Approver and date:
Rollback triggers:
Next evaluation date or triggering change:

This is an engineering review aid. Additional security, accessibility, domain and organizational requirements depend on the product and intended use.