Why we cap monthly valuation swings — and what that trade-off costs us

Every player's valuation is recomputed from scratch each month from that month's match statistics, age, league context and a handful of other signals. Left alone, that process can occasionally produce a number that swings far more than a real change in a player's market value would justify — a data gap, a season-transition artifact, or simply the model overreacting to a short stretch of matches. Since 2026-08-24 we've applied a hard final rule on top of every other adjustment: no single month can move a player's valuation by more than 30% from the previous month's figure, in either direction. It was originally set at 20% and widened to 30% on 2026-09-02.

The cap is a blunt instrument by design, and it has a real cost: it can hide a genuine calculation bug behind a number that merely looks a bit suspicious instead of obviously broken. That's exactly what happened with Harry Kane's valuation this cycle. A stats-ingestion incident during the 2026-08 season cutover corrupted the starting snapshot our monthly comparisons are measured against — his August figure got locked at roughly double what it should have been. Our daily recomputation cycle, working correctly and respecting the cap, spent the rest of the month pulling his live valuation back toward the right number. But the corrupted starting point itself was a separate, frozen field that the cap was never designed to check — so by the time September's snapshot locked in, the month-over-month comparison showed Kane dropping roughly 50%, a number that looked like a real story but was actually two bugs compounding: one from the original data corruption, one from a monitoring gap that let it sit unnoticed for over a week.

We've since fixed both: the corrupted starting snapshot is being corrected, and we added an automated integrity check that now flags this exact class of mismatch — a locked snapshot value drifting outside the cap versus the prior month's live figure — the next time the monthly batch runs, instead of waiting for someone to notice an implausible number by eye. The cap itself stays in place, because the alternative is worse: an unbounded single-month swing reaching a real user because of some other undetected data issue is a bigger risk than occasionally papering over a bug for a few weeks. We'd rather be transparent about that trade-off than pretend the model is bug-free.