Model Registry in Machine Learning

The Problem: Models as Unmanaged Artifacts

In the early days of production ML, models were treated like any other build artifact -- serialized to a file, uploaded to cloud storage, and referenced by a path in a config file. This works surprisingly well when you have three models and two data scientists. It falls apart catastrophically when you have three hundred models and fifty data scientists.

Here's what goes wrong without a registry: a data scientist trains an improved fraud detection model, uploads it to s3://models/fraud-v2-final-FINAL.pkl, sends the path over Slack, and an ML engineer deploys it on Friday afternoon. Monday morning, the model is flagging 40% of legitimate transactions. Which training run produced this model? What data was it trained on? Who approved the deployment? Nobody knows. There's no audit trail, no rollback path, and no way to reproduce the model. This is not a hypothetical scenario -- it's the lived reality of teams operating without a model registry.

The Regulatory Push

Beyond operational pain, regulatory pressure has made model governance non-negotiable. The EU AI Act, India's proposed Digital India Act, and RBI guidelines for AI in financial services all require organizations to demonstrate traceability and accountability for AI systems. A model registry provides the audit trail that regulators demand: who trained the model, on what data, with what evaluation results, and who approved its deployment.

For Indian fintech companies like Razorpay, PhonePe, and Paytm, where ML models make decisions about fraud scoring, credit underwriting, and transaction routing, the ability to trace any production model back to its training data and approval chain isn't just good engineering -- it's a compliance requirement.

Evolution: From File Systems to First-Class Registries

The evolution followed a predictable path:

1. Phase 1 (2015-2017): Models stored as files in shared storage. Version tracking via filename conventions (model_v1.pkl, model_v2_johns_fix.pkl). No metadata, no governance.

2. Phase 2 (2018-2020): Experiment trackers like MLflow Tracking and Weights & Biases began capturing training metadata. But tracking experiments and managing production model lifecycle were still separate concerns.

3. Phase 3 (2020-2023): Dedicated model registry abstractions emerged -- MLflow Model Registry, SageMaker Model Registry, Vertex AI Model Registry. These unified versioning, staging, and governance into a single system.

4. Phase 4 (2024-present): Registries expanded to handle foundation model management, model cards for responsible AI, and integration with LLMOps workflows. MLflow deprecated the traditional stage-based model lifecycle in favor of more flexible aliases and tags.

Key Insight: A model registry is not an experiment tracker. Experiment tracking records what you tried. A model registry manages what you deploy. The boundary between "research artifact" and "production asset" is exactly where the registry sits.

The Library Analogy

Imagine a university library. Researchers produce papers (models), and the library doesn't just dump them in a pile -- it catalogs each one with metadata (title, authors, date, abstract, citations), assigns a unique identifier, and organizes them so anyone can find what they need. The library also tracks different editions of the same work and can tell you which edition is currently on the recommended reading list (production) versus which ones are archived.

A model registry does exactly this for ML models. Each "registered model" is like a library entry, and each "model version" is like an edition. The registry tracks which version is currently recommended for use (production), which is being evaluated (staging), and which has been retired (archived).

Why Not Just Use Git?

This is the most common pushback, and it's a fair question. Git is brilliant for versioning code, but models are fundamentally different artifacts. A model's behavior is determined by three things: the code that defines its architecture, the data it was trained on, and the hyperparameters used during training. Git can version the code, but model weights are often hundreds of megabytes to hundreds of gigabytes -- far beyond what Git (even with LFS) handles gracefully.

More importantly, a model's identity isn't just its weights. It includes the training data lineage, evaluation metrics across multiple slices, the environment it was trained in, and its deployment history. A model registry captures all of this as first-class metadata, not as comments in a commit message.

The State Machine Mental Model

The clearest way to think about a model registry is as a state machine for model lifecycle. Each model version transitions through states -- from None (just registered) to Staging (being evaluated) to Production (serving traffic) to Archived (retired). Each transition has a trigger (an approval, an automated test pass, a manual decision), and the registry records who triggered it and when. This state machine is the governance backbone of your entire deployment pipeline.

