Approve a reproducible model release package

Learning objective

Version, review, and approve custom model artifacts with SageMaker Model Registry. Make the approval refer to an identifiable deployment candidate and the evidence that supports its intended use.

Core idea

A model artifact is not a release decision. SageMaker Model Registry organizes model versions, their deployment specifications, metadata, and approval status. Use it to answer which candidate was reviewed, what evidence the reviewers saw, and whether that candidate is approved for the intended deployment.

Approval needs a reproducible subject. If the bytes behind a registered artifact location change after review, the registry entry can still look familiar while referring to different behavior. Your release process must preserve artifact identity and connect it to the exact model package version.

How it works

Register versions within a model group

Create a Model Package Group for versions solving a defined problem. Register each release candidate as a new version in that group. The registry assigns version identities; the model package ARN distinguishes a particular candidate from its family. Do not use a human label such as “latest” as the production release identity.

CreateModelPackage is the registration mechanism. ModelPackageGroupName associates the package with a group, and InferenceSpecification describes how it can be served, including its container and model artifacts. The versioned package is a deployable specification, not merely a folder containing training output.

Keep the inference container and model data consistent with the reviewed configuration. A custom model that passes offline tests under one tokenizer, container, or serving format can behave differently under another. Include those dependencies in the release evidence rather than assuming that the weights alone define the product.

For a LoRA candidate, record the adapter and its exact base-model compatibility; see 1.2.6. A merged release and a dynamic adapter release need different artifact descriptions. The registry should let a reviewer reconstruct which one was tested, not leave that choice to the deployer’s interpretation.

Attach evidence to the candidate

CreateModelPackage supports ModelMetrics for metric reports and CustomerMetadataProperties for custom key-value metadata. Its ModelCard contains ModelCardContent and ModelCardStatus; use the model card to document intended use and known limitations. MetadataProperties can associate source details such as CommitId and Repository. Use these fields to connect the candidate to its use constraints, evaluation reports, and the code that produced or packaged it.

Keep full evidence in durable artifacts and store precise references in the release record. Useful evidence includes the evaluation dataset version, measured quality slices, latency and throughput results, intended use, known limitations, and adapter compatibility where applicable. The field names are mechanisms; the rubric and release thresholds are your application policy.

Separate evidence from the decision. A quality report can show a candidate meeting a threshold without authorizing its use in every environment or task. A reviewer should be able to see both the measured outcomes and the scope to which the approval applies.

Freeze artifact content for the release. Use unique artifact locations or another verifiable immutable identity and retain the reviewed data instead of overwriting a shared object key. Registry versioning does not excuse mutating the deployment inputs. Preserve previous approved artifacts for rollback; see 1.2.8.

Review and update approval status

The API approval states are PendingManualApproval, Approved, and Rejected. Register an unreviewed candidate as PendingManualApproval. After the release gates are satisfied, an authorized reviewer or controlled workflow can update the package through UpdateModelPackage and its ModelApprovalStatus field.

AWS also documents pipeline condition steps that evaluate a model against requirements. Use a deterministic threshold gate for measures that can be assessed automatically, then retain human review where the decision requires judgment. A pipeline that sets Approved because training completed has implemented a completion gate, not a quality gate.

Distinguish the package’s service status from its approval state. Successful package creation says registration completed. Approved says the release decision permits deployment through the registry path. Neither proves that an endpoint is already serving the candidate or that every production request will be correct.

The review should consider failures, not just gains. Compare with the previous approved version and inspect critical task slices, output validation, and operating behavior. An average improvement can hide a regression for the customer group that carries the highest consequence.

Connect approval to deployment deliberately

The Model Registry documentation describes CI/CD deployment triggered by approval changes in configured SageMaker AI project templates. An EventBridge rule that matches a model approval event can initiate that deployment workflow. A registry entry does not create an arbitrary production endpoint automatically in every account.

Bind the deployment workflow to the exact approved package ARN and validate its status when promoting it. Keep deployment permissions and approval permissions aligned with the team’s review process. Registry approval is not a general substitute for controlling who can deploy other artifacts through other routes. Approval reaches deployment through an approval event that a configured rule matches, and the workflow validates the exact package before promoting it.

Inspect the configured transition behavior. AWS’s provided project-template flow can deploy the latest approved version when a previously approved version becomes rejected. That is a workflow-specific response, not proof that changing a status field alone rolls every existing endpoint back. Your incident procedure must name the pipeline and target it expects to change.

Key distinctions and trade-offs

Model group versus model version: The group organizes related candidates. The package version identifies the particular reviewed deployment subject.

Metadata versus immutable content: Metadata helps explain provenance. It cannot prove that mutable artifact bytes still match the reviewed candidate.

Approval versus deployment: Approval grants release eligibility. A configured deployment workflow creates or updates the serving resource.

Automatic gates reduce review delay and improve consistency for objective measures. Manual approval can add judgment for intended use and material risks. Combine them around explicit evidence so neither becomes a ceremonial checkbox.

Architecture / decision scenario

A team fine-tunes a domain model every week and deploys whichever training job finished last. An incident reveals that the production endpoint’s artifact was overwritten after its evaluation report was generated.

You create one Model Package Group for the task and register each candidate under a distinct artifact identity. The package records the inference specification, code revision, and evaluation report through metadata and ModelMetrics. Candidates start in PendingManualApproval.

The deployment pipeline accepts only the reviewed package version after approval. A later failure can be traced to its exact evidence and predecessor. The team can restore the prior approved release without guessing which training folder once contained its weights.

Common exam traps

• Treating successful registration as approval for production.
• Deploying a group’s newest version without checking its approval status.
• Overwriting the artifact behind an approved package.
• Approving an adapter without its compatible base revision.
• Assuming any approval update automatically deploys or rolls back an endpoint.
• Treating one aggregate evaluation score as the whole review.

What to remember

• Register identifiable release candidates within a Model Package Group.
• Attach evaluation and provenance evidence to the package version.
• Use ModelApprovalStatus to distinguish pending, approved, and rejected candidates.
• Preserve reviewed artifacts and previous approved releases.
• Connect approval events to an explicit deployment workflow.

Knowledge check

References

• AWS, Model Registration Deployment with Model Registry
• AWS, Amazon SageMaker Model Cards
• AWS, CreateModelPackage
• AWS, Update the Approval Status of a Model
• AWS, Update deployment information (Studio)