Concepts · 1 of 6
One run, five steps
For each step, the frontier's admissible actions become a catalogue, one action is chosen, its arguments are generated, and only then does the Commission runtime recheck it and hand it to an effect port. The first three steps are Loom's. The last two are the runtime's.
- LoomProject the catalogue
The frontier's admissible actions become what the model may see.
- LoomSelect one action
From those candidates only.
- LoomGenerate its arguments
For the selected action only.
- CommissionRevalidate
Frontier, case revision and authority, now.
- CommissionInvoke the effect
Through the effect port the embedder supplies.
Shipped · runs today
- ShippedCatalogue projectionOne entry per distinct frontier action, its status decided by Commission admission.
- ShippedSelection inside the catalogueA selection outside the catalogue is refused, whatever its confidence.
- ShippedArguments for the selected action onlyThe generator sees one catalogue entry.
- ShippedRevalidation by the Commission runtimeAgainst the current frontier, case revision and authority provider.
- ShippedEffects through an effect portThe slice performs software.change/1 actions in a git work tree.
Planned · roadmap only
- PlannedArguments checked against the action schemaWhere an action schema comes from is not decided yet.
- PlannedConnector and Substrate effect bindingsNot decided.
A run repeats these steps until it is blocked: by an approval gate, by nothing admissible, by its
step budget, or by an action no effect port performs. run_until_blocked in
b10x-loom-commission is that loop. A step whose action needed authority, which the authority
provider granted and the effect port performed, passes the approval gate: the run goes on. So
does one the effect port refused without ending the run: the executor is told why and may correct
the request within the step budget.
1. Project the catalogue — Loom
The frontier's admissible actions are projected into the catalogue the model can see. Nothing consequential is offered because it was registered at startup; what the model sees comes from the current frontier, which the governor computes with Canon for the case's current revision.
2. Select one action — Loom
A selector picks one action from that catalogue. It can be a model (the slice's ModelSelector, one
forced tool call), a deterministic rule, or, later, a fast typed selector. It chooses only from the
candidates it was given; Loom refuses any other. See action selection.
3. Generate arguments for that action only — Loom
The argument generator is handed the selected catalogue entry and nothing else. Loom records the
request for arguments against the selection it serves, then returns the action as a
ProposedAction.
Since 0.3.0, the local slice can resolve stored-result references while generating those arguments. Only the expanded ordinary arguments reach the proposal and subsequent admission; a reference never grants permission.
4. Revalidate — Commission runtime
Time passes between selection and effect: the case may have moved, and authority may have changed. The runtime turns the proposal into an action request bound to the frontier's revision and revalidates it against the current frontier, case revision and authority provider. An action that needs approval the provider does not give stops the run.
5. Invoke the effect — Commission runtime
The runtime hands the admitted request to the EffectPort once and records what happened as an
observation, never as evidence. The case moves to a new revision only after an effect the port
reports as Performed. A port whose work has not finished, such as a CI job, answers Pending:
the runtime hands it the same request again at the next step, revalidated first, until it answers
otherwise or a budget ends the run Waiting. Loom does not make this call; see where Loom ends.