NeoSyntropyResearch

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 execution

Bounded 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.