Primary sources only, every row dated, and a correction promise that reaches every buyer. This page states the method and its limits in plain terms.
Every row rests on the statute text itself or an agency publication — the code section named in that row’s citation fields. Rows are carried from checker datasets that are anchored, row by row, to those citations; secondary summaries and other vendors’ tables are never the source of a cell. Where a source carries no value — for example, the Final-Paycheck source dataset carries statute sections but no citation URLs — the field ships empty and the gap is disclosed, here and in the data dictionary. Nothing is filled in by inference.
last_verified date. In release 2026.10, that date is 2026-10-26 on all 424 rows across both tables.YYYY.MM. Each release ships the full refreshed file, a machine-readable diff (one row per changed cell: old value, new value, citation, effective date), and a plain-language changelog entry.Feed subscribers receive a quarterly re-verification stamp: the tables are re-checked against their sources on a quarterly cycle, and the stamp states the date of that check. Change alerts are separate and faster — an alert is sent at signing, when a change is enacted, not only when it takes effect, because legislatures regularly sign laws months before they bite.
A change and a correction are different things, and they are labeled differently. If a cell was wrong — not changed by law, wrong — the corrected cell is re-issued to every licensee of record, File buyers and Feed subscribers alike, with the correction called out in the changelog. Buyers are told. A corrected value is never quietly patched into a file and left for buyers to discover.