Placement, Selection & Routing Vocabulary
Disambiguates placement, selection, steering, and control flow; the six-stage composition law and the one fallback rule that governs every placement decision.
"Routing" is used across this site for at least four different things: which sandbox pool a session lands on, which model a request dispatches to, which live agent a delegated task goes to, and which branch a workflow gate takes. None of those pages used to say which one they meant, or link to the others. This page fixes that: it names the four concepts precisely, and lays out the one composition law that governs every decision about where a new execution context lands or which live peer receives delegated work - "placement" and "selection" in the vocabulary below.
Four things people call "routing"
| If you mean... | The term is | Read |
|---|---|---|
| Which sandbox pool / host a new agent session runs on | Placement | This page, then Capacity profiles |
| Which live agent or peer receives delegated work | Selection | This page, then A2A Routing |
| Which LLM a request dispatches to (model + provider + auth mode) | Model routing | Model catalog & routing |
| Which branch a workflow gate or condition node takes | Control flow | Gate node, Condition node |
| How the platform learns which pool/peer performs best over time | Routing intelligence (ranking) | Routing Intelligence - this is stage 4 of the law below, never a gate |
Model routing and control flow are not governed by the composition law on this page - they have their own resolution order and their own docs, linked above. Placement and selection are.
Vocabulary
- Placement - deciding where a new execution context lands: which pool, which host.
- Selection - deciding which live peer receives delegated work (agent handoff, A2A dispatch). The same law as placement, over a different candidate kind: candidates are live peers instead of pools.
- Steering - session-to-session communication between live sessions. This is a transport with its own durability posture, not a decision - it never runs the composition law.
- Routing - the umbrella noun for the decision plane (placement + selection). A daemon's own local scheduling is "local routing."
- Control flow - the workflow DAG's gates and edges. This is deliberately
a separate word: a gate choosing
approvedvsrejectedis not a decision about where anything runs. - Capacity profile - the org-authored, project-granted object that declares the ordered pool list and policy a placement decision draws candidates from. See Capacity profiles.
- Decision record - the immutable trace of one placement or selection decision: candidates considered, exclusions with the stage and rule that excluded them, the chosen target, and the ruleset revision it was evaluated against. See Decision records & explain.
The six-stage composition law
Every placement and selection decision - hosted or local, successful or not - runs through six stages. Each stage holds exactly one kind of power. The order below is an authority order, not necessarily an evaluation order: it fixes which stage gets credited when a candidate is excluded for more than one reason, not the sequence an implementation must check them in.
| # | Stage | Question | Power | On empty candidate set |
|---|---|---|---|---|
| 0 | Intent | What did the author ask for? | Names refs and a preference posture | Documented default cascade, then a loud error |
| 1 | Permission | May this run there? | Hard gate, fail-closed | Typed denial |
| 2 | Viability | Can this run there? | Hard filter | Typed, loud, per-candidate |
| 3 | Preference | Where would we like it to run? | Orders and narrows only | Typed denial naming the pin |
| 4 | Ranking | Which survivor is best? | Orders only, never gates | Not reachable - ranking cannot empty a set |
| 5 | Bind | Make it so | Intersection, then a narrow-only re-gate at claim | Typed denial plus a receipt |
Two properties matter more than the table itself:
- Power is monotone down the table. Permission and viability may only remove candidates. Preference may remove or reorder. Ranking may only reorder - a ranker that can empty the candidate set is a gate wearing a ranker's clothes, and the decision record has nowhere to put that exclusion, by design.
- An empty set is always loud and typed. When permission intersected with viability leaves nothing, the resolver returns a typed unsatisfiable decision naming every candidate it considered and the stage and rule that excluded each one - never a silent queue, never a silent downgrade.
Permission is evaluated fail-closed: an absent, unreadable, or erroring policy ruling denies by default, it never falls open. Ranking (stage 4) is covered in full on Routing Intelligence - the org-admin governance over live/shadow/disabled modes lives there.
The one fallback rule
Fallback is the next candidate in the ordered surviving set. There is no other fallback.
The set a placement decision falls back through is already permitted and already viable - it survived stages 1 through 3 before ranking ordered it. Falling to the next candidate can never cross a policy boundary, which is what makes automatic fallback safe to run without a human in the loop. There is no separately authored fallback list consulted after the ordered set is exhausted, and no ambient default substituted in from outside it: an exhausted set is a typed failure carrying the full exclusion trace, not an invitation to improvise.
Reaching capacity the profile does not name - burst to managed capacity, for example - re-enters at stage 1 as a permission question (an entitlement grant), never as router improvisation. See Capacity profiles - burst posture for how a profile opts into that explicitly.
Selection is the same law, a different candidate kind
Selecting a live peer for delegated work (agent-to-agent dispatch) runs the identical six stages over a different candidate set: candidates are live peers instead of pools; permission is delegability and scope; viability is skill match, declared capabilities, and liveness; preference is an explicit target pin, which short-circuits exactly as a pool pin does; ranking is whichever ordering policy is enabled. "Place a new session" and "delegate to a live peer" differ only in candidate kind - one law, one decision-record shape, one explain surface. See A2A Routing for the selection-specific mechanics (skill matching, load-aware constraints, Thompson Sampling).
Where this is implemented
The composition law is architecture shared between the open-source donmai
execution layer and the closed Rensei platform: the law and vocabulary on
this page are OSS-canonical, and the concrete resolver, the capacity-profile
schema, and the hosted decision-record store are platform-only. The local
donmai daemon evaluates its own routing decisions against its own inventory
and ships its own explain surface (donmai routing explain); the platform
resolver evaluates the same six stages against org-wide capacity and persists
every decision. Neither depends on the other to function. See
Decision records & explain
for both surfaces side by side, and Capacity profiles
for the object stage 3 reads.
Related pages
- Capacity profiles - the preference object (stage 3): ordered pools, ordering policy, burst posture
- Capacity pools - the substrate a capacity profile orders
- Decision records & explain - reading a placement decision after the fact
- Capacity CLI reference -
capacity profile {list,show,set,grant,test} - Routing Intelligence - stage 4, ranking
- A2A Routing - selection over live peers
- Model catalog & routing - a different "routing": which LLM a request dispatches to
- Gate node - control flow, not placement