Technical Summary: Model Routing as a Trust Problem

1. Problem Statement

Modern AI services increasingly rely on adaptive routing systems that dynamically select model versions, service tiers, tool integrations (e.g., web search, file retrieval), regional endpoints, and fallback mechanisms before generating a response. While these routing decisions optimize for cost, latency, and availability, they create a "black box" regarding the actual conditions under which a specific answer was produced.

The core problem is the lack of a portable, per-request record of the runtime path. Current audit logs typically capture the prompt, response, and token counts, but often fail to record critical routing facts such as:

• Whether a moving alias resolved to a different model version than expected.
• Whether a priority service tier was downgraded to standard due to capacity constraints.
• Whether a fallback model was used after a primary provider failure.
• Whether specific tools were invoked or if safety interventions occurred.

Without a compact record of these "material facts," users and developers cannot distinguish between a model hallucination and a routing artifact (e.g., a stale model version or a fallback to a less capable model). This ambiguity undermines trust, reproducibility, and accountability, particularly in high-stakes domains like legal or medical summarization.

2. Methodology

The paper employs a conceptual framework and documentation-based survey rather than live empirical measurement.

• Conceptual Definition: The author defines the "route receipt" as a minimal, compact record of the serving conditions for a single AI request. It is distinct from "model cards" (which document design-time training artifacts) by focusing on runtime execution.
• Schema Design: A minimal schema (v0.1) is proposed, including required fields (e.g., schema_version, receipt_id, served_at, fallback, safety, redactions) and optional fields (e.g., requested_model vs. resolved_model, service_tier, tools, context).
• Redaction Model: The paper proposes a tiered disclosure model where the same receipt object can be viewed by different stakeholders (end users, developers, administrators, auditors) with specific fields redacted or generalized to protect proprietary logic, safety thresholds, and infrastructure topology.
• Survey: The author surveyed public documentation from major AI platforms (OpenAI, Anthropic, AWS Bedrock, Google Vertex AI/Gemini, Microsoft Foundry, OpenRouter, vLLM, SGLang) as of April 29, 2026. The survey categorizes existing "receipt fragments" (e.g., service tier fields, tool traces) and identifies gaps where a unified, portable per-answer record is missing.
• Case Study: A fictional scenario ("Northstar," a legal-tech company) is used to illustrate how the absence of a route receipt leads to "guesswork" during incident investigation, whereas the presence of a receipt allows for rapid narrowing of the root cause (e.g., identifying a model version drift or a tool retrieval failure).

3. Key Contributions

• The Route Receipt Concept: Introduces the route receipt as a necessary artifact for adaptive AI systems, serving as a runtime transparency layer that complements model documentation.
• Minimal Schema and Redaction Model: Proposes a specific data structure that distinguishes between requested and effective routes (e.g., requested vs. effective service tier) and explicitly handles redactions to balance transparency with the protection of proprietary internals.
• Observability Gap Analysis: Demonstrates through a structured table that while individual platforms expose fragments of routing data (e.g., service tiers in API responses or fallback models in logs), no surveyed platform currently exposes a portable, unified per-answer receipt that captures the full route.
• Distinction from Existing Artifacts: Clarifies that route receipts are not replacements for Model Cards, Datasheets, or NIST AI Risk Management Frameworks, but rather a specific runtime record that answers "how was this answer produced?" rather than "what is this model?"

4. Results and Findings

• Fragmented Observability: The survey confirms that routing surfaces are documented but scattered. For example, OpenAI exposes service tiers and web-search traces; Anthropic exposes assigned tiers; AWS Bedrock exposes resolved tiers in CloudTrail. However, these are not unified into a single, portable record per answer.
• The "Moving Alias" Risk: The paper highlights that version aliases (e.g., latest) create reproducibility risks. A benchmark or legal workflow relying on a generic label may fail to reproduce if the underlying version changes, a fact invisible without a route receipt.
• Trust Calibration: The analysis suggests that appropriate reliance on AI requires users to know the route. A "searched" answer, a "fallback" answer, or a "standard tier" answer should carry different weights of confidence than a "priority" or "fixed version" answer.
• Feasibility: The proposed schema does not require inventing new observability planes; it can be assembled from fields many systems already expose (e.g., service_tier, model_identifier, tool_blocks).

5. Significance and Claims

The paper positions itself as a position paper with a schema proposal and a documentation survey, explicitly avoiding claims of live empirical measurement (e.g., it does not measure actual alias drift frequencies or fallback rates).

• Modest Scope: The author claims that the route receipt is a "minimal" and "usable" record, not a comprehensive disclosure of all system internals. It aims to record "consequential route facts" without exposing proprietary routing logic, safety thresholds, or infrastructure topology.
• Implementation Path: The significance lies in shifting the industry from "guessing" the route to "recording" the route. By treating existing routing fragments as a coherent provenance layer, platforms can provide accountability without compromising trade secrets.
• Future Work: The paper identifies the next necessary steps as empirical validation: conducting "alias-drift probes" and "fallback-observability probes" to test whether the proposed schema captures the facts developers and auditors actually need in production.

In summary, the paper argues that for adaptive AI systems to be trustworthy, they must produce a route receipt—a compact, redacted, per-answer record of the service path—just as they currently produce model cards for design-time artifacts. This receipt enables users to verify that the conditions under which an answer was generated match their expectations and constraints.