Theme: A trained model is only one component of a reliable prediction system
Why model deployment needs its own guide
Training a model answers an important question: can useful patterns be learned from the available data? Deployment introduces a different question: can the same prediction logic be used reliably by people and software outside the development environment?
A model can perform well during development and still fail when it is used in practice. Incoming fields may be missing, reordered, or represented with unexpected types. Training-time preprocessing may be recreated incorrectly. An API may accept invalid requests, return ambiguous predictions, or load a different artifact from the one that was tested. Even a technically correct service can become unreliable as its input data, dependencies, or operating conditions change.
Model deployment therefore concerns the complete path from validated inputs to maintained predictions:
Code
flowchart TD A["Validated training data"] --> B["Preprocessing and model pipeline"] B --> C["Versioned model artifact"] C --> D["Validated inference interface"] D --> E["Tested prediction service"] E --> F["Monitoring and maintenance"]
flowchart TD
A["Validated training data"] --> B["Preprocessing and model pipeline"]
B --> C["Versioned model artifact"]
C --> D["Validated inference interface"]
D --> E["Tested prediction service"]
E --> F["Monitoring and maintenance"]
Serving a model is one step in this path. Reliable deployment also requires a stable prediction contract, reproducible artifacts, input validation, automated testing, repeatable packaging, and evidence that the service continues to behave as intended.
The central design decision
This guide saves preprocessing and the estimator together as one scikit-learn Pipeline. A pipeline preserves the ordered transformations used during training and applies the same operations during inference, reducing opportunities for training and deployment logic to diverge (scikit-learn developers n.d.).
The deployed unit is therefore not an isolated estimator. It is a tested prediction pipeline with clearly defined inputs and outputs.
That principle shapes the entire guide:
Build one prediction path, test that path, and deploy the same path.
Position in the CDI learning pathway
This guide assumes that model development already includes appropriate evaluation, validation, and interpretation. It begins when a model has become a plausible deployment candidate—not merely when a training script runs successfully.
The progression is deliberate:
Data Science Foundations → Advanced Data Science → Model Deployment
Data Science Foundations establishes reproducible analysis. Advanced Data Science develops stronger modelling and evaluation decisions. Model Deployment converts a validated pipeline into a usable and maintainable prediction service.
What you should know before starting
Readers should be comfortable with:
running Python programs from a terminal;
working in a repository-specific virtual environment;
reading basic pandas and scikit-learn code;
understanding training, validation, and test data;
interpreting classification probabilities and decision thresholds; and
using Git for ordinary version-control tasks.
Prior experience with FastAPI, Pydantic, pytest, Docker, or production infrastructure is not required. Each is introduced when it becomes necessary.
What you will build
Every implementation chapter extends one compact binary-classification example. The example is small enough to inspect closely but complete enough to include:
numeric and categorical inputs;
preprocessing with a ColumnTransformer;
classification with a probability-producing estimator;
a versioned serialized pipeline;
explicit request and response schemas;
batch and HTTP inference;
automated unit, integration, and API tests;
a containerized prediction service; and
basic monitoring for input and prediction changes.
Changing datasets or estimators in every chapter would hide the deployment logic. Keeping one model, one preprocessing pipeline, and one prediction contract makes each new operational layer visible.
By the end of the guide, you should be able to explain and implement the path from reproducible model training to a locally tested, containerized service—and identify what must still be added for a specific production environment.
How the guide progresses
The chapters follow the order in which deployment concerns should be resolved:
create and verify a reproducible environment;
train one complete preprocessing and modelling pipeline;
save, load, and identify the resulting artifact;
define a stable inference contract;
expose predictions through FastAPI;
test model, schema, and service behaviour;
package the service with Docker; and
observe, maintain, and improve the deployed system.
Later chapters depend on the artifacts and decisions established earlier. Readers gain the most from following the guide in sequence before using individual chapters as references.
Teaching and code conventions
This is a Quarto book following Quarto’s multi-chapter book structure (Quarto n.d.). It uses the CDI guide conventions throughout:
Python is the primary implementation language.
Every repository uses its own .venv.
Complete executable programs belong in scripts/python/.
Bash wrappers belong in scripts/bash/.
Script names begin with their chapter number.
Short illustrative snippets use ordinary python fences and are not executed during rendering.
Generated data, models, results, and reports are separated from source code.
Tests must pass before an artifact is served or containerized.
References are maintained in library/references.bib.
Commands are presented from the repository root unless a chapter states otherwise. Generated outputs support learning and verification; they are not substitutes for the source programs that created them.
Scope and boundaries
The guide teaches portable deployment principles through local Python programs, FastAPI, Pydantic, pytest, and Docker. FastAPI supports typed API development and generates an OpenAPI description and interactive documentation from the application definition (Ramírez n.d.a, n.d.b).
The guide does not claim that a local container is automatically production-ready. A real deployment may also require authentication, authorization, encrypted transport, secrets management, managed infrastructure, continuous delivery, scaling, audit controls, incident response, and organization-specific governance.
Cloud-provider configuration, Kubernetes administration, and vendor-specific observability platforms remain outside the core scope. The architecture developed here nevertheless separates the model, contract, service, tests, and packaging so those capabilities can be added without redesigning the prediction interface.
What comes next
Chapter 01 creates the repository-specific environment, establishes the project structure, and verifies the tools required for the complete workflow. Chapter 02 then trains the single classification pipeline that every later chapter will test, package, serve, and monitor.