Frame the readiness decision tree experiment

Success is not “I followed the tutorial.” Success is producing evidence that: held-out accuracy is reported and export_text shows the splits used. The accepted input is narrow on purpose: numeric rows (hours, practice_tests) with readiness labels. 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: majority-class accuracy on the holdout before fitting the tree. If the finished artifact cannot beat that baseline on the fixture below, stop and revise the claim before writing more code.

X=[[1,0],[2,1],[4,1],[5,2]]; y=[0,0,1,1]
print({'features':['hours','practice_tests'],'n':len(y),'holdout':1})

Expected evidence: feature names and sizes. Treat the printout as a claim about this fixture, not as proof that the toolchain merely started.

For the readiness decision tree on hours × practice tests, a decorative win often looks like a clean run that never checks held-out accuracy plus a tree text dump that mentions both features. Write the metric down now so later pages cannot redefine success after the fact. Also note the operational threat you will eventually gate on: training on labels that embed sensitive attributes without documenting them.

For decision-trees, write the claim on a sticky note in this exact shape: “Given numeric rows (hours, practice_tests) with readiness labels, the readiness decision tree will …”. Fill the ellipsis with the observable part of: held-out accuracy is reported and export_text shows the splits used. Tape the baseline beside it: majority-class accuracy on the holdout before fitting the tree. 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 predict readiness with a path a human can read aloud. If that sentence needs a dashboard, a model zoo, or five services, the lab scope is too wide—shrink the fixture (small hours/practice_tests readiness table with one holdout row) 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/practice_tests readiness table with one holdout row. Note the metric you will eventually require (held-out accuracy plus a tree text dump that mentions both features) so page 4 cannot invent a softer target. The characteristic failure to keep in mind is overfit tree with max_depth unrestricted on tiny data, or missing feature names in export.

At the experiment brief stage for decision-trees, the job is narrower than finishing a product demo. You are creating one progressive evidence piece about small hours/practice_tests readiness table with one holdout row 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: majority-class accuracy on the holdout before fitting the tree.

For this page specifically, success looks like a falsifiable claim and baseline written before coding while still centering the user decision to predict readiness with a path a human can read aloud. If you cannot point to a file, command, or assertion that proves that for the readiness decision tree, stay on this page instead of advancing.

Decision tree glossary

Next