Skip to main content

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.

PlannedAtlas ADR 0073 (the rules every selector follows)

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 probabilityexample policy
p ≥ 0.90Accept the fast selection.
0.60 ≤ p < 0.90Use the reasoning-model selector instead.
p < 0.60Use the full planner, ask for clarification, or do nothing.
These thresholds are an example

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.