What are acceptance criteria?

Acceptance criteria are the conditions that show a requirement was built correctly, written so that anyone, a tester, the owner or an AI coding tool, can check them. A common form is: given a situation, when something happens, then this is the result.

They turn "it should handle credit holds" into something you can try on the finished software and get a clear yes or no.

What do good acceptance criteria look like?

Here are four, for ordinary business rules:

• Credit hold. Given a customer whose open balance plus a new order would exceed their credit limit, when the order is entered, then it's saved on hold and the credit manager is notified.
• Delivery window. Given a customer whose receiving hours are 6 a.m. to 2 p.m., when a dispatcher schedules a delivery for 3 p.m., then the schedule shows a warning and asks for a reason before saving it.
• Approval limit. Given a purchase request above the requester's approval limit, when it's submitted, then it goes to the next approver in line, and the requester can see who has it.
• Overdue tool. Given a tool checked out with a return date of Friday, when Monday morning arrives and it hasn't been returned, then it appears on the attendant's overdue list with the borrower's name.

Each one names the situation, the action and a result someone can observe.

How are they different from requirements?

A requirement says what the software must do: "Orders that exceed a customer's credit limit are held." The acceptance criteria say how to tell it works, including the edge cases: exactly at the limit, a limit of zero, an order that's changed after it was held. Those edge cases become test conditions.

Who writes them?

The people who know the rule should supply the substance: finance knows how credit holds work, dispatch knows the delivery windows. Someone then writes them in a consistent, checkable form. The owner should be able to read every one and agree.

Why do they matter with AI coding tools?

An AI coding tool can turn clear acceptance criteria into automated tests and check its own work against them. Without them, it can only check that the code runs, not that it does what the business needs.

What are common mistakes?

Criteria that can't be observed ("works correctly"), criteria that only cover the happy path, and criteria written after the build to match what was built. Write them before.

Requirements in a Mochlion Build Specification carry acceptance criteria; the sample shows them in place.