How it works
From a request to a decision you can check afterwards.
Eight steps run for every request. The first five decide where the work should go, the sixth runs it, and the last two are what make the next decision better than this one.
The path
Classify → eligible routes → resolve route facts → evaluate → select → execute → measure. Measured outcomes feed back into evaluation, so the path is a loop rather than a line. Each step is described below.
The eight steps in detail
Step 01
Classify the workload
The request states what it needs — task type, privacy tier, budget ceiling — and never which provider should serve it. Classification reads the shape of the work: how much context it carries, whether it needs structured output, whether it is one call or five thousand.
Step 02
Determine eligible routes
Hard constraints are applied first. Privacy tier, budget ceiling and capability requirements are pass-or-fail: a route that cannot satisfy one is removed from consideration entirely, before any scoring happens.
A constraint is not a heavily weighted preference. No score is high enough to carry a route past a gate it failed.
Step 03
Resolve endpoint, model, pricing and capabilities
Each surviving provider is resolved to concrete facts: which endpoint would serve the request, which model, which pricing version is in force at this moment, and what that model can actually do. A provider is not a route until those are known.
Pricing is read as the version active at that instant, not a list price — so the cost used to choose is the cost that would be charged.
Step 04
Evaluate candidates
Every eligible route is scored on predicted cost, expected latency, observed reliability and expected quality for this kind of work. The weighting is per workload: cost and speed dominate a high-volume extraction job, answer quality dominates multi-step reasoning.
Reliability carries its uncertainty. A route with four observations and one with four hundred are not treated as equally known.
Step 05
Select the route
The highest-scoring eligible candidate wins, and the decision is pinned: an exact endpoint, an exact model, an exact pricing version. Nothing is re-selected later.
Pinning is what makes the measurement meaningful. If execution could resolve a different endpoint, the prediction and the outcome would describe different routes.
Step 06
Execute
The workload runs on the pinned route. Budget is reserved before execution and settled after it, in exact integer amounts, so a partial failure cannot leave a charge without a corresponding execution.
If the pinned price can no longer be proven at execution time, the attempt is not quietly charged at a different rate.
Step 07
Measure the actual outcome
Actual cost, latency and outcome are recorded against the prediction that chose the route. Predicted and settled sit next to each other, which is the only arrangement in which an estimate can be checked rather than trusted.
Step 08
Feed evidence back into routing intelligence
Observed results update the statistics behind future decisions, held per provider and per task type. A provider that is fast at classification and slow at long-document analysis is recorded as exactly that, rather than averaged into a single number that describes neither.
This is the step that closes the loop — and the reason the diagram above is a cycle rather than a line.
Modes of operation
The same eight steps, with and without authority.
Shadow and authoritative operation run identical logic. The only difference is whether the decision is allowed to control what executes — which is precisely what makes shadow evidence worth anything.
Shadow
Decides, records, changes nothing
- Steps 1 to 5 run in full. A route is chosen and recorded.
- Your existing routing executes the work, unchanged.
- The prediction for the route that ran is compared against what it actually cost and took.
- Disagreements between the two routers are counted, not averaged away.
- A failure inside the engine cannot fail a customer job — it is recorded and the established path proceeds.
Authoritative
Decides, and the decision is what runs
- The selected route executes. There is no second router behind it.
- Every failure is terminal rather than degraded — falling back would mean routing silently stopped obeying the policy in force.
- A pinned price that can no longer be proven fails the attempt instead of charging a different rate.
- Enabled per deployment, and gated on the evidence a shadow period produced.
- Not enabled by default, and not enabled in Waymesh's own deployment today.
The asymmetry is deliberate. Shadow mode degrades quietly because it is an observer and must never affect a customer job; authoritative mode fails closed because it is the only thing deciding, and a silent fallback there would mean the policy an operator believes is in force is not.
The most useful way to check these steps is against your own traffic, in shadow mode, where they change nothing.