The Missing Record Is the Route Receipt
When a routed LLM answer is wrong, a prompt and a model name rarely explain enough. This chapter examines the proposed route receipt: a compact runtime record that captures the serving conditions of one answer and makes the effective path inspectable. The practical goal is to learn which facts help a user interpret a response, a developer diagnose it, or an auditor challenge it—without turning the system’s hidden reasoning or proprietary routing logic into public data.
Model cards describe artifacts; receipts describe events
A model card describes a trained model or model family. It can explain intended uses, evaluation results, limitations, and known risks. That information remains valuable, but it answers a design-time question: what is this model supposed to do, and how was it evaluated?
A routed answer raises a runtime question: what conditions actually produced this response? The visible model label may identify only the requested route. The serving system may resolve a moving alias to a different version, assign a different service tier, use more or less adaptive compute, invoke a search or retrieval tool, truncate context, fall back to another provider, apply a safety intervention, or process the request through a different region class. A model card cannot record which of those events occurred for one request.
Ordinary request logs often leave the same gap. A prompt, response, token count, timestamp, and generic model label can show what entered and what came out. They may not show whether the model label was fixed or moving, which version served the request, whether a fallback was used, which tool supplied evidence, whether the context was cut, or whether the requested capacity tier was effective. When an incident occurs, the team has to reconstruct the route from several systems, and some of the facts may exist only in a provider’s internal logs.
The route-receipt proposal treats the answer as an artifact of a runtime event. A receipt is not intended to explain why a router chose a provider or reveal the router’s scoring formula. It records material facts about the path: what was requested, what served the request, what auxiliary actions occurred, what state was available, how the response ended, and which details were withheld. In that sense, it is closer to a transaction record than to an explanation of the model’s reasoning.
The distinction between requested and effective route is the center of the design. A request may name a model alias, but the receipt can record the resolved model or at least the class of route that served it. A request may ask for priority capacity, but the receipt can record the effective tier. A request may permit fallback, but the receipt can say whether fallback occurred and, where disclosure allows, why. The record captures the difference between an intention and the condition that actually held.
The proposed fields fall into a few practical groups rather than one exhaustive inventory. Identity and time make the event referable. Model and route fields distinguish a fixed identifier, a moving alias, or a router-selected path. Service fields describe requested and effective capacity and effort status without exposing hidden reasoning. Tool and context fields indicate whether tools were used, whether material was retrieved, and whether input was truncated. Fallback, safety, region, and completion fields describe the conditions that may change trust, policy, or reproducibility. A redaction field explains what was omitted and why.