PaperlayerView exact revision on arXiv

Source-linked AI summary

Task- and Session-Level Model Routing: A Common-Interface Hybrid Evaluation of Four Open-Source Routers Across Four Benchmarks

Kiran N. Kumar, Santhosh K. Saminathan

arXiv:2608.14641v1cs.AI

TL;DR

Open-source routers are difficult to compare because evaluations use different tasks, candidate pools, and execution protocols. This paper applies a common hybrid protocol across four benchmarks and finds that observed gains track selected-tier composition more closely than demonstrated task-specific targeting.

  • Problem

    Open-source routers lack directly comparable evidence because evaluations use heterogeneous tasks, candidate pools, and execution protocols across domains.

  • Method

    The study evaluates four router implementations through a common interface and hybrid protocol across RouterBench, BFCL v4, tau2-bench, and WebArena.

  • Results

    Always-Mid matches Aurelio exactly on three benchmarks and within 0.003 on the fourth, while no benchmark shows vLLM task-specific superiority over a share-matched content-blind allocation.

  • Takeaways & Limitations

    Under the evaluated configurations, fixed-tier controls and selected-tier distributions are necessary because observed gains track tier composition more closely than demonstrated task-specific targeting.

  • Takeaways & Limitations

    Findings are conditional on one three-model candidate pool and frozen task samples, so the observed ordering may not generalize to other pools.

Abstract

from arXiv · show

Agentic systems increasingly delegate model selection to a router, yet open-source routers are usually evaluated with different tasks, candidate pools, and execution protocols, limiting direct comparison. We present a common measurement protocol and hybrid evaluation of four router implementations across RouterBench, BFCL v4, tau2-bench, and WebArena. We evaluate 290 frozen tasks against a locked matrix of 2,610 candidate outcomes. Three routers emit constant or near-constant tier assignments; only vLLM Semantic Router varies materially with prompt content, and it has the highest observed success rate on none of the four benchmarks. Always-Mid matches Aurelio exactly on three benchmarks and within 0.003 on the fourth. For vLLM, task-level superiority tests detect no task-specific advantage over a share-matched content-blind allocation; equivalence is established only on WebArena at the protocol-declared five-percentage-point margin. The results show that, under these configurations and controls, observed gains track selected-tier composition more closely than demonstrated task-specific targeting. Fixed-tier baselines and selected-tier distributions are therefore necessary controls in router evaluation; the findings are scoped to these configurations, candidate pool, and frozen benchmark samples, not to routing paradigms in general.

1 Introduction

Open-source routers are difficult to compare because prior evaluations use heterogeneous tasks, candidate pools, metrics, and execution protocols. This paper introduces a common evaluation framework and reports that, under its tested configurations, fixed-tier composition explains observed success more closely than task-specific routing.

  • Motivation: Heterogeneous tasks, candidate pools, metrics, and execution protocols limit direct comparison among open-source routers.This complicates router selection at a specified quality, cost, latency, reliability, or domain operating point.
  • Framework: The evaluation combines a common router interface, a benchmark suite spanning single-turn QA through long-horizon agentic tasks, and a protocol addressing rank aggregation and task attribution.The paper also provides an adapter interface and EvaluationHarness for evaluating router–benchmark pairs.
  • Evaluation: Four open-source routers are evaluated against RouterBench, BFCL v4, tau2-bench, and WebArena through replayed and live executions sharing one harness, metrics protocol, and plotting pipeline.RouterBench replays logged outcomes; the other three benchmarks execute live model calls.
  • Main result: Always-Mid matches Aurelio Semantic Router exactly on RouterBench, BFCL, and WebArena, trailing it by 0.003 on tau2-bench.This result is reported under the evaluated candidate pool, adapters, defaults, and frozen task samples.
  • Interpretation: Three of four routers are constant or near-constant on the evaluated pool, making raw-success comparisons largely comparisons between fixed tiers.vLLM Semantic Router is the exception whose assignment varies materially; its tests do not detect a benefit from which task receives which tier beyond the mixture itself.
  • Cross-benchmark analysis: Relative rank inverts between benchmarks, while all four routers have identical rank variance: 0.00 pooled and 0.75 strict.Mean rank remains the only separating axis in this suite, and its lead strength depends on grouping.

2 Related Work

