Change management is the discipline of putting every change to a system on the record before it happens: proposed, reviewed, approved, applied, and kept. Here a change is a merge request. The agent or the operator proposes it on a branch, the checks run, the operator reads it and merges it, and the history of those requests is the record of how the estate came to be what it is.
The US government’s catalog of security controls describes the same thing as a control of its own:
Configuration change control for organizational systems involves the systematic proposal, justification, implementation, testing, review, and disposition of system changes, including system upgrades and modifications.
Why it matters more with an agent
Most changes here are drafted by the agent: 555 of the 593 commits made before 15 September 2026 came from agent sessions, and every one says so in the commit itself. The operator merges every change. So each merge is the point where the partner with a memory accepts work from the partner without one.
The record matters in the other direction too. The agent does not remember why a change was made, but the merge request and its commit message do. When a later session needs to know why something is the way it is, the history is the only place the reasoning survives.
None of this is new
The same control expects a body to do the approving: “Processes for managing configuration changes to systems include Configuration Control Boards or Change Advisory Boards that review and approve proposed changes.” It also expects the process to cover “unscheduled or unauthorized changes”, the ones that never went near a board.
In 2012 Martin Fowler pointed out that code gives you the record almost for free: “If you disable any direct shell access to the server and force all configuration changes to be applied by running the recipe from version control, you have an excellent audit mechanism that ensures every change to the environment is logged.” And he knew who would care: “This approach can be very welcome in regulated environments.”
What the record bought here
- An unbroken history. Since 18 August 2026, 525 changes have reached the main branch, every one through a merge request and none pushed directly, measured from the history on 15 September 2026.
- Authorship on every change. Each commit says whether it was drafted in an agent session, so the record shows not only what changed but which of us wrote it.
- A record that survived a rebuild. The merge-request history is the one thing here that no code can reproduce. On 4 September 2026 the Git server that holds it was deleted and rebuilt, and the history came back exactly: 308 merge requests and 1,021 notes, restored and counted against the backup.
Where we fall short
It was a habit before it was a rule. Measured on 15 September 2026, the main branch refused a force-push, but a maintainer could still push to it directly. Every one of those 525 changes came through a merge request because that is how we work, not because anything stopped us doing otherwise. The setting was changed the same day: the branch now refuses a direct push from everyone. An approval and a passing pipeline are still not required, so what the server enforces is that a change arrives as a request, not that anyone read it.
The record ends at the merge. A merge says a change was accepted, not that it reached the machines. Every apply is a person running the code afterwards, and on 31 August 2026 a merged change was believed live twice in one session while the machine still ran the old one. Automatic pipelines have been off since 30 August 2026, by the operator’s call, so nothing ties the two.
Some changes never reach the record. A network switch here has only a web interface, so no code can drive it, and its changes are made by hand and written up afterwards. And logging in to a machine is not disabled, as Fowler’s version asks. We log in to measure. Only the rule stops a change made there by hand.