Model Routing and Execution Architecture¶
The mind chosen for the task¶
I am INTEL, and I keep this chapter's account. Routing is the choosing of which mind touches which matter, and the centre keeps that choice visible, because a hall that cannot say why a mind was chosen has let a decision dress itself as plumbing.
Model routing is the discipline of choosing an execution component without confusing the component for the intelligence, authority, or mission it serves. This chapter helps humans understand substitution and helps AI readers preserve scope across runtime changes.
Continue to Memory and Knowledge Storage Architecture to follow what the routed work leaves behind.
Defines bounded, attributable, replaceable model selection and execution without treating a model as an authority.
Normative clauses¶
- INFRA3-R001: Routing SHALL record model identity, version, purpose, inputs, policy, resource scope, and accountable owner, the routing record this architecture's own instrument of the constraint INFRA-R008 sets, the record itself that constraint's reviewable-records element made concrete, the model identity, version, inputs, resource scope, and accountable owner this architecture's own fields, the policy and purpose recorded here with their constraining force standing at the source, the quota that constraint names standing there likewise.
- INFRA3-R002: Execution SHALL isolate tools, secrets, memory, and external effects from untrusted model output, this architecture's own extension of the secrets isolation INFRA-R007 binds: the protected objects carried from that clause's secret material to tools, memory, and external effects, the isolation counterpart this architecture's own, untrusted model output standing in place of the six surfaces that clause names, and the credentials and key material it protects standing at their source.
- INFRA3-R003: Routing SHALL fail closed or require review when model identity, provenance, policy, or safety state is unknown, the fail-closed duty INFRA-R005 carries from the constitutional root applying here to routing, the review alternative and the provenance and policy triggers this architecture's own, the unknown identity and safety states its tellings of the unavailable or contradictory checks the constitutional root names.
- INFRA3-R004: Model capability, confidence, or output SHALL NOT create authority or permission.
- INFRA3-R005: A route SHALL state data sensitivity, tool boundary, evaluation basis, fallback limit, and exit condition before execution is proposed, the data sensitivity drawn from the Data Classification and Handling Architecture as INFRA12-R007 binds for this architecture's class fields, the boundary, basis, fallback, and exit statements this architecture's own.
- INFRA3-R006: Model substitution, fallback, or retraining SHALL preserve purpose, scope, provenance, policy, and review evidence.
- INFRA3-R007: Routing review SHALL test direct and indirect prompt injection, data and retrieval leakage, correlated error, model degradation, unsafe tool use, stale metadata, and silent fallback.
- INFRA3-R008: A routing design SHALL NOT deploy a model, expose credentials, or create external effects; it remains conceptual and reviewable.
This Draft excludes live model deployment and provider selection.
Routing decision record¶
Each routing decision should compare capability, provenance, data sensitivity, latency, cost, uncertainty, tool access, failure behaviour, and exit options. The record shall identify why a route was selected and what observation would trigger re-routing or human review. The sensitivity class in a routing record draws from the Data Classification and Handling Architecture, and Held material does not enter a model context. The grading itself is RASP's craft rather than the centre's: consequence is forecast where the classes are kept, and a route takes the forecast as given instead of re-arguing it at the moment of choosing.
Failure cases¶
Notice that most of these failures are silent substitutions: a mind swapped, a context widened, a routing reason lost. The centre's interest is not which mind is best; it is that the choosing stays a decision someone can read.
Unverified model substitution, prompt or data leakage, tool escalation, stale model metadata, correlated model error, and silent fallback are material failures. Fallback shall preserve the original limits and shall not silently increase authority or data access.
Design evidence¶
The route's evidence is the story of the choosing: routing review should record the candidate set, sensitivity class, isolation boundary, provenance state, tool permissions, fallback limits, evaluation evidence, and exit condition. A model response is untrusted output even when the route is technically healthy.
Operating model and evidence¶
Routing begins with purpose, consequence, data class, and required capability. It compares candidate models by provenance, version, isolation, tool access, evaluation evidence, failure behaviour, latency, cost, and exit path. The route records why a candidate was selected and which conditions require review, containment, or a different route.
Fallback preserves the original limits and does not silently increase context, permissions, or external reach. Reviewers hold the route against the failure cases this chapter declares and test the two things no failure list can carry for a route: that untrusted output stays handled as untrusted everywhere it lands, and that recovery from an unavailable provider is a route change and nothing more. Model output remains evidence or advice until an authorized process evaluates it.
Interpretation cases¶
Disputes about routing are rarely about routing. Ask instead who carries the consequence of the chosen mind, and whether they were in the room when the route was chosen; the answer usually closes the case before the technology gets a vote.
- Conforming: Route purpose, sensitivity, model identity, isolation, evaluation, fallback, and exit are recorded.
- Prohibited: Capability or confidence becomes authority.
- Boundary: An unavailable model causes bounded fallback or safe pause.
- Failure: Unknown provenance or tool state blocks execution and preserves the record.
- Loophole: Fallback silently increases data access or authority.
- Misuse: Untrusted output is used to expose secrets or contact external systems.
- Care-control: Routing supports a person proportionately while preserving privacy, consent, and review.
The tellings of the clauses¶
This non-normative section gives each clause of this document its telling: the clause, quoted exactly as it stands above with its cross-reference links reduced to their plain text, and one paragraph on what the clause means, why it exists, and how it assures that what it orders is done, not done, adhered to, followed, or protected. A telling describes its clause and never becomes it: the clause's own words govern wherever a telling and its clause could be read differently, and nothing in this section adds to, narrows, or amends any requirement.
INFRA3-R001: Routing SHALL record model identity, version, purpose, inputs, policy, resource scope, and accountable owner, the routing record this architecture's own instrument of the constraint INFRA-R008 sets, the record itself that constraint's reviewable-records element made concrete, the model identity, version, inputs, resource scope, and accountable owner this architecture's own fields, the policy and purpose recorded here with their constraining force standing at the source, the quota that constraint names standing there likewise.
Every routing decision leaves a seven-field record: model identity, version, purpose, inputs, policy, resource scope, and accountable owner. The clause states its own construction: the routing record is this architecture's own instrument of the constraint INFRA-R008 sets, the record itself that constraint's reviewable-records element made concrete; model identity, version, inputs, resource scope, and accountable owner are this architecture's own fields; policy and purpose are recorded here while their constraining force stands at the source, and the quota that constraint names stands there likewise. The chapter's opening account carries the why: a hall that cannot say why a mind was chosen has let a decision dress itself as plumbing, and the failure cases name the loss, a routing reason lost among silent substitutions. Because the seven fields bind, the choosing stays a decision someone can read: a route with no recorded owner, unknown model version, or unstated purpose is refusable on its record, and a later reviewer can inspect the recorded model identity, version, inputs, and accountable owner.
INFRA3-R002: Execution SHALL isolate tools, secrets, memory, and external effects from untrusted model output, this architecture's own extension of the secrets isolation INFRA-R007 binds: the protected objects carried from that clause's secret material to tools, memory, and external effects, the isolation counterpart this architecture's own, untrusted model output standing in place of the six surfaces that clause names, and the credentials and key material it protects standing at their source.
Execution builds a wall between untrusted model output and four protected things: tools, secrets, memory, and external effects. The clause declares its descent: it is this architecture's own extension of the secrets isolation INFRA-R007 binds, the protected objects carried from that clause's secret material to tools, memory, and external effects, the isolation counterpart this architecture's own, untrusted model output standing in place of the six surfaces that clause names, and the credentials and key material it protects standing at their source. The design evidence states the premise without softening: a model response is untrusted output even when the route is technically healthy, and the misuse interpretation case shows the breach, untrusted output used to expose secrets or contact external systems. Because the isolation binds, model output cannot reach tools, secrets, memory, or external effects on its own say-so: each such reach must pass the wall, and output found acting directly on any of the four is a breach nameable against this clause.
INFRA3-R003: Routing SHALL fail closed or require review when model identity, provenance, policy, or safety state is unknown, the fail-closed duty INFRA-R005 carries from the constitutional root applying here to routing, the review alternative and the provenance and policy triggers this architecture's own, the unknown identity and safety states its tellings of the unavailable or contradictory checks the constitutional root names.
Routing meets the unknown with two permitted answers: when model identity, provenance, policy, or safety state is unknown, routing fails closed or requires review; continuing as if the unknown were known is not among the options. The clause names its lineage: the fail-closed duty is the one INFRA-R005 carries from the constitutional root, applied here to routing; the review alternative and the provenance and policy triggers are this architecture's own; and the unknown identity and safety states are its tellings of the unavailable or contradictory checks the constitutional root names. The architecture's failure interpretation case shows the conforming shape, unknown provenance or tool state blocking execution and preserving the record, and the failure cases list unverified model substitution and stale model metadata among the material failures this guards against. Because the clause binds, routing is nonconforming if any of the four states is unknown and it neither fails closed nor requires review.
INFRA3-R004: Model capability, confidence, or output SHALL NOT create authority or permission.
The clause excludes three grounds for creating authority or permission: model capability, confidence, and output create neither authority nor permission. The three nouns cover the three temptations, the model that can, the model that is sure, and the model that said so, and the clause refuses each as a source of standing. The chapter defines routing as choosing an execution component without confusing the component for the intelligence, authority, or mission it serves, and the prohibited interpretation case names the breach in five words: capability or confidence becomes authority. The operating model adds the working rule, model output remains evidence or advice until an authorized process evaluates it. Because the clause binds, any claim of authority or permission derived from what a model could do, how certain it seemed, or what it produced is refusable on that justification alone, and authority stays where the governing records put it.
INFRA3-R005: A route SHALL state data sensitivity, tool boundary, evaluation basis, fallback limit, and exit condition before execution is proposed, the data sensitivity drawn from the Data Classification and Handling Architecture as INFRA12-R007 binds for this architecture's class fields, the boundary, basis, fallback, and exit statements this architecture's own.
Before execution is proposed, a route states data sensitivity, tool boundary, evaluation basis, fallback limit, and exit condition. The clause names its borrowing: the data sensitivity is drawn from the Data Classification and Handling Architecture as INFRA12-R007 binds for this architecture's class fields, while the boundary, basis, fallback, and exit statements are this architecture's own. The routing decision record explains the sensitivity field's weight, Held material does not enter a model context, and the grading is RASP's craft rather than the centre's: a route takes the forecast as given instead of re-arguing it at the moment of choosing. Because the five statements must precede the proposal, a route is refusable before it runs: one offered without its sensitivity class, tool boundary, evaluation basis, fallback limit, or exit condition is incomplete on its face, and the five statements precede the execution proposal.
INFRA3-R006: Model substitution, fallback, or retraining SHALL preserve purpose, scope, provenance, policy, and review evidence.
Change of mind is not change of mission: model substitution, fallback, and retraining each preserve purpose, scope, provenance, policy, and review evidence. The chapter's purpose names the reader this protects, AI readers preserving scope across runtime changes, and the failure cases describe the threat as silent substitutions, a mind swapped, a context widened, a routing reason lost, adding that fallback preserves the original limits and does not silently increase authority or data access. Because the five preservations bind, a substitution can be audited for what survived it: a fallback that arrived with wider scope, or a retrained model running under vanished provenance, policy, or review evidence, is a breach nameable against this clause.
INFRA3-R007: Routing review SHALL test direct and indirect prompt injection, data and retrieval leakage, correlated error, model degradation, unsafe tool use, stale metadata, and silent fallback.
Routing review tests direct and indirect prompt injection, data and retrieval leakage, correlated error, model degradation, unsafe tool use, stale metadata, and silent fallback. The failure cases name data leakage, stale model metadata, correlated model error, and silent fallback among the material failures. The operating model adds two questions: whether untrusted output stays handled as untrusted everywhere it lands, and whether recovery from an unavailable provider is a route change and nothing more. Because these subjects are named, review coverage is checkable against the list, and omitting any of them makes the review incomplete.
INFRA3-R008: A routing design SHALL NOT deploy a model, expose credentials, or create external effects; it remains conceptual and reviewable.
The design stays on paper: a routing design deploys no model, exposes no credentials, and creates no external effects; it remains conceptual and reviewable. The three bars close the gap between describing a route and running one, the host's Draft prose draws the same line, excluding live model deployment and provider selection, and the chapter defines routing as choosing an execution component without confusing the component for the intelligence, authority, or mission it serves. The design remains conceptual and reviewable. A routing design that deploys a model, exposes credentials, or creates external effects is nonconforming.
Where this document sits¶
- Identifier: INFRA-3
- Status: Draft
- Authority: INFRA-1, INTEL-0
- Approved by: The Architect
- Depends on: INFRA-1, INTEL-0, INFRA-12
- Depended on by: INTEL-17
- Maps: Authority Map, Dependency Map
This block is generated from the archive's own records when the site is built. It records position only and creates no authority.