Prior routing work spans query-level selection, production gateways, semantic or intent routing, self-evolving methods, and benchmark-specific evaluation. This paper positions its contribution as a common-interface comparison of four existing routers across one replay benchmark and three live execution benchmarks.

  • Research landscape: Prior routing work covers several partly overlapping lines, each addressing different parts of the problem and typically evaluated on different benchmarks.The paper groups related work accordingly.
  • Routing paradigms: RouteLLM represents query-level binary weak/strong selection, while LiteLLM Router represents production-gateway routing with load balancing, budgets, and fallbacks.RouteLLM is the only trained preference model among the four evaluated routers; LiteLLM emphasizes infrastructure functions.
  • Routing paradigms: vLLM Semantic Router and Aurelio Semantic Router route before generation by embedding similarity to signals or intents, unlike LLM-Blender’s post-hoc output ensembling.The shortlist deliberately separates routing before execution from output selection after generation.
  • Routing paradigms: EvoRoute refines routing policies inside long-horizon agent trajectories, whereas this paper contributes infrastructure and evaluation through a common interface over existing third-party routers.The evaluation spans one replay benchmark and three live execution benchmarks.
  • Evaluation benchmarks: RouterBench provides over 405,000 offline model outcomes, while BFCL, tau2-bench, and WebArena test tool-call correctness, multi-turn policy-constrained agents, and cascading web-navigation behavior.These benchmarks cover routing beyond single-turn offline records, including tool use and long-horizon agent behavior.
  • Evaluation gap: Unlike prior unified comparisons using precomputed single-turn records, this study evaluates RouteLLM, LiteLLM Router, vLLM Semantic Router, and Aurelio Semantic Router under a common interface across replay and live benchmarks.LLMRouterBench is cited as an earlier unified comparison that found routers did not reliably beat simple baselines.

3 Formal Evaluation Framework

This section formalizes router evaluation around task-level decisions, benchmark-specific success and cost, Pareto dominance, and cross-benchmark rank consistency. It shows that inverted benchmark rankings cannot be preserved by a single benchmark-independent scalar and illustrates the constraint with observed Aurelio–LiteLLM results.

  • Benchmark dependence: Once benchmark-specific rankings invert, no benchmark-independent total order or scalar can preserve both rankings without declaring traffic weighting or deployment utility.This aggregation constraint is distinct from the separate requirement to attribute differences at the task level.
  • Formal objects: A task includes its input, tool-call requirement, and finite candidate pool, while a router returns a selected candidate with confidence, fallback, and metadata.Each candidate has task-dependent quality, per-invocation dollar cost, and latency; difficulty descriptors are analysis-only.
  • Operating points: An operating point records mean success rate s(R, B) and mean cost per task c(R, B), computed from benchmark-specific scoring of router decisions.Zero logged cost is admissible for replayed RouterBench cells and can indicate a transport failure.
  • Pareto analysis: A router Pareto-dominates another when it is no more costly and no less successful, with at least one strict improvement; frontier membership excludes dominated routers.The unique cost minimizer and unique success maximizer must each lie on the corresponding frontier.
  • Observed reversal: 0.683 > 0.300 on RouterBench, while 0.811 < 0.833 on BFCL, yielding an observed success-rate reversal between Aurelio Semantic Router and LiteLLM Router.The BFCL difference is Aurelio minus LiteLLM −0.022, [−0.133, 0.100], p = 1.000.
  • Cross-benchmark consistency: Cross-benchmark consistency combines mean rank with rank variance, so low mean rank and low variance identify routers that are both strong and consistent.Mean rank alone cannot distinguish consistently good routers from systems that excel on some evaluated benchmarks and perform poorly on others.

4 Implementation and Reported Metrics

The evaluation uses a common adapter interface and harness to run every router–benchmark pair under deterministic seeding. It reports deployment-focused task metrics plus cross-benchmark Pareto and rank analyses.

  • Adapters: Each router exposes a single route call returning a candidate, confidence, fallback flag, and metadata.Benchmarks expose generate tasks(), producing fixed Task objects with domain, difficulty, tool-call requirement, and candidate information.
  • Harness: The harness evaluates every router–benchmark pair across configurable trials with deterministic per-(router, benchmark, trial) seeding.Its tidy output contains one row per router, benchmark, task, and trial, while new adapters require no harness, metric, or plotting changes.
  • Metrics: The deployment-focused suite includes success rate, cost per task, cost per successful task, latency, fallback rate, and route stability.The metrics are linked to deployment decisions, with cost per task and cost per successful task reported separately because they answer different questions.
  • Cross-benchmark analysis: Cross-benchmark analysis adds the Pareto frontier, mean rank, and rank variance to show how router standing changes across task domains.Mean rank and rank variance capture movement that a single-benchmark leaderboard cannot report.

