Welcome to the final lesson in your pipeline journey! Over the past four lessons, you've built an impressive foundation that processes raw California housing data, trains a Linear Regression model, and systematically evaluates performance using multiple regression metrics. However, there's one critical gap that separates your current workflow from a truly production-ready ML system: your pipeline doesn't make intelligent decisions about what to do with evaluation results.

In this culminating lesson, you'll complete your transformation from ML practitioner to MLOps engineer by implementing intelligent, conditional model deployment. You'll learn to implement conditional logic that automatically registers only high-performing models for deployment, ensuring that your production systems receive models that meet your quality standards. This represents the ultimate evolution from manual model promotion processes to fully automated, criteria-based deployment workflows.

By the end of this lesson, you'll have achieved the holy grail of ML automation — a complete, end-to-end pipeline that takes raw data and automatically produces production-ready inference endpoints, but only when models meet your quality criteria. You'll master deploying approved models using SageMaker's model registry capabilities, completing your journey from raw data to production-ready ML systems with zero manual intervention.

Before diving into conditional deployment logic, let's briefly revisit the solid foundation you've built in previous lessons. Your current pipeline consists of three well-orchestrated steps that work together seamlessly. The preprocessing step transforms raw California housing data into clean training and test datasets, handling feature scaling and data splitting automatically. The training step uses the processed training data to fit a Linear Regression model, saving the trained model artifact to S3 for future use. Finally, the evaluation step takes both the trained model and test data to calculate comprehensive performance metrics.

The evaluation step you implemented in the previous lesson is particularly important for what we're about to build. As a reminder, this step extracts the trained model from its compressed archive, loads the test data, generates predictions, and calculates key regression metrics. These metrics are then saved in a structured JSON format using SageMaker's Property Files feature, making them accessible to subsequent pipeline steps.

The Property Files mechanism you learned about is crucial for the conditional logic we're about to implement. When your evaluation step completes, it creates an evaluation.json file containing all the performance metrics in a structured format. This file becomes available to downstream pipeline steps through the PropertyFile configuration, allowing future steps to programmatically access specific metrics like the R-squared score. This capability transforms your evaluation results from simple reports into actionable data that can drive automated decision-making within your pipeline.

Conditional steps represent one of the most powerful features of SageMaker Pipelines, allowing you to create intelligent workflows that make decisions based on data, metrics, or other criteria. Instead of executing every step in a linear fashion, conditional steps enable your pipeline to branch and execute different logic paths depending on the conditions you define.

In the context of model deployment, conditional approval serves as a quality gate that ensures only models meeting your performance standards reach production systems. Model registration refers to the process of storing a trained model in SageMaker's model registry — a centralized catalog that maintains different versions of your models along with their metadata, approval status, and deployment artifacts. Rather than manually reviewing evaluation reports and deciding which models to register, you can encode your quality criteria directly into the pipeline logic.

For our California housing price prediction pipeline, we'll implement a conditional step that checks whether the trained model's R-squared score meets a minimum threshold of 0.6. The conditional logic will evaluate this score from our evaluation step and only proceed with model registration if the threshold is met. Models that fall below this threshold will be skipped entirely — they won't be registered in the model registry, preventing them from being deployed while still preserving their training artifacts and evaluation results for analysis.

This automated quality control ensures that your production systems only receive models that have demonstrated acceptable performance on your test data, eliminating human bottlenecks and reducing the risk of deploying poor-performing models.

When preparing models for deployment, it's important to create optimized inference artifacts that contain only the components necessary for making predictions. The entry point script serves as the interface between SageMaker's inference infrastructure and your trained model, defining how the model should be loaded when the inference container starts.

We'll create a separate file called entry_point.py that contains only the essential model loading logic:

This entry_point.py script contains only the model_fn function, which is called by SageMaker when the inference container starts. It loads your trained Linear Regression model from the model.joblib file and returns the model object for use in prediction.

By creating this dedicated entry_point.py script with minimal dependencies, we ensure faster startup times and more efficient resource utilization during deployment.

Now that we have our entry_point.py script ready, let's go back to work on our pipeline code to implement the conditional logic that will automatically register high-performing models for deployment. We'll accomplish this by building four key components:

1. Creating a serving model object that packages our trained model with the inference script
2. Configuring a model registration step that stores approved models in SageMaker's model registry
3. Defining a quality condition that evaluates the R-squared score against our threshold
4. Creating a conditional step that orchestrates the decision-making logic to only register models that meet our quality standards

Let's start with the first component by creating the serving model object.

First, we'll create the serving model object that defines how the trained model should be packaged for inference:

The SKLearnModel class serves as a bridge between your trained model artifacts and SageMaker's deployment infrastructure, providing essential metadata and configuration that the model registry and inference endpoints require.

When you register a model using SKLearnModel, you're not just storing the model weights — you're creating a complete deployment package that includes:

• Framework specification: Tells SageMaker which scikit-learn version and Python version to use
• Entry point definition: Specifies which script contains the inference logic
• Execution role: Defines the IAM permissions needed for model deployment
• Container configuration: Sets up the proper runtime environment for your model

The model registry needs this comprehensive information to ensure that anyone deploying the model later will have all the necessary components and configuration. Without SKLearnModel, the registry would only have the raw model file without the context needed for successful deployment.

This approach also enables deployment portability — once a model is registered with all its deployment metadata, it can be deployed by different teams, in different environments, or at different times, all while maintaining consistent behavior and requirements.

Before configuring the model registration step, let's define the model package group name that will organize our registered models in SageMaker's model registry:

