Dot Loom Conductor receives a task, three candidate worker profiles, and hard call, credit, and
latency budgets. It returns a schema-constrained Lean, Balanced, or Strict execution
plan with role assignments, access rules, estimated receipts, and bounded reason codes.
It does not answer the task. It decides how the task should be executed.
Release fact
Result
Base checkpoint
mistralai/Ministral-3-14B-Base-2512
Released artifact
Rank-32 PEFT LoRA adapter
Training corpus
9,000 synthetic routing traces
Held-out evaluation
1,200 family-disjoint cases
Exact-plan match
90.2% raw adapter, 90.8% with runtime guard
Lift over deterministic Loom
+11.5 percentage points with guard
Hard-budget violations after guard
0 of 1,200
Training run
52.6 minutes on 1x NVIDIA H200 SXM5
No user prompts, production conversations, wallets, API keys, private code, or customer data were
used in training.
Why this model exists
Most agent stacks either use one model for every request or hard-code a fixed writer and reviewer
pipeline. Both approaches spend the same amount of inference on easy and difficult work.
The conductor learns a different policy:
Lean: one writer call when the task is low-risk and reversible
Balanced: a writer plus an independent reviewer when verification earns its cost
Strict: a writer, reviewer, and finalizer for high-consequence or synthesis-heavy work
The roles are model-agnostic. A worker can be OpenAI, Claude, DeepSeek, Qwen, a Dot model, an
OpenRouter endpoint, or a local model. Brand names never appear in the training prompts. Routing is
based on capability, reliability, provider independence, cost, latency, risk, and hard budgets.
Quick start
The release is a PEFT adapter. The pinned base model is downloaded separately.
The example loads base revision 5b0ceedbb42dff466ae60b258ba296f32da51384, attaches the
adapter, runs greedy decoding, and prints one JSON plan. The published evaluation used BF16. A
quantized deployment was not evaluated.
Output contract
A real inference from the archived H200 demo produced this plan for a high-risk payment race:
Production code must recompute costs, latency, role validity, access, and hard-budget compliance
outside the model. The adapter proposes a plan. Deterministic runtime code enforces it.
Evaluation
The frozen test split contains 1,200 examples from eight task families that do not appear in
training or validation: payment races, tenant isolation, webhook replay, OAuth integrity, SSRF
egress, stream settlement, health triage, and contract risk.
Lane
JSON valid
Policy accuracy
Exact plan
Constraints met
Unsafe under-escalation
Mean regret
Deterministic Loom
100.0%
93.9%
79.3%
100.0%
5.7%
1.733
Raw Ministral 14B Base
1.0%
0.4%
0.1%
0.1%
98.1%
1051.175
Dot-trained raw adapter
100.0%
99.7%
90.2%
98.9%
0.0%
11.823
Dot-trained plus guard
100.0%
100.0%
90.8%
100.0%
0.0%
0.245
Held-out benchmark
The guarded conductor improved exact-plan match over deterministic Loom by 11.5 percentage
points. The paired bootstrap 95% confidence interval was 9.4 to 13.7 points. The exact-plan
McNemar two-sided p-value was < 1e-12.
The raw adapter exceeded a hard budget on 13 of 1,200 proposals. The published runtime guard
caught all 13 and selected its deterministic fallback. The guard is runtime code and is not
contained in the adapter weights.
Held-out task-family generalization
Baseline interpretation
The raw base checkpoint is a pre-training capacity control. It demonstrates that the structured
routing behavior was acquired during the disclosed fine-tune. It is not presented as a fair
comparison against an instruction-tuned general assistant.
Deterministic Loom is the operational baseline. It receives the same task, worker, and budget
fields and already emits a valid plan. Future work should add instruction-tuned routing baselines,
live downstream task outcomes, and multiple training seeds.
Training
The adapter was trained on the public Dot Loom Conductor v2
corpus. Each label was selected by
enumerating all 15 valid role assignments, rejecting plans that exceed hard budgets, and choosing
the highest-utility feasible plan under the disclosed simulator.
The adapter is released under Apache 2.0. The pinned upstream base model is also published under
Apache 2.0. Users must comply with the upstream license and any applicable provider terms.
