Engineering teams ship the newest model as soon as it's better. Regulators need the model that was live on the day a specific decision was made to still be inspectable three years later. This is a real architectural tension, and most enterprise AI deployments are structurally on the wrong side of it. The discipline that closes the gap has a name — model version pinning as a first-class governance primitive — and its absence is the specific failure mode that turns routine regulatory queries into disclosed material weaknesses.
There is a sentence that appears in incident reports, audit responses, and regulatory correspondence with increasing regularity as enterprise AI deployments hit their second and third year in production. The sentence takes different phrasings but always carries the same substance: "the decision in question was made under an earlier version of the model that has since been retrained and superseded, and the current version produces the following comparable output." It is offered as a good-faith engineering response to a regulatory query. It is received, increasingly, as evidence of a specific governance failure — that the organisation did not consider the retired model version to be evidence in its own right, worth preserving in a form that could answer questions about specific past decisions.
The sentence is a symptom of a deeper architectural pattern. In most enterprise AI systems, the model in production is a single, mutable artefact — a set of weights served by an inference endpoint, updated on a cadence determined by the ML team's judgement about when a newer version is materially better. The old version is retired. The new version is deployed. The transition is treated as a natural operational cadence, similar to how a web application ships a new frontend build. This pattern is coherent under the assumption that the AI system's function is to produce the best available output at any given moment. It is architecturally incompatible with the assumption that the AI system's function is to produce defensible outputs whose specific historical instances remain inspectable long after the moment of decision has passed.
The regulatory frameworks that increasingly govern AI-assisted decisions in financial services, climate disclosure, medical devices, and consequential public-sector determinations all converge on this second assumption. They are not asking whether the model is good today. They are asking whether the model was appropriate on the specific date it made the specific decision that is now under scrutiny, whether that historical model version can be produced as evidence, and whether the organisation can demonstrate governance over the transition from one version to the next. An engineering team that ships a superior model and retires the previous one is answering the wrong question about its own regulatory exposure. Model version pinning as a governance primitive is the architectural discipline that answers the right one.
This piece is about what that discipline actually requires, why it is unusually resisted by ML teams operating under normal engineering incentives, how it interacts with the increasingly common case of models being consumed as vendor APIs rather than self-hosted artefacts, and what the specific pattern looks like at organisations that have implemented it successfully.
Why the natural engineering cadence produces the wrong regulatory posture
The cultural tension here deserves to be named directly. ML teams have strong, correct engineering incentives to ship newer models as soon as they meaningfully outperform current versions. Improved accuracy on the held-out evaluation set is a signal that the newer model is better; retaining the older version wastes inference cost, review capacity, and monitoring surface. Every mature MLOps playbook treats model rollout as a continuous process, with the old version replaced by the new one once the promotion criteria have been met. This is good engineering discipline for systems whose function is to serve the best output.
It is the wrong discipline for systems whose function is to serve auditable outputs. The three failure modes that surface from this mismatch are worth naming precisely.
The first failure mode is historical inspectability. When an auditor or regulator asks about a decision made six months ago, the operational engineering answer is that the model in production is the current version, that the decision in question was made under an earlier version, and that the earlier version has been retired. What follows is a negotiation about whether the current version's output is close enough to serve as a reasonable substitute. Under substantive regulatory reading of AI governance obligations, the current version's output is not a substitute — it is a different response to a different question. The specific decision was made against specific model weights, and the auditor's right to inspect that decision includes the right to inspect the model that produced it. An organisation that cannot produce the exact weights that were serving on a specific historical date has, in the regulator's framing, discarded evidence.
The second failure mode is transition governance. Every model retraining or version transition is itself an event with regulatory implications. Did the new model preserve the calibration properties of the old one? Were the disparate-impact metrics evaluated against the same protected classes? Was the review threshold recalibrated to account for changes in the score distribution? The answers to these questions form the evidentiary basis for the claim that the transition was well-governed. An engineering team that treats retraining as routine operational cadence, without capturing the transition as a first-class governance event with its own documentation, has produced a system whose current output is defensible but whose historical trajectory is not. Regulators are increasingly instrumented to notice that the current defensibility of a model does not imply that the transitions producing it were governed.
The third failure mode is liability chain continuity. When a decision produced by an earlier model version turns out to have been consequential — a fraudulent transaction that was scored as legitimate, an ESG disclosure that was validated when it should not have been, a clinical recommendation that was inappropriate for the patient — the question of institutional responsibility depends on who was accountable for the specific model that made the specific decision. If the organisation cannot reconstruct the model version, the training data lineage, the promotion decision that put that version into production, and the governance sign-off that authorised its use for the specific decision class, then the liability chain has broken. What the organisation is left with is a general defence about its overall AI governance posture, which is a weaker legal position than a specific reconstruction of the governed decision.
These three failure modes compound over the deployment's lifetime. In the first six months of a production AI system, there are typically one or two model versions to keep track of, and the operational cadence of replacement is manageable. By year three, a system that has retrained monthly has cycled through thirty-plus model versions, and every historical decision the auditor might ask about is attached to a version that no longer exists in the production infrastructure. Retrofitting model version pinning at that point is architecturally possible but its fidelity is unverifiable — the organisation is reconstructing historical versions from training data checkpoints, MLOps logs, and code repository state, none of which was designed to be evidence.
What model version pinning as a first-class primitive requires
The pattern I'll describe here was developed through my independent research and refined in the model registry design I built for the DCarbon client engagement delivered via SustainGRC, and has been carried into the PinkMate R&D work on how the discipline ports down to organisations without a dedicated MLOps function. It treats model version pinning as a governance primitive with four properties: immutable version artefacts, concurrent lifecycle staging, transition-event governance, and decision-to-version binding. Each property addresses one aspect of the audit and liability posture that natural engineering cadence undermines. Each is load-bearing.
Immutable version artefacts
The first property is that every model version that has ever served a production decision must be preserved as an immutable, self-contained artefact that can be resurrected and served in the future without dependency on ambient infrastructure. Not a reference to the version. Not a checkpoint in the training pipeline. The complete artefact — model weights, tokenizer state where relevant, preprocessing pipeline configuration, inference-time hyperparameters, and any environment configuration that affects deterministic behaviour — bundled together with a cryptographic hash of its content and stored in an append-only registry whose access controls are governance-legible.
The engineering discipline is that a version artefact must be serve-reproducible. Given the artefact, an engineer three years from now must be able to instantiate an inference endpoint that produces the same output the historical version produced against the same input. This is a stronger claim than "we saved the weights" — it requires that the artefact carries everything needed to reconstruct the inference behaviour, including tokenizer versions, preprocessing steps, and library-level configurations that affect determinism. In practice, the cleanest pattern is to store the artefact as a container image with the weights and all supporting infrastructure baked in, alongside a serialised specification of the inference contract. A container image plus a specification is an artefact whose future serve-reproducibility is a matter of infrastructure availability, not archaeological reconstruction.
The storage cost is real but bounded. In the DCarbon engagement pipeline I built, retained model artefacts across roughly two years of production consumed on the order of a few hundred gigabytes — negligible relative to the overall data infrastructure cost and materially cheaper than the cost of failing to produce a historical model version under regulatory query. The organisational discipline is more demanding than the infrastructure cost: every model that has served a decision must be preserved for at least the retention period that regulatory obligations require, which for financial services and climate disclosure is typically five to seven years and for medical devices can extend to a decade or more.
Concurrent lifecycle staging
The second property addresses transition governance. At any moment, the model registry must be capable of serving multiple concurrent versions of the same model, each attached to a specific lifecycle stage — the current production version, the previous version retained for query response, the candidate version undergoing validation, and any historical versions still within their retention window. Each version has its own inference endpoint, its own monitoring surface, and its own governance metadata attached.
This is a stronger claim than "we can roll back if the new version misbehaves." Rollback capability is a purely operational property — the ability to revert production traffic to the previous version quickly. Concurrent lifecycle staging is a governance property — the ability to simultaneously serve the current production version to live traffic while also serving the previous version to audit-replay queries and the candidate version to validation traffic, without the three interfering with each other.
The practical implementation in the DCarbon engagement pipeline was a routing layer in front of the inference infrastructure that resolved model version requests to specific artefact instances based on the query context. A live scoring request routed to the current production version. An audit-replay request for a historical decision routed to the version that was in production at the decision's timestamp. A validation request for a candidate version routed to the candidate. All three requests could be served concurrently from the same underlying infrastructure, with the routing layer maintaining the invariant that each request received the specific version its context required.
This is architecturally more demanding than serving a single production model, but it is not prohibitive. The routing layer is a small addition to a standard inference gateway; the concurrent serving is a scaling problem, not an architecture problem. The organisational discipline is that the concurrent staging pattern must be built in from the beginning, because retrofitting it against a system that has always served a single model version means retrofitting it against an inference gateway that was not designed to route by version.
Transition-event governance
The third property is that every promotion of a candidate version to production, every retirement of a previous version, and every emergency rollback must be a first-class governance event with its own audit trail. Not a Slack message. Not a git commit. A structured event record capturing the decision, the evidence base supporting it (validation metrics, drift analyses, disparate-impact evaluations), the sign-off from the accountable party, and the timestamp at which the transition became effective for production traffic.
The reason is direct: regulators are not asking whether the current model is well-calibrated; they are asking whether the transition from the previous model to the current one was well-governed. A model that is well-calibrated today but whose promotion from the previous version was undocumented is a model whose current calibration cannot be evidentially attributed to a governed decision. It might be well-calibrated by luck, by drift, by an unrelated infrastructure change, or by the outcome of a promotion whose validation was inadequate. Without a transition-event record, none of these possibilities can be ruled out.
The engineering discipline here is that transition events must be cryptographically bound to the specific artefact versions they concern. A transition event that says "we promoted model version 2.3.1 to production on 14 March" is not self-verifying — it depends on the reader trusting that "2.3.1" refers to the artefact currently labelled 2.3.1. A transition event that says "we promoted the model whose artefact hash is [signed value] to production on 14 March" is self-verifying against the registry — the artefact with that hash either exists and matches, or the transition event is inconsistent with the registry state, which is itself a detectable and reportable condition.
Decision-to-version binding
The fourth property closes the loop with audit replay. Every production decision the system produces must carry, as part of its persisted event record, the specific model version that produced it — not the model name, not the version identifier alone, but a reference that resolves deterministically to the exact artefact in the registry.
This is the property that makes audit replay actually work. Article 10 of this series described how state-complete event persistence enables reconstruction of the state a decision was made against. Decision-to-version binding extends that reconstruction to include the specific model artefact that operated on the state. Together, they close the audit-replay contract: given a decision reference, the system can reconstruct the exact state, the exact model version, and the exact output, with cryptographic proof of fidelity for each.
The practical implementation is that the decision event record includes the artefact hash of the model version that produced it, and the persistence layer verifies that this hash resolves to a valid registry entry before the event is accepted as committed. This adds a small validation step to the write path but produces an evidentiary property that is materially more defensible than a decision record that names a model version by string identifier alone.
The vendor-API problem: what happens when the model is not yours
The pattern above assumes the organisation controls the model artefact. Increasingly, this assumption does not hold. Enterprise AI deployments consuming OpenAI, Anthropic, Google, or specialised vendor endpoints are consuming models whose versioning is controlled by the vendor, whose specific weights are not accessible to the deployer, and whose historical availability depends on the vendor's own retention policies. This creates a distinct set of governance failure modes that industry discourse has largely not caught up to.
The first is vendor-side model retirement. When a vendor deprecates a model version, the organisation that was relying on that version for regulated decisions loses the ability to reproduce those decisions with the specific artefact that produced them. The vendor's replacement version, whatever its merits, is a different model. An audit query about a decision made under the deprecated version has no direct answer.
The second is silent behavioural drift. Vendor APIs typically do not guarantee bit-for-bit output stability even for the same version identifier over time. Underlying infrastructure changes, safety training updates, and routing decisions between backend model instances can all produce output variation that the deployer cannot detect or attribute. A decision made in March against "the same model version" that is queried in September may have been produced by materially different underlying weights.
The third is evidentiary opacity. When the vendor is the source of truth for what the model is, the deployer cannot cryptographically bind decisions to specific artefacts. The deployer can bind decisions to vendor-reported version identifiers, which is a weaker guarantee. Under substantive regulatory reading, this weaker guarantee is often insufficient — the audit chain requires provable state, and provable state requires artefacts the deployer controls.
The mitigation pattern that has emerged in mature deployments is a form of behavioural fingerprinting. Rather than depending on the vendor to provide artefact-level version guarantees, the deployer maintains a rolling calibration suite — a small, versioned set of inputs whose expected outputs are recorded periodically. When the vendor's API produces outputs that diverge materially from the calibration baseline, the deployer treats this as evidence of a version transition and captures the transition as a governance event on their own side. This does not solve the artefact-inaccessibility problem, but it produces a deployer-side record of when the behavioural surface changed, which is often sufficient to answer regulatory queries about what version of the vendor's model was in effect at a specific decision timestamp.
The deeper architectural response is to route regulated decisions through models whose artefacts the organisation can control — either self-hosted open-weights models or vendor arrangements that explicitly guarantee artefact retention and behavioural stability. The engineering discipline is to recognise that using an opaque vendor API for a regulated decision transfers a governance obligation the organisation still carries but no longer has the mechanism to satisfy. Under EBA guidelines on outsourcing, this transfer is itself a governance decision that requires documented sign-off. Under EU AI Act Article 25's obligations on providers of high-risk AI systems, the vendor may share some of the burden, but the deployer remains accountable for the specific decisions the system produces.
What the mature regulatory analogue looks like
There is a specific regulatory framework that has already worked through the version-pinning question at institutional depth, and it is worth naming because it offers the clearest precedent for where AI governance in other sectors is heading. The FDA's guidance on artificial intelligence and machine learning in medical devices distinguishes between locked models (which do not learn from live data and whose behaviour is fixed at the time of clearance) and adaptive models (which continue learning in production and whose behaviour changes over time). The regulatory treatment of the two is materially different. Locked models can be cleared through standard device pathways and their post-clearance obligations are limited to monitoring for real-world performance drift. Adaptive models require a pre-authorised change control plan — the FDA's Predetermined Change Control Plan mechanism — that specifies in advance what changes are permitted, how they will be evaluated, and how they will be reported.
The specific mechanism is illuminating: for adaptive models, the FDA does not attempt to review every model version transition after the fact. Instead, it requires the manufacturer to specify in advance the governed envelope of change within which model updates can occur without new regulatory review, and to preserve evidence that specific updates fell within that envelope. Model version pinning as a governance primitive is the mechanism that makes this evidentiary claim possible — without artefact-level retention and transition-event governance, the manufacturer cannot demonstrate that a specific historical update was inside the pre-authorised envelope.
Financial services and climate disclosure regulation are moving toward the same mechanism, if with different specific vocabulary. PRA SS1/23's model risk management expectations increasingly treat retraining as a governed event whose validation must be documented, whose approval must be attributable to a named accountable party, and whose effects on the model inventory must be tracked. EU AI Act Article 12's logging obligations require that high-risk AI systems maintain records enabling traceability of the system's functioning throughout its lifecycle, which under substantive interpretation includes version-level traceability. The regulatory trajectory across sectors is that the FDA's medical-device pattern will become the mainstream template for AI governance in any consequential decision domain.
Organisations that build model version pinning as a first-class primitive now are building on the right side of that trajectory. Organisations that treat model rollout as ordinary operational cadence will find themselves retrofitting the discipline against a deployment history that was not designed to support it, at meaningfully greater cost and with meaningfully weaker evidentiary standing.
The mid-market pattern
The pipeline I built for the DCarbon engagement had the engineering capacity to implement all four properties at production scale. PinkMate R&D has been surfacing that mid-market organisations can implement a materially simpler version that produces most of the evidentiary value.
For a mid-market deployment, the practical pattern is: store model artefacts as container images in an append-only object store with retention policies aligned to regulatory obligations, use a lightweight routing layer (an inference gateway configured with version-based routing rules) to support concurrent serving of the current and previous versions, record transition events as structured entries in the same governance system that captures other material engineering decisions, and bind decisions to version identifiers with a periodic cryptographic checkpoint that binds those identifiers to the underlying artefacts.
This is meaningfully less sophisticated than a full production model registry with cryptographic binding on every decision. It is meaningfully more disciplined than the natural engineering cadence of "ship the newer model and retire the old one." Under the majority of realistic regulatory queries — including the ones that most mid-market organisations are actually likely to receive — it produces evidentiary responses of sufficient fidelity to close the query without escalation.
The engineering discipline is not in the sophistication of the implementation. It is in the decision, made early, that model version transitions are governance events rather than operational cadence, and that model artefacts are evidence rather than infrastructure. Once that decision is made, the specific implementation can scale to the organisation's engineering capacity. If the decision is not made, no sophistication of implementation later will fully recover the historical fidelity that was lost by treating each retired model as disposable.
What this pattern does not solve
Model version pinning solves the problem of reconstructing the specific model artefact that produced a specific historical decision. It does not solve the problem of training data lineage — the question of what data the model was trained on and how that data was governed at the time of training. This is a distinct governance discipline with its own architectural requirements, and it interacts with version pinning but is not subsumed by it.
Nor does version pinning solve the problem of causal attribution — the question of why a specific model version produced a specific output for a specific input. For deterministic classifiers, causal attribution is partially answerable through the same attribution-stability discipline discussed in earlier pieces in this series. For genuinely stochastic decoding systems, it is not fully answerable, and the version-pinning discipline is scoped to what it can defend: the artefact, the input state, the output, and the governance around each. What the model was "thinking" is a separate question and one the current state of interpretability research cannot fully answer regardless of how well-pinned the model version is.
Naming these limits is part of the honest engineering. Version pinning is a load-bearing property of audit-defensible AI, but it is one property among several. An organisation that implements it in isolation, without the escalation layer, the audit-replay infrastructure, the training-data lineage discipline, and the attribution-stability practices it must sit alongside, has an AI governance posture with one strong pillar and several weak ones. The evidentiary standing of the deployment is set by the weakest of those pillars, not by the strongest.
Where this is heading
The regulatory trajectory across every consequential AI deployment domain is toward treating model versions as evidence, model transitions as governed events, and decision-to-version binding as an evidentiary requirement rather than an operational nicety. Organisations that internalise this now — building the four properties described above as first-class architecture rather than retrofitting them later — are positioning themselves to answer the specific class of regulatory query that most enterprise deployments are structurally unable to answer today.
The sentence that opened this piece — "the decision was made under an earlier version of the model that has since been retrained" — is going to become one of the most consequentially wrong sentences an organisation can offer in a regulatory response over the next three years. Not because retraining is prohibited, and not because organisations are expected never to improve their models, but because the sentence reveals a governance posture in which retired model versions are treated as disposable rather than as evidence. The organisations that have retired versions preserved as immutable artefacts, bound to the specific decisions they produced, with governed transition records connecting them to their successors, do not need to write that sentence. They can produce the actual model version and the actual decision context, and let the evidence speak.
The engineering discipline this piece is arguing for is not exotic. It is the specific architectural commitment that separates AI deployments designed to serve the best current output from AI deployments designed to serve defensible outputs whose specific historical instances remain inspectable. That distinction sounds like an implementation detail. It is architectural. And in the regulatory environment that is now materialising across financial services, climate disclosure, medical devices, and public-sector determinations, it is the difference between AI governance postures that survive scrutiny and AI governance postures that do not.
This is article 11 in a series on the engineering economics of regulated AI. Prior pieces have covered provenance graphs, multimodal validation for climate risk, runtime enforcement, the reproducibility crisis, attribution stability, deterministic orchestration, the cost model for auditable AI, the escalation layer for substantive human oversight, and audit replay as the forgotten half of reproducibility. The next piece will address drift detection under regulatory constraints — the difference between statistical drift monitoring and regulator-defensible drift response, and why the two are less overlapping than most enterprise MLOps teams realise.
