Trust and verify

Acceptance criteria are not a record of what was built. They are the conditions, fixed ahead of the work, under which the work counts as done. Trust and verification are joined by and. Joined by but, the check reads as suspicion; joined by and, the check is the thing that makes trust possible.

The builder writes the criteria. Criteria written by the model are a violation.

A contract states what a piece promises; acceptance criteria state how the promise is confirmed kept. The contract is a property of the system, and it is the concern of Write contracts. The criteria are a property of the task.

Correctness and shippability are separate lines. Correctness is whether the change satisfies the criteria. Shippability is the ship checklist for the change, with tests written and green and the checks already in place still passing. Different parties check the two lines, at different moments.

The change is scored against the criteria by something that did not write it. The gate returns a verdict the builder acts on, and findings that do not block that verdict. Findings go onto a list read on a cadence. A finding that recurs indicts whatever keeps producing it, rather than the change it appeared in.

A green gate verifies the change. Only the builder's own look at the running result verifies the outcome.

Criteria authored by anything other than the builder are a violation. A verdict accepted in place of looking at the running result is a violation. Each substitutes a claim of done for a confirmation of done.

Inspection

Walk me through the acceptance criteria on the last few things we shipped: which are ticked, and who ticked each one against who wrote it.

Held this, or broke it? Say which principle and what happened — tell me at /contact, subject Principles. What moves a band is somebody else's experience, and I'll publish what moved and who moved it.