Local-first Routing and Model Selection

1. The real problem: local-first is a preference, not a shortcut

A workflow may have several execution paths at once: a workstation model, a local/cluster serving endpoint, and one or more remote providers. If the router looks only at locality, price, or latency, it can select a model that is not qualified for the requested task/locale/risk slice. In this lesson, local-first is allowed to matter only after hard gates pass.

2. Keep routing separate from model qualification

AIE-004 determines which exact model/runtime/configuration is qualified for a task/locale/risk slice. AIE-005 consumes that evidence and decides a route. The router may not replace missing qualification with familiarity, model reputation, a general benchmark, or one successful call.

3. Freeze the request contract before evaluating candidates

Every decision begins with a request slice: task, locale, risk, mandatory capabilities, latency SLO, placement/privacy constraints, and data-egress state. If that contract is ambiguous, candidate ranking only looks rigorous; an auditor cannot tell why a route was allowed.

4. Qualification binding must match the exact candidate version

QUALIFIED is insufficient without the relevant model version, runtime/configuration, and slice. If a decisive model/runtime version changes without a matching qualification record, the binding becomes STALE or MISSING. Local-first never grants implicit reuse of an old qualification.

5. Capability is an independent hard gate

A candidate can be quality-qualified yet lack a mandatory capability such as structured output. That candidate is INELIGIBLE; the router must not drop the field, rewrite the prompt, or weaken the application contract merely to keep execution local.

6. Placement and egress remain hard gates after qualification

A remote candidate may have the best quality and latency, but it is not allowed when egress_allowed=false. Conversely, locality is not itself a privacy proof; it only identifies execution placement, which still must be evaluated against policy and deployment evidence.

7. Keep availability and latency evidence separate from folklore

Qualification does not mean availability. A qualified local candidate that is unavailable or whose measured latency violates the request SLO is not eligible for that request. Record the evidence rather than assuming local routes are normally fast.

8. Consume cost signals without owning budget enforcement

AIE-005 may retain a versioned cost signal and use it for bounded preference or ordering, but quota enforcement, retry amplification, and circuit state belong to AIE-008. Routing must not reinterpret or bypass those controls.

9. Decision order: hard gates → eligible set → local preference

The auditable order is qualification binding → capability → placement/egress → availability/latency → eligible candidate set. Only then may local-first preference and route priority run. A high score cannot re-admit a candidate that failed a hard gate.

10. Worked example: why remote-alpha wins

In the baseline fixture, local-ollama-q4 has no Persian qualification; local-vllm-fp16 is qualified for Persian but unavailable; remote-alpha is qualified for the requested Persian/risk slice, egress is allowed, and the route is available. The bounded result is ROUTE to remote, not breaking qualification to preserve locality.

11. Negative case: local structured output is missing

If local-vllm-fp16 is available and qualified but lacks mandatory structured output, the local route fails. If the remote route passes all gates, select remote; if egress is also blocked, return REJECT rather than silently degrading the contract.

12. Stale binding: a new model version needs new qualification evidence

Suppose the local model version changes while the qualification record remains bound to the previous version. Even if the endpoint is healthy, latency is good, and the model name looks familiar, the current candidate is not qualified. With no eligible alternative, DEFER pending requalification is the bounded decision.

13. Route provenance is part of the output

The output is more than selected_route. Retain policy version, request slice, candidate versions, gate results, rejection reasons, and the final selection rationale. Without provenance, downstream code sees only a route name and cannot audit the evidence that allowed it.

14. Lab: eight deterministic fixtures

The lab covers baseline remote fallback, a qualified/available local route, missing capability, blocked egress, stale qualification, local latency breach, remote unavailability, and a transfer case with a new local candidate that lacks a required capability. The evaluator applies hard gates before preference and emits eight result fields per case.

15. Exit checklist and transfer

Before leaving, verify that the request contract is versioned; qualification matches the exact slice and version; capability and egress are hard gates; unavailable or too-slow routes are ineligible; local preference runs only on the eligible set; and rejection reasons plus policy version are recorded. For transfer, recompute from scratch with egress_allowed=false and a newly qualified local candidate that still lacks structured output; do not copy the earlier route decision.