Version Control Governance: CODEOWNERS, Reviews, and Approvals

Version control governance defines who can change what, under which conditions, and with whose approval. Without governance, the version control system captures a history of changes but provides no control over whether those changes should have been made. The main branch from which production deployments are made must be protected, with direct commits prohibited by the technical owner. All changes must flow through a pull request or merge request workflow that requires at least one reviewer who was not the author of the change, automated CI pipeline success before merge is permitted, and ai governance lead approval for changes that affect fairness metrics, model architecture, intended purpose, or any AISDP-documented parameter.

Branch protection rules are enforced at the repository level, not merely by convention. They are documented as part of the qms and remain auditable at all times.

CODEOWNERS files add a layer of compliance-specific, machine-enforced review to the pull request workflow. Paths that affect the model's fairness characteristics, such as feature engineering code, training configuration, post-processing rules, and threshold values, require review from a designated fairness reviewer. Paths that affect security, including authentication, encryption, and access control, require security review. Paths that affect the AISDP documentation require review from the AI Governance Lead or their delegate.

The enforcement is automatic: a pull request that modifies a fairness-sensitive path cannot be merged until the designated fairness reviewer approves it. The Technical Owner configures the corresponding branch protection via the repository API or UI to require status checks to pass, at least one approving review from a CODEOWNERS match, no direct pushes to main, and signed commits. GitHub Branch Protection Rules, GitLab Protected Branches, and Bitbucket Branch Permissions all support this configuration.

The Technical Owner tags candidate releases with semantic version numbers following a major.minor.patch scheme. Major version increments correspond to changes that trigger a substantial modification assessment. Minor version increments correspond to changes that improve the system within its existing compliance envelope. Patch increments correspond to bug fixes and maintenance updates.

The Technical Owner documents the release tagging scheme in the AISDP, keeping it consistent across all repositories covering code, model, data, configuration, and documentation artefacts. This consistency ensures that any deployed version can be traced back to a single, unambiguous release identifier across the full artefact chain.

Write access to version-controlled repositories follows the principle of least privilege. Data scientists hold write access to model training code and experiment configurations. Data engineers hold write access to data pipeline code. Infrastructure engineers hold write access to infrastructure-as-code definitions.

No single role should have unrestricted write access across all artefact types. Administrative access, meaning the ability to modify branch protection rules, access controls, or repository settings, is restricted by the Technical Owner to designated repository administrators and logged. The version control system's own audit trail, recording who logged in, who changed permissions, and who approved which merge, is retained by the conformity assessment coordinator as compliance evidence. This meta-level audit trail is distinct from the version history of the artefacts themselves; it records the governance of the governance system.

Compliance-grade version control means that every artefact in the AI system, including code, data, model, configuration, infrastructure definition, and documentation, has a complete, immutable change history with attribution. Standard software version control achieves this for code; the compliance challenge is extending the same rigour to artefacts that Git was not designed for.

The three-repository pattern provides the architectural structure. A code repository using Git holds application code, pipeline definitions, configuration files, test suites, and IaC templates. A data repository using DVC, Delta Lake, or LakeFS holds dataset versions, feature store snapshots, and data quality baselines. A model repository using MLflow, W&B, or a cloud-native model registry holds trained model artefacts, evaluation results, and model cards.

Each repository has its own versioning mechanism, but they are linked through cross-references: a model registry entry references the Git commit and the DVC data version that produced it, and a Git commit references the DVC data version it was validated against. This linkage is what makes the version control compliance-grade. Given any deployed model version, the organisation can trace back to the exact code, data, configuration, and pipeline execution that produced it. Given any historical inference, the organisation can identify the model version that processed it and the full provenance chain. This end-to-end traceability is the evidentiary foundation for Annex IV documentation.

Signed commits address attribution integrity by cryptographically binding each commit to a verified identity. A standard Git commit records an author name and email, but these fields are self-reported and can be spoofed. GPG or SSH commit signing eliminates this weakness.

For compliance purposes, signed commits provide assurance that the change history is authentic: the person who Git records as making a change is the person who actually made it. This matters for accountability under the QMS and for incident investigation. GitHub, GitLab, and Bitbucket all support commit signature verification and can be configured to require signed commits on protected branches.

Secrets such as API keys, database credentials, and encryption keys must never appear in the Git history. Tools like git-secrets or truffleHog scan commits for accidentally committed secrets, providing an automated safety net. For configuration files that include encrypted values, Git-crypt or Mozilla SOPS provide file-level encryption within the repository.

In production, the engineering team sources secrets from a dedicated secrets manager such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault, never from the repository itself. This separation ensures that even if the repository is compromised, production credentials remain protected.

Branch protection rules and CODEOWNERS files are platform features requiring GitHub, GitLab, or Bitbucket, but the governance intent can be achieved procedurally through documented review policies and manual enforcement. A documented merge policy states that no code reaches the main branch without at least one approved review from a reviewer listed in the review matrix. That review matrix, equivalent to CODEOWNERS, maps file paths to required reviewers.

A single named repository administrator holds exclusive merge permission to the main branch and verifies that the review matrix requirements are met before merging. The trade-off is the loss of automated enforcement: the process depends on the administrator's discipline, and a lapse in merging without proper review creates a compliance gap with no automatic detection. Organisations using the procedural alternative should implement periodic audits of the merge history to detect any lapses. Signed commits require GPG tooling, which is freely available, and can be adopted regardless of the hosting platform.