Skip to main content

Acceptance criteria standard

The contract between Definition and the test gate. Every acceptance criterion (AC) must be concrete enough that a test agent generates an executable test from it without interpretation. Ambiguity here becomes defects downstream, at agent speed.

The rules​

  • Given / When / Then, disciplined toward Specification by Example — each AC pins a concrete example, not a general intention.
  • Three examples per rule: a positive case, a negative case, and a boundary case. Insurance is full of boundaries (renewal dates, backdating, currency rounding, policy states) — name them explicitly.
  • Testable, not aspirational. An AC a test can't check isn't an AC.
  • Ambiguity lint. These words are banned in an AC because they can't be tested: appropriate, quickly, fast, robust, user-friendly, etc., and so on, handle gracefully. A PFD-review skill (to follow) flags them; the Definition of Ready gate blocks on them.

Example​

Rule: A mid-term adjustment (MTA) recalculates premium pro-rata from the effective date.

  • Positive — Given a 12-month policy at £365 When an MTA adds £100 annual cover effective on day 100 Then the additional premium is £100 × 265/365 = £72.60.
  • Negative — Given an MTA with an effective date before the policy start When it is submitted Then it is rejected with "effective date precedes cover start".
  • Boundary — Given an MTA effective on the final day of cover When it is submitted Then one day of additional premium is charged.

Why this matters most in RAPID​

In the old world, an ambiguous AC cost a clarification conversation. In RAPID, an agent will confidently build something from it — plausibly wrong. Precision at Definition is what lets the rest of the pipeline run without a human in the loop on every step. This standard is enforced at the Definition of Ready gate and consumed directly by the test strategy.