Skip to main content

Model Registry and Lineage

Experiment tracking records executions. A model registry gives selected artifacts stable names, immutable versions, review metadata, and lifecycle decisions. Registration does not make a model good; it makes the candidate and its evidence addressable.

Prerequisites​

Complete Model Artifacts and Safe Serialization and the preceding Study Sprint lessons. Be able to distinguish a run from a deployable model version.

Learning goals​

  • define a registry before selecting a registry product.
  • trace a model version backward to code, data, config, environment, and evaluation.
  • separate registration, approval, alias movement, deployment, and rollback.

Registry objects and decisions​

A durable registry usually needs:

  • a stable model name for one prediction contract;
  • an immutable version referencing immutable artifact bytes;
  • the originating run and its data/code/config lineage;
  • signature, schema, class, threshold, environment, and evaluation evidence;
  • intended use, exclusions, owner, review status, and timestamps;
  • append-only approval, rejection, deprecation, and alias history.

“Production” should be a movable alias or deployment reference, not a mutable model version. Promotion is an authorization decision. Deployment is a separate delivery event. A model may be registered but never approved, approved but not deployed, or deployed to only one environment.

Worked example​

After the Study Sprint verifier passes, a conceptual registry record could be:

{
  "model_name": "study-sprint-completion",
  "version": 1,
  "artifact": {
    "format": "datasciencebase.linear-logit.v1",
    "sha256": "<trusted model.json digest>"
  },
  "source_run": "<immutable run identity>",
  "decision": {
    "status": "candidate",
    "owner": "learning-platform-team",
    "evidence": ["metrics.json", "predictions.csv", "run.json"]
  }
}

The candidate status is honest: this 40-row synthetic fixture demonstrates engineering behavior, not production readiness. No accuracy threshold can replace representativeness, harm analysis, privacy review, robustness, or operational validation.

Trace lineage in both directions​

Backward lineage answers which data snapshot, config, code, environment, and run produced model version 1. Forward lineage answers which batch jobs, services, decisions, and reports consumed it. Both matter during an incident: determine exposure before choosing rollback or retraining.

A rollback moves deployment to a previously approved immutable version; it must not overwrite history. It helps when the previous model and current feature contract remain compatible. Rollback cannot undo decisions already made, repair a compromised data source, or solve a changed environment by itself.

Retention and deletion policies must reconcile audit needs with privacy and legal obligations. Lineage should reference governed datasets without copying sensitive rows into every registry record.

Common mistakes​

  • Treating registration as automatic approval or deployment.
  • Updating model bytes in place under an existing version.
  • Keeping only backward lineage and being unable to find affected consumers.
  • Moving an alias without reviewer identity, reason, and evidence.
  • Assuming rollback is safe without checking schema and feature compatibility.

Practice​

Draw the Study Sprint lineage graph from CSV and config through run and model version to a hypothetical batch consumer. Add a corrected dataset and version 2. Then rehearse rollback: list what moves, what remains immutable, and what incident evidence must be retained.

Next steps​

Continue with the next ML Engineering & MLOps batch on serving and delivery, where model signatures, inference schemas, rollout strategies, and rollback become executable system contracts.

Primary sources​

Checked 2026-10-15: MLflow Model Registry documentation, OpenLineage specification, W3C PROV overview, and NIST AI RMF Playbook.