Version Control for Models
Version Control for Models
Learn how to identify, store, compare, approve, promote, deploy, reproduce, roll back, archive, and retire Machine Learning models using immutable artifacts, semantic versions, checksums, metadata, experiment lineage, data references, environment versions, model registries, aliases, and governed lifecycle states.
Introduction
A Machine Learning project rarely produces only one model. Teams experiment with algorithms, features, hyperparameters, datasets, decision thresholds, preprocessing strategies, and dependency versions. Each experiment may produce a different model artifact.
Saving these artifacts with names such as
model-final.pkl,
model-final-new.pkl, or
best-model-latest.pkl does not provide reliable
version control. The names do not explain which data, code,
configuration, metrics, or environment created the model.
Model version control provides every meaningful model release with a unique and traceable identity. It connects the model artifact to its training run, data version, source revision, feature logic, parameters, metrics, environment, approval status, deployment history, and monitoring evidence.
Learning Objectives
By the End of This Lesson
- Define model version control
- Explain why Git alone is insufficient for large model artifacts
- Distinguish experiments, candidates, versions, aliases, and stages
- Create meaningful model-version identifiers
- Apply semantic-versioning concepts to ML releases
- Preserve immutable model artifacts
- Create and verify model checksums
- Record model metadata
- Connect models to source-code revisions
- Connect models to training and evaluation datasets
- Record preprocessing and feature versions
- Record dependency and container-image versions
- Understand experiment-to-model lineage
- Use a model registry
- Use aliases for controlled deployment references
- Promote approved models through lifecycle states
- Compare candidate and production versions
- Roll back to a previous approved release
- Protect model artifacts and registry operations
- Define retention, archival, and retirement policies
Prerequisites
Recommended Knowledge
- Git fundamentals
- Machine Learning training and evaluation
- Train-validation-test separation
- Saving and loading models
- Experiment tracking
- ML pipelines
- CI/CD for ML
- Docker fundamentals
- JSON metadata
- File-integrity checks
Example Packages
- MLflow
- DVC
- scikit-learn
- Joblib
- pandas
- NumPy
python -m pip install mlflow dvc scikit-learn joblib pandas numpy
What Is Model Version Control?
Model version control is the systematic management of model artifacts and every behavior-changing asset associated with them. It ensures that teams can identify exactly which model was created, evaluated, approved, deployed, monitored, or retired.
| Versioned Element | Purpose |
|---|---|
| Model Artifact | Preserves the fitted model or learned parameters |
| Preprocessing | Preserves transformations used before prediction |
| Source Code | Identifies the training and inference implementation |
| Training Data | Identifies the information used to fit the model |
| Evaluation Data | Identifies the evidence used to assess the model |
| Feature Definitions | Preserve feature calculations and prediction-time semantics |
| Configuration | Preserves parameters, seeds, thresholds, and split rules |
| Environment | Identifies compatible dependencies and runtime details |
| Evaluation Report | Preserves measured model-quality evidence |
| Lifecycle Status | Identifies whether the model is experimental, approved, deployed, or retired |
Why Version Models?
Operational Reasons
- Reproduce a historical experiment
- Compare candidate models
- Identify the model serving a prediction
- Promote an approved candidate
- Roll back an unsuitable release
- Investigate incidents
- Audit who approved a deployment
- Preserve the evidence behind a decision
- Separate experimental and production artifacts
- Retire obsolete or prohibited models
final-model.pkl,
final-model-2.pkl, and
final-model-really-final.pkl.
Git Versioning vs Model Versioning
| Area | Git | Model Registry or Artifact System |
|---|---|---|
| Primary Focus | Source files and text-based project history | Models, metadata, lifecycle, lineage, and deployment |
| Large Binary Files | Ordinary Git history is inefficient for large changing binaries | Designed to reference or store larger artifacts |
| Model Metrics | Must be added manually | Can be stored as model or run metadata |
| Lifecycle Status | Requires project-specific conventions | Can represent candidate, approved, deployed, and retired states |
| Deployment Reference | Usually references code or configuration | Can identify the exact registered model version |
| Lineage | Tracks code history | Connects the model with its run, data, metrics, and artifacts |
Experiment, Candidate, Version, and Release
| Term | Meaning |
|---|---|
| Experiment Run | One execution with identified parameters, data, metrics, and outputs |
| Model Artifact | The fitted model or saved learned state produced by a run |
| Candidate Model | A model being considered for approval or deployment |
| Registered Model | A logical model identity containing one or more versions |
| Model Version | An immutable registered artifact with unique identity |
| Alias | A movable human-readable reference to a selected model version |
| Release | An approved application, model, threshold, schema, and environment combination |
| Deployment | A running instance or endpoint using a specific release |
Model Version Identifiers
A version identifier should uniquely identify an immutable model
artifact. It should not depend on a mutable label such as
latest.
| Identifier | Example | Purpose |
|---|---|---|
| Registry Version | 17 |
Automatically identifies a version under a registered model |
| Semantic Version | 2.1.0 |
Communicates the intended significance of a release change |
| Run Identifier | churn-run-2026-001 |
Links the model to its generating execution |
| Content Checksum | SHA-256 digest |
Identifies and verifies file content |
| Source Revision | Git commit identifier |
Identifies the code used to create the model |
Semantic Versioning for Models
Semantic versioning uses the form
MAJOR.MINOR.PATCH. ML teams may adapt the meaning of
each segment, but the policy must be documented and applied
consistently.
| Change Type | Possible Policy | Example |
|---|---|---|
| Major | Breaking input, output, target, or decision-semantics change | 1.4.2 to 2.0.0 |
| Minor | Compatible model or feature improvement requiring full evaluation | 1.4.2 to 1.5.0 |
| Patch | Compatible packaging or metadata correction without intended behavioral change | 1.4.2 to 1.4.3 |
Immutable Model Artifacts
After a model version is registered or approved, its artifact content should not be replaced. Any changed model, metadata, preprocessing, or threshold should become a new traceable version.
1.0.0 while
keeping the same version identifier.
1.0.0 and register the changed
artifact as a new version.
Benefits of Immutability
- Reliable reproduction
- Predictable deployment
- Accurate incident investigation
- Auditable approvals
- Safe rollback
- Reliable checksum verification
- Clear historical comparisons
Calculate an Artifact Checksum
import hashlib
from pathlib import Path
def calculate_sha256(
file_path
):
file_path = Path(
file_path
)
if not file_path.is_file():
raise FileNotFoundError(
f"Artifact not found: {file_path}"
)
hasher = hashlib.sha256()
with open(
file_path,
"rb"
) as artifact_file:
while True:
block = artifact_file.read(
1024
*
1024
)
if not block:
break
hasher.update(
block
)
return hasher.hexdigest()
artifact_checksum = calculate_sha256(
"artifacts/customer_churn_pipeline.joblib"
)
print(
artifact_checksum
)
Verify Artifact Integrity
def verify_artifact_checksum(
artifact_path,
expected_checksum
):
actual_checksum = calculate_sha256(
artifact_path
)
if actual_checksum != expected_checksum:
raise ValueError(
"Model artifact checksum "
"verification failed."
)
return {
"verified": True,
"sha256": actual_checksum
}
Verify Before
- Registering a model
- Promoting a model
- Building a serving image
- Deploying to staging
- Deploying to production
- Rolling back
- Investigating an incident
- Restoring an archived model
Model Metadata
import json
import platform
from pathlib import Path
import joblib
import numpy as np
import pandas as pd
import sklearn
metadata = {
"model_name": (
"customer-churn-classifier"
),
"model_version": "1.0.0",
"artifact_file": (
"customer_churn_pipeline.joblib"
),
"artifact_sha256": (
artifact_checksum
),
"run_id": (
"replace-with-training-run-id"
),
"code_version": (
"replace-with-source-revision"
),
"training_data_version": (
"replace-with-training-data-version"
),
"validation_data_version": (
"replace-with-validation-data-version"
),
"test_data_version": (
"replace-with-test-data-version"
),
"feature_definition_version": "1.0.0",
"input_schema_version": "1.0.0",
"output_schema_version": "1.0.0",
"decision_threshold": 0.60,
"python_version": (
platform.python_version()
),
"numpy_version": np.__version__,
"pandas_version": pd.__version__,
"scikit_learn_version": (
sklearn.__version__
),
"joblib_version": (
joblib.__version__
),
"lifecycle_status": "candidate",
"approval_status": "pending",
"intended_use": (
"Retention-review prioritization"
),
"prohibited_use": (
"Automatic denial or reduction "
"of customer service"
)
}
metadata_path = Path(
"artifacts/model_metadata.json"
)
with open(
metadata_path,
"w",
encoding="utf-8"
) as metadata_file:
json.dump(
metadata,
metadata_file,
indent=4
)
Model Lineage
Model lineage explains where a model came from and how it was produced.
Lineage Should Answer
- Which dataset trained this model?
- Which source revision created it?
- Which feature logic was used?
- Which parameters and random state were used?
- Which environment executed the run?
- Which metrics supported selection?
- Who approved the version?
- Which environments deployed it?
- Which predictions were generated by it?
- Why was it replaced or retired?
Version the Data Reference
Reproducing a model requires the exact training, validation, and testing data or immutable references capable of resolving those datasets.
| Data Reference | Purpose |
|---|---|
| Dataset Version | Identifies a published immutable dataset asset |
| Storage Version | Identifies an immutable object or table snapshot |
| Query Version | Identifies extraction logic |
| Source Timestamp | Records the applicable extraction or snapshot time |
| Schema Version | Identifies the meaning and structure of fields |
| Dataset Checksum | Provides integrity evidence for a materialized dataset |
Version Feature Definitions
Feature Versioning Includes
- Feature name
- Business definition
- Source fields
- Transformation logic
- Observation-time semantics
- Missing-value behavior
- Category handling
- Data type and range
- Owner
- Feature-definition version
Version the Environment
python==3.12.*
numpy==replace-with-tested-version
pandas==replace-with-tested-version
scikit-learn==replace-with-tested-version
joblib==replace-with-tested-version
| Environment Asset | Version Evidence |
|---|---|
| Python Runtime | Python version |
| Python Packages | Dependency lock or tested requirements file |
| System Libraries | Base-image or operating-system package version |
| Container | Immutable image digest |
| Hardware | CPU, accelerator, and architecture information where relevant |
| Framework Runtime | Training and inference framework versions |
What Is a Model Registry?
A model registry is a controlled system for organizing registered model identities, immutable versions, metadata, lineage, aliases, lifecycle status, approvals, and deployment relationships.
| Registry Capability | Purpose |
|---|---|
| Registered Model | Provides a stable logical identity |
| Model Version | Identifies an immutable artifact |
| Tags | Store searchable version metadata |
| Aliases | Provide movable references such as champion or candidate |
| Lineage | Connects versions to experiments and source assets |
| Approval Metadata | Records release decisions and conditions |
| Deployment Link | Identifies environments using each version |
| Audit History | Preserves model lifecycle changes |
Track an Experiment with MLflow
import mlflow
import mlflow.sklearn
mlflow.set_experiment(
"customer-churn-training"
)
with mlflow.start_run() as run:
mlflow.log_param(
"algorithm",
"logistic-regression"
)
mlflow.log_param(
"decision_threshold",
0.60
)
mlflow.log_param(
"random_state",
42
)
mlflow.set_tag(
"code_version",
"replace-with-source-revision"
)
mlflow.set_tag(
"training_data_version",
"replace-with-data-version"
)
mlflow.set_tag(
"intended_use",
"retention-review-prioritization"
)
mlflow.log_metrics(
calculated_validation_metrics
)
mlflow.sklearn.log_model(
sk_model=model_pipeline,
name="model"
)
training_run_id = run.info.run_id
print(
training_run_id
)
calculated_validation_metrics must contain metrics
generated by the actual evaluation workflow.
Register an MLflow Model
import mlflow
model_uri = (
f"runs:/{training_run_id}/model"
)
registered_version = (
mlflow.register_model(
model_uri=model_uri,
name=(
"customer-churn-classifier"
)
)
)
print(
registered_version.name
)
print(
registered_version.version
)
Add Model-Version Metadata
from mlflow import MlflowClient
client = MlflowClient()
model_name = (
"customer-churn-classifier"
)
model_version = (
registered_version.version
)
client.set_model_version_tag(
name=model_name,
version=model_version,
key="validation_status",
value="passed"
)
client.set_model_version_tag(
name=model_name,
version=model_version,
key="input_schema_version",
value="1.0.0"
)
client.set_model_version_tag(
name=model_name,
version=model_version,
key="decision_threshold",
value="0.60"
)
client.set_model_version_tag(
name=model_name,
version=model_version,
key="approval_status",
value="pending"
)
Use Model Aliases
An alias is a movable reference to a selected immutable model version. The version remains unchanged when the alias moves.
client.set_registered_model_alias(
name=model_name,
alias="candidate",
version=model_version
)
candidate_version = (
client.get_model_version_by_alias(
name=model_name,
alias="candidate"
)
)
print(
candidate_version.version
)
| Example Alias | Possible Meaning |
|---|---|
candidate |
Version currently under deployment evaluation |
champion |
Approved version currently preferred for production |
challenger |
Version being compared with the champion |
rollback |
Previous approved version retained for restoration |
Promote an Approved Version
def promote_approved_model(
client,
model_name,
model_version,
approval_status
):
if approval_status != "approved":
raise ValueError(
"Only an approved model "
"can be promoted."
)
current_champion = None
try:
current_champion = (
client.get_model_version_by_alias(
name=model_name,
alias="champion"
)
)
except Exception:
current_champion = None
if current_champion is not None:
client.set_registered_model_alias(
name=model_name,
alias="rollback",
version=(
current_champion.version
)
)
client.set_registered_model_alias(
name=model_name,
alias="champion",
version=model_version
)
client.set_model_version_tag(
name=model_name,
version=model_version,
key="approval_status",
value="approved"
)
Load a Registered Version
import mlflow.pyfunc
registered_model_uri = (
"models:/"
"customer-churn-classifier"
"@champion"
)
loaded_model = mlflow.pyfunc.load_model(
registered_model_uri
)
prediction_output = loaded_model.predict(
inference_frame
)
Compare Model Versions
def compare_model_versions(
candidate_metrics,
champion_metrics
):
metric_names = sorted(
set(
candidate_metrics
)
|
set(
champion_metrics
)
)
comparison = []
for metric_name in metric_names:
candidate_value = (
candidate_metrics.get(
metric_name
)
)
champion_value = (
champion_metrics.get(
metric_name
)
)
difference = None
if (
candidate_value is not None
and champion_value is not None
):
difference = (
candidate_value
-
champion_value
)
comparison.append(
{
"metric": metric_name,
"candidate": candidate_value,
"champion": champion_value,
"difference": difference
}
)
return comparison
Comparison Areas
- Primary model-quality metric
- Secondary quality metrics
- Calibration
- Important error types
- Relevant group behavior
- Latency
- Memory usage
- Artifact size
- Inference cost
- Schema compatibility
- Known limitations
Promotion Is Not Copying
A controlled promotion should update metadata or an alias so that a deployment workflow references an already verified immutable artifact.
production.pkl, and lose the original version
relationship.
Model Lifecycle States
| State | Meaning |
|---|---|
| Experimental | Created during research and not eligible for deployment |
| Candidate | Submitted for formal evaluation |
| Validated | Passed defined technical tests |
| Approved | Authorized for a documented use under defined conditions |
| Deployed | Used by an identified runtime environment |
| Rejected | Failed one or more required gates |
| Retired | No longer permitted for new production predictions |
| Archived | Preserved for history, audit, or investigation |
Approval Record
{
"model_name": "customer-churn-classifier",
"model_version": "1.0.0",
"registry_version": "replace-with-registry-version",
"approval_status": "approved",
"approved_use": "Retention-review prioritization",
"approval_reference": "replace-with-approved-reference",
"approval_conditions": [
"Use only within the documented retention workflow",
"Maintain human review",
"Monitor input quality and delayed performance"
],
"rollback_version": "replace-with-approved-rollback-version"
}
Roll Back a Model Version
rollback_version = (
client.get_model_version_by_alias(
name=model_name,
alias="rollback"
)
)
client.set_registered_model_alias(
name=model_name,
alias="champion",
version=rollback_version.version
)
print(
"Champion restored to version:",
rollback_version.version
)
Verify After Rollback
- The alias resolves to the expected version
- The checksum matches the approved artifact
- The serving environment is compatible
- The input and output schemas are compatible
- The decision threshold is restored
- Health and readiness pass
- Representative predictions match expected results
- Monitoring identifies the restored version
Data Version Control with DVC
DVC can track data and model artifact references through small metadata files committed to Git while the larger content is stored through configured external storage.
git init
dvc init
dvc add data/customer_churn.csv
git add \
.dvc \
.gitignore \
data/customer_churn.csv.dvc
git commit \
-m "Track customer churn dataset"
Configure DVC Remote Storage
dvc remote add \
--default \
model-storage \
replace-with-approved-remote-location
dvc push
git add .dvc/config
git commit -m "Configure DVC remote"
Restore a DVC-Tracked Artifact
git checkout replace-with-source-revision
dvc pull
Verify the Restored State
- Source revision
- DVC metadata
- Downloaded file availability
- Artifact checksum
- Dataset schema
- Configuration version
- Environment compatibility
Recommended Artifact Structure
model-registry-export/
└── customer-churn-classifier/
├── 1.0.0/
│ ├── model.joblib
│ ├── metadata.json
│ ├── input_schema.json
│ ├── output_schema.json
│ ├── evaluation_report.json
│ ├── model_card.md
│ ├── requirements.txt
│ └── checksum.sha256
└── 1.1.0/
├── model.joblib
├── metadata.json
├── input_schema.json
├── output_schema.json
├── evaluation_report.json
├── model_card.md
├── requirements.txt
└── checksum.sha256
Test Model-Version Consistency
import json
import joblib
import numpy as np
def validate_model_version(
artifact_path,
metadata_path,
representative_input,
expected_probabilities
):
with open(
metadata_path,
"r",
encoding="utf-8"
) as metadata_file:
metadata = json.load(
metadata_file
)
verify_artifact_checksum(
artifact_path=artifact_path,
expected_checksum=(
metadata[
"artifact_sha256"
]
)
)
model = joblib.load(
artifact_path
)
actual_probabilities = (
model.predict_proba(
representative_input
)[:, 1]
)
np.testing.assert_allclose(
actual_probabilities,
expected_probabilities,
rtol=1e-10,
atol=1e-12
)
return {
"model_version": metadata[
"model_version"
],
"verified": True
}
Registry Security
| Risk | Control |
|---|---|
| Unauthorized Registration | Restrict artifact and version creation |
| Unauthorized Promotion | Separate registration, approval, and deployment permissions |
| Artifact Tampering | Use immutable storage, checksums, and signatures where required |
| Unsafe Deserialization | Load serialized artifacts only from trusted controlled sources |
| Model Theft | Restrict download and registry access |
| Metadata Exposure | Exclude secrets and unnecessary confidential information |
| Version Confusion | Record immutable versions rather than aliases alone |
| Audit Gaps | Record changes to tags, approvals, aliases, and lifecycle states |
Separation of Duties
| Operation | Possible Authorized Role |
|---|---|
| Create Experiment | Data scientist or ML engineer |
| Register Candidate | Controlled training pipeline |
| Approve Model | Authorized reviewer or governance workflow |
| Promote Alias | Controlled release pipeline |
| Deploy Model | Authorized deployment identity |
| Retire Model | Authorized owner with recorded reason |
| Delete Artifact | Restricted archival or retention process |
Connect Versions to Monitoring
Monitoring events must identify the immutable model version that generated each prediction.
{
"request_id": "generated-request-identifier",
"model_name": "customer-churn-classifier",
"model_version": "1.0.0",
"registry_version": "17",
"artifact_sha256": "recorded-artifact-checksum",
"application_version": "2.3.0",
"input_schema_version": "1.0.0",
"decision_threshold": 0.6,
"prediction": "churned"
}
Version-Specific Monitoring Enables
- Canary comparison
- Champion-challenger evaluation
- Incident scoping
- Quality comparison
- Group-level investigation
- Deployment verification
- Rollback validation
- Historical audit
Version the Complete Release
A production release consists of more than a model version. Record every component that can affect inference behavior.
| Release Component | Example Identity |
|---|---|
| Model | customer-churn-classifier:1.0.0 |
| Registry Version | 17 |
| Application | customer-churn-api:2.3.0 |
| Container Image | Immutable image digest |
| Input Schema | 1.0.0 |
| Feature Definitions | 3.2.0 |
| Decision Policy | retention-threshold:1.1.0 |
| Infrastructure | Deployment-manifest revision |
| Monitoring | Monitoring-policy version |
Retention and Archival
| Artifact Category | Possible Retention Consideration |
|---|---|
| Experimental Model | Retain according to research value and storage policy |
| Rejected Candidate | Retain enough evidence to explain the rejection where required |
| Production Model | Retain while deployed and for the required audit period |
| Rollback Model | Retain while it remains a valid recovery option |
| Retired Model | Archive or delete according to governance and investigation needs |
| Training Data Reference | Respect data retention, deletion, privacy, and reproducibility requirements |
| Monitoring Evidence | Retain according to incident, audit, and privacy requirements |
Retire a Model
Possible Retirement Reasons
- The business use no longer exists
- The model is replaced by an approved version
- The source data is no longer available or permitted
- The model no longer meets quality requirements
- The runtime is unsupported
- A security vulnerability cannot be resolved safely
- The model creates unacceptable outcomes
- A policy or regulatory requirement changes
Retirement Actions
- Stop new production traffic
- Remove deployment aliases
- Update the lifecycle status
- Preserve required audit evidence
- Revoke unnecessary access
- Apply retention or deletion rules
- Update documentation
- Notify dependent owners
Responsible Model Versioning
Governance Requirements
- Record intended and prohibited uses
- Preserve authorized data lineage
- Record evaluation limitations
- Version group-level evaluation evidence
- Version decision thresholds
- Record required human oversight
- Preserve approval conditions
- Connect complaints and incidents to model versions
- Prevent deployment of disallowed versions
- Maintain fallback and rollback versions
- Retire models that are no longer suitable
Common Version-Control Mistakes
Recommended Version-Control Workflow
Identify the Model
Define the logical model name, owner, target, intended use, and prohibited use.
Version the Inputs
Record code, datasets, feature definitions, configuration, schemas, and environment.
Track the Experiment
Record parameters, metrics, artifacts, tags, and training-run identity.
Create the Artifact
Save the complete fitted inference pipeline and calculate its checksum.
Evaluate the Candidate
Compare actual quality, errors, calibration, groups, latency, resources, and limitations.
Register the Version
Publish the immutable artifact with metadata, lineage, metrics, and candidate status.
Approve and Promote
Apply required gates, record approval, and move the appropriate deployment alias.
Deploy and Record
Record the exact model, application, schema, threshold, environment, and image versions.
Monitor by Version
Connect operational, data, prediction, quality, group, and business signals to the immutable version.
Roll Back, Archive, or Retire
Preserve safe recovery options and manage historical artifacts according to policy.
Hands-On Practice
Create Model Metadata
Record model, run, code, data, feature, schema, environment, threshold, and lifecycle versions.
Calculate a Checksum
Calculate and record the SHA-256 digest of a saved model artifact.
Track an Experiment
Log real parameters, calculated metrics, tags, and a model artifact through MLflow.
Register the Model
Create a registered model version connected to the training run.
Create Candidate and Champion Aliases
Use aliases to represent controlled deployment references while preserving immutable model versions.
Track Data with DVC
Track an approved learning dataset through DVC metadata and configured remote storage.
Verify Reproduction
Restore a historical revision, retrieve its data and model artifacts, and validate checksums and predictions.
Practice Rollback
Restore the previous approved alias and verify complete release compatibility.
Knowledge Check
What is model version control?
Explain how it manages immutable model identities, artifacts, metadata, lineage, lifecycle, and deployment relationships.
Why is Git alone often insufficient?
Explain large binaries, data references, model metadata, lifecycle states, and deployment relationships.
What makes a model version reproducible?
Explain code, data, features, configuration, environment, random state, artifact, and evaluation evidence.
Why should model versions be immutable?
Explain traceability, integrity, approval, investigation, comparison, and rollback.
What does a checksum verify?
Explain whether a file matches the content represented by a recorded digest.
What is model lineage?
Explain the relationship between data, features, code, training, evaluation, registration, deployment, and monitoring.
What is a model-registry alias?
Explain a movable name that references a selected immutable model version.
Why must the resolved alias version be recorded?
Explain that an alias may later point to a different version.
What must a rollback preserve?
Explain model, preprocessing, threshold, schema, application, environment, and infrastructure compatibility.
When should a model be retired?
Explain business, quality, security, policy, data, runtime, and responsible-use reasons.
Model Version-Control Readiness Checklist
Confirm Before Production Use
- The logical model name is defined
- The model owner is identified
- The intended and prohibited uses are documented
- Every model has an immutable version
- The artifact checksum is recorded
- The training-run identifier is recorded
- The source-code revision is recorded
- The training-data version is recorded
- The validation-data version is recorded
- The test-data version is recorded
- The feature-definition version is recorded
- The input and output schemas are versioned
- The decision threshold is versioned
- The environment is reproducible
- The container-image digest is recorded where applicable
- Actual evaluation metrics are attached
- Known limitations are attached
- Relevant group analysis is attached
- The approval status is recorded
- Aliases resolve to immutable versions
- Deployment records identify exact versions
- Prediction events identify the model version
- Registry permissions use least privilege
- Promotion requires approved evidence
- Artifact integrity is verified before deployment
- The rollback version is defined
- Rollback prediction consistency is tested
- Retention and archival rules are documented
- Retirement criteria are defined
- Lifecycle changes are auditable
Lesson Summary
| Version-Control Area | Main Outcome |
|---|---|
| Immutable Version | Provides a stable identity for model content |
| Checksum | Verifies artifact integrity |
| Metadata | Documents model configuration, environment, and intended use |
| Lineage | Connects data, code, features, runs, models, and deployments |
| Experiment Tracking | Records parameters, metrics, artifacts, and conclusions |
| Model Registry | Manages model identities, versions, aliases, tags, and lifecycle |
| Alias | Provides a movable reference to a selected immutable version |
| Promotion | Moves an approved version toward operational use |
| DVC | Connects Git revisions with externally stored data and artifacts |
| Monitoring Link | Associates production behavior with the exact model version |
| Rollback | Restores a previous complete approved release |
| Retention | Controls how long artifacts and evidence remain available |
| Retirement | Stops new use of a model that is obsolete or unsuitable |
| Governance | Preserves permissions, approvals, scope, limitations, and auditability |
Key Takeaway
Version control for models gives every meaningful Machine Learning artifact a unique, immutable, and verifiable identity. A complete version connects the model to its training run, code revision, datasets, feature definitions, preprocessing, parameters, environment, schemas, threshold, evaluation evidence, intended use, approval status, deployment history, and monitoring results. Git remains essential for source control, while artifact stores, data-versioning systems, experiment trackers, and model registries manage the larger and lifecycle-specific assets of Machine Learning. Aliases can simplify deployment references, but every release and prediction must record the exact immutable version. This discipline enables reproducibility, controlled promotion, trustworthy investigation, safe rollback, responsible retirement, and accountable model governance.
Get Machine Learning updates by email
Short, practical lessons and course updates from Rumman Ansari. No spam.