Versioned Governance for Frontier AI: A Software-Engineering-Inspired Approach
This paper proposes a software-engineering-inspired framework for AI governance that addresses the "silent drift" of normative policies by advocating for granular versioning, classified change logs, and explicit rollback mechanisms to ensure transparent, auditable, and regulatorily accepted policy evolution.
Original paper licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
Imagine a world where the rules governing powerful artificial intelligence systems are written down in public documents, much like the terms of service for a website or the safety manual for a factory. These documents tell us what the AI is allowed to do, what it must refuse to do, and how its creators promise to keep it safe. For the people who build these systems, the rules are not static; they change constantly as the technology evolves. A rule that seemed safe today might need tightening tomorrow, or a new capability might require a brand-new permission. The problem arises when these changes happen without a clear, public record of what was altered, why it was altered, and who had the authority to make the change. This lack of a clear history creates a situation where the rules drift silently over time. An outsider, such as a journalist, a judge, or a company trying to use the technology, cannot tell if a sentence in the document was merely polished for better grammar or if it fundamentally shifted the boundaries of what the AI is permitted to do.
This silence is dangerous because it breaks the trust required for society to rely on these systems. If a court needs to judge an event that happened last year, they need to know exactly what the rules were at that time, not the rules as they exist today. If a company certified its safety based on a policy from six months ago, they need to know if that policy still means the same thing. Currently, the way these documents are updated often fails to provide this clarity. The changes are real, but the record of them is missing or confusing. This leaves everyone outside the laboratory guessing about the true nature of the rules that govern the technology they are using or regulating.
A researcher named Zhixin Xue has examined this problem and proposed a solution inspired by how software engineers manage code. In the world of computer programming, when developers update a program, they use a strict system to track every change. They assign version numbers that tell users exactly how significant a change is: a major number change means a big, potentially incompatible update; a minor number change means a new feature that still works with the old system; and a patch number means a small fix. They also keep detailed logs that explain exactly what changed and why. Xue argues that the documents governing artificial intelligence should be treated with the same level of discipline. Instead of just posting a new version of a policy without context, the labs should use a structured system that classifies every change, explains the reason for it, and keeps a permanent, unchangeable record of the history.
To test whether this approach is needed and how it could work, Xue looked at five major sets of rules that govern frontier AI systems between 2019 and 2025. These included the usage policies and model specifications from OpenAI, the Responsible Scaling Policy from Anthropic, the European Union's Artificial Intelligence Act, and the Risk Management Framework from the US National Institute of Standards and Technology. The researcher analyzed how these documents were revised over time, looking for signs of this kind of disciplined tracking. The study found that while some of these documents have started to use version numbers and dated lists of changes, they are missing the most critical parts of the system. Specifically, the documents rarely explain whether a change is a major shift in the rules or just a small clarification. They also lack a clear mechanism for rolling back a change if it turns out to be a mistake.
The analysis revealed a pattern the author calls "silent drift." In the real-world examples studied, the most significant changes to the rules often happened in response to sudden, external events, such as the public release of a new, more powerful AI model. However, the documentation of these changes did not keep up. The lists of changes that did exist were often just summaries written in plain language, which described what happened but did not classify the importance of the change. This forces the reader to guess whether a change is minor or major. Furthermore, none of the five instruments studied included a formal way to reverse a policy change if it caused problems. While the laws and standards from governments and international bodies were better at tracking their versions than the private companies, they were still slower to adapt and lacked specific mechanisms for undoing changes.
The paper suggests that the solution is not to invent entirely new laws or institutions, but to adopt a specific, lightweight framework that any laboratory could use immediately. This framework would require that every time a policy document is updated, the author must declare the type of change using a four-level system: major, minor, patch, or build. A major change would be one that alters the fundamental boundaries of what is allowed or prohibited. A minor change would add new scenarios or procedures without changing the core principles. A patch would be a clarification or correction that does not change the meaning. A build would be a version adapted for a specific region or group. Along with this classification, the update would need a detailed log explaining the change and a plan for how to reverse it if necessary.
Crucially, the paper argues that the system must treat the act of misclassifying a change as a recordable event. If a lab claims a change is just a small patch, but an auditor or regulator later determines it was actually a major shift in the rules, that mistake must be logged publicly. This creates a reputation cost for hiding the true nature of changes. The study notes that while software engineers sometimes fail to follow these strict versioning rules perfectly, the discipline works best when there are consequences for getting it wrong. By making the classification of changes a public, auditable claim, the framework aims to make the "silent drift" visible and accountable.
The findings indicate that the tools to solve this problem already exist in the software industry, but they have not been fully applied to the documents that govern AI. The gap is not a lack of technical ability, but a lack of incentive and discipline. The research concludes that as AI systems become more powerful and their rules change more frequently, the need for a clear, versioned history of those rules becomes essential. Without it, the rules governing these powerful systems remain opaque and difficult to trust. With a structured approach, the changes can be made transparent, allowing regulators, courts, and the public to understand exactly how the rules have evolved and to hold the creators accountable for the decisions they make.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.