Skip to main content

52  Routing Heads and Specialist Cores

52.1 Chapter status

Field	Value
Chapter ID	routing-heads-and-specialist-cores
Part	Part III - Routing, Compression, Representation, and Substrates
Status	conceptual
Manuscript maturity	v0.3 claim-proof program
Last updated	2026-08-02
Primary source records	20 assigned records with 18 exact mappings, including relational operator, order, topology, fallback, and abstention routing
Claim label	Design rationale
Evidence level	argument
Source queue	primary: octopus_router, rmi, benchmaxxing; supporting: beastbrain, cognitive_loop_closure, rgs, viea, scf, talos, project_theseus_whitepaper, theseus_operator_os, theseus_architecture_gate, reflexive_router_whitepaper, relational_dimension_compiler; variant: moecot_md; connector/recovery: moecot
Source loading state	source notes: learning_compute_topology, octopus_router, deterministic_capability_compilation, rmi, beastbrain, cognitive_loop_closure, rgs, benchmaxxing, viea, scf, talos, moecot_md, moecot, project_theseus_whitepaper, theseus_operator_os, theseus_architecture_gate, ext_hipporag_2024, ext_dont_hallucinate_abstain_2024, qcsa_whitepaper, reflexive_router_whitepaper, relational_dimension_compiler, ext_kimi_k3_2026, portia_synapse, spider_synapse, coilmoecot; raw cache: octopus_router, rmi, beastbrain, cognitive_loop_closure, rgs, benchmaxxing, viea, scf, talos, moecot_md, coilmoecot; connector/recovery: moecot
Test state	Three routing/runtime schemas; 3/7 route-lease and 4/5 readiness fixtures; a 300-example matched three-seed program; one 60-request ambiguous single-model workload; two conservative dispositions; and twenty-nine live family declarations. The refinement contributes an exact twenty-five-theorem arbitrary finite-run surface, retains four load-bearing legacy routes, and physically retires sixteen projection/fixture declarations. Its independent consumer recompiles the exact surface, covers seven stages and all 42 routes, and rejects 47/47 mutations while keeping route and answer outcomes separately represented and balanced. The only current narrow empirical result remains route discrimination plus exercised non-answer behavior, not useful specialist answers.

52.2 Drafting guardrail

Selection is the first problem of Part III: which bounded capability may act, under which authority and readiness state, with which fallback when the route fails. Octopus Router Architecture and RMI supply the routing vocabulary; Benchmaxxing, SCF, Talos, Project Theseus, and MoECOT supply runtime-evidence pressure. Folded MoECOT material remains an implementation-reference crosswalk, not reproduced runtime evidence. Finite predicates, synthetic lease/readiness fixtures, and bounded matched or ambiguous workloads establish no deployed authority enforcement, trained-specialist utility, independent evaluation, MoECOT replay, orchestration benchmark, natural multi-model routing, or production transfer.

The evidence surface is now more precise than that older boundary. Twenty-nine live family declarations comprise twenty-five arbitrary-run lifecycle theorems and four retained load-bearing legacy routes; sixteen projection or fixture declarations were physically retired. The independent consumer exercises seven stages, all forty-two routes, and forty-seven rejecting mutations. The post-v2.1 workload supplies a bounded local learned-route result: 59/60 route labels were correct and fallback, abstention, and clarification activated. Yet all 360 substantive candidate answers were wrong, so all 20 correct end outcomes were non-answer actions. One 4B model, one seed, a synthetic six-action set, and an internal deterministic evaluator cannot establish useful specialist routing, calibration, independence, authority enforcement, production safety, or transfer.

Opening Part III, this chapter receives the verified procedures and specialist candidates that Part II made possible. The new problem is selection under constraint: which bounded capability may act, under which authority, with which readiness state, and with which fallback if the route fails.

The route is a lease, not a preference. It grants a specialist a task-local envelope for context, tools, budget, evidence obligation, and fallback behavior, and it expires when the task or route state ends.

52.3 Human Reading Path

Concrete lens. The confidence-only router selects the familiar deployment specialist. The governed router abstains because local deletion and public withdrawal require different authority.

Repeated work can become procedural memory records only after evidence matures. That creates the operational routing question: which bounded capability should handle the next piece of work, and why is it allowed to do so?

A route is assignment under constraint, not just a recommendation or a load-balancing choice. It is a temporary lease that should carry scope, readiness, authority, context, tools, fallback, residual burden, and a reason why this specialist is adequate for this task right now. The route should also remember what it refused: stale specialists, missing evidence, excess authority, unsafe tools, or cheaper paths that would lose traceability.

That lease language keeps specialists from becoming ambient agents. A high-quality core can be useful while still being unqualified, unauthorized, too expensive, stale, or unsafe for a particular job. Routing earns trust when it preserves rejected alternatives, not only the winning choice.

Routing is trustworthy only when it preserves why a specialist was chosen and why alternatives were rejected. Runtime packets matter only when ledgers, replay refs, denied routes, failed gates, residuals, and source-state boundaries survive.

52.4 Problem

The stack cannot route every task to one general cognitive core and still claim local authority, local memory, readiness-aware selection, or clean rollback. The more tasks the system accepts, the more it needs a way to say which bounded capability should act, what it is allowed to see, what tools it may use, what evidence qualifies it, and where the result should go if the route fails.

The Octopus Router source frames this as a resident head/router with dynamically selected specialist arms. RMI adds the ratchet: specialist attempts, logs, residuals, benchmark pressure, regression preservation, and lifecycle discipline. In the ASI Stack, the same idea becomes the routing boundary between planning and capability execution.

The hard problem is refusing plausible specialists. A route can look semantically relevant while lacking authority, context adequacy, readiness, budget, proof boundary, or fallback. The router should therefore record not only the selected specialist, but also rejected candidates, blocked reasons, escalation triggers, residuals, and consumer obligations. Routing is governance pressure, not just model selection.

52.5 Why existing approaches are insufficient

Monolithic scaling hides the route. Static tool lists hide the capability boundary. Prompt-only orchestration can choose a tool, but it rarely records why that tool was adequate, which authority envelope applied, which local memory was in scope, how readiness was checked, or what fallback will be used when the result is inadequate.

Routing is not just a performance problem; it is a governance problem. A specialist that can read a private memory, call a tool, mutate an artifact, or advise a high-impact decision is exercising authority. The router therefore needs a registry and a decision record, not just a confidence score.

External routing and MoE work supplies the performance baseline that governance-aware routing has to exceed in discipline, not in claimed benchmark score. Sparse MoE (ext_sparse_moe_2017), GShard (ext_gshard_2020), Switch Transformer (ext_switch_transformer_2021), Expert Choice (ext_expert_choice_routing_2022), Mixtral (ext_mixtral_2024), the MoE survey (ext_moe_llm_survey_2024), FrugalGPT (ext_frugalgpt_2023), Hybrid LLM (ext_hybrid_llm_2024), and RouteLLM (ext_routellm_2024) all make conditional computation, learned routing, capacity, and cost-quality tradeoffs explicit. Specialist cores add authority ceilings, readiness, residuals, and fallback records around that baseline; no route-quality measurement is claimed here.

Route opacity is the immediate routing failure. A system may choose a good specialist and still leave no explanation of rejected candidates, denied authority, missing readiness, fallback options, or residual work. That makes later audit and learning impossible.

52.6 Core Claim

[routing-heads-and-specialist-cores.core, label: Design rationale, support: argument] ASI scales through a lightweight routing head that selects bounded specialist cores with local tools, memory, and authority.

Reader claim. A router should choose the least capable qualified route that meets the task, and it should abstain when ambiguity makes specialist selection unsafe.

Operational rule. Bind the request, candidate denominator, capability need, authority ceiling, readiness lease, context, cost-quality record, fallback, rejected candidates, and residual owner. Authority mismatch or failed readiness blocks selection; unresolved ambiguity routes to clarification or a safe generalist.

52.6.1 Worked ambiguous route: “remove the old release”

A request says, “remove the old release.” One specialist manages local build artifacts; another controls public releases. The phrase does not identify whether “old release” means a generated directory, a Git tag, a hosted page, or a published binary. A confidence-only router selects the public-release specialist because similar phrases appeared in deployment tasks. The governed router sees that the candidates require different authority and effects, so it abstains and asks for the target.

If the answer is “delete the local generated preview,” the least-authority local specialist can proceed under a file-scoped lease. If it is “withdraw the public binary,” a separate release workflow and approval are required. Candidate and fallback records retain the rejected routes and their costs. The finite routing model checks registry, readiness, authority, freshness, overprivilege, evidence, fallback, and residual states; it does not establish learned routing accuracy, calibration, useful throughput, or specialist quality.

The claim remains at argument support. The reviewed passages justify discussion of router heads, specialist arms, permission envelopes, memory routing, residual-aware routing, runtime evidence packets, and arm lifecycle, but they do not by themselves prove that a particular router is safe, empirically superior, or implemented through MoECOT. MoECOT and the Markdown variant supply implementation-reference context only until usable runtime artifacts, replay records, benchmark packets, or reproduced runs are imported.

52.6.2 Claim-source mapping status

Appendix C now maps this routing-head claim to all assigned source notes and records passage-reviewed support for all folded routing and MoECOT runtime-crosswalk mappings. The mappings support router heads, bounded specialist cores, local tools and memory, authority envelopes, residual-aware routing, runtime evidence packets, source-state partitions, replay obligations, and specialist lifecycle discipline, not a solved router, measured routing advantage, or reproduced MoECOT runtime.

