🗂️ Model Versioning and Registry Best Practices

About this simulation

Every trained model is the product of a specific dataset snapshot, code commit, hyperparameter set and random seed. A model registry is the system of record that tracks every version of a model, its lineage (which run and parent version it came from), its evaluation metrics, and its promotion stage — so any production prediction can be traced back to exactly how it was produced.

How it works

• Each glowing node is a registered model version, positioned along a timeline within its lineage branch.
• Lines connect a version to its parent — the run it was fine-tuned or retrained from, forming an auditable lineage graph.
• Node color encodes stage: grey (development), amber (staging), teal (production) and dark red (archived/rolled back).
• Versions whose metric crosses the promotion threshold animate upward toward the production ring; those that regress can be rolled back.

Controls

• Lineage branches — how many parallel experiment branches feed the registry.
• Versions per branch — how many versions were registered along each branch's history.
• Promotion threshold — the metric bar a version must clear to be promoted toward production.
• Metric lens — switch between accuracy (higher is better) and latency (lower is better) as the promotion criterion.
• Show lineage edges — toggle the parent → child connectors.
• ↺ Regenerate registry — resamples a fresh set of versions and metrics. Drag to rotate, scroll to zoom, click a node to inspect it.

Did you know?

Without a registry, teams often can't answer "which exact model is serving traffic right now, and what was it trained on?" — a gap that turns debugging a production incident into guesswork and makes audits and rollbacks far riskier than they need to be.