Model Versioning and Change Control

Overview
Model Versioning and Change Control is a core practice in the Operationalize AI Solution phase of the PMI Cognitive Project Management for AI (CPMAI) methodology. It covers how an AI team tracks every model, dataset, configuration and code artifact that goes into production. It also covers how changes to those artifacts are proposed, evaluated, approved, deployed and, when needed, rolled back. Traditional software changes only when someone edits the code. AI models also change when data, hyperparameters, training pipelines or the operating environment change. That makes disciplined versioning and governed change control essential to running AI reliably.

Why It Is Important
1. Reproducibility: Teams must be able to recreate any model that was ever deployed. This supports debugging, audits and scientific validity. Without versioning, nobody can say exactly which data and code produced a given prediction.
2. Traceability and auditability: Regulators, auditors and internal governance boards increasingly require proof of what model was used, when, trained on what data and approved by whom. This lineage is central to Trustworthy AI and to regulations such as the EU AI Act and sector rules in finance and healthcare.
3. Risk management and rollback: A new model version may underperform, behave unfairly or fail in production. Versioning lets the team quickly revert to a known-good version, which limits business impact.
4. Managing model drift: Models decay as real-world data shifts (data drift and concept drift). Retraining produces new versions. Change control makes sure each retrained model is validated before it replaces the current one.
5. Collaboration: Data scientists, ML engineers, operations staff and business stakeholders need a single source of truth about which model is in development, staging and production.
6. Stakeholder trust and accountability: A formal approval process gives business owners confidence that changes are deliberate, tested and aligned with business objectives.
7. Supports the iterative nature of CPMAI: CPMAI is iterative and agile, with teams looping back through its phases. Versioning makes those iterations manageable rather than chaotic.

What It Is
Model versioning is the systematic identification, storage and tracking of every iteration of an AI model and its associated artifacts. A complete version record typically includes:
- The trained model artifact (weights, binaries, serialized model)
- The training dataset version and data snapshot (data versioning)
- Feature engineering and preprocessing code
- Training code and algorithm choice
- Hyperparameters and configuration files
- Environment details (libraries, frameworks, hardware, container images)
- Evaluation metrics and validation results
- Metadata: author, date, purpose, approval status, lineage to prior versions

Change control is the governance process that manages modifications to production AI systems. It includes:
- Change requests that document what is changing and why
- Impact assessment covering performance, fairness, compliance, downstream systems and users
- Testing and validation against agreed acceptance criteria
- Approval by designated authorities, such as a change control board, model risk committee or product owner
- Controlled deployment strategies
- Documentation and communication
- Rollback plans

In short, versioning answers what exists and how it was built. Change control answers how and when it is allowed to change.

How It Works
Step 1 - Establish a versioning scheme: Teams adopt a naming convention, often semantic versioning (major.minor.patch).
- A major version marks a new algorithm or architecture.
- A minor version marks retraining with new data.
- A patch marks small fixes.
Every version gets a unique, immutable identifier.

Step 2 - Use a model registry and supporting tools: A model registry is a central repository that stores model versions, metadata and lifecycle stage (e.g., Development, Staging, Production, Archived). Examples include MLflow Model Registry, SageMaker Model Registry, Azure ML and Vertex AI. Other tools cover the rest of the artifacts:
- Code is versioned in Git.
- Data is versioned with tools such as DVC, Delta Lake or lakeFS.
- Experiments are tracked with experiment-tracking tools.

Step 3 - Capture lineage: Each model version links back to the exact data snapshot, code commit, parameters and environment that produced it. This creates an end-to-end audit trail.

Step 4 - Trigger changes: Common triggers include:
- Monitoring alerts showing drift or performance degradation
- New business requirements
- New data becoming available
- Detected bias
- Security vulnerabilities
- Regulatory changes
- Scheduled retraining

Step 5 - Submit and assess a change request: The team documents the proposed change and evaluates its impact. The assessment covers accuracy, fairness, explainability, latency, cost, compliance and effect on dependent systems.

Step 6 - Validate: The candidate model is tested against a holdout set and compared with the current production model (the champion/challenger approach). It is also checked for bias, robustness and security against predefined acceptance criteria tied to the business KPIs set in the Business Understanding phase.

Step 7 - Approve: Designated stakeholders review the evidence and approve or reject the change. The level of scrutiny scales with risk: high-impact or regulated models need more formal sign-off.

Step 8 - Deploy in a controlled way: Teams use safe release strategies:
- Shadow deployment: the new model runs alongside production without affecting decisions.
- Canary release: a small percentage of traffic goes to the new version.
- A/B testing compares versions directly.
- Blue-green deployment: two environments allow an instant switch.
CI/CD/CT pipelines (continuous integration, delivery and training) automate much of this within an MLOps framework.

Step 9 - Monitor and roll back if needed: After deployment, the new version is monitored closely. If it fails, the registry allows quick rollback to the previous approved version.