Source	Review state	What it supports	Limit
octopus_router	passage-reviewed local raw cache	Resident head/router selection, dynamically loaded arms, local tools, memory, benchmarks, residuals, permissions, runtime tiers, verification contracts, route patterns, permission envelopes, arm cards, and split/merge/retire policies.	No routed-specialist prototype, learned-router harness, runtime authority enforcement, or routing benchmark has been run here.
rmi	passage-reviewed local raw cache	Head/router, specialist arms, arm registry, memory router, permission router, tool registry, benchmark ledger, residual escrow, verification/safety layer, lifecycle states, and regression-floor preservation.	No independent reproduction, benchmark run, prototype inspection, or empirical specialist-routing result exists here.
beastbrain	passage-reviewed local raw cache	Local, stateful intelligence split across memory, verification, planning, routing, security, consolidation, interface surfaces, semantic intent, intelligence tiers, and capability routes.	Architecture lineage only; hardware, cost, context-length, security, and benchmark claims are source-reported.
cognitive_loop_closure	passage-reviewed local raw cache	Verified procedural memory, tool registry, router, runtime monitor, execution modes, tool cards, risk tiers, lifecycle states, and retirement discipline.	No local loop detector, tool synthesis, router monitor, or verified procedural tool has been executed.
rgs	passage-reviewed local raw cache	Ratcheting system that logs attempts, classifies successes/failures, promotes verified tools, preserves residuals, maintains regressions, and keeps ledgers for routing and interventions.	No local benchmark runs, tool-promotion traces, regression data, or implemented ratchet are present.
benchmaxxing	passage-reviewed local raw cache	Benchmark lifecycle, wall diagnosis, model/benchmark ledgers, anti-Goodhart safeguards, regression conversion, residual preservation, and architecture-change criteria for runtime promotion pressure.	No benchmark harness, mutation, holdout, run, or reproduced performance claim exists here.
viea	passage-reviewed local raw cache	Command contracts, artifacts, specialist-routed work, verified outputs, runtime execution, feedback, residuals, tools, benchmarks, and regression coverage.	No completed VIEA deployment, runtime trace, or verified execution result exists here.
scf	passage-reviewed local raw cache	Runtime cores as replaceable capability implementations behind stable contracts, evidence registries, scoped qualifications, route validation, lifecycle events, rollback, and authority boundaries.	Does not prove MoECOT core safety, evaluator quality, or production replacement behavior.
talos	passage-reviewed local raw cache	Typed jobs, deterministic control planes, execution factories, adjudication, delivery, feedback, evidence records, audit logs, replay, tool isolation, and approval gates.	No Talos runtime, MoECOT-Talos integration, replay run, security result, or benchmark has been reproduced.
moecot_md	authenticated Google Drive text extraction	Terminology normalization for compact orchestrator, specialist lanes, control-plane ledgers, readiness gates, replay, and fail-closed promotion.	Variant source only; it is not independent corroboration and does not verify benchmark, readiness, or runtime behavior.
moecot	authenticated Google Docs extraction	Compact orchestration, routed specialist lanes, fail-closed control planes, run/task/control-plane ledgers, readiness gates, replay, handoff, promotion blockers, residual tracking, and explicit limitations.	Runtime code, route logs, benchmark artifacts, release artifacts, and replay records have not been imported, inspected, or reproduced.
project_theseus_whitepaper	passage-reviewed local public-project source	Octopus head router, bounded specialist arms, schemas, permissions, local memory, benchmarks, residuals, reliability scores, lifecycle state, retirement criteria, and trusted-node task allowlists.	Current Theseus reports, ledgers, code paths, and command outputs were not rerun from this repo.
theseus_operator_os	passage-reviewed local public-project source	Durable work boards, node registries, command-channel parity, skill registry, tool hooks, feedback routing, safety gates, TTLs, kill switches, signed updates, and isolation surfaces.	No Hive board, SQLite database, node registry, command channel, hook ledger, or dashboard was run.
theseus_architecture_gate	passage-reviewed local public-project source	Pre-training checks for ratchet completeness, router readiness, safety ledger, regression suite, residual escrow, bridge benchmarks, procedural tools, routing memory, lifecycle governance, and external-inference zero.	Reported gate snapshot is not reproduced evidence; current gate artifacts were not regenerated or independently inspected here.

52.7 Mechanism

Routing begins where procedural memory leaves off. Once the stack has tools, specialists, memories, verifiers, and fallback lanes, the next problem is not merely “which model answers?” but “which bounded capability may act under this authority envelope?” Octopus Router supplies the head-and-arms structure, RMI supplies the lifecycle and residual pressure, Cognitive Loop Closure supplies routable tool cards, and Theseus/MoECOT supply implementation-reference pressure for node registries, specialist lanes, ledgers, and replay.

The boundary therefore has two records. A Specialist Registry Record describes what a specialist is allowed to do, what it costs, what memory and tools it may access, what evidence qualifies it, and where it must fall back. A Routing Decision Record records why the router selected that specialist for this task instead of a cheaper, safer, more constrained, or more reviewed route.

The decision record should be read as a task-local authority lease, not a standing appointment. The registry declares the specialist’s maximum envelope; the route grants only the subset needed for this task, under this readiness state, with this fallback. That distinction keeps specialist selection from silently becoming authority transfer.

Routing’s local delta is capability leasing. The shared governed-cognition pattern already has records, gates, receipts, and rollback paths; routing adds the rule that capability is not assigned by semantic fit alone. A route must preserve the selected specialist, rejected candidates, authority subset, readiness state, cost-quality predicate, fallback, residual owner, expiry, and non-claim boundary so a successful route cannot launder permanent authority into the specialist.

The operational lifecycle has eighteen stages:

1. Freeze task, consumer, acceptance predicate, capability, authority, rights, risk, budget, deadline, and fallback obligations.
2. Snapshot the versioned candidate registry with capability, exclusions, memory, tools, authority, readiness, evidence, cost, load, and lifecycle.
3. Compile semantic task identity separately from physical model, expert, tool, node, human, or composite routes.
4. Eliminate candidates failing capability, authority, rights, readiness, freshness, privacy, locality, resource, dependency, or conflict gates.
5. Build admissible route features without leaking held-out outcomes.
6. Estimate candidate-specific useful success, failure, refusal, uncertainty, latency, cost, safety, and residual distributions.
7. Calibrate selective prediction against coverage, abstention, clarification, fallback, escalation, and useful outcomes.
8. Choose among single, sequential, parallel, debate, verification, human, reflex, fallback, abstention, clarification, and no-route policies.
9. Prefer the least capable and least authoritative route satisfying the joint predicate, with explicit justification for deviations.
10. Issue a task-local lease binding granted subset, context, tools, budget, deadline, evidence duty, fallback, expiry, and residual owner.
11. Execute through the existing Runtime, Human, or Inter-Stack owner and retain dispatch, refusal, intervention, effect, and cost receipts.
12. Evaluate route correctness separately from answer usefulness, artifact correctness, safety, and evidence adequacy.
13. Activate clarification, fallback, abstention, escalation, cancellation, retry, or residual routes when a gate fails.
14. Update routing memory with chosen and rejected candidates, counterfactuals, outcomes, interventions, costs, uncertainty, and delayed residuals.
15. Monitor load, contention, tail latency, correlated failures, collusion, evaluator drift, concentration, fairness, and specialist interference.
16. Promote, canary, quarantine, split, merge, replace, or retire specialists and policies through readiness gates with rollback.
17. Emit a replayable decision/runtime packet with versions, features, scores, candidates, checks, route or refusal, lease, receipts, costs, and residuals.
18. Compare strong route policies on preregistered natural and adversarial work with independent reproduction and transfer.

flowchart LR
  A["Plan node"] --> B["Capability request"]
  B --> C["Specialist registry"]
  C --> D["Authority envelope check"]
  D --> E["Readiness state check"]
  E --> F["Cost and quality predicate"]
  F --> G{"Adequate route?"}
  G -- "yes" --> H["Selected specialist core"]
  G -- "no" --> I["Fallback, escalation, or residual"]
  H --> J["Routing decision ledger"]
  I --> J
  J --> K["Residual escrow or route memory"]

Reading the route lease: The router grants a task-local route lease, not permanent authority to a specialist. Capability fit, authority envelope, readiness, cost, and quality are checked before selection, and both successful selections and rejected routes feed the ledger for future routing memory.

The routing head should stay small. Its job is to select, load, coordinate, verify, and log. Specialist cores carry bounded local capability: tools, local memory, benchmarks, residuals, permissions, runtime tier, and verification contracts. A core can be a model, tool stack, proof checker, planning compiler, retrieval lane, mathematical substrate, human review lane, or composite worker, but it should be registered through the same boundary.

The router should support several route shapes:

• Single-specialist routing for narrow tasks.
• Sequential routing when one specialist prepares inputs for another.
• Parallel routing when independent specialists can produce comparable outputs.
• Debate or adjudication routing when disagreement is useful evidence.
• Verification routing when one core checks another.
• Reflex or failsafe routing for known safety-critical cases.

Each route shape still needs the same discipline: capability match, authority match, readiness check, cost-quality rationale, fallback, and residual recording.

The decision should also record non-selection. A rejected candidate may be too expensive, underqualified, overprivileged, stale, quarantined, or missing context. Those rejections are evidence for future readiness, routing, and resource policy.

52.7.1 An arm is three contracts, not an expert label

The Octopus Router paper’s arm-anatomy and arm-card tables make a distinction that is easy to lose in agent frameworks. A specialist is not defined by its name, prompt, model endpoint, or benchmark score. It exists at the intersection of three versioned contracts:

