The first full-scale plan failed closed with a weird error
Yesterday Statpro ran its first full-scale canonical-database question compile against the production source. The plan failed closed with a message I did not expect: Certified question capacity exceeds safe bound: 1000001. One row over a million. That is the kind of off-by-one that makes you suspicious.
It was not an off-by-one. The capacity stop, a runaway-enumeration guard set at 1,000,000, was sitting exactly at the ceiling of a single question family. The playerOpponents dimension legitimately saturates at 999,999 rows (floor of a million divided by three leagues, times three). So one dimension alone consumed the entire safety budget, and every other question family got zero headroom.
Reading the guard correctly
The fix was a one-line constant change, but the reasoning mattered more than the code. The stop is a runaway-enumeration guard rather than a product limit. It exists to catch a pathological cross-join exploding into billions of rows. It does not exist to cap legitimate question volume. So it needs to sit above the by-design draft ceiling (the sum of all draft-yielding dimension limits, about 5.7M) while staying far below any realistic pathological case:
// Runaway-enumeration stop, not a product limit: it must sit above the
// by-design draft ceiling (~5.7M, dominated by playerSeasonMetricKeys 4M
// + playerOpponents 1M). The previous 1M bound left zero headroom.
export const MAX_CERTIFIED_QUESTION_CAPACITY = 8_000_000;The Boston Patriots problem
While debugging the capacity stop, a separate certification gate for NFL 1970 failed closed for a completely different reason. Fourteen games for the 1970 Patriots had no certifier name alias. The alias map knew new england patriots but not boston patriots, which is how the canonical data actually stores that team for the 1960 through 1970 seasons.
So the expected-game dedupe counted 203 expected games against the verified-correct 189 canonical games, and produced 10 team-record mismatch criticals. The data was right the whole time. The alias map just did not know about a historical team name change that happened 56 years ago.
The fix adds season-scoped aliases (nfl|boston patriots|1960-1970 resolving to ne) with era-boundary tests. 1959 and 1971 stay unaliased. This mirrors an existing pattern for the Baltimore Colts era. Same bug class, same fix shape.
What the rest of the day looked like
Beyond those two debugging stories, the day shipped a meaningful chunk of infrastructure for the Ask question pipeline:
- Canonical-database question authority: a new selectable authority source threaded through the full manifest pipeline (compile, plan, verify, activation, sharding) with target fingerprints and signed activation artifacts.
- Frozen verification batches: 100-answer test batches with a full evaluator tool, so question quality can be measured against a stable baseline rather than a moving target.
- Answer-chain evidence: a 13-batch HMAC verification chain ran against the production read-only target and recovered 825 systemic failures under revision and signed-target binding.
- NFL 1970 certification: after the Patriots alias fix landed, the strict-certification gate passed (189/189/189 games, zero criticals). Season complete end-to-end.
The pattern I keep seeing
Both bugs today were the same shape: a guard or a map that was correct when it was written, but did not account for the full range of legitimate production data. The capacity stop was sized for a smaller source. The alias map was built before historical seasons needed it. Neither was a logic error. Both were boundary errors against reality.
When a safety guard fails closed on legitimate data, the instinct is to ask why the guard is too strict. That is usually the right question. But the deeper question is whether you know what your guard is actually guarding against. If you cannot name the pathological case it catches, you probably do not know where its ceiling should be.