AI version control explained for developers and engineers

AI version control captures the code, models, training data, prompts, and provenance that together determine how an AI system behaves — and every one of those artefacts deserves the same disciplined tracking you already apply to source code. The immediate recommendation for any development team: extend Git with per-commit provenance metadata and pair it with a dedicated model registry from day one, before your first model reaches production.

The artefacts you need to version:

• Source code — training scripts, inference logic, evaluation harnesses
• Model binaries and checkpoints — weights, quantized variants, ONNX exports
• Training datasets and manifests — raw splits, preprocessed versions, data hashes
• Prompts and templates — system prompts, few-shot examples, chain-of-thought scaffolds
• Experiment configs and hyperparameters — learning rate schedules, batch sizes, random seeds
• Environment and dependency manifests — requirements.txt, Docker images, CUDA versions
• Evaluation evidence — benchmark results, test outputs, human review signals
• Run-level provenance — who triggered the run, which agent, which timestamp

Pro Tip: Record prompts and the agent's observed context at the exact moment of authorship, not in a retrospective summary. Capture-at-authorship is the single most reliable way to reconstruct why a model behaved as it did.

Key takeaways

AI version control requires tracking code, models, data, prompts, and provenance together — no single tool covers all five dimensions, and missing any one of them breaks reproducibility.

Table of Contents

• What does AI version control actually track?
• How does AI version control differ from traditional Git?
• Which tools cover the AI version control stack?
• Practical workflows from experiment to production
• Storage, scaling, and UK compliance considerations
• When should you extend Git versus adopt an AI-native system?
• UK enterprise checklist before adopting AI version control
• What the conventional wisdom on AI version control gets wrong
• Sources

What does AI version control actually track?

AI-aware version control should capture six provenance fields at the moment a change is authored: agent identity, model, prompt or intent, observed context, action trace, and test or review evidence. A standard Git commit records none of those fields. That gap is the core problem.

Consider a concrete inference trace. A production call to a RAG pipeline might involve a specific model version, system prompt hash, retrieval context from a dataset snapshot, and a tool-call sequence logged in an action trace. Without all four identifiers pinned together, you cannot reproduce the output, and you cannot audit which version of the prompt caused a regression.

Practical implementations often combine Git for code, DVC for data, and a model registry for model artefacts — the key is linking those systems with immutable identifiers and lineage metadata.

Metadata fields that matter most in practice: agent or model ID, prompt hash, observed context snapshot, action trace (the sequence of tool calls or decisions), evaluation scores, and human review signals. Tools like Memov demonstrate how prompts, responses, and reasoning can be stored as structured metadata on top of Git using git notes, so that prompt/response pairs survive alongside commits rather than disappearing into Slack threads.

How does AI version control differ from traditional Git?

Git is excellent at what it was designed for: line-level text diffs, branching, and distributed collaboration on source code. The moment you introduce model weights, large datasets, or prompt reasoning chains, its assumptions break down.

The three failure modes teams hit most often:

Large binary files. A fine-tuned LLaMA checkpoint can exceed 13 GB. Git stores every version of every file in its object store, so a handful of checkpoint iterations will bloat a repository to an unworkable size. Git LFS moves the binary to external storage and keeps a pointer in the repo, which helps, but it does not solve provenance.

Missing prompt and reasoning capture. A commit shows that inference.py changed on a given date. It does not show which system prompt was active, what context the model observed, or why the engineer made that edit. Git AI addresses this by attaching agent, model, and prompt metadata to commits or git notes at line level, enabling attribution that a plain diff cannot provide.

Composite versioning. As Paul Serban's analysis shows, semantic versioning (v1.2.3) is often insufficient for AI systems because a single inference depends on at least four independent dimensions: code version, model checkpoint, dataset snapshot, and prompt version. A composite identifier — content hashes plus commit IDs — is more reliable than a single semver string.

Git notes and sidecar refs are viable primitives for adding provenance on top of existing workflows without abandoning Git entirely. They are not a complete solution, but they are a practical starting point.

Which tools cover the AI version control stack?

No single tool covers every artefact. The pragmatic approach is a layered stack where each tool handles what it does best.

Git remains the foundation for source code, configs, and small text artefacts. Every other tool in the stack should link back to a Git commit as the anchor for a given experiment.

