# AI workflow release review

Evaluate the defined task and configuration. A pass supports the tested scope, not general model reliability. The [research companion guide](/guides/acceptance-review) provides the full acceptance record, recovery exercise, and productivity pilot.

**Workflow / owner / intended users:** ____________________

**Permitted inputs / output destination:** ____________________

**Allowed tools and actions / approval requirements:** ____________________

**Model, configuration, and version references:** ____________________

| Test case | Expected behavior | Observed result | Failure consequence | Supported / unsupported / unknown / not applicable with reason | Evidence |
| --- | --- | --- | --- | --- | --- |
| Ordinary representative input |  |  |  |  |  |
| Missing information |  |  |  |  |  |
| Conflicting sources |  |  |  |  |  |
| Stale or superseded source |  |  |  |  |  |
| Earlier AI summary with unsupported claim |  |  |  |  |  |
| Inaccessible material |  |  |  |  |  |
| Malicious instructions in source |  |  |  |  |  |
| Partial action / destination failure |  |  |  |  |  |
| Recovery and independent final-state check |  |  |  |  |  |

**Evaluation set retained for regression testing (where stored, how many cases, who may change it):** ____________________

## Additional checks before release

- [ ] Provenance of the model, prompts, and any fine-tuning or retrieval data is recorded, including provider version and the notification path for provider changes.
- [ ] Adversarial testing was performed by someone other than the builder and the results are referenced.
- [ ] Usage and spending caps are set; the consequence of exceeding them is known.
- [ ] Prompts, retrieved content, and outputs are logged with a retention period and access list appropriate to their sensitivity.
- [ ] Users and affected people are told an AI workflow is involved where that matters, and outputs carry a label where they leave the firm.
- [ ] Where outputs affect people, the review covered unequal treatment across the groups the workflow will see.
- [ ] Decommissioning steps exist: stop, revoke credentials, delete indexes and history, redirect dependents.

## Release decision

**Required quality and source support:** ____________________

**Observed failures / accepted limitations:** ____________________

**Human review procedure:** ____________________

**Reviewer explanation / exception-handling exercise / observed gaps:** ____________________

**Five acceptance checks (quality, authority, path, evidence, final state):** ____________________

**Pause, rollback, and correction procedure:** ____________________

**Monitoring and reevaluation triggers:** ____________________

**Recommendation / supporting evidence / unresolved gaps:** ____________________

**Approval / permitted scope / approver / date:** ____________________

**Execution (not started / attempted / partial / completed / unknown):** ____________________

**Independent verification (observer / authoritative state / evidence / time):** ____________________

**Final acceptance / owner / limitations / next review:** ____________________

Missing evidence remains unknown. Approval is not execution; a successful request is not proof of the final state. A pre-release review may authorize a controlled deployment, while final acceptance remains pending until post-deployment verification.

Include changes to model, prompts, permissions, connectors, and output destinations in reevaluation planning.

## Common failure modes

- The test cases were written by the builder and all pass.
- The provider changes the model and nobody re-runs the evaluation set.
- Monitoring watches uptime, not output quality.
- Approval is treated as acceptance and the post-deployment check never happens.

**Roles: builder / independent reviewer / business owner / approver:** ____________________

This review covers one workflow and configuration. It does not cover the assistant's access to firm data; use the connector and data-flow review for that.