5 Methodology

The study compares four routers across four benchmarks using frozen task samples and a shared candidate-outcome matrix, replaying live routing decisions against saved outcomes. Its methodology fixes task-level/session-level routing, defines paired per-task success as the primary estimand, and limits inference to the selected tasks, candidate pool, adapters, and configurations.

  • Study design: Four routers are evaluated on RouterBench, BFCL v4, tau2-bench, and WebArena under three routing paradigms.The routers are RouteLLM, LiteLLM Router, vLLM Semantic Router, and Aurelio Semantic Router.
  • Task selection: 290 tasks are sampled without stratification: RouterBench and BFCL use unstratified random samples, while tau2-bench and WebArena use deterministic convenience prefixes.The deterministic prefixes do not support design-based generalization to broader benchmark populations.
  • Task selection: 30 BFCL, 60 RouterBench, 100 tau2-bench, and 100 WebArena tasks were set in advance by API cost constraints rather than power calculations.These sample sizes limit the statistical resolution of pairwise comparisons.
  • Outcome matrix: 2,610 candidate-outcome rows cover 290 tasks × 3 candidates × 3 replicates, with no missing cells, cache-served results, or execution failures.The protocol retains failures as graded outcomes rather than dropping affected tasks.
  • Routing granularity: Every benchmark routes at the task or session level, never per turn or per step within a task.WebArena selects one model before the full multi-step trajectory, while tau2-bench selects one --agent-llm for the entire multi-turn session.
  • Estimand and inference: The primary estimand is the mean paired per-task success difference over frozen benchmark tasks, estimated from three outcome replicates and two routing trials.Inference is conditional on the selected tasks, candidate pool, adapters, configurations, and execution settings.

6 Results … 6.4 Baselines, Empirical One-Call Ceiling, and Cascades

Across four benchmarks, router outcomes largely follow candidate-tier success and selected-tier composition rather than demonstrated task-specific targeting. Fixed-tier controls and cascade accounting show that raw success parity does not establish routing value, while oracle gains require extra calls and are not directly comparable to one-call routers.

  • 6 Results: Mid-general outperforms cheap-small on RouterBench, WebArena, and tau2-bench, while BFCL v4 reverses the ordering; mid-to-strong gains are smaller or negative.The mid-to-strong increment is 0.117 versus 0.283 on RouterBench, zero on WebArena, and slightly negative on tau2-bench.
  • 6.1 RouterBench and BFCL v4: 0.683 is Aurelio’s RouterBench success with mid-general selected on every route; cheap-only LiteLLM and RouteLLM reach 0.300, while vLLM reaches 0.400.vLLM selects 81.7% cheap, 1.7% mid, and 16.7% strong.
  • 6.1 RouterBench and BFCL v4: 0.833 is BFCL v4’s cheap-small success, matched by cheap-only LiteLLM and RouteLLM; Aurelio reaches 0.811 and vLLM 0.772.No pair of routers differs significantly on BFCL after averaging trials and replicates within tasks.
  • 6.2 tau2-bench: 0.813 is Aurelio’s tau2-bench success with mid-general selected on 97.0% of routes, versus 0.730 for vLLM and 0.543 for cheap-small.Aurelio exceeds LiteLLM and RouteLLM by 0.270 [0.180, 0.360], p < 0.01, and exceeds vLLM by 0.083 [0.017, 0.153], p = 0.028 after correction.
  • 6.3 WebArena: 0.220 is WebArena success for mid-general, strong-frontier, and Aurelio’s all-mid policy, exceeding cheap-only LiteLLM and RouteLLM at 0.110.WebArena has the lowest observed success rates under this candidate pool; Aurelio matches Always-Strongest.
  • 6.4 Baselines, Empirical One-Call Ceiling, and Cascades: Fixed-tier policies closely match routers on raw success, so raw-success parity alone does not determine whether routing provides value.Potential value may instead come from matching strong-tier quality at lower cost or holding quality while reducing spend.
  • 6.4 Baselines, Empirical One-Call Ceiling, and Cascades: 0.917/0.878/0.927/0.290 is the idealized cheap→mid→strong cascade’s success across the four benchmarks, but it is an oracle upper bound rather than a deployable baseline.The transport-failure cascade never fired because every call returned, so it remained cheap and did not improve on fixed tiers.
  • 6.4 Baselines, Empirical One-Call Ceiling, and Cascades: 1.3 to 2.6 model calls per task are required on average by the idealized cascade, with success-per-dollar falling from roughly 900 on RouterBench to about 1.6 on WebArena.Because cascades may use several calls and ground-truth success as a trigger, their success is not comparable to a one-call router’s.