Git LFS handles large binary files by replacing them with lightweight pointers. It integrates transparently with GitHub, GitLab, and Bitbucket, making it the lowest-friction option for teams already on those platforms. The limitation: storage costs scale linearly with the number of versions, and there is no deduplication.

DVC treats datasets as first-class immutable snapshots and stores them in an object store (S3, Azure Blob, GCS, or a local remote). It generates .dvc pointer files that commit alongside your code, so git checkout and dvc pull together reproduce the exact data state for any historical commit. DVC also supports pipelines, so you can cache and replay individual stages of a training run.

MLflow provides experiment tracking and a model registry. Each run logs parameters, metrics, and artefact paths; the registry adds lifecycle stages (Staging, Production, Archived) and a lineage view. MLflow integrates with PyTorch, TensorFlow, and Hugging Face Transformers via autologging, and its tracking server can be self-hosted or run on Databricks.

Beyond the core four, two emerging AI-native tools are worth knowing. Writ creates per-agent checkpoints (called seals) and uses a convergence engine to merge overlapping changes from multiple agents before materialising a single clean Git commit. noa uses per-agent append-only JSONL logs and snapshot-based history while remaining compatible with the Git protocol, isolating agent work until it is ready to export into the working tree.

CI/CD integration works best when your pipeline pins artefact hashes rather than mutable tags. A GitHub Actions or GitLab CI step that calls dvc repro and logs the resulting run to MLflow gives you a reproducible, auditable build for every merge to main.

Practical workflows from experiment to production

The pattern that works reliably for most teams has three phases: experiment, review, and promote.

1. Branch per experiment. Create a feature branch for each hypothesis. Commit code changes to Git, push data changes via dvc push, and log every run to MLflow with a fixed random seed and a pinned dataset version.
2. Pin a composite version ID. Once a run looks promising, record the Git commit hash, DVC dataset hash, and MLflow run ID together in a version_manifest.json. This is the pinned version manifest that identifies the exact state of every dimension.
3. Canary promotion. Merge to a staging branch and route a small percentage of traffic to the new model version. Gate promotion on evaluation metrics: if the canary fails a threshold, the version policy layer stops the rollout and the previous pinned version stays live.
4. Production merge and registry update. On passing canary gates, merge to main, promote the MLflow model stage to Production, and tag the Git commit with the composite version ID.
5. Rollback. If a production issue emerges, revert the MLflow stage to the previous Archived version and redeploy. Because every dimension is pinned, rollback is deterministic.

Recording prompts and the agent's observed context at the moment of edit is often more valuable for debugging than later summarised notes — capture at authorship.

Pro Tip: Attach your system prompt hash to every MLflow run as a custom tag (mlflow.set_tag("prompt_hash", sha256(prompt))). When a regression appears weeks later, you can filter runs by prompt hash and isolate whether the prompt or the weights changed.

For agent-based systems, Agent Patterns recommends storing each agent run as a pinned manifest of prompt, tool, and policy hashes, with a policy layer that can allow or stop runs. This gives you the equivalent of a feature flag system for agent behaviour.

Storage, scaling, and UK compliance considerations

Storage costs and compliance obligations are inseparable for UK teams versioning training data.

Storage trade-offs:

• Git LFS is convenient but expensive at scale. Every version of a large file is stored separately, and egress fees from GitHub or GitLab's LFS storage can accumulate quickly on large datasets.
• DVC with an object store (Azure Blob in UK South, AWS S3 in eu-west-2) supports deduplication at the block level and long-term retention tiers. For most teams, this is the cost-effective choice beyond a few hundred gigabytes.
• On-premises object stores (MinIO, Ceph) eliminate egress costs and keep data within your own infrastructure, which matters for data residency.

UK-specific compliance points:

When training data includes personal data, versioning it creates a persistent, auditable record of that data's existence. Under UK GDPR (retained post-Brexit and administered by the ICO), you must be able to honour deletion requests. Immutable dataset snapshots and deletion requests are in tension: a snapshot that cannot be altered may retain personal data that a subject has requested be erased. The practical resolution is to anonymise or pseudonymise personal data before it enters the versioned dataset pipeline, and to document that decision in a Data Protection Impact Assessment (DPIA).

Operational checklist for UK teams:

