04. Model Routing Spec
1. Purpose
Define the capability-vector selection contract for IModelVectorRouter, ensuring both dynamic optimization in normal execution and deterministic reproducibility in replay execution.
2. Scope
ModelCapacityVectorIDynamicCapacityProviderIVectorMatcherIModelVectorRouterIComputeShapeAdvisorICapabilityRegistry
3. Normative Requirements
MRS-001Routing MUST be capability-driven, not model-name driven.MRS-002Candidates failing mandatory axes MUST be excluded.MRS-003Dynamic constraints (budget, latency, load) MUST be evaluated.MRS-004Routing scores MUST be recorded for auditability.MRS-005Multidimensional Vector Mapping: Required capability MUST be evaluated across the five core axes:Reasoning,Fidelity,Latency,Economy, andContextWindow.MRS-006Hardware Awareness: ThroughIComputeShapeAdvisor, routing MUST prioritize candidates with higher energy efficiency on the current device shape (GPU/NPU).MRS-007Deterministic Tie-breaking: When multiple candidates share identical scores, selection MUST converge via a deterministic algorithm based on hash and/or priority list.
3.1 Replay-Aware Routing Bypass
MRS-REPLAY-001IModelVectorRouterMUST NOT execute dynamic routing when replay execution detectsReplayContext.LockedProviderInfo.MRS-REPLAY-002During replay, the execution engine MUST enableForce Provider Modeand apply Provider/Model/Quantization values fromLockedProviderInfowithout alteration.MRS-REPLAY-003A replay dump missingLockedProviderInfoMUST NOT be treated as deterministic replay.
4. Fail-Closed
MRS-F001Abort when no candidate satisfies mandatory axes.MRS-F002Block new routing when budget hard limit is reached.MRS-F003Reject capability declarations with schema mismatch.MRS-F004Dynamic Limit Violation: IfIDynamicCapacityProviderdetects overload or unstable connectivity immediately before execution, abort instead of degraded forced execution.MRS-F005Capability Mismatch (ROM Integrity): If required ROM capabilities (for example[[capability.vision]]) cannot be satisfied by a selected model, block as validation failure.
5. Acceptance Criteria
- AC1: Identical inputs and constraints produce identical routing output.
- AC2: Mandatory-axis failing candidates are never selected.
- AC3: Tie cases are resolved deterministically with stable output.
- AC4: During replay execution, selected provider MUST match previously selected provider with 100% consistency.
6. Interface / DTO Definition
Define immutable data structures that guarantee routing lock behavior.
public sealed record LockedProviderInfo(\n string ProviderId,\n string ModelId,\n string QuantizationProfile,\n ModelCapacityVector CapacitySnapshot,\n DateTime CapturedAtUtc);\n\npublic sealed record ReplayRoutingPolicy(\n bool ForceProviderMode,\n LockedProviderInfo LockedProviderInfo);
7. ModelCapacityVector Structure (ROM Representation)
Model capability is registered in ICapabilityRegistry as ROM.
---\nid: "provider.openai.gpt4o"\ntype: "model.capability"\nversion: "1.0.0"\n---\n# Capacity Axes\n* [reasoning]: 0.95\n* [fidelity]: 0.98\n* [latency_score]: 0.60\n* [token_cost_index]: 0.80\n\n# Physical Constraints\n* [preferred_device]: [[device.gpu]]\n* [max_concurrency]: 50
8. Routing Algorithm
IModelVectorRouter finalizes routing in the following steps.
- Context Check
- Requirement Extraction
- Hard Filtering
- Soft Scoring & Dynamic Adjustment
- Final Selection
Check whether replay mode is active and LockedProviderInfo exists. If present, jump to step 5.
Extract mandatory axes from input ROM (for example reasoning > 0.9).
Remove candidates that fail mandatory axes.
IVectorMatcher computes cosine similarity or weighted distance, then apply budget/load penalties from IDynamicCapacityProvider.
Select highest score candidate (or LockedProvider) and record traceability matrix into Replay Dump.
Changelog
- v0.0.0 / v0.0.0.0: Initial draft
- v0.0.1 (2026-05-06): Version upgrade aligned with documentation guidelines
specs/04.MODEL_ROUTING_SPEC.md