6.5 Why Pareto Optimality Alone Does Not Suffice · 6.6 Selected-Candidate Distribution

Pareto-frontier membership alone can conceal meaningful differences in success, cost, and deployment-relevant comparisons with fixed-tier policies. Selected-tier distributions and share-matched tests show that routing variability did not produce a statistically resolved task-specific advantage in these evaluations.

  • 6.5 Why Pareto Optimality Alone Does Not Suffice: 1.000 frontier probability makes LiteLLM nondominated on all four benchmarks, despite RouterBench success 0.300 and WebArena success 0.110 being worst or tied-worst.Pareto membership does not indicate why a policy qualifies or how far a non-member missed.
  • 6.5 Why Pareto Optimality Alone Does Not Suffice: 1.000 cost-floor nondominance for Always-Cheapest ties LiteLLM under both cost bases on every benchmark, so LiteLLM’s guaranteed seat is not unique.A fixed declaration can match the unique cost minimizer.
  • 6.5 Why Pareto Optimality Alone Does Not Suffice: 0.000 fee-basis nondominance makes Aurelio dominated on RouterBench, BFCL, and WebArena, whereas candidate-only nondominance is 1.000, 0.977, and 0.918 respectively.On those benchmarks, Aurelio and Always-Mid have identical success and candidate spend; the $0.01 router charge determines the fee-basis result.
  • 6.5 Why Pareto Optimality Alone Does Not Suffice: Table 7 is scenario analysis rather than a definitive fairness result because the nominal fee is configurable, infrastructure cost was unrecorded, and fixed policies also incur gateway overhead.The reported comparison therefore depends on candidate + service fee versus candidate spend only.
  • 6.5 Why Pareto Optimality Alone Does Not Suffice: 0.003 is Aurelio’s candidate-cost-only tau2-bench success advantage over Always-Mid, but it is equivalent within the protocol-declared ±0.05 margin.This is the only evaluated case of dominating a single fixed policy under candidate-cost-only accounting.
  • 6.6 Selected-Candidate Distribution: 100% cheap-small selection by LiteLLM and RouteLLM shows that benchmark rankings closely track each router’s traffic split across the three tiers.LiteLLM has confidence 1.0 and fallback rate 0; RouteLLM’s confidence is 0.78–0.78 despite never crossing its own threshold.
  • 6.6 Selected-Candidate Distribution: +0.010, +0.019, +0.003, and −0.052 are vLLM’s effects on RouterBench, tau2-bench, WebArena, and BFCL, with Holm-adjusted p values 1.000, 1.000, 1.000, and 0.472.The share-matched content-blind reference holds each benchmark’s tier mixture fixed and permutes task-level tier assignments over 10,000 draws; no benchmark shows an advantage.

6.7 Cross-Benchmark Consistency · 6.8 Expected Success Under Benchmark Traffic Mixtures · 6.9 A Cost- and Latency-Aware Utility