Contract	Required content	What it must not imply
Capability	Included and excluded task families, input and output schemas, tools, dependencies, runtime, local memory, and fallback.	That semantic relevance makes the arm adequate for every instance.
Authority	Maximum memory, tools, runtime, side effects, budget, risk, locality, privacy, rights, and escalation envelope.	That registration grants any of that authority to a particular task.
Evidence	Benchmark frontier, regression floor, residual clusters, reliability, freshness, evaluator and environment scope, lifecycle state, and retirement criteria.	That a score is current, causal, transferable, or sufficient for release.

The registry records the maximum declared envelope. A route grants only its task-local intersection with principal, consumer, policy, rights, readiness, resource, and risk ceilings. Together these form an arm contract, not a standing appointment. This prevents a useful specialist from becoming an ambient agent and prevents a broad “coding” or “research” label from hiding incompatible subdomains, tools, and risks.

An arm result needs an equally explicit envelope. It carries the scoped result, confidence semantics, evidence and provenance, required assumptions, residuals, risk flags, suggested successor or verifier routes, observed cost, and effect receipts. A separate composition receipt records which fields the head used, which conflicts it resolved or exposed, which evidence it discarded, which verification it requested, and why the terminal output is faithful to the arm artifacts. Fluency is not composition evidence.

52.7.2 Semantic routing and physical residency are separate

52.7.2.1 Route the semantic object, not just the destination

Learning–Compute Topology sharpens the word route. Evidence routing decides which observations reach which identities. Judgement routing decides who may evaluate them. Credit routing assigns adaptive responsibility. State routing moves or synchronizes adaptive state. Artifact routing moves checkpoints, proofs, reports, or datasets. Control routing schedules or rewrites the process. Authority routing changes permission. These routes may share infrastructure but must not share an untyped edge.

This distinction catches a subtle privilege bug: a head authorized to select a specialist for a task is not thereby authorized to send that specialist held- out evaluation evidence, update its weights, merge its state, or promote it. Likewise, paging a dormant expert into VRAM is a physical-residency action, not an adaptive-state transfer or topology rewrite.

The route receipt therefore adds semantic channel type, source and destination identity/version, evidence or state provenance, evaluator and credit owner, authority token, delay/staleness, integration semantics, and physical realization. Learned route improvement can change a route policy; adding a new adaptive identity, evaluator, or integration edge is a governed topology- replacement transaction. No LCT package result establishes that these added types improve the existing router; they make the test and its failure legible.

ORA’s resident-head/cold-arm proposal adds a control problem beyond selecting the right capability. A semantically correct arm can still be unavailable, stale, too slow to load, incompatible with a dependency, resident on a disallowed node, or more expensive than a warm generalist. The router therefore must not collapse which capability should act into where and whether its artifacts are resident.

A residency record should bind the selected arm and dependency versions, previous state, placement, trust zone, cold-start and transfer time, bytes moved, peak and active memory, warm-cache status, prefetch reason, unload policy, terminal state, fallback, and observed cost. Useful residency states include cold, loading, warm, active, unloading, unavailable, stale, and quarantined. Loading never expands authority: a prefetched or warm arm remains ineligible until the task-local route lease passes.

Dynamic loading is successful only if the end-to-end route preserves its quality, safety, and isolation floors while improving a declared resource objective. The comparison must include warm generalists, ordinary caching or paging, quantization, and static specialist pools—not merely an always-resident copy of the same modular system. Report cold-start and tail latency, transfer volume, cache-hit and prefetch precision, load/unload overhead, thrashing, unavailable-arm failures, memory saved, and total verification and governance cost. Prefetch also belongs in the threat model because speculative loading can reveal sensitive task intent or expose a capability before authorization.

52.7.3 Topology change is a replacement transaction

The source’s spawn, split, merge, and retire signals are useful diagnostics, not self-executing rules. Repeated demand and residual clusters may justify a new arm; unrelated tools, growing memory, divergent risks, internal branching, and declining reliability may justify a split; overlapping tools, memory, benchmarks, outputs, and failures may justify a merge; staleness, regression, unsafe behavior, supersession, or excessive cost may justify retirement.

Every such change alters the candidate denominator and may also alter route features, memory custody, tool contracts, dependencies, regression floors, cache state, and rollback. The lifecycle decision therefore enters Stable Capability Field and replacement governance with a frozen pre-state, counterfactual no-change baseline, migration map, qualification scope, canary, rollback, affected consumers, and residual owner. A local arm ratchet is not independent in effect when it changes shared embeddings, schemas, tools, memories, or composition behavior. “Independently improvable” is a property to test, not a consequence of modular naming.

52.7.4 Routing linked neural capability objects

Deterministic Capability Compilation gives the router a package richer than an expert ID. A Neural Capability Object declares its field and base identities, owned parameter region, tensor and activation ABI, applicability, authority ceiling, evidence, dependencies, failure channel, fallback, and lifecycle state. The linker resolves collisions, adapters, relocation, router bindings, and compatibility, then emits a receipt whose scope is the exact linked candidate and environment.

Routing is consequently an authority lease, not proof that independently trained modules compose. A sparse route is preferred as the preservation baseline because unchanged paths and fallbacks remain visible. Any shared-state training, cross-expert interference, densification, or route collapse triggers new validation. The proposal supplies an interface and attack surface; no NCO linker or routing result exists here.

52.7.5 MoECOT Runtime Crosswalk

MoECOT is folded here as a runtime crosswalk over routing, not as a reproduced implementation. The useful object is a runtime evidence packet that binds command intake, route-head selection, specialist lanes, control-plane gates, ledgers, replay references, handoff state, promotion blockers, residuals, and source-claim state. A named runtime earns architectural relevance only when those records survive inspection independently of the runtime brand.

The crosswalk separates source-reported, locally reproduced, externally corroborated, and blocked fields. A source can define the expected shape of a run packet, but only imported or reproduced artifacts can move a runtime statement beyond design rationale. That distinction lets MoECOT guide prototype work without laundering source-reported runtime or benchmark claims into evidence.

A MoECOT-style packet also records failed and denied paths. A successful route without denied routes, failed gates, missing replay refs, unresolved handoffs, and residual branches is biased evidence. The runtime crosswalk therefore makes non-execution visible: refused authority, blocked routes, absent replay, and residual handoff are outcomes the router and readiness gate must preserve.

CoilMoECOT adds a narrow pattern for negative-signal specialists. An “anti-expert” is not a negative mixture weight and not an invisible veto. It is a bounded evidence lane that identifies the candidate or plan it challenges, the trace features it observed, its confidence and calibration scope, the maximum penalty it may contribute, the authority that can override it, and the final route effect. It begins in shadow mode and must be compared with ordinary rules and small classifiers. If the lane cannot be removed without changing the control plane, it has already exceeded the specialist boundary.

52.7.6 Semantic-to-physical route compilation

QCSA adds a translation boundary before specialist dispatch. Stable SOIDs say what objects, requirements, claims, tools, or obligations the task concerns; plural semantic virtual addresses say which conceptual facets are useful for this consumer; the routing plane then compiles those records into temporary model, expert, memory, tool, verifier, and decoder choices. Semantic identity does not rotate when hardware moves, load changes, or an expert is replaced.

The route compiler may use a soft address posterior, but it must expose the commitment rule. A low-risk retrieval may fan out over top-k paths; a high-risk tool route may require calibrated confidence, authority checks, independent verification, or clarification; unresolved ambiguity may route to fallback or abstention. Load balance, latency, token budget, cache placement, permission, and approval remain physical-policy objectives and cannot be smuggled into the semantic identity.

This gives the routing receipt four distinct references: subject_soid, semantic_address_certificate_ref, route_policy_and_resource_snapshot, and physical_route_plan_ref. The frozen evaluation compares the full QCSA route against seven baselines and five ablations over 60 held-out cases and three seeds. Full QCSA was Pareto-nondominated against every baseline in five of six families, resolved all labelled objects, prevented all defined synthetic risk failures, and recorded zero unsafe releases. Yet the selected direct-clarification baseline also reached 1.000 task-decision accuracy in every seed, so the paired task delta was exactly 0.000. QCSA used 1.913386 times its operation count, exceeding the preregistered 1.50 governance ceiling.

The matched-resource routing-advantage claim is therefore refuted for this exact workload. The task labels were ceiling-easy, the methods were deterministic rather than learned specialists, and the cost difference between full QCSA and ablations is partly confounded by frozen verifier bookkeeping. Routing should retain stable identity, separate authority, fallback, receipt, and migration interfaces, but it cannot cite this experiment as learned-route, latency, throughput, or efficiency evidence. The core claim remains at argument.

52.7.7 Relational order is another routed resource

The Relational Dimension Compiler extends route choice below the level of model or specialist identity. For a given candidate structure, the router may choose unary lookup, pairwise attention or message passing, a selective triadic kernel, a tree-structured polynomial, a hypergraph update, an equivariant operator, a field solver, an exact join, or a symbolic constraint path. It also chooses candidate topology, factorization, precision, scale, branch resolution, verification effort, and whether to stop or abstain.

The default is not “use the highest order available.” Pairwise computation is the ordinary route. Escalation is warranted only when a lower-order route leaves a material, consumer-relative residual and the expected improvement survives total cost:

RelationalOrderDecision {
  consumer, task, branch, candidate_denominator,
  proposed_entities_and_roles, proposal_recall_basis,
  lower_order_route_and_residual,
  candidate_operator, primitive_arity, factorization,
  expected_quality_or_information_gain,
  compute_memory_communication_verification_and_repair_cost,
  authority_ceiling, fallback, abstention, expiry
}

