MLflow now drives lifecycle promotion inside SageMaker's model registry

Start with the register call. A data scientist logs a model during a training run and registers it with a single MLflow call ^[9]. If the app has its model registration mode set to AutoModelRegistrationEnabled, that call creates a matching Model Package Group and Package version in the SageMaker AI Model Registry ^[8][10]. Four categories of metadata then land in the registry view in SageMaker Studio ^[12]: run metadata, which AWS lists as model parameters, training metrics, the training dataset location and the model artifact path ^[13]; evaluation metrics, attached as a model card that renders on the Evaluate tab ^[14]; an inference specification naming the container image, the model data location and the supported instance types ^[15]; and the lineage associated with the run ^[10].

Two of those four are the data scientist's homework. The inference specification and the evaluation metrics are optional artifacts, attached before registration and then carried into the Model Package ^[11]. Run metadata and lineage fall out of the run itself ^[10]. So half the metadata a governance officer reviews is opt-in per run ^[21]. A reviewer working from the registry alone is reviewing whatever the training code chose to attach.

The inference specification is also a claim about deployability, not a test of it. AWS says the spec lets you deploy directly from the registry ^[15], and then says the package is genuinely deployable only if the model artifacts include the inference handler, for example an inference.py packaged with the model ^[16]. A Package version can therefore look complete on the Evaluate tab and still fail at deploy time.

AWS keeps MLflow as the system of record for experiments and logged models, and makes the Model Registry the system of record for registered models moving through the production lifecycle ^[17]. Lifecycle stage promotion is driven from MLflow ^[4]. Approval, audit and control of which models reach production still sit with the governance officer in the registry ^[18]. The review surface moved: staging-to-production, which previously could not be triggered from the MLflow workflow at all ^[6], is now a call the data scientist makes and the registry records, while the underlying model and its artifacts stay exactly where they were logged.

That also bounds the word authoritative. The sync fires on MLflow registration ^[10], so the registry is complete for exactly the candidates that pass through that MLflow app, and no others. In the single-account walkthrough, the separation between the two personas is IAM guardrails rather than account boundaries ^[20], which means the governance boundary is a policy document.

The adoption work sits in the MLflow app's IAM service role, which needs permission to create Model Package Groups and versions, add tags, and record lineage associations ^[7]. Grant less than that and the registry entry arrives about as thin as the old one, which synced without metrics, evaluation results or lineage and sent the reviewer back into MLflow by hand ^[5]. The default for the whole feature is disabled ^[8], so an account where nobody sets it stays unchanged.