Glossary

Acceptance criteria

Written before the work, checkable after it, and binary either way.

Definition

Acceptance criteria are the conditions a deliverable must satisfy to be accepted by the person who requested it, written before work begins and evaluated as pass or fail rather than as a matter of opinion. The practice comes from agile requirements work, where criteria attached to a user story define its scope and tell the team unambiguously when the story is finished.

Origin: Agile user-story practice
Written: Before work starts
Evaluated as: Pass or fail

Where the practice came from

Acceptance criteria entered mainstream software practice through extreme programming and the user-story format, where Mike Cohn's conditions of satisfaction described the checks a story had to pass before a customer would accept it. Behaviour-driven development later formalised one common shape, Given-When-Then, and made criteria executable as tests.

The reason the practice survived every methodology fashion is that it does one specific job: it moves the argument about scope to before the work, when changing the answer is cheap.

The two formats in common use

Checklist
A list of conditions, each independently verifiable. Best for deliverables that are documents, analyses or artefacts rather than behaviours.
Given-When-Then
Given a starting state, when an action occurs, then an observable outcome follows. Best for system behaviour, and directly translatable into automated tests.

Commonly confused with

Term	Scope	The difference
Definition of Done	Every item the team produces	A team-wide standard such as tests written and documentation updated. Acceptance criteria are specific to one item.
Requirements	The whole system or feature	Describe what to build. Acceptance criteria describe how to check it was built.
Test cases	Verification procedure	Written after, derived from the criteria, and usually more numerous and more detailed.
Success metrics	Business outcome after release	Measured later, in production. Criteria are checkable at handover.

Why they matter more with AI agents than with people

A human colleague who receives a vague brief asks a question. An agent, given the same brief, produces something confidently wrong-shaped and hands it back, having burned the time. Criteria written in advance are the cheapest available fix, because they convert an ambiguous instruction into a set of checks the agent can steer against while working.

In Polaris, a task's checklist is handed to the AI worker as its acceptance criteria. The worker ticks each item the moment it is genuinely complete, so the reviewer opens a delivery with a visible record of which conditions the agent believes it met, and can disagree with any of them before closing the task.

Human-in-the-loop

The system cannot complete the loop without a person, by design.

Delivery comment

Work arrives where the task already lives, attributed and reviewable, and the task stays open.

Work log

The record that makes an unwatched run reviewable afterwards.

AI worker

The difference between an agent you prompt and an agent you assign work to.

Agents deliver, humans close

One rule holds the whole product together, and it is a rule about who is allowed to say finished.

Agentic project management

The line is whether the agent holds the work item or only summarises it.

Questions people ask

+How many acceptance criteria should one task have?

Enough to remove ambiguity and few enough to read at a glance, which in practice is usually three to seven. A task needing fifteen criteria is normally two or three tasks that have not been separated yet.

+Who writes the acceptance criteria?

The person requesting the work, because they are the person who will accept or reject it. The performer can propose additions and should challenge criteria that are untestable, but the requester owns the definition of accepted.

+What makes an acceptance criterion bad?

Any criterion that cannot be checked without a debate. Fast, clear, user-friendly and well-researched all fail the test. Replace each with an observable condition: a named source count, a stated response time, a specific section that must exist.