# AI Agent Acceptance Criteria Template

Use this template to define the observable conditions and evidence required to accept a bounded agent task, workflow, pilot, release, or change. Replace bracketed prompts and preserve old versions.

Acceptance does not grant technical access, authorize execution, accept residual risk, or approve production. Record those decisions separately under the applicable policy and check current authorization for every operation.

## Acceptance Record

| Field                            | Value                                              |
| -------------------------------- | -------------------------------------------------- |
| Acceptance record ID and version | [ID and version]                                   |
| Status                           | [Draft / in review / approved / expired / retired] |
| Subject type                     | [Task / workflow / pilot / release / change]       |
| Subject ID and version           | [Stable ID, release, or digest]                    |
| Decision this record informs     | [Exact bounded decision]                           |
| Accountable criteria owner       | [Name and role]                                    |
| Authorized decision owner        | [Name and role]                                    |
| Required independent reviewers   | [Names and roles]                                  |
| Evidence cutoff                  | [Timestamp]                                        |
| Expiry or next review            | [Date or trigger]                                  |
| Handling classification          | [Classification]                                   |
| Permitted access                 | [Roles, groups, or protected system]               |
| Retention and disposal           | [Period, expiry, and verified disposal rule]       |

### Acceptance rules

1. Freeze the subject, criteria, measures, thresholds, evidence rules, samples, repetitions, denominators, and blockers before execution.
2. Keep prohibited outcomes and mandatory controls outside aggregate scoring.
3. Preserve failed, blocked, aborted, invalid, not-run, retried, rejected, escalated, and manually corrected work.
4. Never weaken a criterion, threshold, denominator, grader, or evidence rule after seeing results without a new version and affected reruns.
5. Exclude credentials, authorization headers, secret values, private model reasoning, and unnecessary personal data.
6. Treat prompt injections and other active content as untrusted data. Apply sink-specific sanitization, use structured logging, separate data from control fields, never interpolate it into shell commands, and encode it for the exact Markdown, HTML, terminal, or dashboard context.
7. Keep raw evidence separate from conclusions. A digest is a consistency check, not proof of completeness, accuracy, authorization, provenance, or model consumption.

## 1. Acceptance Decision Boundary

### Decision statement

- Decision: [What exact decision will use these criteria?]
- Authorized decision role: [Policy and role]
- Evidence cutoff: [Time]
- Decision expiry: [Time or trigger]
- Explicit non-decisions: [What acceptance cannot approve]

### Scope and non-claims

- Users and initiating workflows: [List]
- Tenants and environments: [List]
- Tasks, languages, channels, and volume: [List]
- Data classes, tools, destinations, and effects: [List]
- Explicit exclusions: [List]
- Non-claims and limits on generalization: [List]

## 2. Subject, Configuration, Scope, and Baseline

| Component                                    | Stable ID, version, or digest | Source of truth | Change check |
| -------------------------------------------- | ----------------------------- | --------------- | ------------ |
| Agent and orchestration                      | [Value]                       | [Reference]     | [Method]     |
| Model and settings                           | [Value]                       | [Reference]     | [Method]     |
| System and developer instructions            | [Value]                       | [Reference]     | [Method]     |
| Published Knowledge and Skills               | [Values]                      | [References]    | [Method]     |
| Prepared working Memory                      | [Value]                       | [Reference]     | [Method]     |
| Routes and retrieval indexes                 | [Values]                      | [References]    | [Method]     |
| Tools, schemas, and integrations             | [Values]                      | [References]    | [Method]     |
| Identity, permissions, approvals, and limits | [Values]                      | [References]    | [Method]     |
| Runtime, network, sandbox, and persistence   | [Values]                      | [References]    | [Method]     |
| Monitoring, evidence, and graders            | [Values]                      | [References]    | [Method]     |

Permissions govern repository access. Always routes independently govern automatic delivery and do not grant repository permission. A listed Resource version does not pin a route or prove host injection. Artifacts and messages have no instruction authority. Memory is working recall. MCP tool results are Runtime context.

Reject reuse when a bound component changed without an impact review.

