Acceptance Criteria¶
Test or assessment — instantiates Constraint Formulation
Defines pass/fail or accept/reject conditions for a deliverable, case, design, or decision.
Acceptance Criteria are the pre-agreed, checkable pass/fail conditions a specific deliverable must meet at a specific handoff before anyone is allowed to call it accepted. Their whole point is to fix the bar before the work is done, so that acceptance becomes a test against a stated standard rather than a judgment call made under deadline pressure at the gate. Each criterion is binary and observable — a thing you can run the deliverable against and get a yes or a no — and acceptance is the conjunction of all of them: one failure holds the whole deliverable. This is what separates the mechanism from a general quality review; it does not assess who is allowed into the process, only whether a finished thing clears an output bar that was written down in advance.
Example¶
A payments team is about to ship a "split the bill" feature. Before a line of code is written, the product owner and QA lead agree the acceptance criteria: the split must reconcile to the cent for any group of two to ten people; an attempt to split a charge that was already refunded must be rejected with a clear error; currency and rounding must display correctly for the three launch markets; and end-to-end response must stay under a target latency at expected load.
At the release gate, the build is run against each criterion in turn. Reconciliation passes; the refunded-charge guard passes; latency passes; but the currency display fails for one locale's rounding rule. Because every criterion is a hard pass/fail, that single miss is disqualifying — the feature is held, not shipped, until the locale bug is fixed and the criterion re-run. What would otherwise have been an argument about whether the feature "feels done" is instead a short, factual conversation about one failed check.
How it works¶
The mechanism's distinctive moves are three. First, the criteria are set before the work, by the parties who will hand off and receive the deliverable, so the standard cannot drift to meet whatever was actually built. Second, each criterion is phrased as something with an unambiguous oracle — a concrete input and the exact response expected — so two reviewers reach the same verdict. Third, acceptance is a conjunction: the deliverable is accepted only if every criterion passes, which makes the bar a wall rather than a weighted average. Criteria are attached to one deliverable and one moment (release, deployment, approval, handoff), not to a whole program.
Tuning parameters¶
- Strictness of the bar — how demanding each criterion is. Tighter criteria catch more defects but reject more borderline-good work and slow delivery.
- Granularity — a few coarse criteria versus many fine ones. Fine-grained criteria localize failures precisely but multiply maintenance and can miss holistic quality.
- Binding moment — which gate the criteria attach to (code-complete, pre-release, post-deploy). Earlier gates catch problems cheaply; later gates test the real thing.
- Verification method — automated check versus manual sign-off. Automation makes the test repeatable and cheap but only covers what can be scripted.
When it helps, and when it misleads¶
Its strength is that it destroys "looks done" ambiguity: the standard is fixed while incentives are still neutral, so nobody gets to redefine "acceptable" once they are behind schedule. It also makes a rejection factual and contestable rather than personal — you failed criterion four, not "the reviewer didn't like it."
Its failure mode is that a deliverable can pass every criterion and still be bad, because the criteria measure the measurable and quietly stand in for the quality you actually cared about[1] — a Goodhart-style trap where teams optimize the checklist instead of the outcome, producing a green build over a weak feature. The classic misuse is acceptance theater: criteria written loose enough that everything passes, so the gate signals nothing. The guarding discipline is to keep each criterion tethered to user-visible value and to pair the fixed list with some open-ended exploratory checking that can catch what no criterion anticipated.
How it implements the components¶
Acceptance Criteria fill the output-gate slice of the archetype's machinery — the part that tests a finished thing against a fixed bar:
feasibility_test_case— each criterion is a concrete test the deliverable is run against at the gate, with a defined input and expected result.hard_constraint— every criterion is pass/fail and a single failure is disqualifying, so the criteria act as absolute admissibility conditions on the deliverable.feasible_set— the accepted set is defined precisely as the deliverables that satisfy all criteria at once.
It does not set the constraint_scope_boundary that decides which entities are admitted in the first place, nor provide an exception_authority for appeals — governing who is allowed into the space, and who hears their appeal, is the job of Eligibility Rule.
Related¶
- Instantiates: Constraint Formulation — Acceptance Criteria supply the pass/fail output gate the archetype uses to admit or reject a finished deliverable.
- Consumes: Requirements Constraint Specification — the must-satisfy conditions it turns into testable criteria.
- Sibling mechanisms: Budget / Time Limit · Constraint Review Checklist · Design Constraint Document · Eligibility Rule · Legal Compliance Constraint · Optimization Constraint Model · Policy Rule Set · Requirements Constraint Specification · Safety Constraint
Editorial Notes¶
Form Classification¶
Form family: Rule, Policy & Commitment
Rationale: The mechanism defines pass/fail or accept/reject conditions for a deliverable, case, design, or decision, so its operative form is a standing rule, policy, threshold, or commitment.
Independent corroboration: The frozen evidence defines Acceptance Criteria as 'Defines pass/fail or accept/reject conditions for a deliverable, case, design, or decision', so its operative form is Rule, Policy & Commitment.
Nearest alternative: Decision, Gate & Allocation — It sets reusable conditions for future cases rather than making one bounded case-specific disposition.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Pre-agreed, objectively verifiable pass/fail conditions for a deliverable have a strong systems-engineering, verification, and procurement lineage.
Related originating lineages:
- Computer Science & Software Engineering — Agile requirements and software testing made acceptance criteria a standard feature-level practice.
- Law & Governance — Contractual conditions of acceptance contribute the binding handoff and dispute-resistant standard.
- Organizational & Management Science — Project governance contributes the precommitment, ownership, and completion gate.
Review resolution: Objective pre-agreed pass/fail conditions are most formally grounded in systems-engineering verification and acceptance; software, contracting, and project governance developed convergent forms.
Attribution caveat: The modern term is shared by systems engineering, contracting, and agile software practice, with no clean single first home.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
- NASA Software Engineering Handbook: Acceptance Criteria — Defines acceptance criteria as conditions a system, component, or deliverable must satisfy and ties them to verification matrices and acceptance testing.
References¶
[1] Campbell, D. T. Assessing the Impact of Planned Social Change. The Public Affairs Center, Dartmouth College, Occasional Paper Series, Paper 8 (1976). Warns that decision-linked quantitative indicators face corruption pressure and can distort the processes they are intended to monitor. registry ↩