Table of Contents

    Version Control for Models

    MLOps Fundamentals

    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.

    Core principle: A model version should be immutable, reproducible, traceable, verifiable, and connected to the complete evidence required to use it responsibly.

    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
    Tool independence: Model version control is an MLOps practice. MLflow, DVC, and managed cloud registries are possible implementations, not the definition of the practice itself.

    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.

    Complete Model Version
    Artifact + Data + Code + Features + Configuration + Environment + Evaluation
    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
    Weak Naming Save artifacts as final-model.pkl, final-model-2.pkl, and final-model-really-final.pkl.
    Controlled Identity Assign an immutable version and connect it to its run, code, data, metrics, environment, approval, and deployment record.

    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
    Recommended relationship: Use Git for source code, configuration, tests, schemas, and small metadata files. Use controlled artifact storage or a model registry for model binaries and lifecycle management.

    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
    Identity principle: Use a registry version or immutable content identifier as the authoritative identity. Treat friendly names and aliases as references rather than artifact identities.

    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.

    Semantic Version
    \[ \text{Version} = \text{MAJOR} . \text{MINOR} . \text{PATCH} \]
    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
    ML caution: Retraining on new data can change behavior substantially even when the architecture and source code remain unchanged. Publish a new immutable model version and evaluate its impact.

    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.

    Mutable Release Replace the file behind model version 1.0.0 while keeping the same version identifier.
    Immutable Release Preserve version 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
    )
    Checksum purpose: A checksum verifies that a file matches previously recorded content. It does not prove that the original artifact was safe, accurate, or approved.

    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.

    Model Lineage
    Source Data → Feature Pipeline → Training Run → Evaluation → Model Version → Deployment

    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
    Privacy requirement: Dataset versioning must respect authorization, minimization, retention, deletion, residency, and access-control requirements.

    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
    Skew prevention: Model versions must reference the feature definitions used during training so that production serving can apply equivalent semantics.

    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
    )
    No synthetic metrics: 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
    )
    Registration rule: Registration establishes a versioned model identity. Production deployment still requires evaluation, approval, security, operational validation, and release controls.

    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
    Alias caution: Because aliases can move, record the resolved immutable model version with every deployment and prediction.

    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"
        )
    Promotion principle: Move a deployment alias only after the exact immutable version has passed required quality, security, operational, governance, and responsible-use gates.

    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
    )
    Production traceability: Resolve the alias to its immutable version during release and record that version in deployment metadata and prediction events.

    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.

    Risky Promotion Copy a model manually between folders, rename it production.pkl, and lose the original version relationship.
    Controlled Promotion Keep the immutable artifact in controlled storage and update the approved lifecycle reference after validation and authorization.

    Model Lifecycle States

    Example Lifecycle
    Experimental → Candidate → Validated → Approved → Deployed → Retired
    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
    State-control principle: Define who can perform each transition, which evidence is required, and which automated checks must pass.

    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"
    }
    Approval integrity: The approval record should identify the exact artifact checksum, registry version, evaluation evidence, permitted use, conditions, decision authority, and rollback option.

    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"
    DVC concept: Git tracks the small DVC metadata file, while DVC manages the relationship with the larger dataset content.

    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"
    Credential rule: Do not commit storage credentials to the repository. Use approved identity and secret-management mechanisms.

    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
    Storage principle: Use immutable version directories or registry versions. Never silently replace files inside an approved version.

    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
        }
    Version verification: Confirm both artifact integrity and expected prediction behavior. Successful deserialization alone is insufficient.

    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
    Least-privilege principle: An experiment runner should not automatically receive permission to approve and deploy its own model to production.

    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
    Retention principle: Do not retain every artifact indefinitely. Define retention from reproducibility, rollback, audit, privacy, legal, security, and storage 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
    Responsible-use principle: Versioning should preserve not only what the model is, but also where it may be used, under which conditions, and with which known limitations.

    Common Version-Control Mistakes

    Mistake Use filenames as the only model-version system.
    Correction Use immutable registry or artifact versions with metadata and lineage.
    Mistake Track only the model file.
    Correction Track preprocessing, data, features, code, configuration, environment, metrics, schema, threshold, and approval.
    Mistake Commit large model binaries directly to ordinary Git history.
    Correction Use an approved artifact store, model registry, large-file system, or data-versioning solution.
    Mistake Replace an approved model version in place.
    Correction Publish a new immutable version and preserve the previous version.
    Mistake Deploy a mutable alias without recording its resolved version.
    Correction Resolve the alias and record the exact immutable version in deployment and prediction metadata.
    Mistake Promote a model based only on one metric.
    Correction Apply model-quality, error, calibration, group, security, performance, governance, and business gates.
    Mistake Keep all versions indefinitely.
    Correction Apply documented retention, archival, and deletion policies.
    Mistake Assume the previous model file alone guarantees rollback.
    Correction Preserve the compatible application, schema, threshold, preprocessing, environment, and infrastructure configuration.

    Recommended Version-Control Workflow

    1

    Identify the Model

    Define the logical model name, owner, target, intended use, and prohibited use.

    2

    Version the Inputs

    Record code, datasets, feature definitions, configuration, schemas, and environment.

    3

    Track the Experiment

    Record parameters, metrics, artifacts, tags, and training-run identity.

    4

    Create the Artifact

    Save the complete fitted inference pipeline and calculate its checksum.

    5

    Evaluate the Candidate

    Compare actual quality, errors, calibration, groups, latency, resources, and limitations.

    6

    Register the Version

    Publish the immutable artifact with metadata, lineage, metrics, and candidate status.

    7

    Approve and Promote

    Apply required gates, record approval, and move the appropriate deployment alias.

    8

    Deploy and Record

    Record the exact model, application, schema, threshold, environment, and image versions.

    9

    Monitor by Version

    Connect operational, data, prediction, quality, group, and business signals to the immutable version.

    10

    Roll Back, Archive, or Retire

    Preserve safe recovery options and manage historical artifacts according to policy.

    Hands-On Practice

    1

    Create Model Metadata

    Record model, run, code, data, feature, schema, environment, threshold, and lifecycle versions.

    2

    Calculate a Checksum

    Calculate and record the SHA-256 digest of a saved model artifact.

    3

    Track an Experiment

    Log real parameters, calculated metrics, tags, and a model artifact through MLflow.

    4

    Register the Model

    Create a registered model version connected to the training run.

    5

    Create Candidate and Champion Aliases

    Use aliases to represent controlled deployment references while preserving immutable model versions.

    6

    Track Data with DVC

    Track an approved learning dataset through DVC metadata and configured remote storage.

    7

    Verify Reproduction

    Restore a historical revision, retrieve its data and model artifacts, and validate checksums and predictions.

    8

    Practice Rollback

    Restore the previous approved alias and verify complete release compatibility.

    Knowledge Check

    1

    What is model version control?

    Explain how it manages immutable model identities, artifacts, metadata, lineage, lifecycle, and deployment relationships.

    2

    Why is Git alone often insufficient?

    Explain large binaries, data references, model metadata, lifecycle states, and deployment relationships.

    3

    What makes a model version reproducible?

    Explain code, data, features, configuration, environment, random state, artifact, and evaluation evidence.

    4

    Why should model versions be immutable?

    Explain traceability, integrity, approval, investigation, comparison, and rollback.

    5

    What does a checksum verify?

    Explain whether a file matches the content represented by a recorded digest.

    6

    What is model lineage?

    Explain the relationship between data, features, code, training, evaluation, registration, deployment, and monitoring.

    7

    What is a model-registry alias?

    Explain a movable name that references a selected immutable model version.

    8

    Why must the resolved alias version be recorded?

    Explain that an alias may later point to a different version.

    9

    What must a rollback preserve?

    Explain model, preprocessing, threshold, schema, application, environment, and infrastructure compatibility.

    10

    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.