Acceptance criteria: make intent testable
Acceptance criteria are observable expectations that define when a requirement is satisfied. They let a human reject a plausible but incorrect agent result by comparing the actual behavior with the agreed outcome, constraints and boundaries.
They belong in the PRD and flow into planning, delegation and verification in AI Architect Mastery's AI Driven Development Methodology.
Why criteria come before execution
"Improve security" or "make it faster" leaves the agent to invent success. Criteria identify the relevant scenario, expected result and constraint before implementation choices shape the definition of done.
How to make a criterion useful
- Describe observable behavior under specified conditions.
- Include relevant denied, empty, invalid or boundary cases, not only the happy path.
- State invariants: existing behavior that must remain unchanged.
- Identify appropriate evidence and the environment or data conditions needed to interpret it.
- Keep the human responsible for accepting or clarifying the expectation.
Constructed example: an export requirement
Weak: "Make export secure."
Bounded: "The record owner can export through the existing interface. A signed-in non-owner is denied and receives no record contents. The successful export format remains unchanged."
Evidence includes allowed and denied request tests plus a regression check for the output format. These illustrate a requirement; they are not a complete security assessment.
Tests are evidence, not the definition of intent
A test can encode the same misunderstanding as the implementation. Review whether its assertions represent the requirement, then check its actual result. If ownership was never defined, the right action is clarification of the PRD, not another speculative test.