Sparse routing does not get candidate generation for free. A route that inspects only \(nK^2\) triples instead of \(n^3\) must report how the neighborhoods were constructed, whether the target tuple was ever proposed, and the complete rejected-candidate denominator. Otherwise a privileged proposer can contain most of the intelligence while the advertised higher-order kernel receives the credit.

Admission requires a lower-order rescue: a deeper, wider, better-tuned, or better-structured pairwise baseline receives matched information, data, parameters or priced capacity, inference compute, memory, tuning, and repair. If it reaches the same generalization and calibration at lower total cost, the higher-order route has not earned an efficiency claim. Conversely, a failed naive port or proposal-recall failure is evidence about that attempt, not a refutation of polyadic computation.

The useful routing outputs are therefore order regret, proposal recall, role accuracy, intervention fidelity, calibrated abstention, useful outcome, total lifecycle cost, and residuals—not the nominal tensor order selected. The paper proposes this contract but supplies no trained order router, natural task, or measured advantage.

52.7.8 Pre-deliberative reflexive dispatch

The Reflexive Router sharpens this routing boundary by separating route proposal from route admission. An authenticated event first encounters the constitutional and authority boundary. An explicit route, capability, or workflow command is then resolved before automatic routing, but it may bypass route inference only. It cannot bypass schema validation, qualification, authority, consequence classification, verification, audit, expiry, or revocation. If a forced route is unavailable or inadmissible, the terminal result is a typed failure or an explicitly authorized fallback—never a silent change of route.

Automatic routing is likewise two-stage. Deterministic rules, a calibrated learned model, cache lookup, or another proposer may nominate candidates and emit scores, OOD signals, ambiguity, and abstention. A separate qualification predicate admits only candidates whose capability contract, entity binding, freshness, authority, quality floor, verifier, effect policy, resource budget, and fallback obligations hold. Cost optimization happens only over that qualified set. A high-confidence learned prediction therefore remains a proposal; it does not mint a capability, authority, or execution lease.

flowchart LR
  A["Authenticated event"] --> B{"Explicit command?"}
  B -- "yes" --> C["Deterministic command binding"]
  B -- "no" --> D["Rule / learned / cache proposals"]
  C --> E["Qualification + authority admission"]
  D --> E
  E -- "atomic" --> F["Qualified capability route"]
  E -- "composite" --> G["Bounded semantic-operation DAG"]
  E -- "none" --> H["Clarify / abstain / typed failure"]
  F --> I["Verifier or effect kernel"]
  G --> I
  I --> J["Typed result + dispatch provenance"]

Composite work changes the unit of routing from one label per prompt to a small typed semantic-operation DAG. Exact transforms, retrieval, proof, specialist inference, deliberation, verification, and effects may use different routes while preserving dependencies, qualification receipts, cancellation, retry, partial-result, and plan provenance. The route record must retain the ingress mode, proposals, disqualifications, selected nodes, overrides, fallbacks, and terminal outcome so fast-path coverage cannot hide wrong or unauthorized dispatch.

This is a design integration, not a result. The paper supplies the ordering, contracts, algorithms, threat hypotheses, and ReflexBench plan; it supplies no trained router, implementation, benchmark result, effect campaign, or external reproduction. The core routing claim remains at argument.

52.7.9 Hierarchical routing, selective risk, and bounded cascades

A route taxonomy should not become one enormous flat classifier or a miniature chatbot. A bounded router can first distinguish broad operation families—read, compute, prove, transform, act, deliberate, or clarify—then load only the relevant capability index and refine within that branch. Its output is a typed candidate set with atomicity, scores, margins, OOD indicators, effect class, and abstention probability. It cannot invent a capability name or arguments, and it has no executable authority.

Scores require calibration by route family, request domain, effect class, and observed distribution shift. The operating objective is a risk–coverage curve, not top-one accuracy: thresholds are chosen to keep wrong fast-path execution inside a consequence-specific budget. Distance from known cases, head or ensemble disagreement, low margins, rejected contracts, novel schema/entity combinations, and sudden telemetry drift must change behavior by increasing abstention. Merely logging a lower confidence while downstream execution stays unchanged is not OOD handling.

Qualification can still support a deadline-aware cascade. The runtime may start a cheap admitted computation, reserve time for verification, escalate to a stronger exact or specialist route when ambiguity remains, and use deliberation only for the unresolved synthesis. Every stage inherits the same deadline, authority, privacy, and effect ceiling, and the trace records which candidate failed which obligation. This makes a cascade a sequence of qualified fallbacks rather than an invisible retry ladder.

Outcome traces may update ranking and calibration from observed route success, verification, cost, user correction, and downstream usefulness. They may not update authority. Repeatedly succeeding at a calendar read does not grant calendar-write permission. Router releases therefore bind a versioned model to route-level confusion matrices, risk–coverage curves, adversarial paraphrases, OOD cases, current capability-contract compatibility, shadow evidence, and rollback thresholds. Because routing determines which subsystem sees an event, a small classifier regression can create a system-wide authority, quality, or cost regression.

52.7.10 Fast routing policy and slow routing improvement

VIEA contributes a second separation inside the routing layer. A Fast Router executes the currently admitted policy under hard caps for specialist calls, context, tokens, compute, latency, money, human-review requests, authority, consequence, and fallback. It stays on the critical path and should be deterministic or policy-constrained wherever practical. A Slow Conductor works asynchronously over logs, outcomes, and residuals to propose policy changes, specialist splits or merges, changed defaults, and new fallbacks. It does not acquire online effect authority merely because it learns from more history.

That division avoids replacing a monolithic model with a monolithic orchestrator. It also gives routing failure an owned vocabulary: wrong or missing specialist, context under-allocation, context over-allocation, unresolved specialist conflict, skipped verifier, over-routing, under-routing, and permission mismatch. Each residual binds the admitted policy version, candidate set, disqualifications, selected route, costs, terminal outcome, and recovery. Slow-lane recommendations return through qualification and change control; they cannot edit the live router silently.

52.7.11 PortiaSynapse: replacement-compatible routing must earn each mechanism

The TreeLLM lineage eventually moved from a general DKL navigation proposal to two concrete Synapse designs. SpiderSynapse proposed four parallel hypotheses, three refinements per hypothesis, a mutable working memory, a selector, and coordinate, edge, confidence, and uncertainty heads. Its own report preserves a useful failure: loss plateaued near 0.57, reported accuracy stayed near 68–70%, coordinate alignment stayed near 0.5621, and the memory appeared unused. Those numbers do not prove that branching or memory is intrinsically harmful. They show that a twelve-path system with weak path-level observability could not identify whether representation, supervision, credit assignment, selection, or mutation caused the failure.

PortiaSynapse is the explicit replacement. It narrows the candidate path to a Scout gated MLP, a Focus block with working memory, two residual refinements, and coordinate, edge, and confidence heads over a 512-dimensional RichContext. Its most reusable contribution is the compatibility boundary: SynapseCore, trainable and chain-trainable variants, a diagnostic wrapper, and a registry permit an old route and a candidate route to coexist. Type compatibility is only the first gate, however. A replacement must also preserve input semantics, DKL snapshot identity, coordinate version, edge vocabulary, confidence meaning, latency and resource ceilings, session isolation, fallback, and downstream acceptance behavior.

The phase ladder should therefore be evidence-gated rather than percentage- gated. Coordinate prediction enters first; edge prediction, Focus/memory, confidence, and full integration enter only after held-out improvement, non-regression, and causal-use tests. Per-layer gradients, activation statistics, branch utilization, exact route outcomes, calibration, batch- composition invariance, and fallback behavior remain visible throughout. The source reports an implementation and tests, but its conflicting test counts and incomplete integration/benchmark milestones prevent the book from treating “compiles,” “finite loss,” or “stable steps” as learned routing.

52.7.12 P4/M6 held-out routing result

The completed P4/M6 campaign supplies a bounded mixed result, not chapter-core support. After a 1/4 sacrificial schema failure and a prospectively frozen 4/4 repair, one local quantized Qwen3-8B snapshot produced 32/32 admissible candidate banks over eight tracks and four ingress modes with zero retries. The full reflexive policy routed 31/32 correctly and produced 21 useful outcomes with one wrong fast path, versus LLM-first at 6/32 routes, nine useful outcomes, and eighteen wrong fast paths. The same full policy produced two unsafe outputs versus zero for LLM-first. That mixed frontier is the finding: qualification- first routing changed behavior substantially, but this implementation did not earn a safe or generally useful router claim. All seventeen control classes and fifteen historical harm regressions remain visible; the accepted disposition retains and narrows the result with no support promotion and no new chapter.

52.8 Interfaces

Each route emits a paired record set around the routing decision.

Twelve ownership interfaces surround those records:

1. Intent, Contracts, and Planning own task meaning and acceptance predicates.
2. Stable Capability Fields owns specialist identity and substitution bounds.
3. Procedural Memory owns procedure qualification; Routing only selects it.
4. Virtual Context ABI owns admissible context and memory provenance.
5. Security, Privacy, Rights, and Legal owners define eligibility constraints.
6. Runtime, Humans, and Inter-Stack owners execute; a route is not an effect lease.
7. Verification, Spinoza, Artifact Graphs, and Evidence own result support.
8. Resource Economics owns capacity, budget, protected overhead, and value policy.
9. Readiness, Replacement, and Residual Escrow owns promotion and rollback.
10. Labor OS and Human Collaboration owns worker roles, intervention, and appeal.
11. Personal Hives and MoECOT crosswalks own topology and runtime implementations.
12. Benchmark Ratchets and Claim Ledgers own floors, anti-Goodhart controls, and belief revision.