Across benchmarks, Aurelio remains the leading router under alternative aggregation and all tested success-rate mixtures, but utility rankings change with costs, latency, fees, benchmark sets, and success valuation. Fixed-tier policies can outperform routers in utility, so conclusions are configuration- and accounting-dependent.

  • 6.7 Cross-Benchmark Consistency: Aurelio remains the leading router under both three-suite and four-suite aggregation schemes, although aggregation changes the strength and variance of its lead.The grouping changes the strength of Aurelio’s lead and the variance attributed to it, not the identity of the leading router.
  • 6.8 Expected Success Under Benchmark Traffic Mixtures: 0.683, 0.748, 0.632, 0.385, and 0.696 are Aurelio Semantic Router’s success rates across the five named benchmark traffic mixtures, leading every mixture.These are reweighted existing per-benchmark success rates; no new experiments are run.
  • 6.8 Expected Success Under Benchmark Traffic Mixtures: 0.300 is LiteLLM Router and RouteLLM’s RouterBench success rate, holding them below every router-only success mixture; vLLM sits between.Aurelio wins every router-only success mixture while making almost no content-dependent decisions.
  • 6.9 A Cost- and Latency-Aware Utility: $0.51 is the success-value crossover above which Aurelio’s higher success rate repays its cost premium and leads among routers; below it, LiteLLM leads.This ranking is weighting-dependent and differs from success-only mixture rankings.
  • 6.9 A Cost- and Latency-Aware Utility: Always-Cheapest, Always-Mid from $0.46, and Always-Strongest from $3.29 form the utility envelope among all seven policies in the fee-charged four-benchmark scenario.Aurelio never leads among all seven policies in this canonical scenario.
  • 6.9 A Cost- and Latency-Aware Utility: $0.96 is the first crossover after dropping the zero-latency replay benchmark; in the live-only latency-priced column, Always-Cheapest leads +0.458 against Always-Mid’s +0.428.The benchmark set changes the utility conclusion because RouterBench is where the cheap tier performs worst.

6.10 Deployment Metric Suite

The deployment suite extends evaluation beyond success and cost, using locked routes and macro-averaging across four benchmarks. Aurelio’s selection is predominantly fallback-based despite perfect stability, while LiteLLM Router and RouteLLM match across reported reliability metrics.

  • Deployment metric suite: Deployment metrics are macro-averaged across four benchmarks from the same locked routes and include tool-call accuracy, fallback rate, route stability, confidence, difficulty-band success, and robustness.Tool accuracy covers BFCL v4 and tau2-bench; stability measures cross-seed tier-selection agreement, and robustness is replicate success standard deviation.
  • Deployment metric suite: 0.91 fallback rate and 0.03 mean reported confidence make Aurelio Semantic Router’s selection predominantly fallback-based, despite 1.00 stability.This interpretation follows the adapter’s fallback rule.
  • Deployment metric suite: LiteLLM Router and RouteLLM are identical on every reported reliability column: 0.00 fallback, 1.00 stability, and matching difficulty-band and robustness values.They differ only in the remainder of the reported comparison, which is truncated in the supplied passage.

7 Discussion

Across the evaluated configurations, routing outcomes largely track fixed or near-fixed tier selection rather than demonstrated task-specific targeting. Threshold sweeps can create variable assignments, but the observed quality gains come from relocating to another fixed tier, while substantial reassignment leaves quality benefits unresolved.

  • Observed routing behavior: Three routers are constant or near-constant tier selectors, while vLLM is the only configuration varying substantially with prompt content and leads none of the four benchmarks.LiteLLM and RouteLLM select the cheap tier on every task; Aurelio selects mid-general on all but a handful of routes through its fallback default.
  • Observed routing behavior: No benchmark shows vLLM’s content-dependent variation outperforming a share-matched content-blind allocation; WebArena equivalence holds at the protocol-declared five-percentage-point margin.The strength of the negative differs by benchmark.
  • Fixed-tier baselines: Always-Strongest beats every router on RouterBench, Always-Cheapest leads BFCL, and Aurelio’s tau2-bench edge over Always-Mid is only 0.003.The margin over Always-Strongest is 0.016 and remains unresolved; the transport-failure cascade is identical to Always-Cheapest.
  • Fixed-tier baselines: +0.003 is Aurelio’s tau2-bench difference versus Always-Mid, with hierarchical paired 90% interval [0.000, 0.010], Holm-adjusted TOST p < 0.001, and only one differing task out of 100.The difference is bounded within five success-rate points and is attributable to a single task.
  • Threshold reconfiguration: RouteLLM’s RouterBench sweep is bimodal: 0.300 at thresholds at or above 0.30 and 0.800 at thresholds at or below 0.20, with all 60 tasks flipping together and no intermediate operating point.This is exactly Always-Cheapest or exactly Always-Strongest; mid-general is selected at no threshold.
  • Threshold reconfiguration: Aurelio’s BFCL sweep changes the tier for 5, 18, and 19 of 30 tasks, including a 0.40/0.37/0.23 three-way split, but the graded quality benefit remains unresolved.The sweep’s one large resolved gain comes from relocating to a different fixed tier, while the substantial per-task reassignment does not establish reliable quality improvement.

