Legal Data Freshness: What Refresh Cadence Actually Means, Source by Source

Short answer: refresh cadence is set by the publisher, not the vendor. The CFR is amended continuously, so we pull it daily. The Colorado Revised Statutes are published once a year with no periodic-update process, so pulling them weekly would be theater. "Always up to date" is a sentence with no engineering content; what you need is a per-source cadence, a way to see the last successful pull, and a cron job of your own that checks both. This post gives you all three.

TL;DR

• Cadence is a property of the source. Daily for the CFR and executive actions, weekly for the Federal Register and agency guidance, monthly for court rules and constitutions, annual for the Sentencing Guidelines.
• 24 jurisdictions can be pulled whole (an official bulk export, an API, or a complete per-section fetch), so every run re-pulls the entire code and reconciles it against what is live. Everywhere else runs on a monthly sweep.
• Colorado is checked weekly and re-pulled annually, because the Revisor's office confirmed in writing on 2026-08-17 that the C.R.S. is updated once a year with no process for periodic updates.
• The cadence field on GET /boards reads monthly for every state statute board. Read it as the staleness window a board is alerted against, not a ceiling on how often the corpus is re-pulled.
• There is no published uptime SLA and no freshness SLA. What exists instead is a free, machine-readable way to check the real age of any source yourself, which is harder to fake than a promise.
• Set up a scheduled coverage diff. Two free endpoints, a cron, and 30 lines of Python get you an alert when a source goes stale before your users find it.

One of the posts in our legal data infrastructure series.

Cadence only means something once a source is known to be the publisher's own, which is how to tell where a statute actually came from. Where these intervals are headed is How Fast Should Legal Data Refresh?.

The cadence table

This is the whole schedule, per corpus. If a row says weekly, that source is read every week whether or not anything changed.

The distinction that actually matters: pull-whole versus sweep

Two states can both say "monthly" and mean completely different things. The variable is whether the publisher lets you take the whole code in one go.

Pull-whole means there is an official bulk export (a zip of the entire code), an official API, or a per-section fetch complete enough to walk the whole tree. Every run re-pulls the entire code and reconciles it against what is live, so a section deleted by the legislature disappears from the corpus on the next run. Nothing accumulates.

Sweep means the publisher gives you no bulk artifact, so a scraper walks the site on a monthly cycle. It works. It is slower to notice a deletion, and it is more fragile when the publisher redesigns a page.

The 24 jurisdictions on the rolling weekly bulk cycle

These are re-pulled whole and reconciled on a seven-day rolling slot:

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, Wyoming.

They are hashed into seven day-slots rather than all firing on the same day, so roughly three or four run per day and the cycle rolls continuously across month boundaries. That detail matters more than it looks: an earlier version keyed the slot to the day of the month, which produced a gap at every month end and quietly turned the weekly job into a monthly one. California once went 14 days without a dispatch under that scheme.

The last three boxes are a separate mechanism with its own failure modes, covered in How We Know a Law Changed.

Three of the 24 sit behind a 91-day floor

Arkansas, Georgia, and Tennessee stay on the weekly sweep but carry a minimum interval of 91 days between full passes. The reason is the legislative calendar plus a shared rate ceiling on the source portal.

The Arkansas General Assembly meets in regular session in odd years. Georgia's sits January to early April. Tennessee's General Assembly sits January to April and one full pass is 35,794 documents.

Quarterly asks the publisher for about four full passes a year, which covers the sessions. Keeping them on the sweep at all matters, because a state removed from the schedule entirely is refreshed by nothing and looks identical to a healthy one from outside.

The Colorado case, told properly

Colorado is the clearest example of why a calendar cadence can be a lie.

The Colorado Revised Statutes are published as an annual edition. On 2026-08-17 the Revisor's office confirmed in writing that the C.R.S. "is only updated once a year. There is no process for periodic updates."

So a weekly re-pull of Colorado would produce identical output 51 times a year. It would also cost the publisher a 46-title crawl each week for nothing.

What runs instead is edition-keyed rather than calendar-keyed. Colorado's weekly slot makes one HTTP request against the publisher's directory index, looking for a new crs<YYYY> edition. If the edition has not changed, the run exits with a code that the orchestrator maps to a legitimate skip. When a new edition appears, the full 46-title crawl fires and the corpus is rebuilt and reconciled.

