How This Course Works
One model, carried all the way to production
You do not study fifteen separate subjects. You build one model, at Kestrel, a made-up parcel-delivery company, and you carry it from raw depot scans to a service that keeps working when nobody is watching it. The model predicts late-delivery risk: the chance that a parcel misses its promised day. Kestrel uses it to warn customers at 06:00 and to send spare vans where they are most needed. Every module adds one piece to the same repository, with the evidence that the piece works.
The project, its people, its data and its dates are described in 03-kestrel.md. It is fictional; the real cases that open each lesson are not.
What this course is, and what it is not
This is the infrastructure-and-training track. It is different from AI engineering, where you mostly call models other people trained. Here you train the model, and then you keep it correct. The roadmap puts it plainly: training is the bounded part; keeping a model correct in production is the job. So the course spends its first four modules on getting a model right, and the next seven on keeping it right: data pipelines, experiments, scale, optimisation, serving, MLOps and monitoring.
Who it is for
You can write Python and you have seen a pandas DataFrame. The learner ranges from a beginner with some Python to a working engineer who has trained models but never run one in production. You skip what you know: every module README starts with What you need first. If you have never written Python, start with the Python course in this series.
Theory first, then practice
Every lesson has two halves.
| Half | What happens | Code? |
|---|---|---|
| Theory | The situation at Kestrel, a real case from outside, then every topic explained in plain words with figures and numbers worked by hand, and the open-source option set beside the closed or managed one | No code |
| Practice | Run it, break it, in production, one exercise with a check you can run | 8 to 15 short code blocks, each followed by a code walkthrough |
The theory says what is true; the code proves it on Kestrel's data.
Pictures first
A figure shows an idea; a short paragraph says what the figure shows in plain words. Then the next figure. A lesson has fifteen to thirty figures and takes thirty to forty-five minutes to read properly, plus the time to run the code.
The same colours mean the same things in every figure:
| Colour | Means |
|---|---|
| Blue | Kestrel's system, your code, the normal path |
| Amber | The model, or anything uncertain (a prediction, a score, a probability, a model's text) |
| Green | Correct, safe, passed a gate, within budget |
| Red | Failure, drift, a leak, over budget, a broken contract |
| Grey | Optional, background, a managed or closed service you do not run |
Architecture diagrams use a second style, with layers drawn as dashed panels; 05-image-style-guide.md explains both.
Open source first, managed and closed shown beside it
Every mechanism is built the plain way first (gradient descent in NumPy before PyTorch, a drift statistic by hand before Evidently, a batcher in plain Python before a serving framework), then with the open-source tool that does it properly (scikit-learn, LightGBM, PyTorch, MLflow, Optuna, DVC, Pandera, Prefect, ONNX Runtime, FastAPI, Evidently, SHAP, Fairlearn). The managed or closed options a real team might choose instead (SageMaker, Vertex AI, Databricks, Snowflake, BigQuery, Weights & Biases, Tecton, Arize, WhyLabs, TensorRT, Triton) are shown side by side in a comparison figure, with an official snippet labelled not run here where it helps. You learn what each side costs, what you operate and what you are locked into.
The shape of every lesson
| Part | What happens | Why it is there |
|---|---|---|
| The situation | A problem Kestrel has, with named people | You learn the idea because you need it |
| A real case, first | Something that really happened, from an engineering blog, incident write-up, paper or talk, cited | So you know the idea matters outside a course |
| The idea | Figures, short paragraphs and numbers worked by hand, one running example throughout | The picture comes before the vocabulary and the formula |
| Run it | Short code blocks pasted into Colab, each with a code walkthrough | You see the claim proved and understand every line |
| Break it | You make it fail on purpose | Production models fail; see the failure here first |
| In production | What teams do at scale, including the managed options | The part most courses leave out |
| The question Adaeze will ask | One question in the voice of Kestrel's head of ML | The questions a reviewer or interviewer asks |
| Exercise | One task with a runnable check | You do it, not just read it |
| Key terms and sources | A short glossary and the sources the lesson used | So you can go further |
Three depths of topic
| Mark | Meaning | What you get |
|---|---|---|
| (Essential) | You cannot do the job without it | Figures, worked numbers, code and a "break it" step |
| (Recommended) | Skip it only if you have a reason | A figure and a short section, often with code |
| (Optional) | Knowing it exists is enough | An "awareness card": one figure and one paragraph |
Some ideas appear in more than one place in the roadmap (for example reproducibility, or training-serving skew). Each is taught once. Where it comes back you get a recall card: one figure, one paragraph, a link to the lesson that teaches it, then only what is new.
What every module contains
| File | What it is |
|---|---|
README.md | What the module is for, what you need first, the lesson list |
| Numbered lessons | One file per group of topics |
...-module-lab.md | A guided build that adds this module's piece to the Kestrel repository |
...-incident-file.md | A real, published failure, then the same failure replayed on Kestrel and designed out |
Module 16 is the capstone: one model that lives in production and keeps working without you watching it. You run the whole pipeline from raw data to a registered, gated, benchmarked, monitored model, rehearse a rollback, and answer the roadmap's five questions from your own measurements.
How to run the code
All code runs in Google Colab on the free CPU. Open a new notebook, paste each code block into a cell in order, and run it. Five lessons give a faster or fuller path on a free Colab GPU (a T4); each also runs on the CPU, and the lesson says which numbers came from which.
Only four places in the course call a hosted language model, all in Modules 12 and 13. They use the same short setup cell, which lets you choose Groq, Gemini (both free keys, in Colab) or Ollama (on your own computer) by changing one word: 02-setup-colab-and-llm-providers.md. Running the repository on your own computer, and the parts Colab cannot run (Docker, Kubernetes, an Airflow server, GitHub Actions, Triton, more than one GPU), is on 07-run-locally.md. Those sections give exact steps from official documentation and say plainly that they were not run in the course.
The data is generated, not downloaded
All Kestrel data is made by code with a fixed seed: 147,444 sampled parcels over twelve weeks, nine depots, 200 routes, daily weather, and 300 customer messages. Every learner gets exactly the same data, and nothing has to be downloaded. It contains traps on purpose, the kind real data contains: a column that leaks the answer, a unit that changes on a known date, a new depot that drifts, a group of customers the model serves worse, and labels that arrive late. Lessons paste only the blocks they need from 06-shared-data.md and print a fingerprint you can compare. All of it is simulated, and lessons say so.
Every output is real
Every output printed in a lesson came from running that lesson's code, on the date shown. There are no hand-written "example outputs". Numbers in the text come from those runs, from the shared data or from a cited source. Where a lesson checks hosted-model plumbing (the judge in Module 12) with a scripted fake model instead of a real one, it says so, and the fake's replies are never presented as what a model said.
Your numbers may differ a little
The data, the classical models and the statistics are exact: the same cell on the same data gives the same numbers. Three things can differ: training on a GPU is not bit-for-bit repeatable unless you ask for deterministic algorithms (Module 4 lesson 4 shows how), timings depend on the machine you were given, and library versions in Colab move. Module 8 lesson 3 shows how to measure timings properly, with percentiles and warmup rather than one number.