What learning from data means

The chai stall does deliveries now, and it promises thirty minutes. You have deliveries: 900 rows, each one an order that already happened. For each you know the area, the weather, the rider, the distance, how many items, what time — and whether it arrived late.

The job: for an order that hasn't gone out yet, will it be late? You can't look that up, because it hasn't happened. That gap is the entire reason this track exists.

Features and target

Split the table in two, and learn the two names, because everything assumes them:

• Features — the columns you'll be given. Conventionally X, capitalised because it's a 2-D table: one row per observation, one column per measurement. You'll also hear "the design matrix", "inputs", "predictors", "covariates". Same thing.
• Target — the column you want to know. Conventionally y, lowercase because it's one value per row. Also "label", "outcome", "response", "dependent variable".

X = deliveries[FEATURES]     # (900, 8)
y = deliveries["late"]        # (900,)

One row of X and the matching entry of y are one example: a question and its answer. For the past you have both halves. For the future you'll have X and not y. Learning is using the first situation to handle the second.

What a model actually is

Strip the vocabulary away and a model is a function from a row to a prediction, with some numbers in it that were chosen by looking at your data. Training is the process of choosing those numbers. That's it. Nothing more mystical is happening, and holding onto that keeps you honest later when the words get grander.

Different model families are different shapes of function. A linear model is a weighted sum. A decision tree is a nest of if-statements. A forest is hundreds of trees voting. They differ in what patterns they can express and how much data they need — but all of them are functions, and all of them get fitted the same way.

The trap that shapes everything

Consider a model that simply memorises:

memory = {tuple(row): answer for row, answer in zip(X, y)}

def predict(row):
    return memory[tuple(row)]

It scores 100% on the data it was built from. It also knows nothing, and the first unfamiliar row defeats it completely.

This isn't a strawman. It's what an over-flexible model does — quietly, partially, in a way that looks like excellent results right until the model meets the world. A deep enough decision tree memorises. A high enough polynomial memorises. Any model with more freedom than you have data will do it, and it never announces itself.

Generalisation

So the goal was never "fit the data I have". It is generalisation: working on rows nobody has seen. Once you accept that sentence, most of the field follows from it —

• a held-out test set, so you can measure generalisation at all (lesson 3);
• cross-validation, so the measurement is stable (lesson 8);
• regularisation, so the model has less room to memorise (lesson 15);
• pipelines, so information about the test set can't sneak into training (lesson 13).

Every one of those is a defence against the same failure. If a technique in this track ever feels arbitrary, ask which part of "works on unseen rows" it protects.

The four kinds of problem

Supervised — you have a target column.

• Target is a category → classification. Ours: late is 0 or 1.
• Target is a number → regression. Ours would be minutes.

Unsupervised — no target. Clustering finds groups; dimensionality reduction squeezes many columns into fewer. Module 7.

Notice that the same data supports both tasks here, and the choice is yours. late is minutes > 30 — a threshold somebody picked. Predicting the number keeps more information; predicting the category matches the decision the stall actually makes. Neither is more correct.

When not to use machine learning

The most useful thing in this lesson. ML is a poor choice when:

• You can write the rule. If "over 5 km, or heavy rain" is good enough, write that. It's faster, testable, explainable, and it never drifts.
• You need to be right every time. Models are wrong on a fraction of rows, by design. Payroll, invoices and tax are not fractions-of-rows problems.
• You have very little labelled data. Forty rows is not a training set.
• You must justify every decision. "The forest voted 61/39" does not survive an appeal, or a regulator.

It earns its cost when the pattern is real but too tangled to state — distance interacting with rain interacting with rider interacting with time of day — you have thousands of labelled examples, being wrong sometimes is survivable, and the rule would otherwise need rewriting every month.

Our delivery problem clears that bar, but only just, and it's worth noticing that a hand-written rule would be a genuinely respectable competitor. Lesson 5 makes it compete.