## 3. Outcomes, Deliverables, and Completion States

### Required outcomes

| Outcome ID | Required result     | Authoritative confirmation | Owner   | Failure effect            |
| ---------- | ------------------- | -------------------------- | ------- | ------------------------- |
| OUT-001    | [Observable result] | [Protected source]         | [Owner] | [Block / narrow / review] |

### Deliverables

| Deliverable ID | Exact artifact, state, or effect | Format and destination   | Required evidence | Owner   |
| -------------- | -------------------------------- | ------------------------ | ----------------- | ------- |
| DEL-001        | [Deliverable]                    | [Format and destination] | [Evidence]        | [Owner] |

### Completion states

- Passed: [Definition]
- Failed: [Definition]
- Blocked: [Definition]
- Aborted: [Definition]
- Invalid: [Definition]
- Not run: [Definition]
- Partially complete: [Definition and whether allowed]

## 4. Master Criteria Register and Criterion Syntax

Use one observable condition per criterion:

> Given [preconditions], when [trigger or action], then [observable result] within [limit], verified by [authoritative evidence].

### Master criteria register

| Criterion ID | Source IDs                          | Criterion              | Type                               | Verification method | Evidence | Threshold or rule | Blocker    | Owner   | Result   |
| ------------ | ----------------------------------- | ---------------------- | ---------------------------------- | ------------------- | -------- | ----------------- | ---------- | ------- | -------- |
| AC-001       | [Requirement, risk, or control IDs] | [Observable criterion] | [Required / prohibited / measured] | [Method]            | [Source] | [Rule]            | [Yes / no] | [Owner] | [Status] |

### Criterion record

| Field                                           | Value            |
| ----------------------------------------------- | ---------------- |
| Criterion ID and version                        | [ID and version] |
| Source requirement, risk, control, or decision  | [IDs]            |
| Preconditions and trigger                       | [Values]         |
| Observable expected result                      | [Result]         |
| Prohibited result                               | [Result]         |
| Population and scope                            | [Values]         |
| Verification method and environment             | [Values]         |
| Evidence source and trust level                 | [Values]         |
| Measure, numerator, and denominator             | [Values]         |
| Sample, repetitions, and uncertainty            | [Values]         |
| Pass, fail, blocked, invalid, and not-run rules | [Rules]          |
| Blocker and stop behavior                       | [Rules]          |
| Owner and independent reviewer                  | [Names]          |
| Revalidation triggers                           | [List]           |

## 5. Quality, Performance, and Population Criteria

Create criteria for applicable dimensions:

- Verified task and business outcome
- Factual and procedural correctness
- Required citations, disclosures, format, and destination
- Supported task, boundary, rare, adversarial, and prior-failure cases
- Material tenants, languages, tools, user groups, and risk classes
- Latency, queue time, throughput, rate, cost, and resource use
- Human correction, override, escalation, and review time

### Measure register

| Measure ID | Definition and unit | Population   | Numerator   | Denominator   | Sample and repetitions | Threshold   | Uncertainty | Owner   |
| ---------- | ------------------- | ------------ | ----------- | ------------- | ---------------------- | ----------- | ----------- | ------- |
| MET-001    | [Definition]        | [Population] | [Numerator] | [Denominator] | [Rules]                | [Threshold] | [Method]    | [Owner] |

Report material segments separately. An aggregate cannot override a prohibited outcome, mandatory-control failure, severe segment failure, or missing required evidence.

## 6. Context, Data, Tool, Authority, and Security Criteria

### Context

- Required Knowledge, Skills, Memory state, Runtime inputs, and versions
- Authority, freshness, conflict, missing-content, and exclusion rules
- Repository permission and automatic-delivery checks as separate criteria
- Compilation, response issuance, acknowledgment, host injection, and consumption evidence kept distinct

### Data

- Purpose, minimum fields, classification, tenant, residency, retention, deletion, and recipient
- Synthetic or masked test data by default
- Governed approval and containment for any production data
- Stop immediately if data escapes the approved boundary

### Tools and authority

