Acceptance Criteria Must Be Provable

A criterion you can’t check is a wish

In Let Agents Review Behavior and Intent Too, I said to give a reviewing agent the issue and its acceptance criteria, then have it report which requirements the change satisfies and which it misses.

That only works if the criteria can be checked. “The cancellation flow works well” has no yes or no. A reviewer who tries to verify it ends up guessing what “well” meant. An agent will guess too, and it will sound sure about it.

Whether You Think AI Can or Can’t, You’re Right says a missing definition of done is a setup failure. A vague definition is the same failure with more words. You gave the agent a target it can’t miss, because it can’t be measured.

Rewrite until a check can fail

Take the cancellation example from Behavior Tests Tell You Why the Code Exists. A ticket that says “cancellation works correctly” can’t be proven. These can:

• Stop future renewal charges.
• Keep access until the end of the paid period.

Each one has a check. Create a subscription that would renew on October 1, cancel it, and assert that no charge is due that day. Create one paid through September 30, cancel it, and assert that access still holds on September 15. If those fail, the criterion is false. If you can’t write a check like that, the criterion is still a wish.

Vague words on tickets need the same treatment. Rewrite “The checkout is fast” to “A checkout of 10 line items finishes in under 200ms when you run the repo’s checkout benchmark.” Someone can run the command and get a yes or no. Rewrite “The settings page looks good” to “The save button stays disabled until every required field is valid.” A screenshot of the form with the email field empty and the button disabled backs it up.

If a criterion still says “well,” “fast,” “intuitive,” or “polished,” it isn’t done being written.

Don’t claim done without evidence

An agent will often call the work finished as soon as the file is written. A green test suite isn’t enough either, because green tests don’t prove the agent built what you asked for. The tests can encode the same misunderstanding as the code. That’s why Review the Outcome, Not the Output asks whether the tests check what matters, not whether the agent wrote tests.

So write the criteria before the work starts, and keep them out of the worker’s write path. That’s the same rule as Describe the What, Delegate the How. The agent doing the work shouldn’t get to edit the definition of done. It gets read access only. The check has to live outside the agent that did the work.

When you ask an agent to implement a ticket, ask it to prove each criterion. This is an example to try, not a report of a workflow I’ve already run.

Implement this ticket against the acceptance criteria below.
Do not edit the criteria or the tests that encode them.

For each criterion, report:
- The check you ran: the exact command, test name, measurement, or screenshot
- The result
- If you could not prove it, say so and stop short of claiming done

A passing suite is not evidence for a criterion that has no check.
Reading a test is not a passing test run.
Do not claim done until every criterion has evidence or an explicit gap.

A human still has to look at that evidence. If the criterion was “keep access until the end of the paid period” and the only test asserts that a cancel method was called, that isn’t proof. Send it back.

Acceptance criteria are how you and the agent agree what done means. If a line can’t be proven, it isn’t a criterion yet. Rewrite it before the work starts.