The pull request as the new unit of governance

Somewhere in your organisation there is a spreadsheet, or a Confluence page, or a quarterly ritual involving screenshots, whose purpose is to demonstrate to an auditor that changes to production systems are authorised, reviewed, tested and traceable. Somebody owns it. They probably do not enjoy owning it. Once or twice a year they go around asking engineers for evidence about work those engineers did eight months ago, and the engineers reconstruct it from memory and Slack history, and everyone signs something.

Now here is the odd part. Every single fact in that spreadsheet already existed, precisely and with timestamps, in the version control system. Who proposed the change. What exactly changed. Who approved it. What tests ran and what they returned. When it merged. Which release it went into. The evidence was always there. The organisation just chose to maintain a parallel, lower-quality, human-curated copy of it, because the compliance function and the engineering function grew up in different buildings and never agreed on a shared artefact.

That has been quietly changing for a decade. Agents are what make it urgent, because the parallel copy was already unreliable and is now impossible: you cannot ask an engineer to attest from memory to changes they did not personally make, at a volume nobody is tracking.

So the controls collapse onto the artefact where the evidence actually lives. The pull request stops being a code review mechanism and becomes the place where governance happens.

What the PR was designed for

Worth remembering how modest the original purpose was. The pull request was a lightweight social protocol for open source: here is a change, please look at it, merge it if you like it. It was designed to let strangers propose code to a maintainer without commit access. That is it. There was no notion of compliance, no idea of authorisation, no thought of it being an audit artefact.

Everything else got bolted on afterwards, mostly by accident, mostly because it was the convenient place. Required approvals. Status checks. Branch protection. Signed commits. Code owners. Deployment gates. Each of these was added by someone solving a local problem, and the aggregate is an unplanned governance system that is now, for most software organisations, the single most authoritative record of how change happens.

Being explicit about that unplanned convergence is useful, because it means you can start designing it rather than accreting it.

What a governed change carries

If the pull request is the unit of governance, what does it need to carry? I would argue five things, and most teams have between two and three of them.

Intent. What was this change for, expressed as a link to a work item that states the desired outcome. Not the commit message, which describes what changed. The intent is upstream of the change and is what makes it possible to judge whether the change was appropriate at all. In practice this is a link, and the link has to be reliable rather than conventional, which is precisely where most teams are weak. Branch naming conventions are followed by disciplined humans and inconsistently by everything else.

Criteria and their verdict. What did done mean for this, and was it met. This is the part that used to be entirely tacit, resolved by a human approver applying judgement they never wrote down. Making it explicit is the single largest change in the list, and it is what the second piece in this series was about.

Authorship and authority. Who or what produced this change, and under whose authority did it act. This used to be trivially answered by the commit author. It is now genuinely complicated: an agent produced the diff, a human triggered the agent, a policy allowed the agent to act on that repository, and a model version determined how it behaved. All four are relevant to an incident investigation and none of them is captured by “author: ci-bot.”

Verification evidence. What checks ran, in what version, and what they returned. Not a green tick, which is a summary and loses the information you need six months later. The actual record: which suite, which commit of the suite, which results.

Approval and its basis. Who or what approved it, and on what basis. “Approved by policy: tier three, all checks passed, no protected paths touched” is a legitimate approval and is more informative than a human’s thumbs-up, because it states its reasoning. The important property is not that a human approved it but that the basis for approval is recorded and reviewable.

Together those five make a change accountable: you can reconstruct, without asking anyone, why this change exists, what it was supposed to do, whether it did it, who is responsible, and why it was allowed through.

IntentA link to a work item stating the desired outcome. Not the commit message, which describes what changed.

Criteria and their verdictWhat done meant here, and whether it was met. Used to be entirely tacit inside an approver's judgement.

Authorship and authorityWho or what produced this, and under whose authority it acted. Trivially answered by the commit author until recently.

Verification evidenceWhich checks ran, in what version, and what they returned. Not a green tick, which is a summary that loses what you need in six months.

Approval and its basis"Approved by policy: tier three, all checks passed, no protected paths touched" is a legitimate and more informative approval than a name.

Signing and reversibility

Two properties turn a record into evidence, and both get skipped.

The first is attribution that cannot be forged. If governance rests on the pull request, then the identity of the actor matters. An agent operating with a shared service account is indistinguishable from any other use of that account, which means your audit chain terminates in an anonymous credential. Distinct identities per agent, signed commits, and an unambiguous record of which automation acted are not paranoia; they are the difference between a record and a rumour. This is one of the things that seems fussy until the first incident where you need to know which of eleven automated processes touched a config file.

The second is reversibility. Any automated action should be undoable, and the undo should be a first-class operation rather than an archaeological expedition. This matters more than people expect, because it changes the risk calculation on automation itself. A team will not let software move their tickets, gate their merges or write to their systems of record unless they are confident they can put things back. Reversibility is what makes automation politically acceptable, not just technically safe.

This is the design centre of what we build with GroundTruth: every automated change signed into a chain that can be inspected and reversed. But the principle is independent of any product, and if you are building this yourself, the failure mode to avoid is a log. A log tells you what happened. It does not let you undo it, and it usually cannot prove it was not edited.

The compliance argument is better than the compliance function expects

There is an opportunity here that engineering teams routinely fail to press, and it is worth pressing because it converts a cost centre into an argument for the whole approach.

