Model Registry and Versioning

A trading firm that retrains its models weekly can end up with dozens of versions of the "same" model, each trained on slightly different data with slightly different parameters. Without a system to track them, it becomes easy to lose track of which version is actually running in production, what data it was trained on, and how it differs from last week's version. A model registry solves this by acting as a single catalog: every trained model is registered with a version number, a record of the exact training data and code that produced it, its validation metrics, and its current status (staged, in production, or retired).

Versioning is the underlying discipline that makes the registry meaningful — treating each trained model as an immutable, uniquely identified artifact, the same way source code commits are versioned, so "model v47" always means one specific set of weights trained on one specific dataset, never something that quietly changes underneath that label.

Worked example. A quant team deploys model v12 to production on Monday. By Thursday, live performance has degraded sharply relative to backtest expectations. Because the registry logged that v12 was trained on data through a specific date using a specific feature set, and that v11 (the previous version) is still stored and tagged as "last known good," the team can roll production back to v11 within minutes while they investigate v12, rather than scrambling to reconstruct which model and data combination was actually live.