Frame the tiny linear model experiment

Success is not “I followed the tutorial.” Success is producing evidence that: fitted slope/intercept, one held-out prediction, and MAE are all printed. The accepted input is narrow on purpose: training pairs of hours and scores plus one untouched test pair. That narrowness is what lets you inspect every field and prevents a toy demo from being narrated as a production system.

Record the baseline you must beat: predict mean train score for the holdout before fitting. If the finished artifact cannot beat that baseline on the fixture below, stop and revise the claim before writing more code.

train=[(1,2),(2,4),(3,5),(4,7)]; holdout=(5,8)
print({'train_n':len(train),'holdout':holdout,'model':'linear'})

Expected evidence: train size and holdout pair. Treat the printout as a claim about this fixture, not as proof that the toolchain merely started.

For the hours→score linear fit with holdout, a decorative win often looks like a clean run that never checks holdout absolute error; slope sign matches the hours/score trend. Write the metric down now so later pages cannot redefine success after the fact. Also note the operational threat you will eventually gate on: publishing per-learner residuals that re-identify students.

For train-a-tiny-model, write the claim on a sticky note in this exact shape: “Given training pairs of hours and scores plus one untouched test pair, the tiny linear model will …”. Fill the ellipsis with the observable part of: fitted slope/intercept, one held-out prediction, and MAE are all printed. Tape the baseline beside it: predict mean train score for the holdout before fitting. If someone later replaces your metric with a vibe check, the sticky note is how you push back.

Also sketch the one-sentence user story: a person uses this output to estimate slope/intercept from study hours and score a held-out row honestly. If that sentence needs a dashboard, a model zoo, or five services, the lab scope is too wide—shrink the fixture (small hours/score table with one held-out pair) until the story fits on one screen.

Decide now whether live network calls are allowed on page 1. For this lab they usually are not; inventory and contracts should run offline against small hours/score table with one held-out pair. Note the metric you will eventually require (holdout absolute error; slope sign matches the hours/score trend) so page 4 cannot invent a softer target. The characteristic failure to keep in mind is training on the test row, or reporting R² without the holdout error.

At the experiment brief stage for train-a-tiny-model, the job is narrower than finishing a product demo. You are creating one progressive evidence piece about small hours/score table with one held-out pair that later pages inherit without redefining success. Keep that fixture small enough to inspect by hand, keep outputs copy-pasteable as text, and refuse to narrate this baseline as if it were a production SLA: predict mean train score for the holdout before fitting.

For this page specifically, success looks like a falsifiable claim and baseline written before coding while still centering the user decision to estimate slope/intercept from study hours and score a held-out row honestly. If you cannot point to a file, command, or assertion that proves that for the tiny linear model, stay on this page instead of advancing.

Overfitting glossary

Next