Skip to content

Model Registry and Artifact Lifecycle by Scale

Last updated: 2026-05-24

A model registry is the identity and lifecycle system for release-affecting ML artifacts. In autonomy, that scope is broader than model weights: it includes ONNX/TensorRT engines, containers, calibration-aware packages, semantic maps, map-hygiene layers, prompt packs, offboard labelers, evaluator packs, replay packs, feature/embedding snapshots, adapter weights, rollback bundles, and signed evidence records.

Use this page to design registry semantics across S0-S5 MLOps. Use model-governance-release-evidence.md for claims-and-evidence release packets, secure-artifact-attestation-profile.md for signatures and provenance, evaluation-platform-replay-gates-by-scale.md for evaluation/replay gates, serving-inference-operations-by-scale.md for serving manifests, endpoint traffic policy, batch/online/edge scope, and rollback load paths, pipeline-orchestration-release-workflows-by-scale.md for artifact-producing workflows, and ../ota/perception-slam-artifact-compatibility-matrix.md for the artifact-set compatibility manifest.

The core rule is: aliases are authority, not labels. Moving candidate, shadow, champion, rollback, site_champion, or quarantined changes what downstream systems may load, evaluate, deploy, mine, or trust. Alias movement should therefore be gated by evidence, policy, owner, rollback state, and scope.


Registry Scope

Artifact familyRegistry responsibilityWhy it matters
Model weights/checkpointImmutable version, source run, dataset/split lineage, metric evidence, output digestPrevents ambiguous "latest model" handoffs
Runtime packageONNX/TensorRT engine, container digest, class order, hardware target, dependency lockPrevents offline checkpoint approval from bypassing deployability checks
Serving endpoint or batch serviceService manifest, traffic policy, input/output contract, autoscaling, telemetry, rollback routePrevents a valid artifact from being served to the wrong client, site, or ODD cell
Adapter or LoRAParent model, site/task scope, training data, compatibility, rollback pairPrevents local adapters from becoming invisible production variants
Semantic map or map layerMap bundle, source-map acceptance, semantic taxonomy, map-hygiene layer, release statePrevents wrong map truth from contaminating runtime or training exports
Calibration-aware bundleSensor kit, calibration package, time-sync assumptions, hardware cohortPrevents model/map approval from moving across incompatible vehicles
Prompt/labeler/evaluator packPrompt text, model ID, retrieval corpus, thresholds, judge/evaluator version, reviewer workflowPrevents generated labels or scores from silently changing release evidence
Replay/evaluation packScenario suite, evaluator container, metric spec, expected behavior, waiver statePrevents release gates from drifting without version identity
Feature/embedding snapshotSource corpus, feature code, embedding model, index build, point-in-time proof, deletion statePrevents stale retrieval or feature leakage from affecting training/eval
Evidence/attestation bundleSBOM, provenance, signature, policy result, approval, retention classProves the artifact was built and approved through the trusted path

At S2+, registry identity should be immutable even when aliases are mutable. At S4+, registry records should be retained with evidence for the audit and incident window.


Scale Ladder

MLOps scaleRegistry postureMinimum controlAnti-pattern to block
S0 notebook researchFile path plus run noteCommit hash, config, data pointer, metric output, checkpoint hash when reusedReusing an unlabeled checkpoint as a baseline
S1 repeatable prototypeLightweight model/artifact registry or DVC/W&B/MLflow artifact entryImmutable version, baseline alias, dataset/split link, evaluator versionlatest becomes the only reference
S2 production productProduct registry with controlled aliasescandidate, shadow, champion, rollback, evidence links, runtime package, approval metadataTraining job directly moves production alias
S3 fleet and multi-siteSite/ODD-scoped registry lifecycleSite aliases, release channels, artifact-set compatibility, local holdouts, canary scopeOne global champion hides local site regressions
S4 regulated safety-criticalEvidence-locked registryDual approval, safety-case links, signed attestations, waiver expiry, rollback drill, retention holdAlias movement without immutable evidence and reportability context
S5 platform scaleMulti-tenant registry serviceNamespaces, policy-as-code, audit API, lifecycle SLOs, exception workflow, cross-product inventoryTeams fork registries or bypass shared alias policy