• Encrypt datasets at rest (AES-256) and in transit (TLS 1.2 or higher).
• Apply role-based access controls to your object store and model registry so only authorised roles can read raw training data.
• Set retention policies: keep experiment artefacts for the duration of the project plus a defined audit window; delete raw personal data once anonymised versions are confirmed.
• Document data lineage in your DPIA, referencing the DVC dataset hash as the auditable identifier.
• For enterprise AI deployment, confirm that your object store region is within the UK or EEA before storing any personal data there.

When should you extend Git versus adopt an AI-native system?

The honest answer depends on the scale of your agent concurrency and how strict your provenance requirements are.

Extend Git when: your team is small (under ten engineers), you are in a proof-of-concept phase, your agents are not running concurrently on the same codebase, and your compliance requirements can be met with git notes and a model registry. The operational overhead is low, the tooling is familiar, and you can iterate quickly.

Consider an AI-native system when: you have many agents writing to the same repository concurrently, you need per-agent provenance at a granularity that git notes cannot provide efficiently, or your audit requirements demand a complete action trace rather than a commit-level summary. Tools like Writ and noa trade short-term integration friction for stronger multi-agent convergence and provenance fidelity.

For most UK teams in 2026, extending Git is the right starting point. Migrate to an AI-native layer only when the provenance gaps become a genuine operational problem, not in anticipation of one.

UK enterprise checklist before adopting AI version control

Work through this before committing to a stack or a vendor.

Governance and inventory:

• Catalogue every AI artefact currently in production: model weights, prompt templates, dataset versions, and configs.
• Identify which datasets contain personal data and complete a DPIA for each versioned pipeline.
• Define ownership: who approves a model promotion, who can trigger a rollback, who reviews prompt changes.

Technical readiness:

1. Confirm data residency: your object store region must comply with UK GDPR data transfer rules.
2. Implement role-based access control on the model registry and object store before onboarding the team.
3. Set up encryption at rest and in transit across every storage tier.
4. Define a key management policy (AWS KMS, Azure Key Vault, or equivalent).
5. Establish retention schedules for experiment artefacts, model versions, and raw training data.
6. Build a rollback plan: every production model version must have a tested rollback path, documented in your AI system maintenance runbook.

Procurement and vendor assessment:

• For managed or SaaS tooling, verify contractual data residency commitments and SLA terms.
• Confirm the vendor supports audit exports and e-discovery requests — a requirement for regulated UK sectors.
• Assess open-source dependencies (DVC, MLflow) for long-term maintainability and community health.

Rollout:

• Run a pilot on a non-production model with a small team. Measure time-to-reproduce a historical run as your primary success metric.
• Gate canary promotion on evaluation thresholds agreed in advance.
• Document rollback gates and assign a named owner for each gate decision.

Refer to AI change management guidance for the organisational process layer that sits alongside the technical checklist.

What the conventional wisdom on AI version control gets wrong

Most articles on this topic treat AI version control as a storage problem: where do you put the big files? That framing misses the harder challenge, which is provenance. You can store every model checkpoint perfectly and still be unable to explain why a model behaved differently on Tuesday than it did on Monday, because nobody recorded which prompt was active or what context the agent observed.

The teams that get this right treat prompts as first-class versioned artefacts from the start, not as configuration strings that live in environment variables. A prompt that changes without a corresponding version bump is the AI equivalent of a silent schema migration: everything looks fine until something breaks in a way you cannot trace.

There is also a tendency to over-engineer the tooling before the problem is understood. A team of three engineers does not need Writ's convergence engine. They need Git, DVC, MLflow, and the discipline to pin composite version IDs in every run manifest. The complexity should grow with the problem, not ahead of it.

For UK enterprises specifically, the compliance dimension is often treated as a legal afterthought. A DPIA for a versioned dataset pipeline is not bureaucracy: it is the document that lets you answer an ICO inquiry without panic.

Sources

Start with the conceptual framing, then move to tool docs, then to the AI-native implementations if your use case demands them.

• DVC
• MLflow
• memovai/mem (GitHub)
• Agent Patterns — agent versioning

Suggested reading order: the h5i.dev conceptual piece first, then DVC and MLflow quick starts, then the Agent Patterns governance guide, then the AI-native GitHub projects if your team is running concurrent agents.

Recommended

• Examples of AI system maintenance practices for IT teams
• AI observability explained for UK tech leaders
• API integration AI automation tools: the IT leader's guide