Skip to content

Projects

Three projects, three blocks, one portfolio.

Each block ends with a project your team builds on real data. Each one is less guided than the last: in Project 1 the question is given, in Project 2 the comparison is yours to design, and in the capstone even the problem is yours to choose. By the end of the semester you have three repositories you can show anyone who asks what you can do.

Weeks 1–4 Project 1 · A validated baseline
Weeks 5–9 Project 2 · A model comparison
Weeks 10–14 Project 3 · Capstone

  • Project 1 · Raw data to a validated baseline

    One city, four questions. New York taxi trips from 2026. Each team owns one question, from what a trip will cost to whether its passenger will tip well, and takes it through the four stages of Block 1.

    Open now · due end of Week 4 · 20 points

    Project 1 brief

  • Project 2 · A defensible model comparison

    Several model families, an equal tuning budget, and an honest claim about which differences are real. Written up in the shape of a short technical report.

    Opens in Week 5 · due end of Week 9 · 20 points

    Project 2

  • Project 3 · Capstone

    Your own problem, end to end: framing, pipeline, evaluation, and a deployed model, presented live and defended under questions.

    Opens in Week 10 · presented in Week 14 · 20 points

    Project 3

How every project works

Every week Build in the open

Each lab ends with a project step. Commit as you go: your history is part of the work.

Before the deadline Swap and review

Another team clones your repository, runs it from the README, and tells you what broke.

At the end Defend it

Present what you built and found. Anyone on the team may be asked to explain any part.

What every repository contains

PROBLEM.md, written before any modelling: the question, the target and its decisions, the moment of prediction, the metric, and the baseline.
A cleaning function and a pipeline that rebuild everything from the raw data, and never learn from rows they should not see.
MODEL_CARD.md, written at the end: what the model does, how well, where it fails, and when not to use it.
A README a stranger can follow, from a fresh clone to the final number, including where you used AI.

The repo conventions set out the layout, and the grading page how the 20 points of each project are awarded.

Quote

The method, not the score. A modest result you can defend beats an impressive one you cannot.