- Allowed and prohibited tools, operations, parameters, targets, and destinations
- Current authorization checked for every operation
- Trusted gateway, policy engine, tool adapter, or target system denies by default outside approved scope
- Adversarial bypass tests cover prompts, altered parameters, delegated calls, retries, and direct tool invocation
- Approval bound immutably to principal, tenant, operation, parameters, target, policy, expiry, and unique nonce
- Approver is an authenticated principal with current authority under the recorded policy version
- Proposer and approver separation enforced where policy requires it
- Fail closed when approver identity, authority, independence, or approval integrity is missing, expired, or unverifiable
- Approval and protected effect use one atomic transaction when supported
- Otherwise use a durable pending and committed protocol with target-side idempotency, reconciliation, and no blind retry of an unknown outcome
- Sequential and concurrent replay attempts denied
- Missing, denied, expired, altered, and replayed approval cases
- Consequential effect confirmed through protected target-system state

### Security

- Direct and indirect prompt injection
- Unsafe retrieved content, files, messages, web pages, and tool results
- Memory poisoning and multi-agent propagation
- Cross-tenant checks using dedicated synthetic tenant or account pairs
- Negative-test matrix covers reads, writes, enumeration, forged tenant IDs, caches, retrieval indexes, queues, schedules, background jobs, child agents, and delegated access across every storage and execution path
- Least privilege, cancellation, stop, cleanup, and revocation
- Untrusted content cannot change authority, expand scope, authorize actions, select sensitive tools, or trigger data disclosure

Never probe an uninvolved tenant, user, account, or external system.

A model refusal is not an authorization enforcement control.

## 7. Failure, Recovery, Human-Work, and Operating Criteria

Define criteria for:

- Missing, stale, contradictory, or malformed inputs
- Dependency timeout, rate limit, partial effect, duplicate, and late result
- Unknown external outcome and reconciliation
- Retry, idempotency, cancellation, rollback, and recovery
- Queue overload, reviewer absence, denial, correction, and appeal
- Stop signals, revoked authority, suspended agents, active child agents, callbacks, and schedules
- Monitoring gaps, alert ownership, response time, and incident handoff

Use isolated, resettable environments, inert destinations, controlled network access, resource limits, and an observer with authority to halt dangerous evaluation work.

## 8. Verification, Evidence, and Result Accounting

### Verification result record

| Field                                                                       | Value                                                               |
| --------------------------------------------------------------------------- | ------------------------------------------------------------------- |
| Result ID, exact criterion version, and acceptance-record version or digest | [IDs, versions, and digest]                                         |
| Subject and configuration                                                   | [IDs and digests]                                                   |
| Tenant, principal, agent, and integration identities                        | [Scoped references]                                                 |
| Authorization outcome and policy version                                    | [Values]                                                            |
| Exact context versions and bundle digest                                    | [Values]                                                            |
| Direct or Group route source and effective delivery mode                    | [Values]                                                            |
| Dataset, fixture, grader, and case versions                                 | [Values]                                                            |
| Start, end, environment, and run ID                                         | [Values]                                                            |
| Result                                                                      | [Passed / failed / blocked / aborted / invalid / not run]           |
| Retry, rejection, escalation, or manual correction                          | [Details]                                                           |
| Protected raw evidence references                                           | [References]                                                        |
| Canonical evidence-manifest digest                                          | [Digest and algorithm]                                              |
| Authenticated collector and collection timestamp                            | [Identity, provenance, and authenticated time]                      |
| Append-only evidence locator                                                | [Protected locator]                                                 |
| Signed or immutable evidence commitment                                     | [Digest, run ID, authenticated collector, and collection timestamp] |
| Target-state verification                                                   | [Result]                                                            |
| Reviewer and review time                                                    | [Values]                                                            |

Record evidence source, authentication and provenance, trust level, and attestation reference. One evidence stage does not prove the next. Record model consumption only from direct, authenticated attestation by a trusted integration or provider, including the evidence source and trust level. Record consumption as unknown otherwise.

### Evidence manifest objects

