In traditional software, you version one thing: code (with Git). In ML, you must version three things: code, data, and models. A model is a function of its code and its training data. Change either one, and you get a different model. If you can’t trace back from a production model to the exact code commit and data version that produced it, you can’t debug it, audit it, or reproduce it. This lineage — the chain from data → code → model → deployment — is the backbone of ML governance.

DVC (Data Version Control) is an open-source tool that extends Git to handle large files. Instead of storing data in Git, DVC stores a small metafile (.dvc) in Git that contains the hash of the actual data. The data itself lives in remote storage (S3, GCS, Azure Blob, or local). When you dvc checkout, DVC fetches the correct data version from storage. This means you can git checkout v2.3 and DVC will automatically give you the matching data. DVC also supports pipelines (dvc.yaml) that define the DAG of data processing steps, making the entire pipeline reproducible.

A model registry is a centralized store for trained model artifacts with metadata. Think of it as a “package registry” (like npm or PyPI) but for ML models. Key capabilities: versioning (auto-incrementing version numbers), metadata (parameters, metrics, training data version, code commit), stage management (None → Staging → Production → Archived), aliases (named references like “champion” or “challenger”), and lineage (which experiment run produced this model). MLflow Model Registry is the most widely used open-source option. Cloud platforms (SageMaker, Vertex AI) have their own built-in registries.

A mature model promotion workflow has clear gates: (1) Experiment — data scientist trains and evaluates, logs to tracker. (2) Registration — best run is registered in the model registry. (3) Staging — model is deployed to a staging environment for integration testing, shadow mode (receives real traffic but predictions are not served), and A/B testing. (4) Validation gates — automated checks: accuracy above threshold, latency within SLA, no regression on critical slices, bias checks pass. (5) Production — model is promoted to production with canary deployment (serve to 5% of traffic first). (6) Archive — old production model is archived but kept for rollback.

A “model” in production is more than just weights — it includes preprocessing logic, tokenizers, configuration, and dependencies. Common packaging formats: MLflow Model (framework-agnostic, includes MLmodel descriptor + conda.yaml), ONNX (Open Neural Network Exchange — convert PyTorch/TF models to a portable format for optimized inference), TorchScript (serialized PyTorch models that can run without Python), SavedModel (TensorFlow’s native format), and Docker containers (package everything including the runtime). For LLMs, models are typically served via specialized inference servers (vLLM, TGI) rather than generic packaging.

LakeFS is an open-source tool that provides Git-like operations (branch, commit, merge, revert) directly on your data lake (S3, GCS, Azure Blob). Unlike DVC, which tracks individual files, LakeFS operates at the data lake level — you can branch an entire S3 bucket, make changes, test them, and merge back. This is powerful for: atomic data updates (either all changes apply or none), data CI/CD (test data changes before they reach production), time travel (query data as it was at any point in time), and isolation (each experiment can work on its own branch of the data without affecting others).

Model cards (Mitchell et al., Google, 2019) are standardized documentation for ML models. They describe: model details (architecture, training data, intended use), performance metrics (overall and per-slice — e.g., accuracy by demographic group), limitations (known failure modes, out-of-scope uses), ethical considerations (potential biases, fairness analysis), and deployment context (intended users, deployment environment). Model cards should be stored alongside the model in the registry. The EU AI Act and other regulations increasingly require this level of documentation for high-risk AI systems.

1. Version all three artifacts together — a model version should always link to its code commit and data version. 2. Use semantic versioning for data — major (schema change), minor (new rows), patch (corrections). 3. Never overwrite — always create a new version; storage is cheap, debugging is expensive. 4. Automate lineage — your training pipeline should automatically record which data and code produced each model. 5. Tag production models — always know which model version is currently serving in production. 6. Keep rollback models — retain at least the last 3 production models for quick rollback.