8 Conclusion

The evaluation finds no universally best router: fixed-tier controls distinguish peak success, cross-benchmark consistency, and task-specific targeting. These measurement results are limited to the evaluated configurations, candidate pool, adapters, frozen samples, and replay conditions.

  • Main conclusion: No universally best router emerges; peak success, cross-benchmark consistency, and task-specific targeting are distinct evaluation questions.Fixed-tier controls expose these differences under the common-interface hybrid protocol.
  • Main conclusion: Always-Mid matches Aurelio exactly on three benchmarks and within 0.003 on the fourth.This comparison holds under the evaluated configurations, candidate pool, adapters, and frozen samples.
  • Limitations: The findings are a measurement result, not a verdict on routing paradigms.The stated scope excludes broader claims beyond the evaluated setup.
  • Limitations: External validity is limited by 30 BFCL tasks, deterministic tau2-bench and WebArena prefixes, one three-model pool, defaults, adapter settings, threshold calibration, and replay conditions.The replay omits prompt transformations, post-generation fallback, provider-load effects, and route-conditioned trajectories.

Data and Code Availability

The evaluation materials are publicly available through the project repository, while raw provider outputs remain subject to applicable licensing and usage restrictions.

  • Data and Code Availability: The repository provides the evaluation harness, frozen task identifiers, router configurations, aggregate candidate outcomes, analysis protocol, checksums, and reproduction scripts.Raw provider outputs are distributed subject to applicable licensing and usage restrictions.

A Reproducibility

The appendix establishes reproducibility through a locked artifact, named frozen lineages, checksummed files, and a canonical regeneration entry point. It also documents execution environments, costs, and full-rebuild evidence.

  • Artifact and lineage: Every reported number is reproducible from a named frozen lineage, with the canonical four-benchmark bundle regenerating the main tables and auxiliary results using separate manifested lineages.A single canonical reproduce entry point regenerates the analysis tab.
  • Artifact and lineage: The canonical bundle is paper1 canonical webarena repair v2, protocol paper1-rebuildwebarena-repair-v2, created 2026-07-23T22:57:37Z, with SHA-256 checksums for all eight files.candidate outcomes.csv and routes.csv carry every reported outcome; checksums.sha256 verifies copies.
  • Execution accounting: $363.27355342 total observed spend comprises $299.04753042 candidate-generation, $40.60000000 router-service, and $23.62602300 external metered spend.Infrastructure cost was not recorded; all external metered spend was tau2-bench user-simulator model spend charged per selected cell.
  • Execution environment: Table 24 pins the canonical run’s software versions, while WebArena uses a separate vendored environment with openai==0.27.0 and transformers==4.33.2.The WebArena browser build was the binding constraint repaired before the run.
  • Rebuild validation: The subsequent appendix reports full-rebuild evidence from the locked bundle, including execution matrices, baselines, paired effects, uncertainty, route equivalence, and the artifact manifest.Reported outputs include rank and Pareto uncertainty alongside route-equivalence results.

A.1 Router Configurations

The canonical run uses each router’s package defaults, specified adapters, and a common three-tier pool. RouteLLM applies its default sw ranking win-rate predictor and 0.50 escalation threshold to choose between cheap-small and strong-frontier.

  • Canonical setup: Each router uses package defaults wired through specified adapters against the common three-tier pool.These settings define the canonical full-rebuild configuration.
  • RouteLLM: RouteLLM evaluates the task prompt with the sw ranking win-rate predictor and escalates at the package-default threshold of 0.50.The route goes to strong-frontier when the predicted strong win-rate meets that threshold.
  • RouteLLM: The RouteLLM pool exposes cheap-small and strong-frontier as its weak and strong endpoints.These are the two endpoints used by RouteLLM’s routing decision.
  • Aurelio Semantic Router: Aurelio Semantic Router uses semantic-router with the text-embedding-3-small encoder.The passage identifies this encoder as part of Aurelio’s canonical configuration.

B Canonical Full-Rebuild Evidence

This appendix reports evidence generated from the locked full-rebuild bundle and canonical analysis outputs. It appears only in builds that have completed canonical validation.

  • The appendix is generated from the locked full-rebuild bundle.
  • Its evidence uses canonical analysis outputs.
  • The appendix is absent from builds without completed canonical validation.
Loading 2608.14641v1…