Know exactly which model answered, and who approved it.
The model registry records every model version, its weights digest, serving configuration, license, and approval status. Applications call stable aliases; promotion, rollback, and retirement happen in the registry with a full history.
Models change behavior. Your audit trail should show when.
When a model is swapped, re-quantized, or given a new system prompt, outputs change. If that happens through an engineer restarting a container, nobody can later say which model produced a disputed answer or whether it had been reviewed. In regulated settings that is a finding waiting to happen.
The registry makes the model a governed resource. Each version is immutable, each configuration change is a new revision, and only versions in an approved state can serve production aliases. Every gateway request records the alias, the resolved version, and the configuration revision.
One record per model version.
Weights and digest
Source, mirror location, and a pinned hash, so the bytes that were reviewed are the bytes that run.
Serving configuration
Runtime, quantization, context length, parallelism, and default sampling parameters as versioned revisions.
License and provenance
The license terms, publisher, and any internal restrictions on permitted use, recorded with the model.
Approval status
Draft, in evaluation, approved, deprecated, or retired, with who changed it and when.
Evaluation results
Links to the evaluation runs used to justify approval, on your own test sets.
Classification limits
Which data classifications a model is approved to receive, enforced by the policy engine.
Promotion is a reviewed step, not a deploy script.
- 1
Register
Import the weights from a mirror or offline media, pin the digest, and record license and provenance.
- 2
Evaluate
Serve the candidate in a non-production alias and run it against your evaluation sets and sample prompts.
- 3
Approve
A designated reviewer moves it to approved, optionally through a human approval workflow.
- 4
Promote or roll back
Point a production alias at the new version. Rolling back is pointing it at the previous one.
Applications reference intent, not model names.
Changing which model backs an alias is a registry operation with a recorded reason; application code and SDK calls stay the same.
alias: contract-review
current: mistral-small-3.1@rev4
allowed_classifications: [internal, confidential, privileged]
history:
- version: mistral-small-3.1@rev4
promoted_by: ml-platform-review
reason: "Higher clause-extraction accuracy on eval set v7"
- version: llama-3.1-8b-instruct@rev2
retired: trueIllustrative example · final API surface documented in /docs
Not every approved model should see every kind of data.
A model can be approved for internal documents but not for PHI or privileged material. The policy engine enforces those limits at the gateway on every request.
What each approval state permits.
The registry's approval status is passed to the policy engine on every request, so a policy can treat an unapproved model differently from an approved one.
| State | Can serve | Typical use |
|---|---|---|
| Draft | Nothing | Weights registered, digest pinned, license under review |
| In evaluation | Non-production aliases only | Side-by-side testing against evaluation sets and the current version |
| Approved | Production aliases, within classification limits | The version applications receive |
| Deprecated | Existing aliases until replaced | Signals a planned retirement; no new aliases point to it |
| Retired | Nothing | Kept in history so past audit records still resolve |
Treat model weights like any other third-party artifact.
Weights are large binaries from outside your organization, and they deserve the same scrutiny as a container image. Download them once into a mirror you control, record the source and publisher, and pin a cryptographic digest. Serving nodes load from the mirror and verify the digest, so a substituted or corrupted file is caught before it serves a request.
File format matters too. Some legacy checkpoint formats rely on serialization that can execute code when loaded. Preferring formats designed to hold only tensors, such as safetensors, removes that class of risk. Fine-tuned adapters and merged models should go through the same register, evaluate, and approve path as base models, with their lineage recorded.
Evidence to collect before a version is approved.
- Task accuracy on your own labeled examples
- Comparison against the version it would replace
- Behavior on prompts that should be declined
- Latency and throughput at expected concurrency
- Output quality at the chosen quantization
- Context length tested at realistic document sizes
- License terms reviewed for the intended use
- Rollback target identified and still available
Questions buyers ask
Can we prove which model produced a particular answer?
Yes. Each gateway request records the alias called, the model version it resolved to, and the configuration revision, alongside the requesting identity and policy decision.
Does the registry store the model weights?
The registry records metadata and a digest, and points to weights stored in your own artifact storage or mirror. Weights stay inside your environment and are verified against the digest at load time.
How are model licenses handled?
License terms and any internal usage restrictions are recorded on each model entry. Data.co does not grant model licenses; your legal team should review the terms of each open-weight model you register.
Can model approval require more than one reviewer?
Yes. Promotion can route through human approval workflows with named approvers, so a model change follows the same review discipline as other production changes.
Does this cover embedding models too?
Yes. Embedding models are versioned the same way. Changing an embedding model requires re-indexing, so the registry tracks which index was built with which embedding version.
What happens if an application calls a model that is not registered?
The gateway rejects it. A model name must match a registered, enabled endpoint; anything else is refused and logged, so an engineer cannot point production traffic at an unreviewed model by changing a string.
Can different teams have different approved models?
Yes. Aliases are resolved per request and policy decides which identities may invoke which endpoints, so a research group can use an evaluation alias while production applications only see approved versions.
How long should retired versions be kept?
Keep registry metadata for as long as you retain audit records, so every historical decision still resolves to a model and configuration. Whether to keep the weights themselves is a storage and retention decision for your team.
See it against your own use case.
A 30-minute technical walkthrough, policy simulation on your scenarios, and a deployment recommendation for on-prem, private cloud, or hybrid.