What does done mean? Acceptance criteria and proof

Make “done” something another reviewer can prove

The previous two lessons established the problem and bounded the change. One gap remains: code can exist, a screenshot can look convincing, or a test suite can be green while nobody has written down what must be true and what evidence would prove it.

In this lesson you build Done Matrix v1. For each important behavior, the matrix connects an observable acceptance criterion, a preselected verification method, positive/negative/boundary examples, and the evidence state that permits—or prevents—a Done decision.

This lesson neither selects nor evaluates a technical path. If AI or a developer later proposes a path involving files, components, APIs, data structures, or architecture, FND-001-P04 evaluates that proposed technical path before code. Here the contract is narrower: define what must be demonstrated, before implementation can move the goalposts.

Approximate active time: 45 minutes.

This lesson is for you if: you can explain the scope of a change, but “done” still means something like “works correctly,” “tests pass,” or “looks right,” leaving two reviewers able to reach different pass/fail conclusions.

This lesson is not for: translating criteria into a particular test-framework syntax, treating one screenshot or one test as complete evidence, defining an organization-wide Definition of Done, or evaluating an implementation plan.

Hard prerequisite — FND-001-P02: you must be able to reconstruct a bounded Scope Box v1 with scope, constraints, non-goals, and dependency boundaries kept distinct.

Short FND-001-P02 prerequisite probe

Case: a task list needs a switch between “all tasks” and “unfinished only.” The existing storage structure must not change. A full visual redesign and persistence of the filter choice are out of scope. The filter relies on the existing task status; changing the shared status contract is not owned by this change.

Write four lines: in-scope behavior, constraint, non-goal, dependency boundary. Do not write acceptance criteria or tests yet.

PASS requires 4/4: behavioral scope rather than a file list; an inspectable constraint; a non-goal with operational effect; and a dependency need that does not silently become dependency ownership.

If one item fails, repair only that part of the Scope Box in FND-001-P02 and repeat the probe. A precise Done Matrix built on an ambiguous scope only gives ambiguity a cleaner layout.

Choose the amount of support you need

Every route ends at the same Done Matrix v1 and the same evidence bar. Only the scaffolding changes.

Four-concept route probe

Answer each question briefly without reading ahead:

1. Acceptance criterion: why is “write a test for the filter” not an acceptance criterion?
2. Verification method: why does “completed tasks must not appear” still leave the proof method unspecified?
3. Positive / negative / boundary examples: why is one happy-path example insufficient to expose the rule?
4. Evidence-backed done: if the screenshot looks correct but a relevant test fails, can the change be called Done? Why?

A response passes only when it separates the concept from the thing it is commonly confused with. 4/4 → experienced/Fast Path; 2–3/4 → repair only failed concepts; 0–1/4 → foundation route.

• Foundation: work through the shared task-list case with the full matrix scaffold.
• Repair: revisit only the fragile distinction and rebuild that part of the artifact.
• Experienced / Fast Path: jump to the independent case and construct the matrix without step-by-step prompts.

Fast does not mean lower evidence. It means less guidance.

Mental model: trace a required behavior all the way to evidence

A Done Matrix is a traceability artifact, not a list of tests. Each row follows one behavior or rule from the required outcome to the evidence used to judge it:

The goal is not to make every requirement executable at this stage. The goal is to freeze a judgeable target and its evidence path before implementation results tempt the team to redefine success.

The four foundation concepts

1. Acceptance criterion

An acceptance criterion is an observable, judgeable condition that tells a reviewer whether a required behavior is acceptable.

Weak: “The filter works correctly.” Stronger: “When the unfinished view is active, no completed task is displayed.”

The criterion is the behavioral contract. A test case may verify it; the test case is not the criterion.

2. Verification method

The verification method is the predeclared way evidence will be gathered for a criterion or relevant constraint: a targeted automated test, smoke test, UI observation, diff inspection, or artifact inspection, for example.

For “no completed task appears,” the proof method might use a controlled dataset containing both completed and unfinished tasks and inspect the unfinished-view result.

The criterion says what must be true. The method says how we will obtain evidence about it.

