Why Legal Data Cannot Refresh Faster Than Its Publisher

Legal data should refresh as often as the publisher actually publishes, and not one poll faster. That answer is boring and it is also the only honest one, because a corpus can't be newer than the government office that prints the law. This post gives the live cadence per corpus first, then the four things that decide what cadence is even possible for a given source. We build Vaquill AI, so treat the table as the part you can verify yourself with a free API call.

TL;DR

• Today: CFR and executive actions refresh daily, Federal Register, Statutes at Large, federal agency guidance and state insurance bulletins weekly, and 24 state statute jurisdictions get a full 7-day re-pull. Everything else is monthly or as-of-ingest.
• Cadence is set per source, not as one global number. What a source can carry depends on how often its publisher actually publishes, whether it can be pulled whole, what its access rules allow, and what a reconcile run costs.
• A cadence faster than the publisher's own cycle is theater. Colorado publishes its statutes once a year. Polling it every 6 hours burns 1,460 requests a year to catch one event.
• Only some sources can be pulled whole. 24 jurisdictions publish a bulk export, an API, or a complete per-section fetch. The rest have to be crawled, which is slower and heavier on the publisher.
• Ask for a per-source timestamp, not one global freshness number. A machine-readable last-retrieved value per source is worth more than a single percentage, because one number averages away the exact source you care about.
• Cadence is how often we look. A change feed is what you actually want, and law-change alerts with webhook delivery ship today.

Part of our legal data infrastructure series.

The full per-source cadence table is Legal Data Freshness: What Refresh Cadence Actually Means, Source by Source. What a tighter cadence actually delivers is How We Know a Law Changed.

What refreshes today, and how often

This is the live state as of 2026-08-31. Nothing in it is aspirational.

The 24 jurisdictions on the 7-day full re-pull are Arkansas, California, Colorado, Florida, Georgia, Idaho, Illinois, Indiana, Iowa, Louisiana, Michigan, Mississippi, Missouri, Nevada, New Jersey, New York, Oregon, Pennsylvania, Puerto Rico, South Dakota, Tennessee, Virginia, Wisconsin, and Wyoming. They are on that cadence for one reason: each publishes something a run can pull whole, so every run re-pulls everything and reconciles it against what is stored.

What decides the cadence a source can carry

Cadence isn't a dial a vendor turns. Four properties of the source decide it, and three of the four are outside any vendor's control.

These are the same four gates every primary-law vendor faces, whether or not they talk about them.

Gate 1: the publisher's own publication frequency

This is the gate that matters most, and it is the one marketing pages skip.

Colorado publishes its statutes once a year. A 6 hour poll against Colorado is 4 requests a day, 1,460 a year, to catch a single annual event. Every one of those requests after the first is a request that cannot make the law newer. It burns the publisher's bandwidth, it burns our compute, and it produces a "last checked 4 hours ago" timestamp that means nothing about how current the text is.

Colorado is already on the 7-day sweep, which is itself 52 polls a year against an annual publication. That over-poll is for edition detection, not freshness: a weekly check catches a new annual edition within a week of it landing. Going to 6 hours would buy a few days once a year at 28 times the request volume.

Compare that to the CFR. The eCFR changes on most business days, so a daily pull does real work every time it runs. The Federal Register publishes on business days, so its pull cadence is set by how quickly a run can reconcile a day's rules rather than by the publisher.

The honest version of a cadence claim is per source, tied to the publisher's own cycle. "We refresh hourly" is a claim about our infrastructure. "This source is current through the publisher's 2026 edition, and we last checked it 3 hours ago" is a claim about your answer.

Same law, different clocks

Federal sources show how far apart publisher clocks can be, even for one body of law. The Federal Register is published every business day, according to the National Archives' About the Federal Register page. The eCFR describes itself as a web version of the CFR "that we update daily to better reflect its current status" (its help page). The printed CFR "is updated once each calendar year and is issued on a quarterly basis," with titles 1 to 16 current as of January 1, titles 17 to 27 as of April 1, and so on (National Archives). The printed U.S. Code gets a new edition every six years with annual supplements in between, per the Law Revision Counsel.

Follow one rule through that. It appears in the daily journal on a Monday, shows up in the eCFR once the amendment is applied to it, and reaches a printed CFR volume at the next quarterly issue. A statute takes a slower road: the enacted law first, then the Code, whose printed edition arrives every six years. Four clocks, and no poller speeds any of them up. The most a poller can do is notice sooner when a clock ticks.

Gate 2: whether the source can be pulled whole

There are two ways to refresh a corpus, and they aren't close in cost.

Full re-pull and reconcile. The run fetches every section the publisher offers, rebuilds the payloads, and compares the result against what is stored. Anything that differs becomes a change event with a per-section diff. Anything that vanished is investigated rather than deleted, because a fetch failure must never be reported as a deletion.

