**The Model in the Machine: Why “What You Bought” Is No Longer Self-Eeident**
In the world of AI APIs, the promise was simple: you send a request, the model computes, and you get an answer. But behind the scenes, the reality has become significantly more fragmented. A user might specify “claude-fable-5” but receive a response generated by “claude-opus-4-8.” The request didn’t error; the system simply classified the query as sensitive or benign and silently routed it to a different set of weights. This is the “well-behaved” version of a model switch, and it highlights a fundamental shift in how AI models are identified and delivered.
This phenomenon isn’t an anomaly; it’s a architectural feature. To manage cost and performance, the industry has deployed a triad of routing mechanisms. First, there’s **Substitution**, where a classifier swaps your requested model for a different, often more capable or more economical one. Second, there’s **Degradation**, where the model name stays the same but the precision of the weights changes—full precision versus a quantized version—often without your knowledge. Third, there’s **Drift**, where the name refers to a moving target, as silent updates replace old weights with new ones, all under the same alias.
These three fractures in model identity create a complex landscape for procurement, compliance, and legal accountability. When you contract for a model, what exactly are you purchasing? Is it a specific architecture and set of weights, or is it a “frontier quality” guarantee that the provider is still defining?
### The Legal and Contractual Gray Area
From a commercial law perspective, the model name should act as a description of the goods or service. In a traditional sale, describing a product creates an express warranty that the item will conform to that description. However, hosted AI APIs are typically sold as services, not goods, pushing disputes into the realm of common-law contract, which hinges on the specifics of the terms and documentation.
The danger lies in the disconnect between the user’s intent and the provider’s implementation. If a user “bargained for a name,” they expect that specific model. If the system substitutes a different one, that could constitute a breach of contract. Conversely, if the user bargained for a “capability”—say, “high-quality code generation”—then the specific model running in the background becomes less relevant, provided the output meets the standard. The problem is that this definition of “quality” is currently unwritten and untested, leaving the buyer vulnerable to a mismatch between expectation and reality.
### The Disclosure Gradient and Regulatory Risk
The industry’s response to this complexity is varied, creating a “disclosure gradient” that regulators are already scrutinizing.
* **Anthropic** takes the most transparent approach, notifying the user when a request is rerouted and returning the actual served model in the response object.
* **Cursor** publishes its high-level routing rules but does not disclose the specific model assigned to a given request.
* **OpenRouter** discloses quantization variance in its documentation but defaults to the cheaper, lower-precision path unless the user actively opts out.
This default-to-cheap model raises questions about “dark patterns,” where a design choice nudges the user toward a less favorable option. Furthermore, regulatory bodies are increasingly looking at unsubstantiated claims. If a provider markets a model as “60% cheaper with no quality loss,” they must have the methodology to back that up. The current state of routing—with its opaque substitutions and silent degradations—creates a significant liability risk for any provider that overstates the fidelity of their service.
### The Part Nobody is Looking At: Authentication and Chain of Custody
While procurement and regulation are hot topics, the most immediate legal risk may lie in authentication. In legal proceedings, the authenticity of digital evidence is determined by the chain of custody. Federal Rules of Evidence 902(13) and 902(14) allow for the self-authentication of records generated by an electronic system, provided the system’s reliability is established.
This creates a critical problem. Imagine a lawyer submitting a brief with a fabricated citation. The firm’s logs say it was generated by “Fable-5.” The provider’s logs, however, show a classifier diverted the request to “Opus 4.8.” In this scenario, the chain of custody is broken at the router. The system that created the evidence cannot be accurately named, making it impossible to authenticate the output for court. The model ID has become a legal identifier, but its fluidity turns it into a moving target that cannot reliably confirm or challenge its own origin.
### The Fix: Attestable Model Identity
You cannot solve this problem with better contracts or clearer prose. Contracts are static, but the routing event is dynamic. The solution requires **attestable model identity**.
The fix is a signed, cryptographically verifiable assertion that travels with every response. This digital signature would bind the completion to a specific tuple of data: the served model identifier, the hash of the weights, the precision level, and the system-prompt hash. This information would be signed by a key rooted in hardware attestation, a technology already supported by modern GPU platforms.
The primitive already exists: the `model` field in the response object. What is missing is the trust. A hash of the model identity in a response header would function exactly like a digital signature does for copied data under FRE 902(14), turning a contested factual question into a matter of verifying a certificate. Routing is good engineering, but without a verifiable signature, it is also an unlogged and unverifiable substitution of the product you agreed to buy. The model ID has quietly become the legal name of the system. It is time to decide what that name is meant to identify—and to ensure that identity is more than just a changing label.
### FAQ
**Q: What does it mean when a model is “substituted”?**
A: Substitution occurs when an AI provider’s classifier redirects your request to a different model than the one you specified. For example, you request “claude-fable-5,” but the system, based on its classification of your query, processes it using “claude-opus-4-8” instead. The substitution happens at the API layer, and the response object will often correctly report the model that was actually run.
**Q: What is “degradation” in the context of model identity?**
A: Degradation refers to the practice of keeping the same model name while changing the underlying quality of the service. This is often achieved by serving a quantized or lower-precision version of a model. While the name in your request remains the same, the arithmetic performed by the model may be different, potentially leading to variations in output quality or speed.
**Q: What is “drift” in AI model deployment?**
A: Drift occurs when the model associated with a specific name is silently updated over time. If a provider uses a “-latest” or similar alias, you are using an “unversioned dependency.” The model’s capabilities and behavior can change without any notification, as the alias now points to new weights that replace the old ones.
**Q: Why is authentication a problem for routed AI models?**
A: Authentication relies on a verifiable chain of custody. Legal standards for evidence often require that you can name the exact system that produced a piece of output. If a model request is routed through a classifier that changes the model on the fly, the resulting logs create a gap in the chain of custody. You cannot reliably authenticate the output because the specific model that generated it is ambiguous or unverifiable.
**Q: What is “attestable model identity,” and how could it solve these problems?**
A: Attestable model identity is a proposed solution where every API response includes a signed, cryptographic assertion. This assertion would bind the output to a specific model identifier, a hash of its weights, its precision level, and other system parameters. Because the signature is rooted in hardware attestation, it cannot be falsely asserted by the provider, giving the buyer a verifiable way to confirm exactly what model produced a given result.
### Conclusion
The architecture of modern AI inference is evolving faster than the legal and contractual frameworks that govern it. The simple act of naming a model has fractured into a spectrum of substitution, degradation, and drift. This creates significant risk for enterprises and individuals who rely on these services, exposing them to contractual ambiguity, regulatory enforcement, and evidentiary challenges.
The current patchwork of documentation and routing rules is insufficient. To move beyond this ambiguity, the industry must adopt a standard for **attestable model identity**. The technology for creating a verifiable link between a response and its generating system exists. The question is no longer whether we can build it, but whether we will prioritize the legal and operational clarity it provides. The model ID in your response object is becoming a legal identifier; it is time to define what it truly represents.
