← All writing

Guide

Every claim in the scorecard carries an expiry date

Aug 14, 2026

A scorecard is only as good as its stalest fact. Mine gives every claim an expiry clock, and the quarterly re-check would rather leave a row visibly stale than fake a refresh.

Every claim behind the scorecard lives in a ledger row with a source tier, a last-verified date, and a re-check cadence matched to how fast that particular fact rots.

When a source re-confirms exactly, the row gets a fresh stamp. When it doesn't, the row goes visibly stale. That second behavior is the whole point: most "last updated" stamps record that a page rebuilt, not that anyone re-read a source.

The scorecard is a draft economic report card I helped build for a city commission (details generalized to protect the people involved). Roughly forty factual claims sit under its grades, each one a row in a claim ledger. A row holds the claim, its source, and the source's tier, plus the two columns that do the real work: last_verified and verify_cadence, the clock that says how often the row must be re-checked. These columns exist so my scorecard can't wear a fresh timestamp it didn't earn.

Why do facts rot on different clocks?

Because their sources move at different speeds. A statute barely shifts in a decade. A live licensing dashboard can change under you in a week. Census-vintage numbers (vintage: which edition of the source a figure came from) roll over once a year, all at once.

One re-check schedule would be wrong in both directions: too slow for the live figures, pure busywork for the stable law. So the worklist that designed this system, dated 2026-06-10, sorted every row into four classes: static-legal, annual-vintage, point-in-time, and live-status. Point-in-time and live-status rows get a 90-day clock. Annual-vintage rows get an annual one. Stable law is re-checked on legislative news, not on a timer. The same design brief specified a guard that warns on overdue rows. It also required that a different model class do the re-checking than the one that wrote the row, so the author never grades its own homework. Its own words for the goal: re-verification becomes machinery, not heroics.

What does the quarterly walk actually do?

Less than you'd expect, on purpose. The walk is read-only on values. Two runs are on the record, 2026-06-18 and 2026-07-15, over a ledger of 39 and then 40 rows. Both re-checked the most volatile claim clusters regardless of due dates, and each run changed exactly six last_verified dates and zero metric values.

A row is re-stamped only when its source re-confirms exactly: same figures, same vintage. If anything moved, the run is not allowed to "helpfully" refresh the number while it verifies. That would be two jobs in one prompt, and the second job corrupts the first — a verifier that can edit values will eventually smooth over exactly the drift it was built to catch.

The runs also state plainly what they could not reach. One dashboard renders in JavaScript and its domain was blocked from the sandbox. The run confirmed its figures through an official-page search snippet and labeled the confirmation as exactly that: a snippet match, not a direct read. Weaker evidence, recorded as weaker evidence.

What happens when a source dies mid-quarter?

The best row in this ledger is the one that refused its stamp.

Between the ledger's build and the June run, a federal agency superseded the eligibility list underneath one claim (details generalized). Whether the region still qualified now lived in an appendix the sandbox could not read, a binary spreadsheet, plus an interactive federal map that needs a real browser. The run had a choice: assume continuity and re-stamp, or hold.

It held, twice. In both recorded runs that row's last_verified stays frozen at 2026-06-10, visibly stale. The row carries a written follow-up path — open the appendix in a browser, search for the region, then stamp the row to the new list's vintage — and a flag for me. The July run even noted that browsers were technically connected and still declined to drive one, because letting an unattended task drive a browser is a decision that belongs to a person.

Stale-with-a-reason is a far better state than "refreshed." A re-verification job that always comes back green is measuring its own scheduler, not the world. I've been burned by that shape before, when a green check hid missing records; this ledger is the same lesson applied to facts instead of files.

Where does the human come back in?

Some confirmations no fetch can settle. A budget adoption was pending during both runs, and its outcome re-bases several revenue rows. The runs did not guess the outcome from news coverage. They wrote an action flag: confirm the adoption result, then re-base the named rows against the adopted schedule. Judgment routes to me by construction, the same division of labor as the rest of my verification setup.

The design is small enough to steal. Give every factual claim a row. Give every row a source, a date, and a cadence matched to how fast its source moves. Make the re-check read-only on values. And make "blocked" a first-class outcome with a reason, a follow-up path, and an owner. Facts rot on different clocks; a verification system that can say "blocked, not confirmed" is worth more than one that always comes back green.

Which claim in your dashboard has quietly outlived its source — and would your refresh job tell you, or just re-stamp it?

I'm Ali — I run real life-and-work admin on AI agents, then check their work in the open. More at /about.

Published under my standards. Found an error? Tell me — corrections go in the corrections log, dated, never silent.

@online{ali2026expirydates,
  author = {Ali},
  title  = {Every claim in the scorecard carries an expiry date},
  date   = {2026-08-14},
  url    = {https://alidoes.ai/claims-with-expiry-dates/}
}

Caught something I got wrong? Send it directly. Confirmed corrections go in the corrections log.