Route plurality
Route plurality is what happens when the same end state can be reached by several genuinely different sequences of steps. Someone who wants pancakes might cook them at home, order delivery, or walk to a diner: three different routes, one shared result. Whether those count as the same route or different ones depends on how loosely the end state is described: at "pancakes available to eat," all three serve; at "homemade pancakes," only the first does.
Definition
At coarse-grain inclusion criteria, multiple distinct routes can satisfy the same resulting state.
Where plurality emerges
Inclusion-criteria granularity gates plurality. The same surface-level resulting state — phrased coarsely — admits multiple causally distinct routes. Tighten the inclusion criteria and the plurality collapses; loosen them and it expands.
There is no plurality between identical endpoint pairs. The critical route between a specific pair of starting and resulting conditions is singular. Apparent plurality between "the same" endpoints reduces to specification — either the starting conditions weren't actually the same across the routes, or the resulting state was specified coarsely enough that routes producing materially different states all count.
In activation work both usually apply: users arrive with different starting conditions, and the team's completion criteria typically live above the granularity that would distinguish those routes.
Each route has its own critical route
Plurality at the coarse-grain resulting state does not weaken the singularity claim at the critical-route level. Each route has its own critical route between its specific starting conditions and the shared coarse-grain resulting state. Three routes producing "user has a working dashboard" — one from API integration, one from CSV upload, one from sample dataset — have three distinct critical routes, each singular for its endpoint pair.
What the routes share is the coarse-grain resulting state. What differs is everything that bridges the start and the end.
Path design becomes strategic
Path design shapes the affordance landscape the user navigates. The route the user actually takes emerges from their selections within that landscape. Users move toward their sought state by continuously recalibrating based on available affordances and their now-state conditions, so different users from the same starting conditions produce different actualized routes — and the same user across attempts can too, as conditions and affordance availability change.
The provider's job is making affordances reachable, recognizable, and integratable at the moments users need them. Failing any of those tests produces routing-around: the user takes a different route, possibly outside the offering.
Example
"User has a working dashboard" admits several routes. A user with API credentials can connect a live data source. A user with exported data can upload a CSV. A user with neither can load a sample dataset. All three produce the same coarse-grain resulting state — a dashboard exists, with data in it, that the user can read.
Each has its own critical route. The integration route depends on auth, endpoint mapping, and schema reconciliation. The CSV route depends on file parsing, column-typing, and field assignment. The sample route depends on dataset selection and a working preview render. None substitutes for another.
At a tighter specification — "user has a dashboard connected to their production data" — only one route serves. The plurality holds at the coarse-grain level and collapses when the inclusion criteria tighten.