Specialist Registry Record fields:

• specialist_id
• registry_epoch
• owner
• capabilities
• authority_envelope
• authority_scope
• memory_lease_policy
• memory_refs
• tool_lease_policy
• tool_permissions
• runtime_tier
• cost_profile
• readiness_state
• quality_predicates
• fallback_routes
• residual_refs
• evidence_refs
• route_limitations
• non_claims

Routing Decision Record fields:

• decision_id
• task_id
• capability_request
• candidate_specialists
• selected_specialist
• rejected_candidates
• non_selection_evidence
• route_shape
• route_receipt
• authority_check
• granted_authority_subset
• denied_authority
• readiness_check
• context_lease
• tool_lease
• verifier_requirement
• budget
• expiry
• cost_quality_reason
• fallback_route
• residual_owner
• residuals
• ledger_refs
• non_claims

Arm Result Envelope fields:

• arm_id
• arm_version
• route_lease_ref
• scoped_result
• confidence_semantics
• evidence_refs
• provenance_refs
• required_assumptions
• residuals
• risk_flags
• suggested_successors
• verifier_requests
• resource_receipts
• effect_receipts
• non_claims

Composition Receipt fields:

• composition_id
• route_decision_ref
• arm_result_refs
• fields_used
• fields_discarded
• material_disagreements
• conflict_dispositions
• verification_refs
• provenance_preservation_check
• terminal_output_ref
• faithfulness_evaluator_ref
• residual_owner
• non_claims

Arm Residency Record fields:

• arm_id
• artifact_and_dependency_versions
• prior_residency_state
• target_residency_state
• placement_and_trust_zone
• route_lease_ref
• prefetch_reason
• warm_cache_state
• bytes_transferred
• cold_start_latency
• peak_and_active_memory
• load_unload_overhead
• availability_result
• fallback_ref
• terminal_residency_state
• cost_receipts
• non_claims

MoECOT Orchestration Record fields:

• run_id
• runtime_packet_state
• command_ref
• orchestrator_id
• route_head
• specialist_cores
• control_plane_gates
• route_authority_ledger
• ledger_refs
• readiness_gate_refs
• replay_refs
• denied_routes
• failed_gates
• missing_replay_refs
• handoff_refs
• promotion_blockers
• residuals
• source_reported_fields
• locally_reproduced_fields
• externally_corroborated_fields
• blocked_fields
• source_claim_state
• non_claims

Planning requests capabilities, not personalities. Governance bounds authority. Evidence updates readiness. Execution receives the selected specialist and the authority envelope. Artifact graphs receive the route decision so downstream claims can be traced back to the capability that produced them.

A route receipt is the routing interface artifact. It records selected specialist, rejected candidates, granted authority subset, denied authority, context lease, tool lease, readiness state, verifier requirement, budget, fallback, expiry, and residual owner.

The public schemas now make that receipt explicit. Specialist registry records carry owner, registry epoch, authority envelope, memory/tool lease policies, route limitations, and non-claims. Routing decision records carry rejected candidates, non-selection evidence, route receipt, granted and denied authority, context/tool leases, verifier requirement, budget, expiry, residual owner, and non-claims. MoECOT orchestration records add runtime-packet state, route authority ledgers, denied routes, failed gates, missing replay refs, source-reported fields, locally reproduced fields, externally corroborated fields, blocked fields, and non-claims. These fields establish neither route quality nor runtime behavior; they preserve the information future route-quality, replay, and runtime-evidence tests need.

52.9 Invariants

1. Every decision binds exact task, consumer, registry, policy, feature, evaluator, model, tool, environment, and time versions.
2. Semantic, capability, implementation, node, worker, and route identities stay distinct.
3. Every eligible and rejected route remains in the candidate denominator.
4. Granted authority is the intersection of task, principal, specialist, policy, rights, privacy, locality, readiness, and budget ceilings.
5. Eligibility gates precede scoring and fail closed on required unknown state.
6. Route relevance, route correctness, answer quality, artifact truth, effect safety, evidence adequacy, support, and release remain separate.
7. Non-answer actions are scored against coverage and useful outcomes.
8. The least capable and least authoritative adequate route wins or deviation is justified.
9. Consequential routes carry fresh leases, fallback, cancellation, evidence duty, and custody.
10. Rejections, counterfactuals, interventions, costs, and delayed outcomes stay recorded.
11. Training and threshold selection cannot inspect held-out labels or evaluator outputs.
12. Comparative policies receive matched resources, authority, help, retries, and time.
13. Multi-route policies account for correlation, collusion, aggregation, and added cost.
14. Load and failure cannot silently change authority or evaluation standards.
15. Registry, policy, model, tool, memory, evaluator, benchmark, or rights changes expire affected leases.
16. Quarantine, replacement, rollback, and retirement block new ordinary routes.
17. Replay reconstructs frozen admissible inputs and records nondeterminism.
18. Evidence language stays inside the exercised workload, policy, specialist, evaluator, model, environment, organization, threat, cost, and time envelope.
19. Arm capability, maximum authority, evidence, and task-local granted authority remain distinct records.
20. Semantic selection never implies residency, availability, placement trust, or permission to load and execute.
21. Composition preserves every material arm disagreement and cannot create evidence, confidence, authority, or consensus absent from its inputs.
22. Prefetch, warm residency, and cache state confer no route eligibility or effect authority.
23. Spawn, split, merge, replace, quarantine, and retirement preserve complete identity, dependency, memory, consumer, regression, migration, and rollback records.

The important invariant is that selection and authorization are different predicates. A specialist can be the best semantic match and still be disallowed because its authority scope, readiness state, or evidence state is inadequate for the task.

Least-capable adequate routing keeps specialist selection governed. The router should not select a stronger, broader, or more privileged specialist unless the task’s risk, context demand, verifier requirement, or fallback policy justifies it.

Specialist retirement and readiness downgrade remain routable states, so old capability does not silently stay in circulation.

Traceability across layers is the runtime invariant. A runtime route must be traceable to a command, specialist selection, authority envelope, readiness decision, ledger, replay status, and residual set. Without that trace, the runtime crosswalk is bypassing the stack instead of serving it.

52.10 Failure modes

1. Semantic-fit laundering selects relevance without authority, readiness, utility, privacy, or budget.
2. Oracle laundering uses privileged or label-leaking routes as attainable baselines.
3. Route-label leakage exposes held-out actions or outcomes during training or tuning.
4. Router overconfidence suppresses clarification, fallback, abstention, or escalation.
5. Abstention laundering counts non-answer activation as utility while answers remain wrong.
6. Fallback theater defines a route that never activates or repeats the failure.
7. Authority laundering widens tools, context, budget, duration, or delegation.
8. Readiness laundering treats branding, schemas, benchmarks, or stale evidence as deployment.
9. Candidate-denominator erasure hides rejected, unavailable, costly, human, or no-route options.
10. Cost-quality laundering hides retries, verification, labor, delay, failure, or residuals.
11. Specialist sprawl costs more to govern than routing saves.
12. Load blindness sends work to saturated specialists without recalibration.
13. Correlated-expert or collusion failure repeats shared error through debate or voting.
14. Evaluator capture shares models, prompts, code, data, or incentives across routing and judgment.
15. Routing-memory poisoning amplifies early mistakes, popularity, or adversarial records.
16. Lifecycle drift keeps compromised, replaced, quarantined, or retired specialists eligible.
17. Replay theater omits nondeterminism, denials, interventions, costs, and residuals.
18. State-of-the-art theater generalizes from synthetic route accuracy or non-answer coverage.

Wrong selection should become a residual and a benchmark candidate. Overconfidence should become a route-quality defect. Authority leak should become a governance incident. Specialist bloat should trigger split, merge, retirement, or quarantine review. Composition hallucination should be routed through verification or tribunal review rather than hidden behind a fluent final answer.

Route laundering is the specialist-core failure. A task is routed through a broad specialist because that is convenient, then the successful output is used to justify broader authority even though the route never proved that narrower specialists were inadequate.

Runtime branding is the crosswalk failure. A concrete implementation name makes the routing story feel operational before the run packet, replay references, failed gates, denied routes, and residuals have been imported. The route ledger must keep the source-reported, reproduced, corroborated, and blocked fields separate.

52.11 Minimum Viable Implementation

The minimum viable routing surface is now larger than a schema and smaller than a production router. It contains three public record schemas, three valid and seven invalid routing-lease fixtures, four valid and five invalid readiness/residual fixtures, two bounded routing programs, two accepted no-promotion or narrow transition records, and twenty-nine live Lean declarations. This surface makes route decisions inspectable and exercises several refusal paths; it does not establish useful specialist answering or safe deployment.

The specialist_registry_record schema describes a bounded specialist core. The routing_decision_record schema records the task, candidates, rejected candidates, selected route, route shape, route receipt, authority subset, denied authority, readiness check, leases, verifier requirement, budget, expiry, fallback, residual owner, residuals, and ledger references. Passing these fixtures confirms structural validity only; routing accuracy still requires measured route outcomes.

AsiStackProofs.RoutingRefinement contains an exact twenty-five-theorem surface over the authored request-to-closure transition system. Four retained legacy routes in AsiStackProofs.Routing and AsiStackProofs.MoECOTRuntime preserve selected-route and source-boundary ownership. These declarations establish facts about encoded finite records; learned-router selection quality, specialist correctness, production lease enforcement, and correct MoECOT execution or replay remain outside those facts.