The same repository can contain artifacts at different scales. A research detector can remain S1 while a semantic-map publisher is S4 and a prompt-based offboard labeler is S5 because it feeds multiple product teams.


Lifecycle States

StateMeaningAllowed next states
scratchLocal experiment artifact with no reuse guaranteepreserved, deprecated
preservedArchived for reproducibility or comparisonbaseline_candidate, deprecated
baseline_candidateProposed as comparable baselinebaseline, rejected, deprecated
baselineAccepted comparison pointcandidate, deprecated
candidateReviewable artifact with complete registry identityshadow, rejected, quarantined
shadowRuns without behavior authoritysite_canary, champion, rejected, quarantined
site_canaryLimited authority in a named ODD cellsite_champion, restricted, rollback, quarantined
site_championApproved for one ODD cellexpanded, restricted, rollback, deprecated
championApproved default for a defined product scopeexpanded, rollback, deprecated
restrictedApproved with exclusions or mitigationschampion, rollback, deprecated
rollbackKnown-good artifact set retained for recoverychampion, deprecated after rollback window
quarantinedArtifact is unsafe, incompatible, stale, or under incident reviewrejected, repaired_candidate, deprecated
deprecatedNot used for new release decisionsRetention or deletion after policy allows

Do not rely only on tool-native states. MLflow aliases, W&B aliases, SageMaker approval statuses, Vertex model aliases, and Kubeflow registry metadata can support lifecycle control, but the autonomy program still needs its own authority semantics and ODD scope.


Alias Policy

AliasRequired evidence before assignmentScope rule
baselineFrozen split, evaluator version, reproducible run, limitation noteModel family or task
candidateRun manifest, dataset/split IDs, output digest, evaluation manifest, artifact recordProduct or artifact family
shadowRuntime package smoke, replay smoke, telemetry schema, rollback targetSite/vehicle cohort if live
site_canaryODD-cell manifest, local holdout, replay, monitor thresholds, on-call ownerOne ODD cell only
site_championSite-sliced release decision, delayed-label review, rollback proofSite, route, task, map/calibration state
championRelease packet, approver record, compatibility manifest, attestations, rollback targetExplicit product scope
rollbackPrevious compatible artifact set, cache state, load test, retention holdSame runtime/map/schema scope as active release
quarantinedIncident, drift, compatibility, evidence, or security triggerBlocks loading except for investigation
deprecatedReplacement, end-of-life decision, retention policy, consumers notifiedCannot be target of new release

Avoid aliases that imply authority without scope. production is ambiguous unless the registry record names product, site, task, runtime, map, calibration, telemetry schema, and ODD.


Registry Record Contract

Every release-relevant artifact should have a registry record that can be queried by humans and machines.

FieldRequired contents
artifact_idImmutable ID, version, type, digest, storage URI, owner
artifact_familyModel, adapter, engine, container, map, calibration bundle, prompt pack, evaluator pack, replay pack, feature snapshot, evidence bundle
authority_stateLifecycle state and allowed-use scope
producerWorkflow ID, code commit, container digest, builder identity, dirty-state disposition
inputsDataset, split, feature/embedding snapshot, map, calibration, taxonomy, prompt, evaluator, replay, or parent-model IDs
evaluationEvaluation manifest IDs, metric spec, replay suite, runtime smoke, known failures, waiver state
compatibilityModel/map/calibration/runtime/telemetry/taxonomy compatibility hash and rollback set
deployment_scopeProduct, site, route, task, vehicle kit, weather/lighting, release channel, data residency
securitySignature, SBOM, provenance, vulnerability disposition, policy result
governanceApprovers, release packet, safety-case claim IDs, exception/waiver owner, expiry
retentionEvidence class, legal/safety hold, deletion eligibility, consumer notification state
lineage_queriesReverse links to active deployments, training data consumers, labels, maps, incidents, and monitoring events

At S5, the registry should expose an audit API that answers: "Which artifact versions can influence this vehicle/site right now?" and "Which data, labelers, evaluators, maps, and prompts influenced this artifact?"


