Starting conditions
Starting conditions are the circumstances a user shows up with that a path is built around: what they already have, what they already know, where they're already positioned. They're a commitment about who the path is for at its entry, whether or not the team has stated it out loud.
Definition
The specific circumstances of the user's starting state — what they have, what they know, what they're positioned with — as the path commits to accepting them at entry.
What the conditions cover
Three classes of circumstance: what the user has (assets, accounts, content, data, money, time available), what the user knows (information, skills, mental models, awareness of options), and what the user is positioned with (relationships, role, environment, prior context). At the moment a user enters a path, these specific facts constitute the texture of the starting state — not the state's name, but its actual substance.
Two users can share the same intent and arrive in nominally the same state but with different starting conditions. A team signing up for a project tracker because they want shared visibility into work-in-progress can arrive with an existing tracker they're migrating from, or with no tracker at all. Same intent, different conditions, different work required from the path.
What the path commits to
Starting conditions function as a commitment made by the team designing the path. The team decides which conditions the path will assume are present at entry — which cluster of starting circumstances the path will treat as valid input. Users who arrive with those conditions form the cohort the path actually serves; users in different conditions fall outside the path's scope, whether or not anything in marketing or signup filtered them out.
This commitment pairs with completion criteria at the other end. Together they fix the endpoints of the critical route — the causal map of what any route bridging entry and completion must satisfy. Without committed starting conditions, the critical route can't be constructed: the question "what causes the first completion criterion?" terminates somewhere, and where it terminates is what the path is treating as given.
Inclusivity vs. coverage
Widening the entry surface — dropping requirements on starting conditions — widens the served cohort but obligates the path to cover more causal territory. Narrowing the entry surface serves a tighter cohort with shorter critical routes. The trade isn't inclusivity against reliability; a wider entry doesn't break the route, but it forces the path to handle the additional territory the wider cohort arrives in.
The failure mode is widening entry without extending the path: users enter at conditions the path's first steps don't actually accept. From the user's perspective they were invited in; from the path's perspective they're in a state the design didn't plan for. The pull-the-ripcord audit diagnoses this at runtime by checking the conditions users arrive with against the conditions step N of the path demands.
Example
A payment-acceptance product commits to a stated entry of "you have a website where you sell things." Two signup cohort members arrive with that intent. The first has a Shopify storefront doing a few hundred dollars in monthly orders; the second has a Rails app they built themselves and a checkout page in progress. Both passed the stated entry filter — they have websites where they sell things. But their starting conditions diverge sharply on what they have (an existing storefront with payment plumbing vs. raw application code), what they know (Shopify admin vs. backend integration), and what they're positioned with (a platform that auto-installs payment integrations vs. a codebase requiring manual work). The route from entry to first paid conversion either commits to one set of conditions and acquires only those users, or covers both — in which case the critical route forks early and the design has to absorb the fork.