The current corpus is the crs2026 edition, 45,794 points across 35,758 sections, cut over from the publisher's own site on 2026-08-23.

What cadence: monthly on a state statute board really means

Every state statute board on GET /boards declares cadence: "monthly". That looks like it contradicts the rolling seven-day cycle above. It does not, and the reason is worth understanding before you size your own polling.

The declared cadence is the staleness window the board is alerted against. It is the interval past which we treat silence from that source as a problem worth paging about. It is a floor on our own monitoring, not a ceiling on re-pull frequency.

A single declared cadence across all state statute boards keeps the alerting simple. If a state's refresh fails, it surfaces within a month rather than within a quarter, and every state is measured against the same yardstick.

Underneath it, the 24 bulk jurisdictions actually re-pull on the seven-day cycle, and the rest run the monthly sweep. So monthly is the guarantee. Weekly is what most of the big states get.

Read cadence together with retrievalStatus, always:

Each of those values is defined in the status and currency reference. Anything other than current means silence on a watch is uninformative rather than evidence that nothing changed. That distinction is the entire value of the field. A watch that has not fired because the source is failing looks exactly like a watch that has not fired because the law did not move, unless you check.

Check freshness yourself instead of taking a number on trust

The useful thing a data vendor can give you here is not a percentage. It is a free, machine-readable way to check the actual age of any source yourself, at any time, without asking anyone. GET /us/statutes/coverage and GET /boards both cost zero credits, and the coverage endpoint reference documents the first field by field.

The two are different kinds of thing, and the second is the one your monitoring can use. An SLA is a promise about the future backed by a credit. A lastRetrievedAt timestamp is a fact about the past that you can read and act on before your users notice anything. A vendor quoting a 99.9% freshness figure with no per-source timestamps is asking you to trust a number. Per-source timestamps hand you the raw material to alert on.

Ask for both. Contractual commitments belong in the contract, and neither one substitutes for an endpoint you can poll.

The scheduled coverage-diff recipe

Here is the monitoring most teams should run. It takes two free calls and catches every class of staleness before a customer does. A shorter version lives in the coverage monitoring recipe.

Step 1: snapshot coverage on a schedule

#!/usr/bin/env bash
# freshness-snapshot.sh - run daily via cron
set -euo pipefail
STAMP=$(date -u +%Y-%m-%d)
OUT=~/vaquill-freshness

mkdir -p "$OUT"
curl -sf https://api.vaquill.ai/api/v1/us/statutes/coverage \
  -H "Authorization: Bearer $VAQUILL_API_KEY" > "$OUT/coverage-$STAMP.json"
curl -sf https://api.vaquill.ai/api/v1/boards \
  -H "Authorization: Bearer $VAQUILL_API_KEY" > "$OUT/boards-$STAMP.json"

Step 2: diff today against yesterday and alert on the deltas that matter

#!/usr/bin/env python3
"""freshness-diff.py - alert on stale boards and coverage drops."""
import json, sys, datetime as dt

MAX_AGE_DAYS = {"daily": 3, "weekly": 10, "monthly": 40, "annual": 400}

def load(path):
    with open(path) as fh:
        return json.load(fh)

def check_boards(boards):
    now = dt.datetime.now(dt.timezone.utc)
    problems = []
    for b in boards.get("items", []):
        status = b.get("retrievalStatus")
        cadence = b.get("cadence", "monthly")
        last = b.get("lastRetrievedAt")
        if status in ("failing", "never_retrieved"):
            problems.append((b["label"], f"status={status}"))
            continue
        if status in ("paused", "retired", "not_scheduled"):
            continue # declared on purpose, not a failure
        if not last:
            problems.append((b["label"], "no lastRetrievedAt"))
            continue
        age = (now - dt.datetime.fromisoformat(last.replace("Z", "+00:00"))).days
        if age > MAX_AGE_DAYS.get(cadence, 40):
            problems.append((b["label"], f"{age}d old, cadence={cadence}"))
    return problems

def check_coverage(today, yesterday):
    drops = []
    old = {j["state"]: j["sections"] for j in yesterday.get("jurisdictions", [])}
    for j in today.get("jurisdictions", []):
        before = old.get(j["state"])
        if before and j["sections"] < before * 0.97:
            drops.append((j["state"], before, j["sections"]))
    return drops