The model package group is like a folder in SageMaker's model registry that keeps all versions of your California housing models organized in one place. Each time your pipeline runs and approves a model, it will create a new version within this group, allowing you to track how your models improve over time.

Next, we'll configure the model registration step that will store approved models in SageMaker's model registry:

The RegisterModel step takes your trained model and creates a permanent record of it in SageMaker's model registry. Remember that the inference_model parameter references the SKLearnModel object we created earlier, which packages your trained Linear Regression model with the entry_point.py script needed for making predictions.

Let's break down the key parameters:

• content_types and response_types: These specify the data formats your model can handle. By setting both to , you're telling SageMaker that this model accepts CSV input data (like housing features) and returns CSV output (predicted prices). This matches the format of your California housing dataset and ensures proper data handling during inference.

Now we'll create the condition that evaluates model performance based on our quality threshold:

The ConditionGreaterThanOrEqualTo condition compares the R-squared score from your evaluation step against a threshold of 0.6. The JsonGet function extracts the specific metric from the evaluation report using the JSON path regression_metrics.r2_score, which corresponds to the structure of the evaluation.json file created by your evaluation script.

Finally, we'll create the conditional step that orchestrates the decision-making logic:

The ConditionStep evaluates the list of conditions and executes different step collections based on the results. When the condition evaluates to True, the registration step is executed. If the condition evaluates to False, no steps are executed (empty else_steps list), preventing low-quality models from entering your deployment pipeline.

With all the conditional logic components defined, we can now integrate the new conditional step into our existing pipeline. The updated pipeline maintains the same three-step foundation you've built while adding intelligent decision-making capabilities:

The pipeline execution flow now includes an additional decision point after evaluation. Here's how the enhanced pipeline works:

1. Preprocessing Step: Transforms raw California housing data into clean training and test datasets
2. Training Step: Fits a Linear Regression model using the processed training data
3. Evaluation Step: Calculates performance metrics (including R-squared score) and saves them to evaluation.json
4. Conditional Step: Examines the R-squared score and makes a deployment decision:
   • If R-squared ≥ 0.6: Executes the RegisterModel step, creating a new approved version in the model package group
   • If R-squared < 0.6: Skips model registration entirely, preventing the low-quality model from entering the deployment pipeline

This conditional logic transforms your pipeline from a simple training workflow into an intelligent system that applies consistent quality standards. Every model that gets registered through this pipeline has demonstrated acceptable performance on your test data, giving you confidence that deployed models will meet your quality expectations. The automated nature of this process eliminates manual review bottlenecks while ensuring that quality standards are consistently applied across all training runs.

After your pipeline has successfully executed and registered an approved model, you can deploy it independently from a different environment or at a later time. This separation between training and deployment workflows is a best practice in MLOps, allowing you to deploy models on different schedules and test deployment configurations without re-running the entire training pipeline.

Since this is your first time working with SageMaker's model registry, let's understand what happened when your pipeline registered the model. The model registry acts as a centralized catalog that stores different versions of your models along with their metadata, approval status, and deployment artifacts. Each registered model receives a unique identifier called an ARN (Amazon Resource Name) that you can use to reference and deploy that specific model version.

To deploy an approved model, you'll first need to query the model registry to find the latest approved model from your pipeline. This works similarly to how you've searched for training jobs before, but instead of looking for training job names, you're searching for model packages within a specific group:

The list_model_packages function works similarly to the training job listing you've used before, but it searches within a specific model package group and filters by approval status. The SortBy='CreationTime' and SortOrder='Descending' parameters ensure you get the most recently approved model first.

Once you have the response from the model registry query, you need to extract the specific model package ARN that you'll use for deployment:

The response returns a dictionary with a ModelPackageSummaryList containing model package information. Since we sorted by newest first, model_packages[0] gives us the most recent approved model. We then extract the ModelPackageArn from this model package summary to get the unique identifier needed for deployment.

When you run this code, you'll see output similar to:

This ARN is the unique identifier for your approved model package. It contains all the information SageMaker needs to deploy your model, including the trained model artifacts, the inference script, and the deployment configuration that was specified during registration. The number at the end (in this case /1) represents the version number of the model package within the group - your first approved model will be version 1, the second will be version 2, and so on. We'll use this ARN in the next step to create a deployable model object.

Now that you have the ARN of your approved model, you can deploy it using the same serverless deployment approach you've used before. However, instead of deploying a model object created from training artifacts, you'll deploy a ModelPackage object created from the registry entry:

The key difference here is that you're creating a ModelPackage object instead of an SKLearnModel object. The ModelPackage automatically includes all the deployment configuration (entry point script, framework version, etc.) that was specified when the model was registered by your pipeline. This approach demonstrates the power of the model registry — all the deployment details are packaged with the model, making deployment consistent and repeatable.

This deployment workflow represents the final piece of your end-to-end MLOps system. Your pipeline trains and evaluates models automatically, registers only those that meet quality standards, and now you can deploy approved models independently whenever needed. This separation allows you to maintain different deployment schedules, test various deployment configurations, and roll back to previous model versions if needed.

You've now implemented intelligent, conditional model registration in your SageMaker pipeline. By adding a quality gate based on the R-squared metric, your workflow ensures that only models meeting your performance standards are registered for deployment. You also learned how to query the model registry for approved models and deploy them independently, enabling a robust separation between training and deployment workflows.

With these enhancements, your pipeline now embodies key MLOps best practices: automated quality control, systematic model versioning, and consistent, criteria-based deployment. This sets the stage for fully automated, production-ready ML systems that can be managed and scaled with confidence. You're ready to move on to the next practice, where you'll put these concepts into action and see your pipeline make real deployment decisions based on model quality.