Eridian
ROUTING

Routing Policy Is a Control, Not a Preference File

James Okafor · · 11 min read

Routing Policy Is a Control, Not a Preference File

In 2025 we described routing as architecture: cost, latency, quality, fallback. That was true and incomplete. By 2026 the institutions we run for treat the routing file the way they treat a firewall change. We updated the product to match.

A routing policy is versioned, hashed into the signed record, and gated.

What a policy contains now

  • Ordered chain of model IDs that exist in the project's residency map
  • Hop timeout and retry class
  • Budget-aware demotion rules (soft cap behavior)
  • Pin mode: free, prefer, strict
  • Eval scorecard IDs that must be allow or allow_with_gate for each model
  • Change ticket ID when the version was published
{
  "routing_policy": "rp_legal_msa_7",
  "version": 7,
  "pin_mode": "prefer",
  "chain": ["claude-sonnet-5", "gpt-4o"],
  "scorecards": ["eval_legal_msa_term_2026q1"],
  "timeout_ms": 30000
}

prefer means we try Claude first and may fail over. strict means we do not. free is sandbox.

Publishing v8 requires dual control. The diff the approver sees is the chain, the pin mode, and the scorecard IDs, not a JSON blob with forty unrelated keys.

Fallback is an event

Every hop is in the record. "The request succeeded" is not enough when hop 1 was a 503 and hop 2 was a different model. Committees have started asking for fallback counts the way they ask for override counts. We put fallback_triggered on the export in Q4 2025. Use it.

Eval gates on the chain

A model cannot sit in a production chain without a non-expired scorecard for that template. When a scorecard expires, we do not keep routing and hope. New runs fail with eval_scorecard_expired until counsel and engineering refresh and dual-control the pin.

This stopped a quiet provider upgrade in February 2026. The vendor changed a model ID in place. Our ID mapping noticed. The scorecard did not match. Traffic stayed on the previous ID until the card was re-run.

Cost is allowed to lose

Budget-aware demotion can drop a quality-optimized chain to a cheaper model when the project is over soft cap. That demotion is a control event, visible to the project owner. It is not a stealth downgrade. If legal forbids demotion, they set budget_demote: false and accept the hard envelope instead.

Routing is how we stay up. It is also how we stay inside policy. If your chain can change without a second human and a scorecard, it is a preference file. We do not ship those on production desks anymore.

James Okafor

VP of Engineering

James Okafor is Vice President of Engineering at Eridian. He holds the production path of the operating system, from model access to signed record. Routing, evaluation, residency, and the controls that keep institutional workloads inside policy sit under his function. His work is to keep Eridian reliable, reviewable, and fit for regulated use at institutional scale.

Related Posts