if __name__ == "__main__":
    t_cov, y_cov, t_brd = (load(p) for p in sys.argv[1:4])
    for label, why in check_boards(t_brd):
        print(f"STALE {label}: {why}")
    for state, before, after in check_coverage(t_cov, y_cov):
        print(f"DROP {state}: {before} -> {after}")

Step 3: know which signals are real

The 3% threshold is a starting point, not a law. Tune it per jurisdiction once you have two weeks of your own snapshots, because a small code and a large one drift at different rates.

What cadence does not buy you

Cadence tells you how often a source is read. It does not give you a time machine.

Each citation carries exactly one text, the current one, and a refresh that lands a new version replaces the old rather than filing it beside it. There is no as_of=DATE parameter to ask for a past one. If your product needs the exact wording of a statute as of a past date for a litigation argument, this is not the tool for that job.

What you get instead: amendment history and a lastAmendedYear per section, a yearFrom/yearTo filter keyed on the publisher's credited amendment year, change events captured on every refresh, and per-section diffs on the boards you watch. Together those answer "when did this last move, and what moved." They do not answer "what did it say in 2019."

Be careful with the year filters. They key on the last amendment year the publisher credits, so they follow the law rather than our rebuild date, and about a fifth of sections carry no amendment credit at all because some publishers print none. Those sections drop out of results once either bound is set. Amendment History and Point-in-Time Law takes that filter apart properly, including the census behind the one-in-five figure.

Which cadence should you build on

The honest version of that last row: state insurance bulletins are a pilot that lands state by state, and six jurisdictions have no court rules at all. Both facts are covered in the provenance post, which explains why each gap exists and why filling it from a commercial aggregator is not on the table.

FAQ

How often is US legal data actually updated?

It depends entirely on the publisher. The eCFR is amended continuously, so a daily pull is meaningful. The Colorado Revised Statutes are published once a year, so anything faster than an annual re-pull produces identical output. Any vendor that gives you one refresh number for all of US primary law is averaging over sources that behave nothing alike.

What does refresh cadence mean for a legal data API?

Cadence is how often the provider reads a source, whether or not anything changed. It is not the same as how often the law changes, and it is not the same as how quickly a change reaches you, which also depends on the reconcile and change-detection steps that run after the pull.

How do I check whether a legal API's data is stale?

Call its free coverage and boards endpoints on a cron and store the JSON. For Vaquill AI that is GET /us/statutes/coverage and GET /boards. Compare lastRetrievedAt against the declared cadence for each source, and flag anything older than about three times its cadence. The script above does this in 30 lines.

Why does Vaquill AI say cadence is monthly for state statutes if some states refresh weekly?

The declared cadence is the staleness window a board is alerted against, which keeps monitoring uniform across all 52 state and territory statute boards. Underneath it, 24 jurisdictions re-pull whole on a rolling seven-day cycle. Monthly is the commitment; weekly is what most large states get in practice.

Does Vaquill AI publish an uptime or freshness SLA?

No. There is no published uptime SLA and no freshness SLA today. What is published instead is per-source retrieval timestamps and status on a free endpoint, so you can measure the real thing rather than rely on a percentage.

Which US legal corpora update daily?

Two: the Code of Federal Regulations and Executive Orders with other Presidential Documents. The Federal Register agency-rules corpus, Statutes at Large, federal agency guidance from 34 named sources, and state insurance bulletins from 49 jurisdictions are all weekly.

What happens when a state repeals a section?

On a bulk jurisdiction, the next run re-pulls the whole code and reconciles it, so the repealed section is removed from the live corpus on that run. On a monthly-sweep state, removal happens on the next sweep. Either way a change event is written, and any watch on that board fires with a per-section diff.

Can I get an alert when a specific statute section changes?

Yes. Create a watch on the relevant board and you get changes with a per-section diff, delivered by webhook or readable by polling. Size your polling against the board's cadence, because checking more often than the source is read gains you nothing.

Is a weekly cadence good enough for compliance work?

For federal rulemaking, usually yes, because a final rule's effective date is almost never inside a week of publication. For anything with a same-week deadline, weekly is not enough on its own and you should pair it with a direct read of the publisher. Match the cadence to the shortest deadline your users face, not to the average one.

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.