Debug overfit tree with max_depth unrestricted on tiny data in the readiness decision tree

Do not start with a speculative fix for the readiness decision tree. Force the failure on purpose, save the before output, then change one cause at a time. Retries are allowed only for transient conditions—not for bad input that will fail forever on decision-trees.

clf=DecisionTreeClassifier(max_depth=2) print({'max_depth':clf.max_depth,'reason':'limit overfit on tiny n'})

Expected evidence: **max_depth 2 rationale**. If you cannot reproduce on demand, you do not yet control the failure mode for `decision-trees`.

After repair, rerun the exact reproduction command. Keep the failing fixture as a regression seed for the observability page. For the readiness decision tree on hours × practice tests, remember the claim you are restoring: held-out accuracy is reported and export_text shows the splits used.

Store a one-command reproduction for: overfit tree with max_depth unrestricted on tiny data, or missing feature names in export. The command should use small hours/practice_tests readiness table with one holdout row or a minimal mutant of it. Paste the failing output into notes/failure-before.txt (or your shell scrollback as copied text). After the fix, paste notes/failure-after.txt and keep both.

Retries belong only on transient faults. If the failure is bad input, a bad allowlist, or a logic bug in the readiness decision tree, retrying will amplify cost without repairing trust around predict readiness with a path a human can read aloud.

Classify the failure as prevent, detect, contain, or recover—using this lab’s language, not a generic poster. For decision-trees, the first fix should usually be detect+prevent at the boundary, because overfit tree with max_depth unrestricted on tiny data, or missing feature names in export is cheaper to stop early than to explain in production prose.

At the debugging 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 before/after evidence for the characteristic failure 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

Previous · Next