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 cannot 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 is not 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.

Gate 2: whether the source can be pulled whole

There are two ways to refresh a corpus, and they are not 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 is not a config change, it is four times the request volume against a publisher who did not build for it.

The quiet failure mode in the right column is the reason crawling harder is not 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 prohibit automated access. Those corpora are paused and declared, not crawled harder.

A corpus sits in paused when it is complete and officially sourced but not re-pulling, most often because the publisher's own access rules require it. Each one is named in the freshness array with the reason it stopped.

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

A faster cadence never means ignoring robots.txt. That is not a nice-to-have position, it is a hard ceiling: for these sources the publisher has set the cadence, and no engineering effort moves it.

Gate 4: cost and reconcile time

The corpus is 4,150,839 distinct sections indexed as 12,003,716 retrieval passages across 53 jurisdictions. A full re-pull is not 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 do not 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, how often we intend to read it, and how that last read went, in lastRetrievedAt, cadence and retrievalStatus respectively. Each status value is defined in the status and currency reference. The shape looks like this, with illustrative values:

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

A source with a paused or failing retrieval status shows up here rather than going silently stale. That is the whole design goal: you should be able to tell a stale source from a healthy one 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, a measuredAt timestamp, a currency block stating what each corpus is current through in the publisher's own words, and a freshness array that declares every deliberately paused corpus with its reason. The pause reasons in Gate 3 above are not a blog post disclosure. They are fields in the API response.

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 are not polling it. You care that when the text moves, you hear about it, and that when it does not move, nobody wastes your time.

Where cadence and the change feed meet is the honest version of this whole post. Cadence is not 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 does not. 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 does not publish that often, so the extra requests cannot make the law newer. Some publishers prohibit automated access entirely. And a full re-pull across 4,150,839 sections is a pipeline run, not a fetch, so running it four times a day costs real money to catch changes that are not 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 is not 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 retrievalStatus. The call is free and needs only an API key. For statutes specifically, GET /us/statutes/coverage adds a currency block stating what the corpus is current through in the publisher's own words, plus a measuredAt timestamp for the counts themselves.

Why are some state statute corpora paused?

Some sit paused, meaning complete and officially sourced but not currently re-pulling, most often because the publisher's own access rules require it. Each pause is declared with its reason in the freshness array of the coverage response rather than left for you to discover.

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

Versioning here runs off the amendment record rather than a date parameter. Storage keeps one text per citation, the current one, so there is nothing older to return: no as_of=DATE parameter, no version list per section, no arbitrary-date diff. What you get instead is 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, from the matter workbench to drafting, document comparison, document matrix, and citation-verified research.