3. Positive, negative, and boundary examples

Examples make the rule concrete from several directions:

• positive: behavior that should occur;
• negative: behavior that must not occur;
• boundary: an edge, empty state, or transition where the rule is easy to misunderstand.

These examples do not have to start as Gherkin or code. Their first job is to expose the rule clearly; they may later become executable tests.

4. Evidence-backed done

A change is Done only when the relevant acceptance criteria and constraints have sufficient evidence. If a critical criterion is unverified or its evidence fails, the Done decision is blocked.

This is deliberately narrower than an organization-wide Definition of Done. We are deciding whether this bounded change has been proved, not defining team policy for every piece of work.

Build Done Matrix v1 from the Scope Box

Start with Scope Box v1. Bring in only the behaviors and constraints that belong to this change. Then create one matrix row for each important behavior or rule.

Suggested fields:

Use four construction rules:

1. Observable first. State the result at a judgeable boundary rather than guessing implementation details.
2. Choose proof before code. Preselect the evidence method so the target is not rewritten after seeing the implementation.
3. Cover the rule, not only the happy path. Include occurrence, non-occurrence, and a meaningful boundary.
4. Treat Done as a conclusion. A critical evidence gap or failure keeps the overall change out of Done.

Where AI can help—and where it stops

AI can point out vague criteria, generate candidate counterexamples, compare possible proof methods, or audit a matrix for missing boundaries. It cannot manufacture acceptance authority, mark unexecuted evidence as PASS, or explain away a relevant failure. The final Done decision remains a traceable human judgment.

Worked case: proving the unfinished-task filter

The prior Scope Box already says: the user can switch between all tasks and unfinished only; storage structure does not change; filter persistence and full-page redesign are outside the change.

A compact Done Matrix could look like this:

Notice what is absent: no component choice, state-management prescription, file list, or architecture decision. P03 does not make those choices; if a concrete technical path is proposed, P04 evaluates that proposed path before code.

After implementation, Evidence/Result is filled with actual evidence. A good-looking screenshot cannot cancel a relevant failing test; the critical row remains failed and the change is not Done.

Four plausible failure modes

Failure 1: the criterion is a slogan

“Filter works correctly” gives independent reviewers no stable pass/fail boundary. Repair it with a condition and an observable result.

Failure 2: criterion and proof collapse into “tests pass”

“Tests pass” is meaningless unless the relevant test or inspection is tied to a specific criterion. Repair the traceability: criterion first, proof method second, evidence item third.

Failure 3: the matrix contains only a happy path

A normal case may miss non-occurrence, empty-state, or transition behavior. Add a negative and a meaningful boundary example.

Failure 4: attractive evidence hides contradictory evidence

A screenshot can look right while a relevant test fails. Preserve the contradiction. A critical FAIL or evidence gap blocks Done.

Experienced bridge: contradictory evidence and moving goalposts

Real repositories often present mixed signals: a PR says “all green,” a screenshot looks fine, but the relevant test was skipped; or an edge case fails after the main path succeeds. Another failure is subtler: someone edits the acceptance criterion after implementation so the existing behavior suddenly qualifies as success.

The experienced move is to freeze the criterion and proof method before the result, preserve contradictory evidence, and keep the status BLOCKED or NOT_RUN when proof is incomplete. If satisfying the criterion appears to require a different technical path, keep that need separate from the Done contract; any proposed path must be evaluated in P04 before code. Do not rewrite the Done contract to rescue the plan.

Different ways to express a criterion

Done Matrix v1 is notation-neutral:

• Condition → observable result is compact and tool-independent, but careless wording can remain ambiguous.
• Scenario examples make context and outcome concrete. Current Gherkin documentation uses structures such as Given/When/Then to express context, event, and expected outcome; that is one optional notation, not a requirement of this lesson.
• Direct test cases are useful proof artifacts, but if the behavioral contract exists only inside test code, reviewers can lose the higher-level reason for the test.

The useful separation is stable: criteria remain understandable without the tool, while verification methods can later bind to the team’s chosen test or inspection mechanism.

