Fresh-data testing

Build-along · ~10 min at your own keyboard

A model asked to test its own work generates test cases that flatter its own assumptions. The fix: test with data it has never seen, like a real closed listing from last year or a comp set you know is weird. Fresh data finds the failures polite tests never will.

Your starter: Plan diff against last year's unit

Prompt

Make it yours: Point it at your real unit folder and last year's, and set the one pattern your materials use for a student's work so the stop rule fires on your data, not on an example.

Compare the unit plan at [path] against last year's at [path].

Report, in this order: days new since last year (number and objective as the plan has them); days whose standard code changed; any day whose materials list names a file the folder does not hold.

If any line carries a student's name, an ID or a grade beside a name, say so and stop on that line. No student goes in by name in anything that goes to the next step.

Do not rate a lesson, decide the pacing, or propose a cut. Where a field is missing write [YOUR CALL: the day, and the calendar it comes from]. The decision stays yours on every day that moves.
Save the report as unit-diff-[date].

The coach checks that what you paste back is your own work. The starter pasted back unchanged won't pass.

Do this

0/4

Share what happened

Paste what fresh inputs you used, what broke, and the category of failure.