KAN › The method · lesson 7 of 7

Good, bad, test and blue

A check earns its place only if it could fail. KAN's verification is built around that: show the right behaviour, show that a wrong one is caught, and keep the verdict with the person who owns acceptance.

Teaches from kan/rung-delivery.md, “Good, bad, test, blue, and acceptance”, kan/6w-sdmr.md, “Design a falsifying check”, specs/ecd/team/team.md, “Hand off an interface with its consumer's check”, kan/foundations.md, kan/guide/aus/50-specification-by-example.md and kan/guide/aus/80-delivery-and-learning.md.

The rule

• Good: “establish a concrete example of the behavior the consumer needs.”
• Bad: “choose a violating input or failure that distinguishes a correct result from false success.”
• Test: “exercise the changed boundary at the level needed to support the claim.”
• Blue: “address findings, simplify, refactor, and harden when there is a reason.”
• Acceptance: “the named owner judges whether the agreed value is available with sufficient evidence and known limits. A passing build, transport receipt, completed job, or commit alone is insufficient.”

The bad case is the one people skip, and the falsification section says why it matters: “A check that succeeds regardless of the violated property cannot support the claim.” When a check cannot run, it is reported as could-not-measure: never “report an unrun check as passed”.

The squad adds rule A, from the team record: hand off an interface with its consumer's check. The check that judges a piece of work is written by its consumer, not by the builder, and a READY for an interface, contract or gate carries that check's result.

Examples as the specification

The good and bad cases are examples, and KAN takes that from Specification by Example: “Agree good, bad, and boundary cases before they become implementation assumptions.” An example is evidence, not proof: “Examples are selected evidence, not an exhaustive proof of correctness.”

Given/When/Then is a way to write an example down, not the work of finding it. The AUS guide says so directly: “BDD encompasses discovery, formulation, and automation; the Given–When–Then format does not create that work by itself.”

A story's own checks also don't replace the quality bar for the whole increment. The guide takes that distinction from the Scrum Guide's Definition of Done: “the particular criteria of one story do not replace the overall quality bar.”

Try it

In the EchoEdu delivery

The Agile Agent Workflow lane's test was run before its fix. It went red on three of six rows, and each row named the gap: 172 pages where 174 were expected, the course root missing, and the broken links counted by target, 691 to the landing and 290 to /why. After the two pages were restored it went green, six of six.

Then came the bad cases. A mutant that trimmed the navigation inside the course's module made every one of the 174 pages differ. Served through the real route, the same mutant dropped the parity judge to 0 of 174, which proved that the route renders through the course's module and not a default (READY KAN CRS0RWwEilKifI). The judge itself belongs to the Integration seat, not to the lane that was judged: rule A in practice.

The READY carried all of that, and its limits: one suite could not run without a database, and was reported as not run. Acceptance stayed with the gate.

Check yourself

1. Your new test passes on the first run. What do you do before you trust it?
2. Why is a mutant served through the route stronger evidence than the same mutant in a unit test?
3. The build is green and the commit has landed. Is the story accepted?

Previous: Escalate a consequential choice · Up: The method · Next section: The board

Teaches ecd/kan at 2d1b5c8e, 25 October 2026.