Routing
The permitted route that can do the work
Router is an OpenAI-compatible service that receives a request plus the constraints policy allows, chooses a permitted route, calls it, and returns the answer with a receipt of where the work ran.
Policy decides which routes are allowed. Router decides which of those routes is the right one: sufficient capability, at the lowest expected cost.
What you get
One endpoint, several models
Applications keep a single chat address. Router selects among European, global, open-source and private models that the policy has already allowed.
Security and sovereignty stay hard limits
Region, provider and required capability are eligibility rules. They are not diluted into a score that a cheaper model can win.
Capability before cost
Router looks for the lowest expected-cost route that is permitted and capable enough for the current work. A cheaper model is used when it can succeed, not merely because it is cheaper.
The route can change as the task changes
A request may become easier after a plan, or harder after a failure. Router can assign a different model between steps. It does not switch provider in the middle of a single answer.
PEP can raise the bar, not lower it
When PEP reports that a plan missed the intent, Router can demand a stronger model for the remaining work. That feedback cannot widen what policy permits.
A receipt of the decision
The caller receives the answer and a record of the route. A receipt for a region outside the allowed list is rejected. If Router cannot be reached, PEP can fall back to a configured model.
This page describes Router. It is not available to order.
The other products
- PEP — The boundary in front of the model. Corporate policy is the floor. A person can make that boundary tighter. They cannot make it looser unless the organisation has said so.
- Search — Each subject keeps its own index: the sites, feeds and pages that belong to that subject, refreshed on a schedule and retrieved when a model is allowed to look.