Architecture Options

Registry architectureAdvantagesDisadvantagesBest use
Folder plus Markdown release noteCheap, transparent, no service dependencyWeak queryability, alias drift, poor multi-user controlS0 exploration only
Git/DVC artifact manifestReproducible, reviewable, good for data snapshotsNot ideal for mutable deployment aliases or high-volume artifact metadataS1 baselines and offline artifacts
MLflow Model RegistryStrong experiment/run integration, aliases/tags, model loading by aliasNeeds extra metadata for maps, calibration, safety evidence, and non-model artifactsS1-S3 model lifecycle and small platform teams
W&B Registry/artifactsStrong artifact lineage and alias workflows, good UX for teamsRegistry authority and safety gates need external policy integrationS1-S3 research-to-product handoffs
SageMaker Model RegistryManaged model groups, versions, approval status, deployment integrationAWS coupling and custom autonomy metadata need disciplined extensionsAWS-native S2-S4 product lanes
Vertex AI Model RegistryManaged model versioning, aliases, evaluation/deploy/test integrationGCP coupling and limited fit for custom map/replay artifactsGCP-native S2-S4 model lifecycles
Kubeflow Model RegistryKubernetes-native platform component, open-source extensibilityRequires platform ownership and metadata disciplineS3-S5 self-hosted platform teams
OCI/artifact registry plus metadata DBDigest-native, works for containers, engines, SBOMs, arbitrary artifactsNeeds custom lifecycle UI/API and release semanticsRuntime packages, signed artifacts, edge deployment
Custom autonomy registryCan represent model/map/calibration/replay/site semantics exactlyExpensive to build and easy to under-maintainS4-S5 when standard registries cannot express safety scope

A pragmatic architecture is often split: MLflow/W&B/SageMaker/Vertex/Kubeflow for model versions, OCI registry for runtime containers and engines, data catalog for datasets/features, and a thin autonomy artifact-set registry that binds them into one compatibility and release record.


Artifact-Set Registry

Autonomy releases are artifact sets, not single models.

Artifact-set memberCompatibility question
Model or adapterWas it trained and evaluated for this taxonomy, ODD, and runtime package?
Runtime engine/containerDoes the deployed artifact match the evaluated package and target hardware?
Serving service manifestDoes the endpoint, batch job, traffic split, input/output schema, telemetry, and scaling policy match the approved scope?
Semantic map/map layerDoes the map state, release-state layer, and taxonomy match the model contract?
Calibration packageDoes the sensor kit and time-sync state match training/eval/replay evidence?
Telemetry schemaCan monitoring, canary, and incident replay interpret outputs correctly?
Prompt/labeler/evaluator packDid any generated label, score, or report affect the artifact or release decision?
Replay/evaluation packDid the artifact pass the exact scenario and metric suite required for the scope?
Rollback setCan the previous known-good set still load under active runtime and schema?

The registry should store both member IDs and a compatibility hash over the member set. If any member changes, the release evidence must either be invalidated or explicitly reviewed as compatible.


Deletion, Retention, and Rebuild

Artifact stateRetention rule
Scratch artifactDelete after short TTL unless referenced by preserved run note
Baseline artifactRetain while comparisons depend on it
Candidate artifactRetain until rejected and no incident/review depends on it
Shadow/canary artifactRetain through delayed-label window and rollback window
Champion/site championRetain while deployed plus evidence/incident window
Rollback artifactRetain and periodically load-test until no active deployment depends on it
Safety-evidence artifactRetain under legal/safety policy; do not garbage-collect from cost-only rules
Quarantined artifactRetain until root cause, consumers, and corrective action are closed

Deletion should be dependency-aware. A model can be deleted only if no active deployment, replay result, safety case, label batch, map export, incident, or rollback set depends on it.


Managed-Site and Semantic-Map Rules

