What This Module Covers

A data scientist once sent me a Jupyter notebook that trained a working model and asked me to deploy it. It ran top to bottom in their kernel and nowhere else. The cells depended on each other in run order, the imports assumed one folder, and there was no way to call it from anything but the notebook. When they said “it works,” what they meant was “it works in this one kernel on this one machine.” Getting it into production wasn’t a modeling problem at all. It was an engineering one, and it took every skill in this module: packaging it, putting it under version control, making its imports survive a move, validating its inputs, and pinning the environment so it ran the same anywhere.

That’s the arc of this module. You start from a script that runs, and you turn it into something another engineer can rely on. Not just once, but reliably.

What this module is

This is the first module of the track. It assumes nothing about prior content modules. All you need is the getting-started setup in place and the ability to write Python that runs. From there, you build a real package: a loan-default scorer for the Lending Club dataset that the whole course is built on, structured so it imports without surprises, runs as a program, validates its inputs, and reproduces in another environment.

What you will learn

The module moves through six lessons. The first three get a real package built, converted from a notebook, and under version control. The last three are the hardening pass, where each lesson goes back to the working package and fixes a problem that would have detonated later:

• Package mechanics. Here you learn the target shape on its own: what a module and an import really are, why the layout has a src/ folder, how a package gets one obvious way to run via python -m and a __main__ entry point, and how an editable install makes import mypkg resolve from anywhere. This is the blueprint the next lesson converts into.
• Convert the notebook. Take a real notebook a data scientist would hand you. It builds features, trains a logistic regression, and prints a test AUC, but it only runs top to bottom in one kernel. You convert it into the package shape: feature-building and training lifted into importable functions, the run behind the __main__ guard, the same AUC now produced by an installed package (a feature-engineering leak carried forward intact, for M3, Numerical & Statistical Foundations, to fix). This is the package every later lesson hardens.
• Version control your package with git. Put that package under git, push it to GitHub, and learn the everyday loop of change, add, commit, push by understanding what each step actually does. Then branches: an isolated line of work that keeps main working while you change things, the workflow every later module and project depends on.
• Make the imports robust. The package worked because you ran it one specific way. It breaks the moment it’s moved, scheduled by a different tool, or collected by a test runner from elsewhere, because imports resolve against the search path, not the directory you launched from. You’ll see why importing a module should not run its job, and why the editable install was load-bearing rather than cosmetic.
• Make the data contracts solid. A dict of features has no fixed shape, so a typo’d key or a string where a number belongs flows straight into the model and scores nonsense without an error. You’ll state the shape so a checker can catch drift, then validate at the boundary with pydantic so malformed input is rejected or coerced where it enters, with one contract shared by both the training and serving paths.
• Make it reproducible. The last gap before another engineer can rely on the package is that it has to run the same elsewhere. You’ll isolate the environment so installs can’t collide, lock the exact resolved versions of every direct and transitive dependency for a deterministic install, and draw the commit-side line with a .gitignore: commit the lock, ignore anything regenerable, large, or secret.

The module ends with a project you build in your own GitHub repository: the same package discipline, applied yourself to the Adult / Census Income dataset. You build a package that imports without side effects, runs as a module, validates its records, reads its runtime configuration through one typed settings object, and installs from a lock file. The lessons work the techniques on Lending Club. The project is where you prove them on the dataset you’ll carry through every module, against a rubric that maps line by line to these lessons.

How it builds on what came before

This is Module 1, so it doesn’t stand on a prior content module. It stands on the getting-started setup, a working Python and a place to run it, and turns that into the foundation everything else in the track depends on. The package you build here is the thing later modules train models on, serialize, and serve. The git workflow is the one every later project assumes. The typed contract is the first defense against the train/serve skew you’ll meet again in the next module. Nothing here is throwaway scaffolding. It’s the base layer, and the rest of the course is built on top of it.

What you will be able to do

By the end you’ll have a package that imports without side effects, runs as a module through a __main__ entry point, lives under version control on GitHub, carries typed data contracts at its boundary, and installs from a locked dependency set that reproduces the same environment anywhere. Each of those properties, when violated, is a specific failure this module already showed you, and you’ll have fixed each one on a thing that was already working. The thread through all six lessons is the same: making it run is the start of the job, and the judgment that makes it safe for someone else to build on is the rest of it.