Most software change controls in regulated environments (change authorised before implementation, segregation of duties between author and approver, testing evidence retained, changes traceable to a requirement, emergency changes documented after the fact) are satisfied better by a well-designed pull request pipeline than by the manual process that currently claims to satisfy them.

Better in specific ways. The evidence is contemporaneous rather than reconstructed. It is complete rather than sampled. It cannot be quietly backdated. It covers one hundred percent of changes rather than the ones somebody remembered to log. Any honest auditor prefers a system where the control is enforced mechanically over one where it is asserted retrospectively by the person being audited.

The obstacle is almost never the regulation. It is that the control was originally written down in terms of the manual process, so the audit asks “show me the change advisory board minutes” rather than “show me that changes were authorised.” Mapping the control intent onto the pipeline evidence is a translation exercise, and it usually requires one engineer and one compliance person spending a genuinely unpleasant afternoon together. That afternoon has a better return than almost anything else either of them will do that quarter.

Evidence reconstructed for audit

• Assembled quarterly from memory and screenshots
• Sampled, not complete
• Can be quietly backdated
• A parallel copy that was already unreliable

Evidence produced contemporaneously

• Recorded at the moment it happened
• Covers one hundred percent of changes
• Cannot be backdated
• Already exists, with timestamps

The one control that gets legitimately harder is segregation of duties. When an agent writes the code and a human approves it, is that separation or not? The human did not write it, so formally yes. But if the human triggered the agent, specified the work, and reviewed the output, the independence is thinner than the control intends. I do not think the industry has a settled answer, and anyone who tells you it is obviously fine is not thinking about it hard enough.

The failure mode: ceremony without meaning

The predictable way this goes wrong is that the pull request accumulates required fields and mandatory checks until it becomes a form, and the form becomes something people route around.

You can watch it happen. Someone adds a required template with eight sections. Someone adds a mandatory security questionnaire. Someone adds a second approver requirement for a class of change that turns out to be forty percent of all changes. Each addition is individually reasonable and defended by a genuine incident. Within a year, opening a pull request costs twenty minutes of paperwork, and the response is not better compliance. The response is bigger pull requests (to amortise the overhead), longer-lived branches, and a healthy trade in emergency exceptions.

The discipline that prevents this is to insist every gate be machine-evaluated or deleted. A required field that a human fills in with free text is a tax with no enforcement. A check that verifies a property automatically is a control. If you cannot express the requirement as something a machine can evaluate, you have not understood the requirement well enough to enforce it, and adding it as a text box is worse than leaving it out because it creates the appearance of a control where none exists.

Machine-evaluated or deleted. A required field a human fills with free text is a tax with no enforcement; a check nothing acts on is a checkbox.

And governance load should scale with risk. A dependency bump and a change to payment authorisation should not carry the same ceremony, and a system that treats them alike will be routed around at exactly the wrong end.

The corollary is that governance load should scale with risk, which is the same argument as the tiering in the piece on code review. A dependency bump and a change to the payment authorisation path should not pass through the same checklist, and a system that treats them identically is telling you it has not thought about either.

Where this breaks down

The limits, and the first two are structural.

Not all change flows through pull requests. This is the largest gap and it is growing rather than shrinking. Infrastructure changed through a cloud console. Feature flags flipped in a SaaS dashboard. Database migrations run by hand during an incident. Configuration changed in a vendor’s admin UI. Machine learning models retrained and promoted through a pipeline nobody governs. Every one of these is a production change and none of them appears in your beautifully governed repository. A team that believes it has full change governance because its pull requests are locked down often has a wide-open side door, and the side door is where the outages come from.

Emergency changes break the model and always will. Production is down at 3am. Somebody fixes it directly. Every governance design has an emergency path, and the emergency path is where controls are actually tested. The realistic goal is not to prevent this but to make the after-the-fact reconciliation cheap and mandatory, so the exception gets recorded rather than forgotten.

Governance concentrated in one artefact is a concentrated risk. If the pull request is where authorisation lives, then your version control platform is now part of your control plane, and a compromise of it, or a misconfiguration of branch protection, or an over-privileged integration token, undermines everything at once. Distributed manual processes were slow and inconsistent and, in a narrow sense, more resilient to a single failure. Putting all the controls in one place means that place needs a level of security attention it probably is not getting.

Signed provenance is only as strong as the weakest identity in the chain. Signing is straightforward. Ensuring every automated actor has a distinct, non-shared, correctly-scoped identity across every tool in a real organisation is not, and most teams have at least one shared token doing something important. The audit chain is exactly as trustworthy as that token.

And the segregation of duties question is genuinely open. I raised it above and I want to end on it rather than resolve it, because a resolution would be dishonest. When the volume of automated change is high and the human role is specification and sampling, the traditional author-approver separation is being satisfied in form more than in substance. Regulators have not caught up. When they do, some of the arrangements teams are running today will not survive contact.

The takeaway

Every control an organisation cares about is converging on an artefact designed for none of them, and that is mostly the right outcome, because the evidence lives there and it lives there contemporaneously rather than reconstructed.

Making it deliberate means five things on every change: intent, criteria and verdict, authorship and authority, verification evidence, and the basis for approval. Plus attribution that cannot be forged and actions that can be reversed. And one rule that keeps the whole thing from turning into a form: every gate is machine-evaluated or deleted.

If the change is the unit of governance, then the boundaries between the people and systems that touch it matter enormously. The next piece looks at what happens to handoffs when there are fewer humans in the chain and more machine boundaries in it, and why the number of transitions can go up even as headcount goes down.