Resulting state
A resulting state is the endpoint of a transition: the state of affairs that holds once the transition is complete. It's defined by a particular set of conditions that have to be true for the transition to count as done, like "pancakes available to eat," "kid can ride a bike," or "invoice sent." Resulting state is a property of the transition itself, not of the user; the transition has the same resulting state whether or not it happens to match what any particular user was after.
Definition
The endpoint of a named transition — the state at which a transition counts as complete, as defined by its completion criteria.
The endpoint of a transition
Every transition has two endpoints. The starting state is where the transition begins; the resulting state is where it ends. A user grilling a steak starts in a state where the steak is raw and ends in a state where it's grilled and edible. The two endpoints together specify the transition's shape.
Defined by completion criteria
Completion criteria specify the resulting state's contents — the IF-conditions that must hold for the transition to count as complete. For "I have grilled steak I can eat now," completion criteria include things like steak being present, cooked through, at a particular doneness, and seasoned. Plate color and ambient lighting are incidental.
Completion criteria are analyst commitments. The analyst picks which characteristics of the resulting state count toward completion and which fall outside the boundary; the same surface name (e.g., "pancakes available to eat") can yield different resulting states depending on which commitment is made. A name alone doesn't specify a resulting state — the completion criteria are what make it operationally usable.
The distinction from sought state
Resulting state is transition-side — a property of a named transition, the terminus the transition is specified to produce. Sought state is user-side — a property of the user, the state their energy is directed toward, present before any particular transition exists.
The two coincide when a transition is named such that its resulting state matches what the user is pursuing. That coincidence is something intent-aligned design has to produce, not a default condition. A transition can have a resulting state no user is pursuing; a user can have a sought state no transition is well-aligned to. Treating the two as identical collapses the distinction the framework relies on for evaluating whether a transition serves the user.
Example
A freelancer signs up for invoicing software. One named transition is "invoice sent to client." Its resulting state holds when an invoice exists in the system addressed to the client, contains the freelancer's services and amount, and has been delivered to the client's email address. The browser the freelancer used and which template they picked are incidental.
That resulting state might match the freelancer's sought state — "get paid for last month's work" — or it might not. "Invoice sent" is the transition's terminus; "get paid" sits further along the freelancer's pursuit.