Evaluate the defined task and configuration. A pass supports the tested scope, not general model reliability. The research companion guide 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.