Model Versioning and a Model Registry: Promoting a Run to a Named, Deployable Version
The problem, from first principles
01-experiment-tracking produces many runs, each with its own metrics, but a run isn't automatically "the model in production." A model registry is the missing piece between experimentation and deployment: a named, versioned record that tracks WHICH run became WHICH numbered version of a model, and WHICH version (if any) is currently promoted to serve real traffic.
From theory to code
Implement create_registry, register_model_version (linking a run to a new, sequentially-numbered model version), promote_to_stage (moving a version between lifecycle stages), and get_version_at_stage.
Constraints
register_model_version(registry, model_name, run_id, metrics)assigns sequential version numbers PER model name, starting at1; new versions start in stage"none".promote_to_stage(registry, model_name, version, stage)raisesValueErrorfor an unrecognized stage.- Promoting a version to
"production"must automatically move whatever OTHER version was previously"production"to"archived": at most one version can be"production"at a time. get_version_at_stage(registry, model_name, stage)returns the matching version dict, orNoneif none match.
Hints
Open one at a time. Each gives away a little more than the last.
Hint 1
Version numbers are len(existing_versions) + 1: a simple, deterministic counter scoped to each model name independently, so two different models both start numbering from 1.
Hint 2
promote_to_stage's "at most one production version" rule needs a loop over ALL of a model's versions: set the TARGET version to the new stage, and separately check every OTHER version: if it's currently "production" and the new stage being applied is "production", demote it to "archived".
Keywords
No results yet
Run your code to check it against the examples, or submit to run every test.