Storage is the least interesting thing it does
An object store holds artefacts perfectly well. What it cannot tell you is which of the forty files under models/ is authoritative, which one is serving traffic right now, which one served traffic in March, who decided that, and what evidence they had. Those are the questions a registry exists to answer, and they are questions about authority rather than about bytes.
The clearest way to see the difference is to consider what happens when someone leaves the team. With a bucket and a naming convention, the knowledge of which artefact matters lives in a person's head and in a deployment script. With a registry, it lives in a queryable record: version 17 of credit-risk is in production, promoted on the fourteenth by a named approver, superseding version 15, on the strength of an attached evaluation report.
Lineage means links to immutable things
The registry entry for a version should let you walk backwards to everything that determined it. The dataset snapshot identifier, not the table name. The code commit, with a clean-tree flag. The resolved configuration including hyperparameters and the feature list. The container image digest for the training environment. The identifier of the training run in whatever tracking system produced it, so the loss curves and intermediate metrics remain reachable. The evaluation report as it stood at promotion, including the metric values and the slices they were computed on.
The word doing the work in that list is identifier. A lineage field that records "trained on the customer table" records a name whose contents have since changed, which is a description rather than a link. A field that records a snapshot id resolves to a fixed set of rows. The whole value of the registry rests on this distinction, and it is where an implementation is usually weakest.
The forward direction matters equally and is more often missing. Given a data snapshot you have just discovered to be corrupt, which model versions were trained on it, and which of those ever served? That query is what turns a data incident into a bounded remediation instead of an open-ended audit, and it is only answerable if lineage was stored as structured links rather than as free text in a description field.
Stage transitions are events, not a mutable label
A registry version carries a stage — staging, production, archived, or whatever vocabulary you adopt. The important design point is that the transition between stages is an event with an actor, a timestamp and a reason, appended to a history, and not merely a field that gets overwritten.
This is what lets you answer questions after the fact. When did version 15 stop being production? Who approved 17? Was 16 ever promoted, or did it fail its gate? Overwrite a stage field and every one of those answers is destroyed by the next promotion. Append transitions and the history of the model in production is reconstructable, which is precisely what an auditor, a post-incident review and a "when did this regression start" investigation all need.
Approval belongs in the same record. Whether the approver is a human in a regulated workflow or an automated gate that evaluated a threshold, the transition should say which, and if it was automated it should reference the evaluation that authorised it. An approval you cannot attribute is not a control.
Serving resolves a version, and logs the one it resolved
The registry earns its place at runtime by giving the serving path a stable handle. The service is configured with an alias — the production version of credit-risk — resolves it at load time to a concrete version and an immutable artefact, and then logs that concrete version on every prediction it makes.
That last step is the one that closes the loop, and it is the reason this question is worth asking. Without it you know which model is deployed now and you can never establish which model produced a specific past decision. With it, a prediction record carries credit-risk/17, the registry resolves 17 to its data, code and evaluation, and the chain from a customer's outcome back to the training set that shaped it is complete.
prediction log registry lineage
------------- -------- -------
model: credit-risk/17 --> version 17 --> snapshot ds-2026-06-30-a
--> commit 9f3c1ab (clean)
--> image sha256:8b1e...
--> eval report-4471
transitions:
2026-07-14 staging -> production (approver: a.rao)
2026-07-30 production -> archived (superseded by 19)
Note that the high-volume side of that sketch carries one short string. Everything expensive is stored once per version and reached by reference, which is what makes per-request traceability affordable.
Why deployment scripts do not substitute
Teams often argue they already have this: the deployment pipeline records what it shipped, so the git history of the config repository is the registry. It is a reasonable position and it fails in a specific way. The deployment record tells you which artefact path was configured, not what that artefact was trained on, whether it passed evaluation, or whether the file at that path is still the file that was there. It also has no representation for a model that exists, has been evaluated, and has deliberately not been promoted — which is most of the models you train.
The related trap is treating the registry as a passive catalogue that something else updates after the fact. If a model can reach production by any route that does not pass through the registry — an engineer copying a file, a service reading a path from an environment variable — then the registry is documentation, and documentation drifts. It has to be the mechanism, so that the only way to deploy is to promote, and the only way to promote is to leave a record.
The registry answers "which model, on whose authority, trained on what" for every version, including the ones that never shipped. If a model can reach production without passing through it, it is a catalogue rather than a control.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).