Routing research
A small model plans execution topology
The router sees a bounded candidate set and returns strict JSON describing which nodes run and in what order.From intent to plan
Retrieval and reranking reduce a potentially large graph to ten request-local candidates. The router reasons over those candidates and the current FSM context.
Architecturetext
intent + state + history
→ semantic retrieval
→ candidate reranking
→ router SLM
→ transition validation
→ topology executionBounded output
- Nodes in one inner list can run in parallel.
- Inner lists run in sequence.
- Candidate 9 is reserved for unsupported or out-of-scope fallback.
- The runtime, not the model, decides whether the proposed transitions are legal.
Router responsejson
{
"reasoning": "Identity must be verified first.",
"topology": "sequential",
"execution_plan": [[0], [1]]
}Training direction
The training pipeline fine-tunes Qwen2.5-1.5B with supervised learning and GRPO. Rewards emphasize valid JSON, topology agreement, and execution-plan agreement.
Synthetic scenarios span customer support, fintech, supply chain, marketing CRM, and DevOps. Their constraints teach planning patterns; they are not a runtime axiom engine.
Architecture and training behavior are documented in ARCHITECTURE.md and train/grpo_rewards.py.