The synthetic routing decision lease harness makes the first route-receipt discipline executable. It checks three valid and seven expected-invalid packets for least-capable adequate selection, rejected overprivileged specialists, selected-route authority-envelope containment, missing-readiness fallback, expired context leases, residual ownership, selected-specialist registration, rejected-candidate evidence, and MoECOT source-boundary non-claims. The accepted no-promotion record evidence_transitions/v1_x_measured/routing_decision_lease_no_change.json keeps this as synthetic fixture evidence and blocks learned-router, route-quality, deployed authority-enforcement, specialist-quality, MoECOT replay, orchestration benchmark, and chapter-core promotion claims.

The architecture-neutral refinement at AsiStackProofs.RoutingRefinement extends those record checks into a reachable request-to-closure lifecycle. It binds task, registry, complete candidate denominator, selected specialist, authority, readiness, context and tool leases, evaluator, policy, and consumer; then separates dispatch, route outcome, answer outcome, unsafe outcome, cost, revocation closure, and acknowledgment. A transformer, Mamba-family state-space model, KAN, recurrent core, graph system, memory-augmented system, or future substrate can occupy the specialist slot only through this same contract. That abstraction is not evidence that the substrates are interchangeable or equally capable: the route can be correct while the answer is wrong.

The exact theorem surface proves that every finite event list preserves all fourteen task, registry, candidate, specialist, capability, authority, readiness, lease, evaluator, policy, and consumer identity fields and cannot assign support or external effects. Rejected events preserve complete state, route and answer counters remain separately represented and balanced, event batches compose, and a closed route absorbs every suffix. The independent consumer recompiles that exact surface before exercising the bounded suites.

The folded MoECOT slice adds an orchestration fixture, finite source-boundary predicates, finite negative-case theorems, and source-only packet checks inside the route-lease harness. The new Lean negative cases reject runtime-core promotion records missing readiness, regression, or replay evidence and unavailable-text-only runtime claims that try to promote above argument. The smallest honest runtime-crosswalk fixture records one accepted command, one denied route, one missing replay reference, one residual handoff, one failed gate, and one promotion blocker. These checks cover record shape, route-lease discipline, and evidence partitioning only; they are not runtime replay, orchestration benchmarks, specialist-quality results, route-quality measurements, or deployment claims.

The 300-example post-v2 program supplies a matched three-seed comparison, but oracle, learned, rule, and fallback policies all tied on the separable held-out split. The 60-request post-v2.1 successor makes routing policies differ: the learned router selects 59/60 routes and exercises fallback, abstention, and clarification. Yet all 360 substantive candidates are wrong. Together these programs establish a reproducible local failure boundary—route discrimination can improve while answer utility stays at zero—not a successful specialist system.

52.12 Mature Research Target

Routing becomes strategic when it is a governed capability market inside the stack. It is not a bigger tool picker. It is a control boundary that can select among specialists, proof checkers, retrieval lanes, local runtime cores, human review, and fallback routes while preserving the authority, evidence, and residual obligations attached to the choice.

Routing is a governed lease, not a suggestion engine: a lightweight head selects bounded specialists only with the authority, context, tools, fallback, and residual ownership the task permits. The live registry needs registry epochs, capability cards, cost and latency profiles, readiness states, authority envelopes, memory and tool lease policies, route limitations, non-claims, retirement criteria, and fallback routes.

Route receipts record selected and rejected candidates, non-selection evidence, granted and denied authority, context leases, tool leases, verifier requirements, budget, expiry, residual owner, and route shape across single, sequential, parallel, adjudicated, verification, and failsafe routes. Planning requests capabilities, governance grants only the task-local authority subset, VCM supplies context leases, readiness gates decide routability, evidence ledgers update specialist quality, and artifact graphs preserve route provenance for downstream claims.

Wrong routes become benchmark cases, overbroad routes become least-capable-adequate regressions, repeated successful routes become procedural-memory candidates, and stale or unsafe specialists move through quarantine, split, merge, retire, or retrain states. Wrong specialist selection, router overconfidence, authority leak, specialist sprawl, composition hallucination, and route laundering are converted into denied routes, fallback routes, escalation records, quarantine decisions, or residual escrow rather than hidden degradation.

This specialist-routing surface is still a target architecture. Routing support remains argument until routing decisions, specialist leases, readiness checks, fallback paths, residual records, and contention/evaluator tests show that work is delegated to bounded capability fields rather than to whatever model looks strongest in the moment.

At maturity, the same routing surface can admit MoECOT-style runtime packets without trusting runtime branding. A compact orchestrator receives typed commands, asks the route head for bounded specialist lanes, applies control-plane gates, records authority decisions, runs or denies work, emits task and replay ledgers, and hands off artifacts with residuals and promotion blockers attached. Successful runs become replay and benchmark candidates; failed gates become readiness blockers; denied routes improve authority policy; missing replay refs block promotion; residual handoffs become work items rather than implementation lore.

The next SOTA challenge is a preregistered, naturally heterogeneous campaign, not another clean synthetic classifier. It should compare an oracle ceiling, learned and rule routers, a single strong generalist, random and cost-aware baselines, confidence cascades, selective policies, human escalation, and the full governed route. Candidate models and specialists must receive matched tools, context, authority, help, retries, and wall-clock budgets. The joint scorecard must report substantive task utility, selective risk and coverage, unsafe release, route and answer calibration, latency, monetary and compute cost, human work, verification cost, interference, load, rollback success, and unresolved residuals.

The causal design must separately ablate learned selection, specialist training, readiness gates, task-local authority, fallback, abstention, clarification, independent evaluation, routing memory, and load-aware placement. A routing benefit is credible only if it survives natural holdouts, adversarial ambiguity, multiple strong current models, multiple seeds, independently implemented evaluation, and at least one transfer setting. Expected causal signatures are explicit: removing learned selection should hurt route choice without automatically changing candidate quality; removing specialization should hurt substantive utility on bounded domains; removing authority gates should increase unsafe or overprivileged execution; and removing selective actions should increase forced wrong answers. If those signatures do not appear, the corresponding mechanism remains an argument or is narrowed or refuted.

52.13 Codex test plan

Test	Purpose	Status
Specialist registry and routing decision fixture validation	Check that the specialist registry and routing decision fixtures match their public schemas and declare capabilities, authority, memory, tools, readiness, predicates, candidates, selected route, checks, fallback, residuals, and ledgers.	implemented by protocol validation; validated locally
Specialist routing accuracy test	Check that capability requests select specialists with matching declared capabilities under synthetic tasks.	planned; not run
Post-v2 matched routing program	Compare oracle, learned, rule, generalist, fallback, and abstention policies on a frozen 300-example program over three seeds.	completed; oracle, learned, rule, and fallback tied at 162/180 on a separable split; accepted no_change
Post-v2.1 ambiguous routing program	Force learned, rule, generalist, fallback, abstention, and clarification behavior to differ on 60 held-out requests.	completed; learned route choice was 59/60, but all 360 substantive candidates were wrong; accepted narrow boundary only
Routing decision lease harness	Check synthetic route leases for least-capable adequate selection, overprivileged rejection, selected-route authority-envelope containment, missing-readiness fallback, expired-lease residualization, rejected-candidate evidence, residual ownership, and MoECOT source-boundary non-claims.	implemented by python3 scripts/validate_routing_decision_lease.py; accepted no-promotion decision at evidence_transitions/v1_x_measured/routing_decision_lease_no_change.json; no learned-router, route-quality, MoECOT replay, or deployed authority-enforcement claim
Authority/readiness route predicate	Check that a selected route satisfies authority and readiness.	implemented in AsiStackProofs.Routing; checked by Lean build
Failed-readiness fallback predicate	Check that failed readiness routes to fallback or residual rather than promotion.	implemented in AsiStackProofs.Routing; checked by Lean build
Routing decision lifecycle route	Check that modeled routing decisions route missing capability requests, missing specialist registries, authority mismatches, readiness failures, fallback/residual handling, stale leases, missing cost-quality records, overprivileged selections, missing rejected-candidate evidence, missing non-claim boundaries, and complete selections to explicit finite outcomes.	implemented in AsiStackProofs.Routing; no learned-router, route-quality, runtime enforcement, specialist-quality, MoECOT replay, or benchmark claim
Routing and replaceable-substrate lifecycle refinement	Check exact request/registry/lease custody, complete candidate denominators, label-leak rejection, ambiguity-triggered selective action, task-local dispatch, distinct route and answer outcomes, revocation closure, and absence of support/effect authority.	implemented in AsiStackProofs.RoutingRefinement and python3 scripts/validate_routing_refinement.py; three exact suites, seven stages, 42 routes, 47/47 mutations; no natural utility, strong-model transfer, deployed runtime/replay, substrate-superiority, RSI, or support claim
Authority-bounded routing test	Check that a selected route cannot exceed the gate authority scope or use a blocked route during canary/default promotion.	implemented by readiness/residual gate harness for synthetic route/gate/replacement records; deployed router enforcement not run
Fallback route test	Check that failed readiness or quarantine preserves a fallback route and residual record.	implemented by readiness/residual gate harness for synthetic canary/default and quarantine scenarios; live fallback execution not run
MoECOT orchestration fixture validation	Check that the orchestration fixture matches the public schema and declares run, command, orchestrator, route head, specialist cores, gates, ledgers, readiness refs, replay refs, handoff refs, blockers, residuals, and source-claim state.	implemented by protocol validation; validated locally
MoECOT source-ingestion gate	Check that MoECOT-specific claims cite inspected source notes or imported artifacts before promotion.	planned; not run
Runtime crosswalk completeness test	Check that a runtime record links command, route, cores, gates, ledgers, replay, handoff, and residuals.	planned; not run
Readiness/replay mapping review	Check that promotion decisions reference readiness and replay artifacts, not source branding alone.	partially implemented by readiness/residual gate harness for readiness mapping; MoECOT replay mapping not run

