The calibration page's data: the same resolved-forecast pool the launch gate judges, broken down by question family, plus the live track the gate does not judge yet.

Scope follows the gate exactly. The pastcast track is the current question-generation scheme and the forecaster version named by the most recent gate evaluation — older regimes are retired, and mixing them was measured to flatter the numbers (see foresight_backtest.report._resolved_pastcasts). The live track is every real-time forecast that has resolved, all versions, because a reader deserves the whole real-time record, not a curated slice. One row per question: the latest forecast, which is what resolution scored against.

Horizon is the REAL horizon the gate scopes on — resolution date minus the as-of date (a live forecast's issue date) — bucketed, with every bucket's row count returned so the page can offer only the scopes that exist. The default scope is the gate verdict's own horizon (its report's horizon_days, bucketed): since the 30-day experiment the archive holds pastcasts at more than one horizon and pooling them was measured to flatter the headline (BSS 0.155 pooled against 0.107 at the gate's 7 days). horizon=all pools on purpose; a verdict that names no horizon (older reports) scopes nothing.

The verdict follows the same scope. regime.gate is the latest verdict that judged THIS horizon, or null with regime.gate_scope saying in words that no gate covers it — never a fallback to another horizon's verdict, because a passing 7-day verdict served beside the 90-day maintenance families reads as those families having passed a gate they have not. regime.latest_gate still carries the newest verdict overall, stamped with its own domain and horizon_days, so the distinction survives outside the browser (the MCP tool has no page, no card and no selector).

Both verdict blocks are under the withheld contract, through calibration.public_gate_row — the same helper /v1/calibration's gate_history uses, not a second copy of the rule. A verdict scoped to a withheld family keeps its identity and its recorded passes, every statistic in its report is null, and it carries a withheld block; withheld is null on every verdict still published. This block used to be the row as stored, report blob and all, and it read as harmless only while the newest row happened to be the trusted news-tone run: the first gate row scoped to a withheld family — which is what a backtest over the maintenance families creates — would have published that family's n and Brier skill here, from a route whose family table withholds exactly those numbers three keys further down.

Every family resolved off a GH Archive activity series is WITHHELD, unconditionally: the windowed maintenance families (commits_90d, release_90d) and the legacy daily-threshold families that read the same three series (commits_hourly, release_published, stars_hourly — keyed by their metric because they carry no provenance family). Every question in that pool was resolved by counting a GH Archive series whose capture collapsed, so the outcomes those forecasts were scored against are themselves unreliable and no score over the pool is sound — at any horizon, over any window, however healthy the series looks now. Their n and every statistic beside it are JSON null (never 0, never omitted) and the family carries a withheld block with reason: "resolutions_untrusted" saying so; withheld is null on everything still published. Their rows are not folded into a track total either, and a track left with nothing to score goes null rather than reporting n=0. This matches /v1/risk and /v1/proof exactly: one endpoint must not withhold a number the next one publishes. It does not end when the source looks healthy again.

Unknown query parameters are ignored on purpose: published proof links carry campaign tags (utm_campaign=...), and a 422 on those would break every campaign-tagged link into this record. An invalid VALUE for horizon is still a 422.