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 27 August 2026, over the trailing 60 days. Reproduce with python scripts/scoreboard.py.
| Source | Median | Worst | Catches |
|---|---|---|---|
| Prince William County, VA | 1d | 8d | 3 |
| Loudoun County, VA | 3d | 8d | 26 |
| PJM TEAC (Dominion load requests) | 7d | 7d | 1 |
| Dallas, TX | 8d | 8d | 1 |
| Austin, TX | — | — | no live catches yet |
| Columbus, OH | — | — | no live catches yet |
| Mesa, AZ | — | — | no live catches yet |
| Mesquite, TX | — | — | no live catches yet |
| San Antonio, TX | — | — | no live catches yet |
| Seattle, WA | — | — | no live catches yet |
| Madison, WI | — | — | no live catches yet |
| Nashville, TN | — | — | no live catches yet |
A source reading "no live catches yet" may still hold matters on its jurisdiction page: those are first-scan backfills, found the moment a brand-new collector came online, which measure how old the archive was, not how fast we detect. They are reported separately, never folded into this table.
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.
This page is re-checked automatically every day (health check "published speed claim"), which fails, loudly, the moment any number here overstates what the database actually shows. It does not fail if we understate our own speed, only if we overstate it. Questions: gridfreeze@shaachi.com.