Concepts · 3 of 6
The fast selector
A fast typed-decision model as one implementation of ActionSelector, gated by confidence. No fast selector exists yet; this page describes the design.
A fast typed-decision model fits the selector role well: given the candidate actions, it returns one of them with a probability. The reasoning model then generates arguments for that action. Where selection is a narrow classification, this can reduce latency and cost.
The fast selector is one implementation of ActionSelector. It is never the governor, the
authority, the argument generator or the executor.
frontier candidates derived upstream; admissible only
↓
compact selection context
↓
fast typed choice action id + probability
↓
confidence gate
├── high → reasoning model generates arguments → schema validation
└── low → reasoning-model selector, or full planner
↓
ProposedAction → Commission rechecks revision, frontier, authority → effect
Confidence policy
An example policy:
| selector probability | example policy |
|---|---|
p ≥ 0.90 | Accept the fast selection. |
0.60 ≤ p < 0.90 | Use the reasoning-model selector instead. |
p < 0.60 | Use the full planner, ask for clarification, or do nothing. |
More columns: swipe horizontally, or focus the table and use the arrow keys.
Exact thresholds must be calibrated per domain and measured by a trial (Atlas ADR 0101). A high probability changes which path picks the action; it never changes what the action is allowed to do.
How a fallback is recorded
When the fast choice is not accepted and the stronger selector answers instead, Loom records both
selections. The fast one is Overruled and names the selection that replaced it; the replacement
alone reaches argument generation and revalidation. Each selection carries the strategy of the
selector that made it, so an evaluation can tell which selector each pick came from. An accepted
fast choice is one selection with no replacement, and a fast choice outside the candidates is never
a selection.
Large catalogues
A large action set can be split into a hierarchical choice: first a tool family, then a specific action. Every level of that hierarchy contains only frontier-admissible actions.
No dependency on one vendor
The selector abstraction is meant to support local inference, hosted inference, other typed decision models and deterministic selectors. Loom must not depend semantically on one selector vendor or model. The repository's integration notes describe the first candidate.