Completion criteria
Completion criteria are the things that have to be true about a result for it to count as officially complete. For grilling a steak, that could include the steak being present, cooked through, at the right doneness, and seasoned; plate color and time of day don't make the cut.
Definition
The IF-conditions of a transition's resulting state — the characteristics that must hold for the transition to count as complete.
Conditions of the resulting state
Every transition has a name that compresses what its resulting state contains. Completion criteria specify those contents: the particular characteristics whose satisfaction makes the resulting state hold. For "I have grilled steak I can eat now," completion criteria include the steak being present, cooked through, at a chosen doneness, and seasoned. Incidental characteristics — plate color, time of day, room temperature — co-occur with valid instances but don't bear on whether the transition counts as complete.
Completion criteria are the Essential characteristics of condition tiering, made operational. The Expected and Related tiers describe characteristics that are typical or correlated rather than definitional; they inform auxiliary routes and broader affordance-landscape thinking, but the critical route is sized to the Essential set only.
A chosen boundary
Any surface name ("pancakes available to eat," "first invoice sent," "at the airport") admits infinitely many specifications. The analyst chooses which characteristics belong inside the boundary and which stay outside; completion criteria are that choice in operational form.
The chosen boundary determines what comes after. The critical route gets constructed by tracing causes back from each completion criterion to the user's starting conditions; a different boundary produces a different route. The fidelity check asks whether the chosen name accurately compresses what's inside the boundary. The boundary itself is an analyst selection, not a discovered fact about the user's intent that the analyst is recovering.
Route-independent within a specification
Once the criteria are committed, they hold regardless of how the user got there. "I have grilled steak" has the same completion criteria whether the steak was pan-seared, charcoal-grilled, or sous-vide-then-torched. This is what enables route plurality at coarse-grain inclusion criteria — multiple routes can satisfy the same completion criteria, which is why the provider shapes the affordance landscape rather than dictating the route.
Surfacing the criteria
Two operations surface what the completion criteria are, working from opposite directions:
-
Remove-and-test filters existing candidates. Take a proposed characteristic, mentally remove it from the resulting state, and ask whether the user would still say the transition completed. If yes, it's incidental. If removing it would make the user say "no, that's not what I was trying to accomplish," it's a completion criterion.
-
The Rosie-the-Robot test generates candidates when none exist yet. Imagine a competent agent producing the outcome and presenting the result; list the conditions under which you'd reject what they produced. The rejection conditions converge on the completion-criteria set.
Both operations point at the same underlying commitment from different sides. Remove-and-test reads the cluster boundary the analyst is already operating against; Rosie generates the boundary when no candidates exist yet to filter.
Example
For the value milestone "first invoice sent through the tool" in an invoicing SaaS, completion criteria might include:
- The invoice contains accurate client billing information
- Line items and totals are correct and consistent
- The invoice is delivered through a channel the client will actually see
- The invoice is attributed to the user's business identity (name, branding, payment details)
A plate-color analog at this scale would be "the invoice was sent on a weekday" — co-occurring frequently with valid sends, but absent without breaking the transition. A user wouldn't reject a weekend-sent invoice as "not really sent."
If the team commits to "delivered through a channel the client will actually see," a route that emails to an address the user never validated fails the criterion even if the email technically sent. The criterion governs what the route has to produce, not what the offering technically does.