A scientific experiment has little value if another team cannot identify the instrument that produced its measurements. In AI, the instrument is increasingly a moving target. A model may retain the same public name while its underlying weights, instructions, safety layers, tool connections or serving configuration change. Researchers from King's College London, the Alan Turing Institute and the European AI Office argue in a paper published on 2 November that this gap between labels and deployed behaviour now threatens meaningful oversight.[1]
The paper, published in Nature Machine Intelligence, makes a case for versioning that conveys changes relevant to users, regulators and researchers rather than simply adding cosmetic numbers to product names. Its authors use the GPT-4o sycophancy episode as a case study, describing how changes in an AI system can alter interactions without providing outsiders with a sufficiently clear account of the modification. The example illustrates a broader governance issue; the paper is a proposal for better disclosure, not an announcement that every provider has already adopted it.[1]
What is a model version, exactly?
A service answering questions is rarely just a frozen collection of neural-network weights. The outcome can depend on system instructions, routing between models, retrieval indexes, moderation settings, external tools and sampling parameters. A vendor could hold the underlying model constant while changing one of these layers and produce very different answers. Conversely, a new internal deployment might not materially affect a particular use case. A useful version record should therefore describe the relevant system boundary and the significance of a change, rather than pretend that a version string captures every implementation detail.[1]
For a hospital evaluating a clinical drafting assistant, this distinction can be operational. A result from a February evaluation may no longer describe the product staff use in November. The hospital does not necessarily need the supplier's full training repository, but it does need to know when the tested behaviour or dependency chain changed enough to justify another assessment. The same problem affects legal, educational and public-sector uses, where a model's apparently identical name can make two audits seem comparable when they are not.[1]
The authors advocate a commitment-based approach to meaningful versioning. The word 'commitment' matters: an identifier should be attached to an accountable description of what was deployed and when. Disclosure must still be proportionate, because suppliers have legitimate security and commercial confidentiality concerns. The goal is independent traceability of consequential changes, not mandatory publication of secrets or weights. A hash of one component alone would be inadequate if the surrounding service continues to evolve invisibly.[1]
What a model name does and does not tell users
| Evidence or decision | What it actually establishes |
|---|---|
| Publication | Peer-reviewed Nature Machine Intelligence article, 2 November 2026Source 1 |
| Observed governance gap | Public model identifiers may remain unchanged across consequential system updatesSource 1 |
| Proposed direction | Meaningful, commitment-based version recordsSource 1 |
| Status | Academic policy proposal; not a binding universal version standardSource 1 |
Where reproducibility breaks
Suppose a researcher publishes an evaluation of a named model on a set of benchmark tasks. Months later another team repeats the exercise with the same published name and sees a different result. Without version provenance, it is difficult to separate sampling variability from changed instructions, tools or model routing. The two results may both be valid descriptions of distinct systems, yet the record can make them appear contradictory. This creates false confidence for procurement and false confusion in science.[1]
Versioning is also a legal and oversight question. Regulators may care about which deployed configuration generated a harmful decision and whether the provider made a risk-relevant modification after testing. A user asking for a correction needs more than an assurance that a feature has been 'updated'. A credible record would connect dates, tested configurations, scope of change and rollback options, while clearly marking what information remains unavailable.[1]
A feasible rather than perfect standard
A practical design could distinguish major behaviour-changing releases from minor maintenance updates and publish enough information for clients to decide when to rerun their own validation. A finance company could retain the version record alongside transaction logs; a research group could store it with its prompts, sampling settings and datasets; a government buyer could make version notice a contractual obligation. These are applications of the proposal, not new regulatory mandates arising automatically from the Nature paper.[1]
The hard question is enforcement. Suppliers can define their own categories too generously, while downstream product builders might unknowingly introduce changes that invalidate a model provider's earlier test. Meaningful versioning is thus a governance discipline spanning model, application and deployment. It is not a substitute for safety evaluation, but it can make evaluation results interpretable over time.[1]
The paper's central challenge is simple: if a system can change in consequential ways while keeping an unchanged name, neither trust nor scientific replication can rest on the name alone.[1]
Sources & further reading
- AI needs meaningful versioning Nature Machine Intelligence · 2 Nov 2026 · Accessed 2 Nov 2026