Model Registry
Beginner 12 min read Model Registry

The Model Registry

The checkout counter between training and serving

A model registry is the single source of truth for models: what exists, what's serving, who owns it, and what evidence it passed. It's the bridge between experimentation and deployment.

model registrymodel storesource of truthMLflowmodel governance
Prerequisites: Why Version Models Model Lifecycle Stages
Before we start

What you will learn

  • List what a model registry stores beyond the artifact
  • Explain why the registry is the source of truth for what's serving
  • Connect registry usage to governed promotion
Introduction

What is this?

A model registry is a central store for model versions and their metadata — stage, owner, metrics, lineage, aliases — acting as the single source of truth shared by training, serving, monitoring and governance. Algorithms talk to the registry; nobody decides 'which model is production' out-of-band.

Motivation

Why do you need it?

  • Without a registry, 'which model is live' lives in someone's head or a deployment to-do list.
  • Promotion needs an auditable record: who moved what, when, with what evidence.
  • Serving, monitoring and rollback all reference registry entries, so one change updates every system.
  • Governance (review, sign-off, access control) is enforceable where versions live.
Think about it

Mental model

Imagine

An airport control tower vs scattered pilots

Think of

The model registry

Pilots can't each decide which runway is 'the main one'. The tower (registry) holds the single plan — who's on approach, who's cleared, who's holding — and everyone reads against it. Remove the tower and chaos isn't far off.

Mechanics

How it works

  • Training pipelines register versions, attaching artifact + metrics + lineage + owner.
  • Versions move between stages (staging, production, archived) only via transitions with evidence.
  • Approvals, permissions and audit logs live on the registry.
  • Serving queries the registry for what to load; monitoring reports version-tagged metrics back.
  • Queries (list running models, who owns X) answer governance questions directly.

The registry as the hub connecting ML systems.

Training
Registry
Serving
Monitoring
Governance
Real world

In production

  • A 30-model platform routes all deployment decisions through the registry — no side channels.
  • A compliance team reviews the registry to enumerate models, their owners and their stages.
  • Rollback = transition the registry pointer back to an archived version; serving follows.
Guidelines

Best practices

  • Make the registry authoritative: doorbell training, serving and monitoring to it.
  • Require promotion evidence (metrics, shadow agreement) on every transition.
  • Enforce ownership: every registered model has an accountable owner.
  • Retain archived versions — deletion is a policy decision, not storage hygiene.
Watch out

Common mistakes

  • Running production models that were never registered — governance blind spot.
  • Registry updated by hand, drifting from reality within weeks.
  • Stage transitions with no evidence or approvals, defeating the audit purpose.
  • Registries treated as a ledgers only, disconnected from serving and monitoring.
When things break

Debugging tips

  • 'We don't know what's serving' — the registry query answers it; if it can't, reality already diverged.
  • Trust the registry, but verify periodically: sample running endpoints against registry state.
  • Permission errors on promotion? Check the stage-transition approval policy, not code.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/2
1

Which is the primary purpose of a model registry?

2

Production should only serve model versions that were registered with evidence.

Go deeper

Official documentation

MLflow Model Registry
docs