Do not confuse this per-change matrix with an organization-wide Definition of Done. Team-wide review or documentation rules may exist separately; this lesson is limited to evidence for the current bounded change.

Guided and independent practice

Guided case

Order search Scope Box:

• In scope: search uses the full order number only.
• Observable behavior supplied by this case: (1) an existing full order number makes its corresponding order observable; (2) a non-existent full-format number does not return a different order as a match; (3) a partial number is not a successful match and does not activate fuzzy/partial matching.
• Constraint: the order schema does not change.
• Out of scope: customer-name search, page redesign, and fuzzy search.
• Dependency: order number already exists in accessible order data.

Build Done Matrix v1 with three criteria, one for each supplied observable behavior. For each, define a proof method and positive/negative/boundary examples. Link at least one relevant constraint to inspection evidence. Do not propose an implementation plan.

Independent case — Fast Path destination

Assignment upload case — use only this authority packet:

• Problem: some learners upload the same file again because they cannot tell whether the first upload succeeded.
• Approved in-scope behavior: after an existing upload attempt receives a terminal success or failure signal, that state becomes observable for that same attempt. A later attempt must not inherit the visible terminal state of an earlier attempt.
• Constraint: the current storage provider does not change.
• Out of scope: automatic retry, refactoring the entire upload subsystem, notification redesign.
• Dependency: the existing upload service can return terminal success or failure, but it may remain processing before a terminal signal arrives.
• Conflicting current notes: one stakeholder note says, “if no terminal signal is visible after 10 seconds, show failure”; the service-owner note says, “slow processing is not failure; do not label failure without a terminal failure signal.” Neither note is marked as superseding the other.
• Explicit unknown: this task has no approved rule for what the UI should claim after 10 seconds while the service still reports processing.

Build Done Matrix v1 without inventing which note wins. Write at least three acceptance-criterion rows from the approved behaviors above, with proof methods, positive/negative/boundary examples, and initial evidence states. Add one separate unresolved row for the 10-second processing conflict and keep it BLOCKED with evidence NOT_RUN until authority resolves the rule. Do not silently turn the unknown into an acceptance criterion. End with one sentence stating which technical decision P03 does not make and what FND-001-P04 does with a proposed technical path.

Verification: when is the matrix strong enough?

Check four critical dimensions:

1. Concept closure: criterion, proof method, example coverage, and evidence-backed done are present and not conflated.
2. Artifact traceability: each criterion traces to the Scope Box, and each proof/evidence item traces to its criterion.
3. Neighbor boundary: the matrix decides what must be proved, not how to implement it; P04 has not been absorbed.
4. Human evidence discipline: gaps, failures, and contradictions stay visible; AI or tool output is not sufficient acceptance authority by itself.

Sufficient evidence for this lesson is an independent Done Matrix v1, one defended pass/fail decision, and an explicit P04 boundary. Machine checks can validate consistency, but human review remains necessary.

Assessment and transfer

Assessment covers five moves: explain a bounded distinction, build a matrix for a fresh case, diagnose a flawed artifact, make a human decision under ambiguous or conflicting evidence, and transfer the artifact into a new domain.

Blocking answers need self-contained, judgeable evidence: clear criteria, relevant proof methods, example coverage, evidence state, and the P04 boundary. “Tests pass” or “looks right” is not enough.

Transfer preserves the invariants without copying the task-list surface wording.

References and freshness

The core definitions in this lesson come from the course’s bounded lesson specification. No external standard or testing tool defines the MAKNOW Done Matrix v1 format.

For requirements-engineering context, ISO/IEC/IEEE 29148 status was rechecked on 2026-09-05. The 2018 Edition 2 remains the published International Standard and is at stage 90.92 — to be revised. Edition 3 is still a Draft International Standard under development, so it has not yet replaced the 2018 publication as the normative edition.

Official Cucumber/Gherkin documentation was also rechecked on the same date. It describes Gherkin scenarios as executable specifications and uses Given/When/Then-style steps for context, event, and expected outcome. This lesson treats that as an optional notation, never as a required framework or as the definition of an acceptance criterion.

Any future claim about a current standard or live tool must be rebound to a current primary source before publication, or narrowed/removed.