Registries, Approval, and Release Candidates

Registering a model makes it discoverable and gives it an identity. It does not prove that the candidate meets the production contract, or that its dependencies are still compatible.

A useful registry sits inside a release process. It stores or references immutable candidates, metadata, evidence, ownership, lifecycle state, and the mutable aliases used for routing.

A candidate can move through review while its immutable version stays fixed.

A tag is not a version. NIST's container security guide tells organisations to access images “using immutable names that specify discrete versions”. Under the heading “Stale images in registries” it explains why. A “latest” tag “is only a label attached to the image and not a guarantee of freshness”. That guidance is from September 2017. This failure is documented industry guidance, not a hypothetical.

Kubernetes describes the same mechanics from the other end. A registry can repoint a tag. Some Pods then run the old code and some run the new one, while every deployment manifest still reads the same. The fix it names is the digest. “An image digest uniquely identifies a specific version of the image, so Kubernetes runs the same code every time it starts a container with that image name and digest specified,” the Kubernetes documentation says. A model alias behaves exactly like a tag. A resolved model version behaves exactly like a digest.

A release candidate is stronger than a weight file. It should bind the runtime artifact, input and output contracts, transformation dependencies, evaluation report, known limitations, operational profile, and rollback target.

A regulator has already written down what such a bundle must contain when the model is expected to change. In the US, a device manufacturer can pre-authorise future model changes by getting a Predetermined Change Control Plan approved. The FDA's guidance defines it: “Predetermined Change Control Plan (PCCP): The documentation describing what modifications will be made to a device and how the modifications will be assessed.” A PCCP has to bind three things, and a metric table is not one of them: a Description of Modifications, a Modification Protocol — the verification and validation activities, with acceptance criteria fixed in advance — and an Impact Assessment. The FDA issued that guidance on 4 December 2024 and reissued it on 18 August 2025. The statute behind it, section 515C of the FD&C Act, dates from 29 December 2022.

The registry can index that bundle. Approval should evaluate the product contract. A candidate can be technically valid and still fail capacity, fairness, security, or workflow requirements.

Neither should be used as theatre, and a passing gate is not a substitute for the third column.

CrowdStrike's Channel File 291 update of 19 July 2024 is the demonstration. A Rapid Response Content bundle went straight to the whole fleet. The IPC Template Type defined 21 input parameter fields. The integration code that invoked the Content Interpreter supplied 20. The Content Validator passed the bundle anyway, because it too assumed 21 inputs, and the resulting out-of-bounds read crashed Windows hosts. Microsoft estimated 8.5 million Windows devices affected, less than one percent of all Windows machines. The automated gate ran and cleared the release. What was absent was traffic control.

The sixth finding of CrowdStrike's own root cause analysis, published on 6 August 2024, is titled “Template Instances should have staged deployment”. The mitigation added afterwards reads: “New Template Instances that have passed canary testing are to be successively promoted to wider deployment rings or rolled back if problems are detected.” Canary testing, deployment rings and bake-in time were not exotic requirements. They were the column this release skipped.

The workflow should preserve exact identity while allowing controlled routing: assemble the bundle, run automated gates, perform accountable review, assign a mutable route, and record the resolution.

Step 3 is where the scope of the approval gets written down, and in the EU that scope has a legal edge. The AI Act — Regulation (EU) 2024/1689, adopted on 13 June 2024 and published in the Official Journal on 12 July 2024 — requires in Article 43(4) that a high-risk AI system already assessed go through a new conformity assessment procedure in the event of a substantial modification. There is one carve-out, and it is the interesting part: “For high-risk AI systems that continue to learn after being placed on the market or put into service, changes to the high-risk AI system and its performance that have been pre-determined by the provider at the moment of the initial conformity assessment and are part of the information contained in the technical documentation referred to in point 2(f) of Annex IV, shall not constitute a substantial modification.”

Article 3(23) defines 'substantial modification' as a change “which is not foreseen or planned in the initial conformity assessment carried out by the provider”. That is what step 3 is recording: the envelope inside which later versions may be routed, and the boundary past which the approval is void. Registration belongs to the same discipline. Article 49(1) requires the provider, or where applicable the authorised representative, of a high-risk AI system listed in Annex III — other than those in point 2 of Annex III — to register themselves and their system in the EU database referred to in Article 71 before it is placed on the market or put into service. Step 5 then persists the exact version each deployment and decision resolved to.

A registry succeeds when engineers can find approved assets, compare evidence, reproduce how a candidate was chosen, and roll back without private knowledge. It fails when it becomes a catalog of orphaned experiments.

That is a codified practice rather than a preference. NIST SP 800-218, the Secure Software Development Framework, version 1.1 of February 2022, states it as a numbered task: “PS.3.1: Securely archive the necessary files and supporting data (e.g., integrity verification information, provenance data) to be retained for each software release.” PS.3.2 asks for collecting, safeguarding, maintaining and sharing provenance data for all components of each release — in an SBOM, for example. PS.2.1 requires making integrity verification information available.

The framework maps those tasks to Executive Order 14028 of 12 May 2021. Its section 4(e) requires “providing a purchaser a Software Bill of Materials (SBOM) for each product”, and requires “attesting to conformity with secure software development practices”. Retention and retirement rules should therefore be designed early. Otherwise the registry stops being an operational control and becomes an archive nobody trusts.