Crawl. The run walks the table of contents and fetches pages one at a time. Slower by orders of magnitude, heavier on the publisher, and more fragile: a renumbered pager or a lazy-loading index can stall a crawl partway and return a run that looks successful.

24 jurisdictions publish a bulk export, an API, or a complete per-section fetch, which is exactly why those 24 are the ones on the weekly cadence. The rest have to be crawled. Moving a crawled state from monthly to weekly isn't a config change, it is four times the request volume against a publisher who didn't build for it.

The quiet failure mode in the right column is the reason crawling harder isn't the lever it looks like. A crawl that reaches 110 of 254 pages and stops, because the site renumbered its pager mid-walk, produces a run that reports success and a corpus that is missing more than half of what changed. Faster crawling multiplies that risk instead of reducing it.

Gate 3: politeness and the publisher's own rules

Some publishers restrict automated access, and that sets a ceiling on how hard a source can be polled.

For those sources the publisher has set the cadence, and no engineering effort moves it. Crawling harder is not a lever, and a vendor who quotes you a faster rate on such a source is selling you a polling rate, not newer law.

Court rules have a related shape: six jurisdictions with no corpus, for four different reasons, each named in Legal Data Provenance.

What the rules of the road say

Politeness has a standard. The robots.txt convention began in 1994 with Martijn Koster, and the IETF published it as RFC 9309 in 2022. The RFC is plain that this is a courtesy protocol: "These rules are not a form of access authorization." A robots.txt file locks nothing, so it works only when crawlers choose to honor it.

Publishers also speak up when automated traffic gets heavy. In August 2022 a Hacker News commenter quoted a notice from FederalRegister.gov and eCFR.gov: "Due to aggressive automated scraping of FederalRegister.gov and eCFR.gov, programmatic access to these sites is limited to access to our extensive developer APIs." (deathanatos, Hacker News, August 2022). A publisher that points traffic to an API instead of its pages is setting a ceiling on cadence in public.

There is also a cheap way to ask whether a page changed, when the server supports it. HTTP conditional requests let a client say which version it already holds, and the server can answer 304 Not Modified when that version is still current (RFC 9110). That saves bandwidth. It can't make a publisher publish sooner.

Gate 4: cost and reconcile time

The corpus is 5,389,575 distinct sections indexed as more than 20 million retrieval passages across 56 jurisdictions. A full re-pull isn't a fetch. It is fetch, extract, mirror the publisher's own artifact byte for byte, assign identity, enrich, chunk, build payloads, embed, upsert, and reconcile.

Every stage runs behind nine named gates that default to fail, each refusing to publish a run rather than publish something wrong. Gates cost time, and that is the point of them. What each one refuses, and why the default matters more than the list, is in every layer a legal corpus passes through.

Embeddings are cached and keyed by content hash, so an unchanged section costs nothing to re-embed. That is what makes a weekly full re-pull affordable at all. The fetch, the extraction, the gate evaluation and the reconcile pass don't cache away, and those scale with the section count rather than the change count.

So the arithmetic on a six-hour cadence is simple. It means running the pipeline four times a day over millions of sections to catch a change count that, for most state statute corpora, is measured in single digits per week. The cost is real and the yield is near zero, which is why cadence is set per source rather than as one global number.

Why a checkable timestamp beats a freshness percentage

A single global freshness percentage is the wrong instrument for a corpus assembled from 53 publishers on 53 different schedules. Here is the argument for what to publish instead.

A global freshness number is an average across corpora that behave nothing alike, and averaging destroys the signal you needed. A claim like "99% of our corpus refreshed within 24 hours" is dominated by whichever corpus has the most sections. It tells you nothing about the one Puerto Rico insurance bulletin your product depends on.

What replaces it is a per-source, machine-readable, free check. GET /boards returns every watchable source with its own timestamp:

GET https://api.vaquill.ai/api/v1/boards
Authorization: Bearer vq_key_...

There is no credit charge for that call, and you can fire it in the API playground before writing any code. Every row it returns names when the source was last read and how often we intend to read it, in lastRetrievedAt and cadence respectively. The shape looks like this, with illustrative values:

{
  "boards": [
    {
      "corpusType": "CFR",
      "jurisdiction": null,
      "cadence": "daily",
      "lastRetrievedAt": "..."
    },
    {
      "corpusType": "STATE",
      "jurisdiction": "ks",
      "cadence": "monthly",
      "lastRetrievedAt": "..."
    }
  ]
}

Compare lastRetrievedAt against cadence yourself. That is the whole design goal: you should be able to judge how old a source is without asking us. Turning that into a scheduled check is the coverage monitoring recipe.

The second half is GET /us/statutes/coverage, also free. It returns per-jurisdiction counts and a measuredAt timestamp saying when those counts were last measured. What a section is current through travels with the section itself, as currentThrough in the publisher's own words where the publisher states one.

What to demand from any vendor on freshness

Take this to whichever provider you are evaluating, including us. Five items, all of which should be answerable in an afternoon.