Fixture-shape validation, twenty-nine live family declarations across Routing, MoECOT, and the reachable refinement, the readiness/residual harness, the routing decision lease harness, the independent refinement consumer, and both bounded routing programs are implemented. Twenty-five refinement theorems and four retained legacy theorems remain live; sixteen weaker declarations are retired. The independent surface covers seven stages, 42 routes, and 47/47 rejecting mutations. The post-v2.1 program uses one synthetic six-action workload, one seed, one 4-bit 4B model (mlx-community/Qwen3-4B-4bit), and an internal deterministic evaluator. It therefore cannot discharge the remaining requirement for natural tasks, useful specialist answers, multiple strong models and seeds, independent evaluation, trained-specialist interference, production authority enforcement, runtime replay, or transfer.

52.13.1 Formalization hooks

Tag	Module	Target	Status
lean:routing.specialists.operational_invariant	AsiStackProofs.RoutingRefinement	Every finite routing lifecycle run preserves exact task, request, registry, candidate-set, selected-specialist, capability, authority, readiness, lease, evaluator, policy, and consumer custody; rejected events preserve exact state, route and answer accounting remains separate and balanced, batches compose, closure is absorbing, and support or external effects remain unassigned.	implemented
lean:routing.specialists.failure_blocks_promotion	AsiStackProofs.RoutingRefinement	Missing authority, readiness, fresh leases, selective handling, fallback or residual ownership, dispatch isolation, observed route/answer/unsafe/cost outcomes, lifecycle currentness, revocation closure, or acknowledgment blocks progress without mutating exact state.	implemented
lean:routing.specialists.decision_lifecycle_route	AsiStackProofs.RoutingRefinement	The independent consumer preserves all 42 routing outcomes, including label-leak rejection, complete candidate denominators, least-capable-adequate selection, ambiguity-triggered selective action, fallback/residual routes, and separate dispatch, observation, and closure.	implemented
lean:moecot.runtime.operational_invariant	AsiStackProofs.RoutingRefinement	A runtime-backed route cannot qualify until inspected source state, concrete runtime evidence, replay evidence, task-local dispatch authority, and isolation bind to the same lease.	implemented
lean:moecot.runtime.failure_blocks_promotion	AsiStackProofs.RoutingRefinement	Unavailable or source-only runtime material, missing replay evidence, or unobserved route and answer outcomes cannot be laundered into runtime, routing-quality, support, or deployment claims.	implemented

These proof hooks now resolve to a reachable finite lifecycle plus independent route-consumer evidence. Of the twenty-nine live family declarations, twenty-five belong to the refinement and four retained legacy routes remain load-bearing; sixteen weaker projections or fixture admissions were retired. The proofs still derive finite route or negative consequences from them. This classification prevents theorem count from standing in for breadth or empirical validity. The companion route-lease harness checks record-level selection and refusal discipline. These surfaces do not prove routing accuracy, useful specialist answers, learned-router generalization, runtime enforcement, MoECOT behavior, replay correctness, deployment readiness, or source-reported performance.

52.14 Source crosswalk

Source ID	Title	Layer	Planned use	Readiness
reflexive_router_whitepaper	The Reflexive Router	pre_deliberative_reflexive_routing_control_plane	Command-before-automatic ordering, proposal/admission separation, qualification-first selection, calibrated abstention, atomic versus DAG routing, typed fallback, and dispatch provenance.	source note available
octopus_router	Octopus Router Architecture	routing_modular_intelligence	Lightweight head/router with dynamically loaded specialist arms and local boundaries.	source note available; local raw cache available
rmi	Ratcheting Modular Intelligence	capability_ratchet	Benchmark pressure, residual escrow, verified modular capability, regression preservation.	source note available; local raw cache available
beastbrain	BeastBrain Cognitive Architecture	whole_stack_lineage	Architecture lineage. Organism paradigm, SSD-native/geometrically verified intelligence.	source note available; local raw cache available
cognitive_loop_closure	Cognitive Loop Closure	procedural_memory	Repeated cognition should become procedural memory / verified tools.	source note available; local raw cache available
rgs	Ratcheting Generative Systems	compression_capability_growth	Bridge between active compression, procedural memory, benchmark frontiers, verified AI growth.	source note available; local raw cache available
benchmaxxing	Benchmaxxing: The Performance Ratchet	benchmarks_evidence	Benchmarks as pressure surfaces, saturation to regression, harder frontier, anti-Goodhart safeguards, and runtime promotion pressure.	source note available; local raw cache available
viea	Verified Intent-to-Execution Architecture	whole_stack_execution_spine	Human intent to command contracts, artifacts, specialist routing, runtime targets, verification, feedback, and regression coverage.	source note available; local raw cache available
scf	Stable Capability Fields	governance_recursive_self_improvement	Stable boundaries, replacement, bounded authority, scoped qualifications, route validation, rollback, and lifecycle transitions.	source note available; local raw cache available
talos	Talos Protocol	labor_execution_os	Typed jobs, deterministic control planes, execution factories, adjudication, delivery evidence, audit logs, replay, tool isolation, and approval gates.	source note available; local raw cache available
moecot_md	moecot_agent_whitepaper.md	implementation_reference	Markdown export/source variant for compact orchestrator, specialist lanes, control-plane gates, readiness, replay, and truthful limits.	source note available; local raw cache available
moecot	MoECOT-Agent Architecture Whitepaper	implementation_reference	Folded runtime crosswalk: governed low-parameter multi-core runtime, readiness gates, ledgers, replay, handoff, and explicit limitations.	source note available; connector or recovery required
project_theseus_whitepaper	Project Theseus Whitepaper	report_first_rmi_prototype	Local-first report-driven RMI implementation reference: SymLiquid, SparkStream, Octopus Router, residual escrow, self-evolution gates, Hive runtime, observability.	source note available
theseus_operator_os	Hive Operator OS and Work Board	labor_os_operator_surface	Shared command vocabulary, durable SQLite work board, node registry, background/watch/wake contracts, skill registry, tool hooks, feedback routing, and safety-visible operator surface.	source note available
theseus_architecture_gate	Theseus Architecture Gate	readiness_gate_governance	Pre-training readiness gate covering ratchet completeness, router readiness, safety ledger, residual escrow, bridge benchmarks, procedural tools, routing memory, lifecycle governance, and external-inference zero.	source note available
ext_hipporag_2024	HippoRAG	associative_long_term_memory	Personalized PageRank graph navigation as a routing comparator; relevance remains separate from evidential adequacy, update correctness, and routing safety.	source note available

The routing sources support specialist selection, lifecycle state, residual-aware fallback, operator-visible control, and a runtime evidence-packet crosswalk. The folded MoECOT mappings now point to reviewed source notes and connector extracts, but they still do not claim local routing accuracy, runtime safety, replay correctness, benchmark reproduction, or MoECOT execution.

52.14.1 Manifest source assignment reconciliation

These rows keep Routing Heads and Specialist Cores’s manifest assignments visible at their recorded review boundary. Passage review does not establish local reproduction, performance, safety, deployment, or support-state movement.

