Scope
Tenant, application, subject, credentials, tool schema, and policy version can all change whether prior evidence applies to a current request.
// routing guide
Safe AI model routing is a qualification problem.
A routing decision is safe only when the request still satisfies the assumptions behind it. Cost and latency matter, but they come after policy, identity, freshness, output quality, tool risk, and a credible fallback path.
Product-fit boundary
Punk routes eligible supported traffic among live, cache, reusable plan, artifact, or model paths according to configured evidence and policy. It is not a blanket promise to replace a flagship model or automate consequential decisions.
// route inputs
Ask what makes this request eligible now.
Freshness
Time-sensitive data, read results, and external state need a declared freshness policy. Similarity is not a substitute for a valid TTL or fresh read.
Quality
Use task-appropriate checks: exact fields and schemas where possible; calibrated semantic or human review where meaning is the standard.
Action risk
Consequential tools raise the bar. Replay and shadow suppress or dry-run effects; policy may block or require approval regardless of quality.
Runtime health
Recent mismatch, schema drift, provider availability, or artifact failure should lower confidence and may remove a route from consideration.
Fallback
When the route is ineligible or fails, return to the configured live provider where policy allows. Record why the decision changed.
// route hierarchy
Prefer the simplest eligible path.
Block or hold when policy requires it
Policy is not an optimization preference. An action that violates rules, lacks identity, or needs approval should not become cheaper by taking another model route.
Reuse only when safe and fresh
An exact response or declared tool result can be valuable, but its key must retain the authorization and freshness boundaries that made it valid.
Use a proven reusable path
Deterministic artifacts and plan reuse need replay and shadow evidence for the same workload assumptions, plus ongoing mismatch monitoring.
Use a model when judgment remains necessary
Model substitution should be evaluated for the actual task class and output requirement; a lower-cost model is not inherently adequate.
Stay live when uncertainty wins
Live pass-through is a correct outcome for low-confidence, high-risk, fresh, or uncommon work.
// questions for your router
Demand an explanation, not a mystery score.
A good route explanation says
- Which path was selected and which alternatives were considered
- Which policy, evidence, and freshness checks applied
- What tenant, app, and subject scope was used
- What fallback is available if the route cannot serve
A review should also ask
- How a route is evaluated before it becomes live
- What disables it when quality or schemas drift
- Whether side effects were blocked, suppressed, approved, or executed
- Whether savings are measured separately from forecasts
Start by proving one route can earn trust.
Observe a bounded workload first, then review the evidence, policy, and fallback requirements before enabling a different path.