Calendar arithmetic, fixed.
The pipeline was adding 30-day chunks where the page was adding calendar months. The two answers drifted by a day or two over a 24- to 36-month horizon.
After the previous sprint reconciled the pipeline registry with the seven live predictions on the page at the calendar-month level, a small but persistent mismatch remained at the calendar-day level. Every resolve-by date in the prediction registry was one to three days off from the corresponding date on the page. The page was hand-anchored on the NPC adoption day (the 12th of each month); the pipeline was emitting the 3rd, the 28th, the 1st, and the 24th depending on the lag.
The cause was the arithmetic. The pipeline was computing the resolve-by date by adding 30-day chunks to the adoption date for each month of lag — treating every month as exactly 30 days. At 18 months, that is 540 days, which lands on the 4th of the target month rather than the 12th. At 36 months, the error grows to closer to a week. The error is small in absolute terms but it makes a public scoreboard with named resolution dates look like nobody is checking.
This release switches to true calendar-month addition (12 March plus 18 months equals 12 September, regardless of whether the intervening months have 28, 30, or 31 days). All seven 15FYP resolve-by dates now anchor on the 12th: sovereign AI, climate-energy, and quantum continuation at 12 September 2027; EV consolidation and embodied AI at 12 March 2028; semiconductor self-sufficiency at 12 September 2028; and common prosperity v2 at 12 March 2029. Page and pipeline are now reconciled at the calendar-day level, not just the calendar-month level.
Technical detail
- The resolve-by date computation in the pipeline was switched from adding the lag in months times thirty days to true calendar-month addition via the standard dateutil library.
- All seven 15FYP resolve-by dates were re-emitted on the 12th. The page's hand-curated dates were already correct; the Python output now matches them.
- The prediction registry was regenerated cleanly with the corrected arithmetic; no other row changed.
- Verification: re-running the pipeline after this fix produces a manifest where every resolve-by date falls on the 12th of its target month, matching the rendered page.
What this opens. The class of bug here — arithmetic that is correct in the small but drifts in the large — is exactly what the per-run manifest diff is for. Every pipeline run now records computed dates alongside the constants they were computed from, so a future drift like this surfaces as a one-line diff rather than a calendar-day mystery.