1. Intended workflow
The deliverable supports [defined workflow] for [defined users] using [approved inputs]. Actions outside that boundary are excluded unless added through change control.
AI acceptance criteria examples
Define “working” before fixing the price of an AI project.
Fixed-price AI acceptance criteria turn a probabilistic deliverable into a bounded decision: which evidence will be tested, which thresholds apply, what the client must provide, and what happens when the result falls outside the boundary.
Why AI criteria differ
Acceptance cannot depend on one demonstration or one exact output.
Many AI systems can produce more than one acceptable answer. The contract therefore needs a versioned evaluation set, a scoring method, thresholds, prohibited outcomes, and a rule for variance across repeated runs where non-determinism affects the result.
Engineering reasoning: “the feature works” is not testable until the parties define the representative cases, acceptable behaviour, failure classes, operating conditions, and evidence required for acceptance.
This page offers engineering scoping language, not legal advice. Contract terms should be reviewed by qualified counsel for the relevant parties and jurisdiction.
Contract language
AI acceptance criteria examples
2. Evaluation set
Acceptance will be assessed against evaluation set [version], containing representative cases, named exception classes, and prohibited outcomes approved by both parties.
3. Quality threshold
The deliverable is accepted when it meets [agreed measure and threshold] overall and does not breach the separate threshold for [high-consequence slice].
4. Human review
Cases matching [defined conditions] must route to human review with [required context]. Automatic completion of those cases is a release-blocking failure.
5. Repeated runs
Where outputs vary, [number] runs per designated case will be assessed and acceptance will use [agreed distribution or failure-rate rule].
6. Operational boundary
Under the agreed load and environment, the deliverable must remain within [latency], [cost], [availability], and [retry] limits measured by [named method].
7. Client dependencies
The client will provide [data, access, reviewers, systems, and decisions] by [dates]. A delayed or materially changed dependency follows the agreed change process.
8. Handover
Acceptance includes delivery of [code, configuration, evaluation assets, runbooks, monitoring, cost model, documentation, and knowledge-transfer sessions].
Change and acceptance
Separate a failed criterion from a changed problem.
A failed criterion means the deliverable does not meet the agreed evidence boundary. A changed model, data source, workflow, integration, policy, volume, or evaluation set may be a scope change instead. The agreement should state who can approve a change and how price, schedule, and acceptance evidence are revised.
Record the acceptance run with the deliverable version, environment, evaluation-set version, configuration, results, exceptions, and sign-off. If a criterion fails, the record should distinguish remediation, an approved waiver, a scope change, or rejection.
Public sources
Sources that inform the evidence boundary
NIST AI RMF Playbook: Measure
NIST's Measure resources support context-specific quantitative, qualitative, and mixed-method assessment. Read the NIST resource.
NIST Secure Software Development Framework
NIST SP 800-218 provides a public framework for defining and communicating secure development practices across producers and acquirers. Read NIST SP 800-218.
Published method
Agent frameworks for this decision
For agent-based workflows, these documents expand on the decision above. They describe our method, not client results.
AI Agent Control Checklists
Use the control-record and evidence worksheets to specify what must be demonstrated at acceptance and handover.
AI and Agent Governance Framework
Separate business acceptance, technical validation and change authority before agreeing the delivery boundary.
Next decision
Define the acceptance boundary
Describe the intended deliverable, known dependencies, and the decision that acceptance must support. Fixed pricing follows a clear scope; it does not replace one.
We review your enquiry and reply by email. No commitment to a paid project; scope and terms are agreed before work begins.
Prefer email? dev@alpha-ai.dev