Conditions
Conditions are the specific circumstances inside a state: what the user has, knows, and is positioned with at that moment. If the state is "standing in the rain", then the conditions are whether the user is holding an umbrella, standing next to a puddle, hearing tires splash past. The state names the situation; the conditions fill in what's actually in it.
Definition
The specific material circumstances within a state — what the user has, knows, and is positioned with at that moment.
State vs. its conditions
A state is the state itself; its conditions are the specific circumstances within it. "Standing in the rain" is a state. Holding an umbrella, standing next to a puddle, hearing tires splash — those are conditions of that state. When the framework speaks of a state without qualifier, it means the whole: the state plus its conditions. When precision requires distinguishing the two, the conditions are the granular layer underneath the name.
Conditions cover what the user has (objects, accounts, tools, prior outputs), what they know (information, context, recognition of what's available), and what they're positioned with (relationships, permissions, things their now-circumstance puts within reach). Motivation is not a condition — it lives on the user side per the intent decomposition, not as a structural property the framework reads from a state.
Three specializations
The general primitive specializes by where it sits relative to a transition:
- Starting conditions: the starting state's conditions, specifically as the path commits to accepting them.
- Completion criteria: the resulting state's conditions in IF-form — what must hold for the transition to count as complete.
- Sub-conditions: the intermediate conditions a transition requires between its endpoints, when the gap can't close in one move.
Each carries the operational commitment-shape its position requires. Starting conditions and completion criteria are analyst commitments about path boundaries; sub-conditions are the intermediate-state primitive that critical-route construction operates on.
Same sought state, different conditions
Two users can share an intent and still arrive with different conditions — same sought state, different material on hand. The route from each user's conditions to the completion criteria differs accordingly. State names alone collapse this difference; conditions preserve it.
Example
A user shows up at a no-code site builder wanting "a live site for my consulting business." Same sought state, three different starting conditions:
- Has copy already written in a Google Doc, a logo file, no domain purchased yet.
- Has a domain registered from a previous attempt, and nothing else.
- Has nothing on hand — just an idea and a credit card.
Three users, same intent, three different starting positions. The route from each set of conditions to "live site" differs: the first user benefits from a flow that drops existing copy into a template; the second needs domain-attachment surfaced early; the third needs template-selection to come before any content step. An onboarding designed for "the user wanting a live site" without reading conditions delivers the wrong route to two of the three.