The Week-Six Signal: Why Most Interventions Arrive Too Late

Midterm grades land in week eight or nine of a standard sixteen-week semester, and by the time a registrar's early-warning system flags a student against that data, roughly 55 percent of the term's instructional days are gone. The signal is accurate. It is also close to useless as a trigger for intervention, because there isn't enough semester left to change the trajectory the signal just confirmed — a student who's already three assignments behind and averaging 40 percent attendance in week nine doesn't need to be identified, they need to have been identified five weeks earlier, when an advisor calling them back into the course still had a plausible chance of working.

This is the part institutions get backwards when they build "early warning" around midterm grades: midterm is not early. It's the halfway point. Treating it as an early-warning trigger is a category error dressed up as data infrastructure — the dashboard looks sophisticated, updates in real time, color-codes students red and yellow, and still arrives at exactly the moment when the set of available interventions has shrunk to "withdraw before it hurts the GPA."

Why week six, specifically

Week six isn't a round number we picked for symmetry. It's the earliest point in a typical semester where three conditions are simultaneously true: enough graded work exists to distinguish a struggling student from a slow starter (most courses have returned two to four graded assignments by then), attendance and LMS-engagement patterns have stabilized enough to read as a trend rather than noise (a single missed week in week two is ambiguous; a pattern across five-plus weeks is not), and there is still enough of the semester left — ten-plus weeks — that a changed behavior can plausibly change the outcome. Move the trigger to week four and you're mostly reacting to noise: a rough start, a family emergency, an add/drop-period course switch that hasn't settled. Move it to week eight and you've rebuilt midterm with extra steps.

Building a signal that fires reliably at week six is not a matter of running the same midterm model two months earlier. It requires instrumenting sources midterm systems typically ignore: LMS login frequency and assignment-submission timing (not just grades — when work gets submitted relative to the deadline is often a stronger early signal than the grade itself), attendance captured at the section level rather than aggregated to a single course-level percentage, and financial-aid and billing-hold status, which correlates with dropout risk in ways that have nothing to do with academic performance and everything to do with whether a student is still enrolled by week ten. None of this is exotic data. Most of it already exists in the LMS, the SIS, and the billing system. It's rarely stitched together on a six-week cadence because most institutions built their warning infrastructure around the reporting calendar — when grades are due — rather than around the window in which action is still possible.

The trade-off nobody likes to name

Firing earlier means firing with less certainty, and that has a real cost: a week-six model built on four weeks of data will flag some students who would have recovered on their own, and every false positive spends advisor time and, more importantly, spends a bit of the student's trust in a system that just told them they're at risk when they weren't. We've found institutions underestimate how much this matters — a risk flag that turns out to be wrong doesn't read as "cautious," it reads as "the algorithm doesn't know me," and that skepticism is durable. It carries into how the student receives the next flag, including a correct one.

The honest fix isn't a better threshold. It's separating detection from intervention intensity — a week-six flag should trigger a light-touch check-in, not the same escalation a week-eleven flag would, because the cost of being wrong is asymmetric with how far into the semester you are. Get that calibration right and the earlier signal is worth the noise. Get it wrong, and you've just moved the false-alarm problem two months upstream without fixing it.