A Model Name Is Not a Model Identity
TL;DR: A model identifier tells you what was requested. It may not tell you what was resolved, deployed, loaded, or used for inference. Those are different identities — and they require different evidence.
When we call an AI API, we usually identify the model with a string:
provider/model-name
That is a convenient reference.
But it is not necessarily an identity.
A model identifier may be pinned to a particular release. It may represent a versioned model. It may be a mutable alias such as latest. It may even remain callable after retirement while the provider routes requests to a replacement.
From the application side, all of these can look almost identical:
model = "some-model-name"
But they carry very different provenance semantics.
That distinction matters once we ask a deceptively simple question:
Which model actually served this request?
The same name can resolve to something else
A useful real-world example comes from xAI.
In its May 15, 2026 model retirement documentation, xAI explains that requests sent to several retired model slugs can continue to resolve after retirement while being served by replacement models.
That is useful for compatibility.
Applications do not necessarily break simply because an older identifier was retired.
But from a provenance perspective, it creates an important distinction:
requested identifier
≠
resolved model
The caller can keep sending the same familiar identifier while the provider changes what that identifier routes to.
So storing only:
provider + model_name
may not be enough to reconstruct what happened later.
A name is a reference, not necessarily an identity
Consider a simplified timeline.
"model-name"
│
┌──────────┴──────────┐
│ │
T0 T1
│ │
▼ ▼
Provider Resolution Provider Resolution
│ │
▼ ▼
Release A Release B
SAME REQUESTED NAME
≠
SAME RESOLVED IDENTITY
Figure 1 — A name is a reference. An identity needs evidence.
The requested string may be identical at both times.
The resolved target may not be.
Same requested name ≠ same resolved identity.
The point is not that every provider behaves this way.
They do not.
The point is that an evidence model needs to represent the distinction when they do.
Requested and resolved identity are different evidence
A more useful provenance record looks like this:
Provider
↓
Requested Identifier
↓
Resolution Event
↓
Resolved Identifier
Each element answers a different question.
Requested Identifier
What did the caller ask for?
Resolution Event
What evidence connects that request to a provider-side resolution at a particular point in time?
Resolved Identifier
What did the provider say the request mapped to?
Keeping these concepts separate prevents another subtle mistake.
A provider may document that an old identifier now routes to a replacement.
That documentation is evidence about provider routing policy.
It is not automatically evidence that a particular production request was observed following that route.
Those are different evidence strengths.
Resolved model identity still isn't runtime identity
Even if we know the resolved model identifier, another boundary appears:
requested model
≠
resolved model
≠
deployed configuration
≠
loaded runtime weights
A deployment control plane may declare one model.
A process configuration may point to that model.
A runtime may report that it loaded that model.
None of those statements, by themselves, necessarily prove which exact weights were resident in memory when an inference executed.
This distinction becomes more important as inference systems become more dynamic.
Model aliases can change.
Loaders can be independently versioned.
Quantization logic can change the representation consumed at runtime.
Weights can be transformed, cached, resharded, or materialized into runtime-specific layouts.
Execution backends can rewrite or replace parts of the computation.
So provenance increasingly needs to describe a chain of identity transitions, rather than a single model name.
A better provenance chain
One possible evidence chain is:
Provider
↓
Requested Identifier
↓
Resolution Evidence
↓
Resolved Model Identity
↓
Artifact Identity
↓
Deployment Evidence
↓
Runtime Identity
↓
Inference Evidence
↓
Output Provenance
Each transition answers a different question:
- What did the caller request?
- What did that identifier resolve to?
- Which artifact was expected?
- What was deployed?
- What did the runtime observe?
- What evidence connects the inference to that runtime state?
- What evidence exists for the resulting output?
Those questions should not collapse into a single boolean such as:
verified = true
A useful assurance system should preserve what was verified, at which layer, from which evidence, and with what limitations.
Evidence does not become stronger by implication
Suppose we have provider documentation describing a routing rule.
That does not automatically upgrade into stronger runtime evidence.
Provider Documentation
│
▼
Routing Policy Evidence
│
├── does NOT automatically prove ──→ Observed Production Resolution
│
├── does NOT automatically prove ──→ Loaded Runtime Weights
│
└── does NOT automatically prove ──→ Inference Weight Attribution
Figure 2 — Evidence does not become stronger by implication.
A useful way to think about these levels is:
DOCUMENTED → OBSERVED → RUNTIME-BOUND → INFERENCE-ATTRIBUTED
Moving from one level to the next requires additional evidence.
Plausibility is not enough.
A provenance system should be able to preserve states such as:
AVAILABLEPARTIALUNAVAILABLENOT OBSERVEDNOT VERIFIED
without turning missing evidence into success.
How OMIV models this boundary
This is one of the boundaries we are working on in the Open Model Integration Validator (OMIV).
OMIV is an offline-first evidence and verification framework for AI artifacts, transformations, deployments, and runtime identity.
Phase 6E models evidence around:
provider
→ API surface
→ requested identifier
→ resolution event
→ resolved identifier
→ deployment evidence
→ runtime identity
The goal is not to turn documentation into stronger evidence than it actually is.
For example, OMIV's current xAI runtime-resolution case study records documented mutable-alias and routing semantics.
It deliberately does not claim that OMIV:
- made a production xAI API request;
- observed a production resolution response;
- inspected runtime memory;
- identified loaded runtime weights;
- or proved which weights produced an inference.
That limitation is part of the evidence.
OMIV also includes scope-limited Phase 6E synthetic evidence that preserves the distinction:
requested identifier
≠
resolved release
≠
runtime weight identity
rather than silently upgrading one claim into another.
What this does not prove
Recording a model-resolution chain does not prove:
- that the provider itself is authentic;
- that a replacement identifier represents an immutable release;
- that the declared artifact was actually deployed;
- that the expected weights were loaded;
- that those exact weights were resident during inference;
- that those weights produced a particular output;
- that two inference backends are behaviorally equivalent;
- or that the model is safe.
OMIV Phase 6E also does not implement provable inference.
These are separate assurance claims requiring separate evidence.
That separation is intentional.
A signature can prove something about signed bytes.
A deployment record can prove something about a declared deployment.
A runtime observation can provide evidence about runtime state.
An inference proof — if one exists — addresses another question entirely.
They should not be treated as interchangeable.
Why this matters beyond API aliases
Mutable API aliases are only one example of a broader trend.
Modern AI deployments contain far more identity-bearing components than just model weights:
- model artifact
- tokenizer
- configuration
- runtime engine
- loader
- quantization implementation
- runtime plugin
- execution backend
- deployment configuration
- execution environment
Some of these components are independently versioned.
Some are dynamically resolved.
Some transform the model before execution.
Some change how stored tensor representations are interpreted.
Some influence which kernels or execution paths actually run.
That means reproducibility increasingly depends on preserving more than:
model = "some-model-name"
The model name is only the beginning.
From model identity to an evidence graph
A more realistic system may eventually look less like a single identifier and more like an evidence graph:
Provider / Registry
│
▼
Resolution Evidence
│
▼
Artifact Identity
/ \
/ \
▼ ▼
Tokenizer / Config Transformation
│
▼
Quantized / Derived
Representation
│
▼
Deployment Binding
│
▼
Runtime Identity
│
▼
Inference Evidence
│
▼
Output Provenance
Not every deployment will have evidence for every node.
That is fine.
The important property is that missing evidence remains missing.
A partial chain should remain partial.
Where OMIV goes next
OMIV currently treats these evidence surfaces as separate, typed records rather than collapsing them into a single "verified model" label.
The next step is to make these records portable and composable through an Assurance Bundle.
The idea is simple:
evidence generated at different stages of the model lifecycle should be able to travel together without losing:
- its original subject;
- its scope;
- its identity;
- its authority;
- its limitations;
- or the historical context in which it was collected.
That makes the long-term question much broader than:
Which model did we request?
A better question is:
What evidence do we have for every identity transition between the artifact we intended to use and the output we actually received?
That is a much harder question.
But it is also the question a trustworthy AI deployment eventually needs to answer.
OMIV
Open Model Integration Validator (OMIV) is open source and currently available as a public preview.
The project focuses on evidence across the chain:
artifact identity
→ remote provenance
→ transformation
→ quantization
→ tokenizer/configuration
→ trust and policy
→ deployment binding
→ runtime identity
→ output provenance
If you work on model publishing, inference runtimes, provenance, model conversion, or deployment assurance, I'd be especially interested in real-world cases where a human-readable model identifier and the actual deployed identity can diverge.
Those edge cases are often where the most interesting provenance problems begin.