Step 10 - Document and communicate: Release notes, model cards and updated documentation are published. Stakeholders are informed, and older versions are archived according to retention policies.

How It Fits CPMAI
The CPMAI methodology has six phases:
1. Business Understanding
2. Data Understanding
3. Data Preparation
4. Model Development
5. Model Evaluation
6. Model Operationalization
Model Versioning and Change Control sits mainly in Phase 6 but depends on artifacts from every earlier phase. Monitoring in operationalization often triggers a return to earlier phases, such as new data preparation or retraining. Versioning keeps those loops controlled. It also supports Trustworthy AI principles: transparency, accountability, governance and auditability.

Key Terms to Know
- Model registry: central catalog of model versions and lifecycle stages.
- Data versioning: tracking dataset snapshots used for training.
- Lineage/provenance: the traceable history of how a model was created.
- Champion/challenger: comparing a new candidate model against the current production model.
- Rollback: reverting to a previous stable version.
- Model drift: degradation due to changes in data or relationships.
- MLOps: practices that combine ML, DevOps and data engineering for reliable operations.
- Model card: a document describing a model's purpose, performance, limitations and ethical considerations.
- Immutable artifacts: versions that cannot be altered once registered.

Common Pitfalls
- Versioning only the code and not the data or environment
- Retraining automatically and deploying without validation or approval
- No rollback plan
- Ad hoc naming that makes versions untraceable
- Skipping documentation, which undermines audits
- Treating AI change control the same as static software change control, ignoring data-driven change

Exam Tips: Answering Questions on Model Versioning and Change Control
Tip 1 - Think "reproducibility and traceability first": When a question asks why versioning matters, the strongest answers mention reproducing results, auditing decisions and tracing lineage. Pure convenience or storage savings are weaker answers.

Tip 2 - Remember that AI versioning covers more than code: Look for answer choices that include data, model, parameters and environment. An option that versions only source code is usually a distractor.

Tip 3 - Prefer governed, validated change over speed: Suppose a scenario describes a retrained model that looks better in development. The best next step is usually to validate it against acceptance criteria and obtain approval through change control, not to deploy it immediately to production.

Tip 4 - Rollback is the go-to response to a failed deployment: If a new version causes problems in production, the preferred immediate action is often to roll back to the last approved version, then investigate. This is better than debugging live or retraining on the spot.

Tip 5 - Link changes to monitoring: Drift detection and performance monitoring are the usual triggers for change. Questions may test whether you recognize that monitoring outputs feed change requests and retraining cycles.

Tip 6 - Use safe deployment strategies: When asked how to reduce risk when releasing a new model, choose shadow, canary, A/B or champion/challenger approaches over a full immediate cutover.

Tip 7 - Connect to business objectives: CPMAI is business-driven. Acceptance criteria for a new version should tie back to the business KPIs defined in Business Understanding, not just technical metrics like accuracy.

Tip 8 - Include stakeholders and governance: Correct answers often involve the appropriate approvers, such as the product owner, model risk or governance board, or compliance. Look for documentation and communication steps too. Be wary of answers where a lone data scientist makes and deploys production changes unilaterally.

Tip 9 - Watch for Trustworthy AI angles: If the question mentions regulation, fairness or audits, the answer likely emphasizes lineage, documentation (model cards), approval records and bias re-testing for each new version.

Tip 10 - Identify the iterative loop: CPMAI is iterative. A question may ask what happens after drift is detected. The answer is typically to return to earlier phases (data preparation or model development), produce a new version, evaluate it, and redeploy through change control.

Tip 11 - Eliminate extreme or absolute answers: Be cautious of options with words like \"never retrain\", \"always deploy automatically\" or \"delete old versions.\" Good practice keeps archived versions for audit and rollback.

Tip 12 - Recognize the tools conceptually: You will not usually need vendor specifics. Do know that a model registry manages versions and stages, Git manages code, data versioning tools manage datasets, and CI/CD/CT pipelines automate controlled delivery.

Sample Question Walkthrough
Scenario: A fraud detection model in production shows declining precision due to new transaction patterns. The data science team retrains it and sees improved results offline. What should the project manager ensure happens next?
Approach:
- Eliminate \"deploy immediately\" because it bypasses governance.
- Eliminate \"keep the old model indefinitely\" because it ignores the drift.
The best answer is to register the new version with full lineage, validate it against business acceptance criteria and fairness checks, and obtain change approval. Then deploy using a controlled strategy such as canary or champion/challenger, with a rollback plan ready.

Summary
Model Versioning and Change Control makes AI solutions reproducible, auditable, safe to update and aligned with business goals throughout their life in production. For the exam, remember these elements:
- Version everything (data, code, model, configuration, environment).
- Govern every change (request, assess, validate, approve).
- Deploy carefully (shadow, canary, A/B, champion/challenger).
- Monitor continuously, and always be able to roll back.
- Document for accountability.