One caveat on reading our own boards output honestly. The cadence field reads monthly for every state statute board, including the 24 that get a weekly full re-pull. It is the staleness window a board is alerted against, not a ceiling on re-pull frequency, and the reasoning behind that choice is laid out in what refresh cadence actually means, source by source. Read lastRetrievedAt for the real answer, and treat cadence as the alarm threshold.

That gap is worth checking on any vendor, not only this one. The timestamp is a measurement, the cadence is a policy, and when the two disagree you should believe the timestamp.

The change feed is the real answer

Cadence is how often we look. It is an input. What a customer actually wants is to be told when something moved, and that is a different product.

Law-change alerts ship today. Boards are the registry of watchable sources, keyed by corpus type plus jurisdiction, with jurisdiction null for federal. A watch subscribes to one board. When a refresh reconciles a source and finds that a section's stored text differs from what came back, that difference becomes a change event with a per-section diff, logged against that refresh run. There are endpoints to list changes, fetch a single diff, list deliveries, and send a test delivery, and webhook delivery is live. The subscriber side of all that, including why you still poll, is in Law Change Alerts API: Webhooks for When a Statute or Rule Actually Moves.

That inverts the freshness problem. With a change feed you no longer care whether a corpus refreshed at 06:00 or 18:00, because you aren't polling it. You care that when the text moves, you hear about it, and that when it doesn't move, nobody wastes your time.

Where cadence and the change feed meet is the honest version of this whole post. Cadence isn't a number in a marketing table. It is how soon your webhook fires, on the specific sources where the publisher actually publishes faster than the corpus is polled. Everywhere else, polling harder changes nothing except the infrastructure bill.

For the coverage matrix in docs form, see the API coverage guide.

FAQ

How often does US legal data actually change?

It depends entirely on the corpus. The eCFR changes on most business days and the Federal Register publishes on business days, so daily and near-daily cadences do real work there. A state statutory code typically changes in bursts around a legislative session and then sits still for months, and some states publish a consolidated edition only once a year.

Is a six hour refresh live today?

Only where the publisher supports it, and for most sources the publisher doesn't. The live cadence is daily for the CFR and executive actions, weekly for the Federal Register, Statutes at Large, federal agency guidance, state insurance bulletins and 24 state statute jurisdictions, and monthly or slower for everything else.

Why not just poll every source every hour?

Three reasons. The publisher usually doesn't publish that often, so the extra requests can't make the law newer. Some publishers restrict automated access. And a full re-pull across 5,389,575 sections is a pipeline run, not a fetch, so running it four times a day costs real money to catch changes that aren't there.

What does the cadence field on GET /boards mean?

It is the staleness window the board is alerted against, meaning how long a board can go without a successful retrieval before it is treated as overdue. It isn't a ceiling on re-pull frequency. Every state statute board reads monthly in that field even though 24 of them get a full re-pull every seven days, so read lastRetrievedAt when you want the observed answer.

Does Vaquill AI publish a freshness SLA or an uptime SLA?

No. Neither is published today, and the position in this post is that a per-source machine-readable timestamp is more useful than a single global percentage, because a global percentage is an average that hides the specific source you depend on. GET /boards and GET /us/statutes/coverage are both free and both give you the per-source answer.

How do I check when one specific source was last pulled?

Call GET /boards, find the row matching your corpus type and jurisdiction, and read lastRetrievedAt and cadence. The call is free and needs only an API key. For statutes specifically, GET /us/statutes/coverage adds per-jurisdiction counts with a measuredAt timestamp for those counts, and each section carries currentThrough in the publisher's own words where the publisher states one.

Can I query a statute as it read on a past date?

Yes, with a caveat that matters. asOf=YYYY-MM-DD on a section body reconstructs the earlier text from the before-side of the first change observed after your date, and flags isBounded when the answer rests on when capture began rather than on the law. That is a reconstruction, not a published record. For federal regulations the answer is stronger: published GPO annual editions of the CFR are stored and served as stored_edition. Alongside it you get per-section amendment history and lastAmendedYear, a yearFrom / yearTo filter on the last amendment year the publisher credits, change events captured per refresh, and per-section diffs on a board you are watching.

What is the difference between a change event and an effective date?

A change event is a detected difference between two retrievals of the same section. An effective date is a legal fact published by the legislature or agency. They frequently disagree, because a publisher can restate a page without the law moving, and a real amendment can be published weeks or months before it takes effect.

Do I have to poll the API to find out something changed?

No. Create a watch on the board you care about and receive change events with per-section diffs over webhook. There are also endpoints to list changes, fetch a single diff, list past deliveries, and fire a test delivery so you can verify your endpoint before you rely on it.

Priyansh Khodiyar

Co-Founder & CTO

Priyansh leads engineering and AI at Vaquill AI: the pipelines that pull statutes, regulations and court rules from every US jurisdiction's official publisher, and the REST API, MCP server and open dataset that serve them.