How to define acceptance criteria with AI

Start with the user journey and invariant

Write who is trying to do what, under which conditions, and why. Then state the invariant—the condition that must remain true across implementations. For a synthetic feature allowing an administrator to duplicate an assessment template, an invariant might be: “Duplication creates a new editable template without changing the source template or transferring unauthorized access.”

List relevant actors, system states, data sensitivity, dependencies, and out-of-scope behavior before asking AI for cases.

Derive criteria through six lenses

### Happy path

Describe the smallest successful journey and its observable result.

### Negative behavior

Specify invalid input, unavailable dependencies, insufficient permission, and conflicting state. Criteria should say what the user sees and what the system does not change.

### Boundaries

Test zero, one, maximum, just-over-maximum, dates at cutoffs, empty values, long values, and concurrent actions where relevant.

### Data and permissions

Define what is copied, regenerated, omitted, logged, and visible to each role.

### Recovery

State behavior for partial failure, retry, timeout, and duplicate submission.

### Accessibility

Include keyboard, focus, name and role, error identification, status communication, and relevant assistive-technology behavior. W3C explains that WCAG success criteria are testable and that conformance evaluation combines automated and human evaluation. Accessibility should not be reduced to a single automated scan.

Worked synthetic criteria

AC1 — Successful duplication: Given an administrator can view source template T, when they choose Duplicate and provide a valid unique name, then a new draft template is created with copied scenario content, a new identifier, and an audit event; T remains unchanged.

AC2 — Permission denial: Given a member without duplication permission can view T, when they attempt the duplication route directly, then no new template is created and the interface communicates that permission is required without exposing restricted settings.

AC3 — Name boundary: Given the proposed name exceeds the documented maximum, when the user submits it, then creation does not begin, the field is identified in the error, and focus moves to an actionable message.

AC4 — Partial failure: Given content copy succeeds but audit-event persistence fails, when the operation cannot complete atomically, then the user receives a retry-safe failure state and no usable duplicate is exposed.

AC5 — Repeated action: Given the original request times out after reaching the service, when the user retries, then the system does not create multiple indistinguishable templates.

These criteria intentionally avoid dictating the technical implementation except where observable integrity requires it.

Use AI as a coverage critic

Provide the journey, invariant, state model, and first criteria. Ask AI to find uncovered role-state-action combinations, ambiguous terms, unobservable outcomes, and contradictions. Require it to explain why each proposed case could change release confidence. Reject cosmetic rewrites.

Make criteria executable in principle

For every criterion identify setup, action, observable result, and evidence. Link it to a test level—unit, integration, end-to-end, security review, accessibility evaluation, or manual product review. “Works correctly” and “is user-friendly” are not acceptance criteria until converted into observable conditions.

Verification checklist

Trace each requirement to at least one criterion; cover unauthorized actors and invalid states; test boundaries; define atomicity and retry behavior; include accessibility evaluation; remove implementation assumptions that do not affect behavior; identify evidence; and review with product, engineering, design, and quality owners.

Sources and claim map

The feature, roles, limits, and failure behavior are synthetic. This educational method does not assure defect-free software, accessibility conformance, security, or product outcomes.

• W3C Web Accessibility Initiative, Understanding Conformance: supports treating accessibility success criteria as testable and combining automated checks with human evaluation.
• W3C, Web Content Accessibility Guidelines 2.2: provides the stable technical standard and testable success criteria for accessibility requirements.

Sources: [1] [2]