MLOps Model Lifecycle & Governance

A bank denies someone a loan. Eleven months later a regulator asks: which model made this decision, what data was it trained on, who approved it for production, and can you reproduce the exact score it produced that day? If the honest answer is "we're not entirely sure — someone retrained it a few times since then and we don't have the old training set anymore," the bank does not have a machine learning problem. It has a governance problem, and it is now the company's most expensive problem, because regulatory findings, lawsuits and forced model retirements cost orders of magnitude more than the discipline that would have prevented them.

Everything else in this track — experiment tracking, containers, CI/CD, canary releases, drift monitoring — produces artifacts and events: a training run, an image, a test result, a traffic shift, an alert. Governance is the layer that turns those artifacts and events into an answer to two questions any serious organization will eventually be asked: why is this model allowed to make this decision, and prove it. In an interview, "how would you govern this system?" is where a candidate distinguishes "I can build a model" from "I can be trusted to run one in a business that has auditors, regulators, and customers whose lives the model affects." This subject is the track's capstone precisely because it is not really about a new technique — it is about connecting everything else into something an outside party can trust.

We will not re-teach experiment tracking (covered in Experiment Tracking & Model Registries) or containerization (covered in Containers & Reproducible ML Environments); here we treat them as building blocks and focus on the governance layer wrapped around them: the lifecycle as a whole, versioning as a discipline that spans every artifact, who approves what and why, what an auditor actually asks for, and what a model card is for.