Formal Model

A model registry can be formalized as a tuple $R = (M, V, S, T, \Lambda)$ where:

• $M = \{m_1, m_2, \ldots, m_n\}$ is the set of registered models (logical model names, e.g., "fraud-detector", "recommendation-ranker")
• $V: M \rightarrow \mathcal{P}(\mathbb{N})$ maps each registered model to its set of version numbers
• $S = \{\text{None}, \text{Staging}, \text{Production}, \text{Archived}\}$ is the set of lifecycle stages
• $T: M \times \mathbb{N} \rightarrow S$ maps each (model, version) pair to its current stage
• $\Lambda: M \times \mathbb{N} \rightarrow \mathcal{M}$ maps each (model, version) pair to its metadata record $\mathcal{M}$

Metadata Record

Each metadata record $\mathcal{M}$ contains:

$\mathcal{M} = (A, H, D, E, P, C)$

where $A$ is the artifact URI (location of serialized model weights), $H$ is the set of hyperparameters, $D$ is the training data reference (dataset version or hash), $E$ is the evaluation metrics dictionary, $P$ is the provenance record (experiment ID, run ID, code commit), and $C$ is the model card (documentation for responsible AI).

Version Ordering and Promotion

The promotion function $\pi: (M \times \mathbb{N} \times S) \rightarrow S$ defines valid stage transitions. In a typical registry:

$\pi(m, v, s) = \begin{cases} \text{Staging} & \text{if } s = \text{None} \text{ and } \text{eval}(m, v) \geq \theta \\ \text{Production} & \text{if } s = \text{Staging} \text{ and } \text{approved}(m, v) = \text{true} \\ \text{Archived} & \text{if } s \in \{\text{Production}, \text{Staging}\} \end{cases}$

where $\theta$ is the minimum evaluation threshold and $\text{approved}(m, v)$ indicates whether human or automated approval has been granted.

Storage Efficiency

For model families derived via fine-tuning from a common base, storage can be optimized using delta encoding. If model version $v_2$ is fine-tuned from $v_1$, we store only the parameter delta:

$\Delta_{v_1 \rightarrow v_2} = \theta_{v_2} - \theta_{v_1}$

MGit (Hao et al., 2024) demonstrated that this approach reduces storage by up to $7\times$ for lineage graphs of fine-tuned models. This is particularly relevant in the era of foundation models, where the base model may be 70B+ parameters and fine-tuned variants differ by a small fraction of weights.

The model registry is the governance backbone of production ML systems -- a centralized, versioned catalog that manages the full lifecycle of trained models from registration through staging, production deployment, and eventual archival. It solves three critical problems that every scaling ML organization faces: versioning (tracking every model iteration with full provenance), governance (enforcing approval workflows and audit trails before models reach production), and discoverability (enabling any team member to find, compare, and understand any model in the organization).

At its core, a model registry implements a state machine for model lifecycle, with metadata storage, artifact storage, and a governance engine as its primary subsystems. The architecture separates lightweight metadata (version numbers, metrics, lineage pointers) from heavyweight artifacts (model weights, config files) for efficient querying and scalable storage. Tools range from open-source self-hosted options like MLflow and DVC (starting at ~INR 5,700/month for infrastructure) to cloud-managed solutions like SageMaker Model Registry and Vertex AI Model Registry, to SaaS platforms like Weights & Biases and Neptune.ai.

The model registry is not a luxury or a nice-to-have -- it is the formal boundary between experimentation and production. Without it, organizations accumulate technical debt in the form of untraceable deployments, impossible rollbacks, and compliance gaps. With it, teams gain reproducibility by design, safe rollbacks in minutes, automated deployment pipelines triggered by model promotion events, and the audit trails that regulators increasingly demand. For Indian companies operating under RBI AI guidelines and the upcoming Digital India Act, the governance capabilities of a model registry are not just good engineering -- they are a compliance requirement.