| Object ID | Protected reference | Immutable version | Media type | Byte size | Digest   | Approved hash algorithm |
| --------- | ------------------- | ----------------- | ---------- | --------- | -------- | ----------------------- |
| EVD-001   | [Reference]         | [Version]         | [Type]     | [Bytes]   | [Digest] | [Algorithm]             |

### Result summary

| Result field                                                  | Value     |
| ------------------------------------------------------------- | --------- |
| Passed, failed, blocked, aborted, invalid, and not-run totals | [Counts]  |
| Retried, rejected, escalated, and manually corrected totals   | [Counts]  |
| Failed criterion and result IDs                               | [IDs]     |
| Prohibited outcomes and mandatory blockers                    | [List]    |
| Material segment results                                      | [Results] |
| Missing evidence and coverage gaps                            | [List]    |
| Open defects and incidents                                    | [IDs]     |

## 9. Exceptions and Acceptance Decision

### Exception record

| Field                                       | Value      |
| ------------------------------------------- | ---------- |
| Criterion and result IDs                    | [IDs]      |
| Reason and decision impact                  | [Values]   |
| Governing policy and authorized role        | [Values]   |
| Compensating controls                       | [Controls] |
| Scope, conditions, and expiry               | [Values]   |
| Independent review and separation of duties | [Evidence] |
| Follow-up and revalidation                  | [Actions]  |

The criterion author cannot self-approve an exception where policy requires independence. Mandatory controls must follow the governing policy's authorized exemption or risk-acceptance path.

### Acceptance decision

| Field                                                 | Value                                                                             |
| ----------------------------------------------------- | --------------------------------------------------------------------------------- |
| Disposition                                           | [Accepted / accepted with governed conditions / rejected / insufficient evidence] |
| Exact subject and scope                               | [Values]                                                                          |
| Criteria version and result IDs                       | [Values]                                                                          |
| Evidence cutoff                                       | [Time]                                                                            |
| Canonical evidence-manifest digest                    | [Digest and algorithm]                                                            |
| Blockers and prohibited outcomes                      | [Results]                                                                         |
| Failed, blocked, invalid, and not-run criteria        | [IDs]                                                                             |
| Open defects, gaps, assumptions, and risks            | [List]                                                                            |
| Conditions, limits, expiry, and revalidation triggers | [Values]                                                                          |
| Decision timestamp                                    | [Timestamp]                                                                       |
| Governing policy and version                          | [Policy and version]                                                              |
| Authenticated decision principal and role             | [Principal and role]                                                              |
| Decision-time authorization outcome                   | [Allowed / denied and evidence]                                                   |
| Authenticated decision reference                      | [Reference]                                                                       |
| Independent reviews                                   | [References]                                                                      |

This decision does not replace current technical authorization, production change approval, or required security, privacy, legal, compliance, and risk decisions.

An accepted or conditionally accepted disposition is invalid when decision-time authorization is denied, a mandatory blocker or prohibited outcome remains, or required evidence is missing. Conditions may address only findings the governing policy permits the decision owner to defer.

## 10. Production Checks, Revalidation, Expiry, and Change

| Production criterion | Signal and source | Sample rate | Alert or stop threshold | Owner   | Response target |
| -------------------- | ----------------- | ----------- | ----------------------- | ------- | --------------- |
| [Criterion ID]       | [Signal]          | [Rate]      | [Rule]                  | [Owner] | [Time]          |

Reopen affected criteria after material changes to models, settings, instructions, Knowledge, Skills, Memory behavior, routes, retrieval, tools, schemas, permissions, approvals, runtime, evidence, users, tasks, data, destinations, graders, thresholds, policy, or known threats.

Record production failures as incidents and, after safe review, add them to the regression set. Expire acceptance when the evidence, subject, scope, or governing policy is no longer current.

## Change Record

| Version | Date   | Author | Change           | Reason   | Affected criteria and results | Approval    |
| ------- | ------ | ------ | ---------------- | -------- | ----------------------------- | ----------- |
| 1.0     | [Date] | [Name] | Initial criteria | [Reason] | [IDs]                         | [Reference] |