## Definition An **executable acceptance criterion** is a statement about software behaviour for which a machine can decide pass/fail without human judgement. Its defining property: no prose, no "should be reasonably fast", no "user-friendly error message" — just a predicate that returns true or false. ## Anatomy A useful AC has four parts: 1. **Precondition** — what the criterion assumes about the system. 2. **Trigger** — concrete and reproducible. 3. **Observable outcome** — binary. 4. **Verification mechanism** — a test, sometimes a script, never a human glance. ## Bad vs Good **Bad** (prose, unverifiable): > Users should be able to log in quickly and see a friendly error if their password is wrong. **Good** (executable): > AC1: Given user `[email protected]` with password `…`, when `POST /auth/login` is called with those credentials, the response is `200 OK` with body matching schema `LoginSuccess` within 250ms p95 over 100 sequential requests on staging. > > AC2: Same user with wrong password returns `401 Unauthorized` with body `{"error":"invalid_credentials"}`, and the same response is returned for non-existent emails (no username enumeration). > > Verification: `test/auth/login.spec.ts` covers both; CI fails on either assertion. Notice how AC2 surfaces a security property the prose buries. ## The "Feed the Spec Back" Pattern Once an AC is written, feed it to the same model that wrote the code and ask for inputs not covered by the test that could violate the AC. Specs turn sycophantic "looks good" review into property-based interrogation. ## Related - [[Spec-Driven Development]] - [[Gherkin Scenario]] - [[Spec-as-Prompt Pattern]] - [[Specification by Example (Adzic)]]