Transition scoping
Transition scoping is the work of deciding the scale at which to describe something a user is doing, and committing to what falls inside that description. The same underlying activity can be named at different scales: "sent an invoice," "got paid this month," "kept the business running." Each scale is legitimate, but the scope isn't really chosen until the start, end, and internal pieces at that scale have been spelled out.
Definition
The operation of identifying where a transition sits on a stack and what it consists of: picking its altitude on the stack, specifying its starting and resulting conditions, decomposing it into sub-transitions, sequencing those causally, and locating its relations to parents and siblings.
Altitude-picking opens the operation
Altitude-picking is where the operation starts: which level of the stack are we naming? But altitude can't be committed to seriously without specifying the structure at that altitude — the conditions at the start and result, the sub-transitions below, the causal links between them. Picking an altitude without specifying its structure produces a name with no underlying difference — see hot-air diagnostic. Specifying without committing to an altitude can't begin, because there's no transition to specify. Altitude-picking and structure-specification are aspects of one operation.
Scope fidelity applies at whatever altitude is chosen. The name must compress the difference-structure at that altitude accurately — not at a level above or below.
The same activity has many valid altitudes
A user activity can be named at multiple altitudes, and each is a valid scoping of the same underlying activity. "Sent an invoice to a client for services rendered in September," "sent an invoice," "got paid," "ran a business" — all four name the same underlying activity, scoped at different altitudes. None is more correct than the others as a description of what the user did.
Altitude and time-span are coupled. The "send invoice" / "get paid" pair shows this directly: "get paid" contains "send invoice" as a sub-transition (larger nesting) and extends the timeline rightward to include payment receipt, follow-up, and reconciliation (longer span). Higher altitude and wider time-span describe the same scoping move from two angles.
Scope serves the downstream work
Each altitude is valid in itself, but only one altitude serves a given piece of downstream work. The choice is functional, driven by what the apparatus on the other end needs to do with the named transition.
- Intent theorization: scope needs to be specific enough to ground a usable design brief and general enough to describe a cluster of users. The canonical move is "user wants Uber to a wedding" → "user is attending a formal event."
- Completion-criteria identification: scope needs to match the level at which the route produces a discriminable resulting state.
- Commercial-application scoping: scope needs to match the workflow level at which the four-filter test is being run.
Altitude can be too large or too small
Two failure modes:
- Too large: scope so broad the downstream work can't act on it. Cluster names that don't discriminate user populations, completion criteria that don't discriminate routes, workflow levels at which intervention isn't operationally available.
- Too small: scope so specific it fragments what should cluster. Multiple instances of the same underlying transition named as separate transitions, completion criteria enumerated at implementation detail rather than at the level of the resulting state.
Both produce names that pass scope fidelity at their own altitude — the compression of structure is accurate — but fail to serve the work the name is for.
Example
A team running intent theorization on a rideshare app interviews a user who says "I needed to get to my friend's wedding on Saturday." Scoping the transition at "get to a specific wedding" fragments — every wedding-attendance instance becomes its own transition, and the cluster never forms. Scoping at "go somewhere" is too coarse — it doesn't discriminate the formal-event intent from grocery runs or airport trips, which produce different design briefs.
The altitude that serves the apparatus is "attending a formal event": specific enough to cluster users with shared characteristics (dress code, timing constraints, the social cost of arriving late or sweaty) and general enough to cover weddings, galas, business dinners, and formal interviews as instances of the same scoped transition.