Git Repository Management & Branch Protection

Compliance-grade version control requires that every version is immutable once committed, attributable to a named individual with a verified identity, timestamped from a trusted source, and retrievable for the full ten-year retention period. These requirements shape the repository management and branch protection configuration.

The main branch, from which production deployments are made, must be protected. Direct commits are prohibited; all changes flow through a pull request workflow requiring at least one reviewer who was not the author, automated CI pipeline success before the merge is permitted, and AI Governance Lead approval for changes affecting fairness metrics, model architecture, intended purpose, or any AISDP-documented parameter. Branch protection rules are enforced at the repository platform level (GitHub, GitLab, or Bitbucket), not merely by convention.

Signed commits (GPG or SSH) cryptographically bind each commit to a verified identity, providing assurance that the change history is authentic. This matters for accountability under the QMS and for incident investigation. Write access follows the principle of least privilege: data scientists access model training code, data engineers access pipeline code, and infrastructure engineers access IaC definitions. Administrative access is restricted to designated repository administrators, and all administrative actions are logged.

Key outputs

• Branch protection configuration (review requirements, CI gates, signed commits)
• Access control matrix following least-privilege principles
• Administrative action logging
• Module 10 AISDP documentation

Mandatory Code Review

Every change to the AI system’s codebase must pass through a mandatory code review before reaching the main branch. The review requirement is enforced by the branch protection rules described in : a pull request cannot be merged without at least one approved review from a qualified reviewer.

Code review serves multiple compliance functions. It provides a second pair of eyes on changes that may affect the system’s behaviour, fairness characteristics, or security posture. It creates a documented record of the review (the reviewer’s identity, comments, and approval decision) that forms part of the Module 10 audit trail. It also creates an opportunity for the AI Governance Lead or their delegate to assess whether a change has compliance implications that require further analysis.

The review process should be structured to ensure that reviewers have the context they need. Pull request descriptions should explain the purpose of the change, its expected impact on the system’s behaviour, and any AISDP modules affected. For changes that touch fairness-sensitive code (feature engineering, thresholds, post-processing rules), the review should specifically address the fairness implications and reference any updated evaluation results.

Key outputs

• Mandatory code review enforced via branch protection
• Pull request template with compliance-relevant fields
• Review records retained as Module 10 and Module 2 evidence

CODEOWNERS Enforcement (Fairness Code, Thresholds, Feature Engineering)

CODEOWNERS files add a compliance-specific layer to the code review process by designating which roles must review changes to particular file paths. This is a machine-enforced control: a pull request that modifies a fairness-sensitive path cannot be merged until the designated reviewer approves it.

A reference CODEOWNERS configuration is provided below. AISDP threshold configurations and protected attribute definitions require AI Governance Lead approval. Model source code requires both AI Governance Lead and Technical SME review. Data handling code requires Technical SME and DPO Liaison review. Infrastructure and Kubernetes configurations require Technical SME and platform team review. CI/CD pipeline definitions and security policies require security team and Technical SME review.

The CODEOWNERS file transforms what would otherwise be a procedural expectation (“fairness code should be reviewed by the governance lead”) into an architectural constraint (“the platform will not permit a merge until the governance lead approves”). This distinction matters for conformity assessment: an assessor can verify that the constraint is in place and that the platform enforces it, providing stronger assurance than a policy document that may or may not be followed in practice.

Key outputs

• CODEOWNERS file mapping paths to required reviewers
• Platform configuration enforcing CODEOWNERS on protected branches
• Evidence of enforcement (blocked merges, approval records)
• Module 10 AISDP documentation