The Modeling Task That Ate the Unit
You assign a three-day modeling task: students must use a real dataset (monthly electricity use for a school building over 24 months) to build a model, predict next year's use, and recommend an energy policy. Day 1 goes well - students graph the data and notice seasonal patterns. Day 2, you find: six of eight groups are stuck trying to fit a single straight line to obviously seasonal data; two groups have fit a sine curve but can't explain what the parameters mean; one group has abandoned the data and is writing a policy recommendation based on 'common sense.' You have one day left before the task is due, and the unit test is in four days.
1. Diagnose the modeling breakdown using the modeling cycle, and identify which phase each group is stuck in.
Read the worked answer
Mapping groups to the modeling cycle (identify → formulate → compute → interpret → validate):
- Six groups fitting a straight line to seasonal data: They are stuck at formulate. They selected a model before characterizing the data's structure. The failure isn't computation - it's that they didn't ask 'what shape does this data have?' before choosing a function family. They may also be stuck at validate without knowing it: a straight-line fit to seasonal data has obviously patterned residuals, and they haven't checked.
- Two groups with a sine curve who can't explain parameters: They got through formulate and compute but are stuck at interpret. They can produce
A sin(B(t−C)) + Dbut can't say what A, B, C, D mean in electricity terms (amplitude = seasonal swing in kWh; period = 12 months; phase = which month peaks; vertical shift = baseline use). Interpretation is the phase where modeling becomes meaningful, and they've skipped it. - One group writing policy from 'common sense': They've abandoned the cycle entirely - they jumped from identify straight to a policy claim, skipping formulate/compute/interpret/validate. This is the most concerning because it looks like productivity.
Key insight: No group is stuck at compute. The breakdown is at the front (formulate) and the back (interpret/validate) of the cycle - the phases that are hardest to teach and most often skipped.
2. Plan Day 3 to get every group to a defensible product, given that the unit test is in four days.
Read the worked answer
With one day left, I can't fix all phases for all groups. I'd triage to the highest-leverage phase per group and use a shared whole-class move to save time.
Opening (10 min) - whole-class validate move: Project one group's straight-line fit with its residuals (anonymized). Ask: 'What pattern do you see in the residuals?' The patterned residuals are the argument against the line - and it's the same argument for all six groups. This is one move that serves six groups, and it teaches validate as a habit.
Then, targeted (25 min):
- Six line-fitting groups: Don't ask them to fit a sine curve from scratch - no time. Ask them to (a) state why the line fails using residuals, and (b) describe qualitatively the seasonal pattern (peaks in which months? how big is the swing?). A qualitative model with a justified rejection of the linear one is a defensible product. If a group is fast, give them a pre-fit sine curve to interpret.
- Two sine groups: Give a parameter-translation scaffold: 'A = ___ kWh means ___.' Require one sentence per parameter. This is a 10-minute fix.
- Policy group: Require them to attach one number from the data to one policy claim, with the source cited. That's enough to make it modeling rather than opinion.
Closing (10 min): Each group states one thing their model can and cannot do. This builds validate into the product.
Test protection: The unit test in four days should not depend on sine-curve fitting if most students didn't get there. I'd adjust the test blueprint - model interpretation and residual reasoning, not parameter estimation - and note the change.
3. What would you change about this task's design next time, and why?
Read the worked answer
The task failed at the formulate phase for most groups because I never taught or scaffolded it - I assumed students would look at the data and choose a model, but model selection is a skill, not a reflex.
Changes:
- Add a 'characterize before you model' step. Before any fitting, require a written description: 'This data rises/falls/cycles because ___. The shape is ___.' Groups that skip this are the ones that grab a line. Make it a checkpoint I sign off on.
- Provide a model menu with trade-offs, not a blank page. Give 3–4 candidate model families (linear, quadratic, exponential, sinusoidal) with one-line descriptions of when each applies. Choosing from a menu with justification is still modeling; choosing from nothing is a guess.
- Build in a validate checkpoint at Day 2. Require groups to plot residuals and write one sentence. This catches the line-fitting groups a day earlier, when there's time to fix it.
- Make interpretation a required product element. Every parameter must get a sentence in context. The sine groups' failure was predictable if interpretation isn't required.
- Shorten to two days, or extend to four. Three days was enough for compute but not for formulate + interpret + validate. The task was over-scoped for the time.
Why this matters beyond this task: The pattern - students compute but can't formulate or interpret - is the classic modeling failure mode. The fix is to make the non-computational phases explicit, required, and checkpointed, not assumed.