Model Staging

Model staging is the process of assigning a trained machine learning model to a lifecycle state — Staging, Production, or Archived — within a model registry before it handles real user traffic.

What It Is

Before a newly trained model touches real users, it needs a review process. Model staging is that process made explicit. Instead of deploying a model directly after training, the team registers it with a stage label that tells everyone — and every downstream system — what the model’s current status is.

Think of it like a software release pipeline, but for models. In code deployments, a build moves through dev, staging, and production environments. Model staging applies the same logic: the model artifact moves through defined states, and each transition requires an intentional decision, not an accident of timing.

The typical set of stages looks like this:

• None — a freshly registered version, not yet reviewed
• Staging — a candidate under evaluation; can be tested without affecting live traffic
• Production — the approved version currently serving users
• Archived — a retired version kept for audit, reproducibility, and rollback purposes

In MLflow, which is designed for reproducible ML deployments alongside version control tools like DVC, this is built directly into the model registry. When you register a trained model, you assign a stage. Moving it to Production creates a transition record: who approved it, when, and which experiment run produced it.

That audit trail is the reason model staging matters beyond process discipline. When something goes wrong in production — a metric drop, an unexpected output pattern, a compliance query — the stage history tells you exactly which model version was live, when it was promoted, and what training run it came from. Without staging, that answer requires manual archaeology through commit logs and deployment records.

Experiment tracking and model staging divide the work cleanly. Experiment tracking records every training run and its metrics. Model staging takes the best candidate from those runs and walks it through the approval process. The two systems ask different questions: experiment tracking asks “what have we tried?”, staging asks “what is live, what is under review, and what is retired?”

How It’s Used in Practice

The most common scenario: a data scientist trains a new model version and registers it in the model registry as Staging. The team runs validation — comparing it against the current Production model on a held-out dataset (a separate data sample excluded from training), or through shadow mode evaluation where the new model scores live requests without returning its results to users. Once the validation checklist passes and a reviewer approves, the model transitions to Production. The previous Production model drops to Archived automatically.

From the serving layer’s perspective, nothing changes: the endpoint reads the current Production model by stage label, not by version number. Swapping models means updating the stage label in the registry, not touching deployment configuration.

Pro Tip: Use stage transitions as your team’s decision log. Every promotion from Staging to Production should include a comment: what validation passed, who approved it, and any known limitations. That comment becomes the record when your model audit happens three months later.

When to Use / When Not

Common Misconception

Myth: Model staging and model versioning are the same thing.

Reality: Versioning assigns a number to every registered model artifact (version 1, version 2, version 3). Staging describes where in the deployment lifecycle that version currently sits. Version 3 might start in None, move to Staging, then Production, then Archived — the version number never changes, only the stage label. The two track different things: identity versus status.

One Sentence to Remember

A model’s stage label is the registry’s way of saying which version is approved for users, which is still being evaluated, and which has been retired — so every team member and every downstream system reads the same answer.

FAQ

Q: Can two model versions be in Production at the same time? A: Yes, many registries support concurrent Production versions — useful for canary deployments (routing a small percentage of traffic to the new version before full rollout) or A/B testing where the serving layer splits traffic between two approved versions.

Q: What’s the difference between model staging and a deployment environment? A: A deployment environment is infrastructure — the server or cluster where code runs. Model staging is metadata on the model artifact in the registry. A Staging-stage model can run on production infrastructure for shadow testing; the two concepts are independent.

Q: Does archiving a model delete its artifacts? A: No. Archived models keep all their artifacts, metrics, parameters, and lineage in the registry. Archive means “no longer active in deployment” — the model can be inspected, compared against newer versions, or promoted back to Staging if needed.