For airside, port, yard, campus, warehouse, construction, mine, and urban-district mapping applications:

  • Registry aliases must be scoped by ODD cell when local map state, route/task, weather, or vehicle kit changes behavior.
  • Semantic maps require registry records for source-map acceptance, map-hygiene layers, release-state labels, taxonomy version, projection/calibration evidence, and map-publication decision.
  • LiDAR-only, LiDAR-image fusion, image-distilled, and open-vocabulary/offboard labeler routes must register different artifact dependencies. A LiDAR-only runtime model cannot inherit an image-dependent evaluation claim unless the dependency is explicitly train-time only.
  • Stationary people, parked movable assets, cones, pallets, FOD candidates, construction barriers, and temporary work-zone objects must remain registry-visible as removal, quarantine, or release-state decisions when they influence map publication or training export.
  • Local adapters and thresholds should be first-class registry artifacts. A site-specific threshold file can change safety behavior as much as a model checkpoint.

The registry is therefore also a map and label governance system. It must prevent a reviewed map truth, candidate label, removed dynamic residual, and release-approved static point from collapsing into the same unqualified artifact.


Failure Modes

Failure modeConsequenceControl
Mutable latest drives deploymentFleet loads an unreviewed artifactLoad by immutable version or gated alias only
Alias has no ODD scopeOne site approval becomes global approvalRequire site/task/map/calibration scope on authority aliases
Registry lacks runtime package identityCheckpoint passes but deployed engine failsRegister model package, engine/container, and compatibility hash
Registry lacks map/calibration identityModel runs against unseen geometry or sensor stateBind artifact set to map and calibration package
Rollback artifact expiresRecovery requires emergency rebuildLoad-test and retain rollback sets through active window
Quarantined artifact remains consumableBad data/model/map continues to affect training or evidenceRegistry policy blocks downstream use by state
Foundation-model labeler is not registeredPrompt/model drift changes labels invisiblyRegister prompt/model/retrieval/threshold/reviewer state
Registry is used as evidence store onlyRelease packets exist but no deployment controlEnforce aliases and deployment admission against registry state
Registry becomes too slowTeams bypass it with local artifactsPlatform SLOs, self-service templates, and narrow mandatory fields

  • mlops-scale-research-scope.md - MLOps maturity ladder and lifecycle controls.
  • mlops-reference-architectures-by-scale.md - registry placement, durable interfaces, and architecture patterns.
  • mlops-migration-checklist-by-scale.md - triggers for moving from local artifacts to managed registry services.
  • mlops-scorecards-and-kpis-by-scale.md - registry, release, rollback, and evidence KPIs.
  • model-governance-release-evidence.md - claims-and-evidence release packets and approval ownership.
  • evaluation-platform-replay-gates-by-scale.md - evaluation manifests and replay/runtime gates before alias movement.
  • serving-inference-operations-by-scale.md - serving manifests, traffic policy, endpoint readiness, autoscaling, ODD-cell rollout, and rollback.
  • platform-sre-reliability-by-scale.md - registry SLOs, alias audit durability, backup/restore, DR, tenant isolation, and platform incident controls.
  • secure-artifact-attestation-profile.md - signing, SBOM, provenance, and policy verification.
  • pipeline-orchestration-release-workflows-by-scale.md - workflow states that produce and promote artifacts.
  • site-sliced-release-evidence-by-scale.md - ODD-cell release manifests and site-scoped aliases.
  • offboard-labeler-registry-by-scale.md - prompt, labeler, evaluator, threshold, and reviewer artifact governance.
  • feature-embedding-store-ops-by-scale.md - feature/vector index identity and deletion propagation.
  • ../data-platform/data-catalog-lineage-quality-ops.md - dataset, label, feature, replay, and semantic-map data-product contracts that registry records must cite.
  • ../ota/perception-slam-artifact-compatibility-matrix.md - artifact-set compatibility manifest.
  • ../ota/software-update-management-system-ops.md - OTA/SUMS update and rollback controls.
  • ../../40-runtime-systems/ml-deployment/production-ml-deployment.md - production loading, canary, monitoring, and rollback.
  • ../../30-autonomy-stack/perception/overview/aggregated-map-semantic-segmentation.md - semantic-map release-state and artifact dependencies.

Sources

Public research notes collected from public sources.