GridFreeze · detection speed
How fast do we actually detect a matter?
We alert the day we detect a matter. Over the last 60 days detection ran a median of 3 days from the source's own date, with a worst case of 15. Speed varies by source, and every alert prints its own measured lag so you can check it. Next business day is the engineering target.
Published pair last reviewed 24 August 2026 (canonical definition and population both co-signed).
What "detection lag" means
Every matter we publish comes from a real document, a meeting agenda, a filing, a minutes record, that carries its own date. We compare that date to the moment our pipeline actually wrote the row, counted as whole calendar days, not hours. That gap is the number on every county page and every alert.
We do not store when a document was first posted online, only the date the document itself carries (a meeting date, or a filing's intro date). Posting usually happens a little before the meeting, so this number is the best evidence we have, and if anything it slightly understates the true gap from posting.
What we leave out, on purpose
- Documents older than 60 days. When a brand new source comes online it sweeps in years of past records at once. The age of that archive is not our speed, it is just how old the archive was.
- Sources we check by hand, not on a schedule. A manually seeded record measures how long a person took, not how fast the machine is.
- A source's own first catch. The very first documents a new collector finds were already sitting there before we arrived, we could not have caught them any faster. Only catches made once a source is already running count toward its speed.
- One-off corrections. When we fix a parsing bug and it backfills old records, those are repairs, not a measure of daily speed.
What is left, after all of that, is what counts: a source running on its normal schedule, actually catching a new matter. That is the population in the table below.
The number at the top of this page is deliberately more cautious than the table below it. The table shows what we measured most recently. The published pair is fixed until both engineers agree to move it, and only ever moves upward, never down just because a slow week rolled out of the measurement window. Right now the table's worst case is better than what we publish. That is the direction we want to be wrong in.
Per-source numbers
Measured 20 October 2026, over the trailing 60 days. Reproduce with python scripts/scoreboard.py.
| Source | Median | Worst | Catches |
|---|---|---|---|
| Columbus, OH | 0d | 0d | 1 |
| Prince George's County, MD | 1d | 1d | 12 |
| Loudoun County, VA | 1d | 1d | 4 |
| Prince William County, VA | 1d | 2d | 4 |
| Madison, WI | 1d | 1d | 1 |
| Austin, TX | n/a | n/a | no live catches yet |
| Dallas, TX | n/a | n/a | no live catches yet |
| ERCOT GIS (generation, corroborating) | n/a | n/a | no live catches yet |
| Mesa, AZ | n/a | n/a | no live catches yet |
| Mesquite, TX | n/a | n/a | no live catches yet |
| Nashville, TN | n/a | n/a | no live catches yet |
| PJM TEAC (Dominion load requests) | n/a | n/a | no live catches yet |
| Seattle, WA | n/a | n/a | no live catches yet |
A source reading "no live catches yet" is not necessarily idle. Some are brand new: they may already hold matters on their jurisdiction page, first-scan backfills found the moment the collector went live, which measure the archive's age, not our speed, and are reported separately, never folded into this table. Others were catching things on cadence and simply have nothing left inside the trailing 60 days right now, a real current lull, not a fault.
A real example, worked out
Signal #1652, Dallas, TX. Already counted in the table above, not a hand-picked demo.
“Data Centers in Dallas: Preliminary Research [Emily Liu, Director, Planning and Development]”
Source posted: Aug 18, 2026 · Detected: Aug 26, 2026 · 8 days later
The math: Aug 26, 2026 minus Aug 18, 2026, counted in whole calendar days, is exactly what is shown above, and it is exactly what the Dallas, TX row in the table already counts.
Verify this yourself
Every number on this page is read from our production database, never estimated. If you have access to this codebase, three read-only commands reproduce everything above:
python scripts/scoreboard.py # latency and freshness per source python scripts/verify.py # source-link and quote rule, across all signals python scripts/detection_latency.py # full latency detail, including excluded backfills
If you do not have that access, the worked example above is the same proof in public form: two real dates, a real quote, and a real link to the source document, so the arithmetic can be checked without trusting anything we say about it.
The per-source table is recomputed from the production database every day, and a daily health check ("published speed claim") fails, loudly, if that refresh ever stops. The published pair at the top is checked by the same health check, which fails the moment it overstates what the database shows. It does not fail if we understate our own speed, only if we overstate it. Questions: gridfreeze@shaachi.com.