← Back to field notes
Routing2026-07-105 min read

Model routing that explains itself

Why capability, cost, latency, reliability, and organization preference belong in one visible decision.

A routing decision selecting a teal model path among glass model nodes
route / score / select

A model router should not feel like a slot machine. When a request goes to a different model, the developer and platform owner should be able to answer why. Policate makes the decision inspectable by keeping the scoring axes and candidate set visible.

Five axes, one decision

The router evaluates capability, cost, latency, reliability, and organization preference. Policies filter the candidate set first; routing then ranks the models that remain. A deep architectural review can favor capability while a bulk refactor can shift weight toward cost and latency.

That makes routing a product decision the company can tune, rather than a hidden heuristic that only appears in a bill at the end of the month.

Fallbacks are part of the contract

A good route is more than a winner. It includes an explainable fallback chain, region constraints, provider health, and an explicit reason a candidate was rejected. The same data powers the Gateway trace and the Direct runtime bundle, where the binary performs the local choice.