Sources answer "who says so." The verifiedOn field answers a different question that most registries never ask out loud: when did anyone last look?
There is a gap between a constant being sourced and a constant being watched. A row can cite the right document and still rot — the document gets superseded, the rule gets repealed, the value gets corrected — and a citation cannot notice any of that on its own. The facts registry closes the gap with a field so plain it is easy to underrate: verifiedOn, the date a human last confirmed the row against its primary source. This piece is about the discipline that field enforces, the statuses that back it, and why the registry's most reassuring artifact is a correction it left visible.
Three statuses, one honest lifecycle
Every row carries a status, and the API's own description defines the vocabulary: verified means confirmed against the cited primary source; repo-asserted means the value is in use but pending human re-confirmation; historical means superseded and kept for the record. The lifecycle is the design. A row does not go from current to deleted — it goes from verified to historical, with its source and dates intact, because stored envelopes that cited it still exist and still deserve an explainable citation. And the middle status is the candid one: a registry that can say "this value is asserted but not yet re-confirmed" is a registry whose "verified" actually means something.
| Status | What it certifies | What a reader should do |
|---|---|---|
| verified | A human checked this row against the cited source on the stated date | Rely on it, and cite it with its period |
| repo-asserted | In use, awaiting human re-confirmation | Usable, but check the source yourself for high-stakes work |
| historical | Superseded — kept so old answers stay explainable | Never apply it to a current computation |
The cadence behind the date
A verification date implies a verification calendar, and the registry's calendar follows the sources rather than the seasons. Year-scoped rows get re-verified when their document cycle turns — the autumn cost-of-living and inflation-adjustment documents for retirement limits and income thresholds, the spring §223 procedure for HSA figures. Statutory rows — the NIIT rate, the HSA catch-up, the SBA guaranty percentages — carry permanent-style periods and need attention only when Congress acts, which is exactly what their period field signals. The legislative scan is the cadence's backstop: rules get repealed as well as revised, and the WEP/GPO repeal is the standing reminder that a registry watching only for new numbers will miss deleted laws entirely.
Why the date is not the authority
A subtle misreading is worth preventing: verifiedOn is an audit field, not an authority field. The source document is what makes a value true; the date only records when a human last confirmed the two still match. A row verified yesterday against the wrong document would be worse than a row verified last quarter against the right one — which is why the registry treats source precision as the harder discipline, and why the correction in the callout above mattered even though no displayed value changed. Freshness and correctness are different axes. The registry holds both because a reader needs both to decide how much checking of their own a given use deserves.
What integrators should do with the field
- Read verifiedOn relative to the row's document cycle — a year-scoped row verified before its season turned is due, not wrong.
- Weight status over recency — verified and historical mean more than any date alone.
- For regulated work, re-verify against the cited source yourself and record your own date — the registry's citation makes that a five-minute task.
- Watch the notes field — corrections and cadence explanations live there.
- Copy the pattern — any constant your own product maintains deserves a source, a period, a status, and a date.
The field as a promise about people
Everything else in the platform is mechanical — hashes verify, harnesses diff, fixtures assert. The verifiedOn date is the one field that certifies a human act: someone opened the document and looked. That is deliberately unautomatable. Software can prove that an engine matches a spec; it cannot prove that a spec matches the Internal Revenue Bulletin. The registry's answer is to make the human check a recorded, dated, public event — small enough to repeat every cycle, visible enough that skipping it would show.
Sources
- [1] Worthune facts registry. https://worthune.com/facts
- [2] Worthune facts API (status definitions in the response itself). https://worthune.com/api/v1/facts
- [3] Worthune writing: Anatomy of a Facts Registry Row. https://worthune.com/writing/facts-registry-explained