Implementation Acceptance Criteria
What are Implementation Acceptance Criteria?
Implementation Acceptance Criteria (IAC) are low-level, technical specifications of exactly what a solution component must do to be considered correctly built. Where a Business Acceptance Criterion defines the business outcome, an IAC specifies the implementation detail — the precise conditions a developer or tester can verify against the built system.
For example, if a Business AC states “Users must receive a clear error message if they enter incorrect credentials”, the IAC might be:
- Given the user submits a login form with an unrecognised email address, when the API responds, then a 401 status is returned with the error code
INVALID_CREDENTIALS - Given the user submits a login form with a correct email but wrong password, when the API responds, then a 401 status is returned and the failed attempt counter is incremented
IACs are referenced using the prefix IAC- — IAC-1, IAC-2, and so on.
Given / When / Then
Like Business Acceptance Criteria, IACs can be recorded as free-text or in Given / When / Then format. Given/When/Then is the preferred format where possible.
Benefits of Given / When / Then Format
- Precision: Forces the author to define the exact pre-conditions, trigger, and expected outcome — removing ambiguity from technical specifications.
- Directly testable: Each IAC maps one-to-one to an automated test case. There is no interpretation step between the specification and the test.
- Reduces back-and-forth: Developers and testers share the same unambiguous specification. Disputes about what “correct” behaviour looks like are resolved before build begins.
- Covers edge cases: Thinking in Given/When/Then naturally surfaces exception paths — the error conditions, boundary values, and concurrent-access scenarios that free-text tends to miss.
- Feeds AI agents directly: A well-formed IAC is a ready-made prompt component for AI code generation tools. See IAC and AI Agents below.
Free-text description is also available — useful where the Given/When/Then structure does not fit naturally (e.g., a non-deterministic outcome, a visual/UX constraint, or a performance envelope).
IAC and Business Acceptance Criteria
ArchRepo has two levels of Acceptance Criteria:
| Business Acceptance Criteria (BAC) | Implementation Acceptance Criteria (IAC) | |
|---|---|---|
| Focus | Business outcomes and user value | Technical correctness and build specification |
| Audience | Business stakeholders, product owners | Developers, testers, solution architects |
| Level | High-level — what must be true | Low-level — exactly how it must behave |
| Prefix | AC- | IAC- |
A single BAC can link to one or more IACs. The IAC specifies the implementation detail that delivers the BAC’s business outcome.
See Business Acceptance Criteria for the higher-level business counterpart.
IAC and Building Blocks
IACs are linked from the solution components they specify. When viewing an Application, Application Pattern, API, or UI Component in ArchRepo, the associated IACs appear in the specification panel — giving each building block its own verifiable technical specification.
This makes it straightforward to answer the question: “How do we know this component is correctly built?” — the answer is in its IACs.
IAC and AI Agents
IACs are highly effective as inputs to AI code generation agents. A Given/When/Then IAC provides the agent with a precise, machine-readable specification — reducing hallucination and improving the quality and correctness of generated code and tests.
A well-structured set of IACs for a component can be pasted directly into an AI agent prompt as the acceptance specification, with the agent tasked to generate the implementation and the tests that verify it.
Fields Reference
See Implementation Acceptance Criteria Fields for a description of each field and guidance on what to record.