Source	Intake role	Boundary
learning_compute_topology	Passage-reviewed comparator: Learning–Compute Topology: Formalizing the Causal Organization of Adaptive Systems. Corben-authored August 2026 research paper and executable preparation package that separates model architecture, learning-process topology, execution topology, and physical compute topology. It contributes adaptive-identity tests; typed evidence, judgement, credit, state, artifact, control, and authority relations; LCT-IR; Learning Causal Normal Form; seven bounded propositions; topology metrics; a semantic compiler firewall; Adaptive Branch–Validate–Integrate; toy and analytical phase diagrams; and an explicit falsification program. The bundled reference implementation passes 11 unit tests, but implements only bounded conformance behavior and does not establish neural-training benefit, causal completeness, universal canonicality, safety, scaling superiority, or ASI.	The formal propositions hold only under their stated finite, explicit-state, interface-sufficiency, information-theoretic, and cut-capacity assumptions. The executable supplement covers a bounded IR/validator/normalizer/compiler/simulator slice; the phase diagrams are toy or analytical, the ABVI topology is proposed, and the novelty matrix is a scoped comparison rather than a global novelty proof. No local implementation, reproduction, performance, safety, deployment, support-state, or ASI result is established by this reconciliation row.
deterministic_capability_compilation	Passage-reviewed Corben architecture source: Deterministic Capability Compilation: A Capability-Preserving Ladder from Executable Scaffolds to Governed Adaptive Agents. Corben-authored July 2026 architecture and research program for compiling executable scaffolds into contract-bound experts and linked Neural Capability Objects while retaining semantic obligation mass balance, candidate-specific translation validation, fallback, residual escrow, authority ceilings, reification, and effect-complete recovery. Existing chapters are upgraded first; no foundry implementation, learned-capability result, preservation result, safety result, SOTA result, AGI, ASI, or support-state promotion is inferred.	No local implementation, reproduction, performance, safety, deployment, support-state, or ASI result is established by this reconciliation row.
ext_dont_hallucinate_abstain_2024	Passage-reviewed comparator: Don’t Hallucinate, Abstain: Identifying LLM Knowledge Gaps via Multi-LLM Collaboration. Supports measuring abstention with coverage, accuracy, calibration, and useful response behavior while treating self-reflection and model agreement as fallible evidence.	The ACL models, prompts, domains, collaboration schemes, and reported gains were not reproduced; the local single-model router is not an independent multi-model panel. No local implementation, reproduction, performance, safety, deployment, support-state, or ASI result is established by this reconciliation row.
qcsa_whitepaper	Passage-reviewed comparator: Question-Compiled Semantic Addressing. Separates semantic identity and address selection from the physical expert/model route, while making fallback, abstention, load, cost, hardware, permissions, and verifier requirements explicit in the compiled route plan; the later repository adds a bounded local 12-lane implementation, 60-case held-out evaluation over 13 systems and three seeds, and one 13-stage governed vertical trace.	The exact matched-advantage and resource gates failed, and the active-question ablation is N2 proxy/regime evidence rather than an exact or broad refutation. No learned-router, trained-specialist, production, chapter-core promotion, AGI, or ASI result is established. No local implementation, reproduction, performance, safety, deployment, support-state, or ASI result is established by this reconciliation row.
relational_dimension_compiler	Passage-reviewed comparator: The Relational Dimension Compiler: Adaptive Polyadic Cognition with Bounded Computational Arity and Unbounded Semantic Structure. Extends routing to candidate topology, relational order, operator family, factorization, precision, scale, branch resolution, verification effort, and stopping or abstention under a complete proposal-through-repair cost ledger.	No learned order router, proposal-recall result, regret bound, useful polyadic route, or natural-task routing advantage is demonstrated. No local implementation, reproduction, performance, safety, deployment, support-state, or ASI result is established by this reconciliation row.
ext_kimi_k3_2026	Metadata-first comparator: Kimi K3: Open Frontier Intelligence. Primary technical report and official architecture summary for KDA/Gated-MLA hybrid attention, Attention Residuals, Stable LatentMoE, Quantile Balancing, SiTU-GLU, and Per-Head Muon. The approximately 2.5x scaling-efficiency result is provider-reported for the integrated 2.8T system and does not identify a transferable component effect.	No passage-level source claim, local implementation, reproduction, safety, performance, deployment, support-state, or ASI result is established by this reconciliation row.
portia_synapse	Passage-reviewed comparator: PortiaSynapse: A Cognitive Spider Architecture for DKL Navigation. TreeLLM successor architecture for a replacement-compatible Scout, Focus, refinement, coordinate, edge, and confidence route with phased training, diagnostics, stable traits, registry selection, and fallback.	Conflicting source test counts, incomplete integration and comparative benchmarking, possible batch-coupled attention, mutable-memory isolation, and weak exact task metrics remain unresolved; no local route learning is established. No local implementation, reproduction, performance, safety, deployment, support-state, or ASI result is established by this reconciliation row.
spider_synapse	Passage-reviewed comparator: SpiderSynapse: A Multi-Hypothesis Reasoning Architecture. Failed predecessor case for multi-hypothesis routing, repeated refinement, mutable working memory, selection, typed output heads, path diagnostics, and one-path recovery.	Its reported plateau does not identify branching, refinement, memory, selector credit, label smoothing, or supervision geometry as the cause and has not been locally reproduced. No local implementation, reproduction, performance, safety, deployment, support-state, or ASI result is established by this reconciliation row.
coilmoecot	Passage-reviewed comparator: CoilMoECOT Whitepaper v2.0. Full composite connector text section-audited. Retains prime-temporal trace features, Graph/Trace-first placement, ledger-derived diagnostic tuples, removable shadow lanes, explicit pre-planner/post-plan/post-run insertion points, anti-experts as visible penalty signals, bounded update slices, and benchmark/canary/rollback promotion. Repeated MoECOT, packaging, and task-system appendices are treated as shared substrate rather than independent evidence.	Design and implementation specification only; no local route, ablation, benchmark, canary, rollback, model-quality, safety, latency, or cost result. No local implementation, reproduction, performance, safety, deployment, support-state, or ASI result is established by this reconciliation row.

52.15 Post-v2 matched routing result

The frozen 300-example routing/deliberation program trained a multinomial router only on the 180-example training split and evaluated 60 held-out tasks at three seeds. Across 180 seeded decisions, oracle, learned, rule, and fallback/abstention routes each produced 162 correct answers; the single general specialist produced 130. Every route used the registered two-operation budget, and wrong-specialist counterfactuals were retained.

The equality among oracle, learned, and rule routing is a limitation, not a victory: request features made this corpus too separable, and fallback and abstention activated zero times. The experiment therefore does not establish fallback calibration, model-scale routing, trained-specialist interference, or production transfer. routing-heads-and-specialist-cores.core remains argument through an independent no_change disposition.

52.16 Post-v2.1 ambiguous routing result

The successor workload deliberately includes ten held-out requests for each of six actions. The learned router selects 59/60 correct routes, the oracle 60/60, the rule route 41/60, and the generalist 10/60; fallback, abstention, and clarification all activate. This resolves the earlier “indistinguishable policies” defect only within the frozen finite set. All 360 generated substantive candidates are wrong, so the learned policy’s 20 correct outcomes come entirely from correct fallback/abstention/clarification behavior. The routing disposition is narrow: route discrimination and selective non-answer coverage are established locally, while specialist answer utility, interference, calibration, and transfer are not.

This result came from one synthetic six-action workload, one seed, the mlx-community/Qwen3-4B-4bit model, and an internal deterministic criterion evaluator. The test run took 2,156.55 wall-clock seconds. The accepted transition is evidence_transitions/post_v2_1/ambiguous_routing_narrow.json; it blocks core promotion until substantive answer utility, independent evaluator validity, multiple models and seeds, natural workloads, and production safety, latency, cost, and transfer have been measured.

Source	Title	Use and boundary
ext_dont_hallucinate_abstain_2024	Don’t Hallucinate, Abstain	Comparator for selective prediction and abstention; it motivates measuring coverage with utility rather than treating abstention activation as sufficient.

52.17 Summary

Routing makes modular intelligence governable only when it is recorded as a bounded decision. The head selects; the specialist acts within a local envelope; evidence updates readiness; residuals become future pressure. The folded MoECOT material adds the runtime packet shape that a concrete orchestrator would need to emit. The sources, fixtures, finite Lean predicates, readiness/residual harness, and route-lease harness define and exercise parts of that decision surface; they do not establish production runtime behavior.

The bounded empirical record goes one step further but exposes a harder failure. A learned router distinguished 59/60 routes in the ambiguous local workload and used selective non-answer actions, while every substantive candidate answer was wrong. The project therefore has local evidence for route discrimination and non-answer coverage, not for useful specialist intelligence. The next proof burden is joint: improve substantive task utility under matched resources while preserving calibration, least authority, fallback, latency, cost, replay, and residual honesty on natural and adversarial holdouts.

The router therefore becomes a control surface for capability, authority, memory, cost, fallback, and lifecycle rather than a clever dispatcher. The readiness gate is what the router must respect: a capability can be semantically appropriate and still not ready for ordinary use.

The handoff is strict: the router may propose a route, but readiness determines whether that route is ordinary, canary, diagnostic, quarantined, or residual.

A route should explain why this specialist, under this authority, now. If that answer cannot be reconstructed, the router is not yet a governable control surface.

52.18 Evidence reconciliation (2026-07-16)

The invariant protocol, field meanings, and inference limits are stated once in Living Book Methodology. This packet contains only the chapter-specific projection; its authoritative per-atom rows are the routing-heads-and-specialist-cores slice of experiments/claim_family_terminal_coverage/results/result.json.

The core remains blocked after full attempt at argument support. The strongest family attempt was Ambiguous routing and deliberation confirmatory campaign. Its exact boundary is: Mixed bounded routing effect with unsafe outputs and no support promotion; no general router, deliberation, or transfer claim. Across 76 atoms, the terminal ledger records 76 blocked_after_full_attempt.

Chapter-specific field	Value
Family / atom denominator	CF-05 / 76 atoms
Terminal dispositions	76 blocked_after_full_attempt
Core	routing-heads-and-specialist-cores.core: blocked_after_full_attempt at argument
Core attempted / missing lanes	causal, empirical, executable, formal, source-synthesis / normative, transfer
Attempted local lanes	causal, empirical, executable, formal, source-synthesis
Missing or unproved lanes	normative, transfer
Strongest family bundle	Ambiguous routing and deliberation confirmatory campaign (natural_work): A 32-task held-out real-model workload across eight tracks, four ingress modes, eight routing arms, and four stopping arms.
Negative controls	17 active control mutations; five disposition mutations; 15 preserved extra-compute harms; wrong-fast-path and unsafe-release accounting.
Accepted transitions	none
Maximum inference	Mixed bounded routing effect with unsafe outputs and no support promotion; no general router, deliberation, or transfer claim.
Reproduction / next burden	Replay scripts/validate_p4_m6_routing_deliberation.py and scripts/validate_claim_family_terminal_program.py; fill the named atom-specific lanes under a new prospective protocol.

52.19 Handoff

Routing records why a specialist was selected, but selection is not qualification. Replaceable Cognitive Substrates: Beyond Transformer Monoculture asks what the router may point at when the learned engine is no longer assumed to be a Transformer. It defines the substrate-neutral proposal, state, evidence, cost, fallback, and lifecycle boundary that lets different computational affordances compete without inheriting effect authority.