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 re-pulling the whole code on a calendar 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.

Reviewed and corrected on 12 October 2026. This is general information, not legal advice.

TL;DR

• Cadence is a property of the source. On the live GET /boards list (12 October 2026, 310 boards): daily for the CFR and the Federal Register, weekly for the US Code and federal local court rules, monthly for nearly everything else, quarterly for the Arkansas, Georgia and Tennessee statute boards.
• Some states can be pulled whole (an official bulk export, an API, or a complete per-section fetch), so a run re-pulls the entire code and reconciles it against what is live. Everywhere else a scraper sweeps the site.
• Colorado is checked once a month for a new edition and re-pulled only when one appears, 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.
• cadence is declared per board, so read it together with lastRetrievedAt. A lastRetrievedAt older than the cadence allows means silence on a watch tells you nothing.
• Freshness is something you can measure yourself. Per-source retrieval timestamps are free (they need an API key but cost no credits) and machine-readable, which is harder to fake than a promise.
• Set up a scheduled coverage diff. Two free endpoints, a cron, and about 50 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. Why a vendor cannot go faster than the source is the subject of Why Legal Data Cannot Refresh Faster Than Its Publisher.

A short history: the law has always run on a schedule

Publisher-set cadence is older than the internet. Print law had one too. The Office of the Law Revision Counsel prepares the U.S. Code for the House, and its About page says a complete new edition is printed every six years, with five annual cumulative supplements in the years between. It also says why the printed Code always trails the statute book. Printing "cannot begin until after the corresponding congressional session ends because laws enacted at the end of the session may affect titles at the beginning of the Code," so "there is necessarily a lag between the date a law is enacted and the date on which it appears in the printed version of the Code."

The statute builds that lag in. 1 U.S.C. 204, on govinfo, says the Code establishes the law as "in force on the day preceding the commencement of the session following the last session the legislation of which is included." In other words, a printed Code speaks as of a session boundary and makes no claim about the day you read it.

The online Code moved that rhythm from years to weeks. The same OLRC page says its staff updates the default online version "throughout a congressional session on an ongoing basis," and its Currency and Updating page states the date the online Code is current through (on 12 October 2026, Public Law 119-120, enacted October 7, 2026). That is still a schedule set by editors. The official source keeps its own clock and tells you what it reads.

The other federal sources keep different clocks. The Federal Register is published every business day, according to the National Archives' About the Federal Register page. The Code of Federal Regulations is revised in print in quarterly installments, and the story of how it got that way is in our CFR API post. A cadence table like the one below is really a list of other people's clocks.

The cadence table

This is the schedule per corpus, read from the cadence field of GET /boards on 2026-10-12. If a row says weekly, that source is meant to be 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.

Either way, the state corpora refresh about once a month, and the board for each state's statutes tells you when the last read happened.

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

Three statute boards declare a quarterly cadence

The boards for Arkansas, Georgia and Tennessee declare quarterly, the only state statute boards that do. A source that republishes per legislative session gains nothing from a monthly full re-crawl, and keeping the state on a thinned schedule matters because a state removed from the schedule entirely is refreshed by nothing and looks identical to a healthy one from outside. Read lastRetrievedAt on those boards rather than assuming a date.

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 re-pulling Colorado's whole code every month would produce identical output eleven times a year. It would also cost the publisher a 46-title crawl each time for nothing.

What runs instead is edition-keyed rather than calendar-keyed. Colorado's monthly slot makes one HTTP request against the publisher's directory index, looking for a new crs<YYYY> edition. If the edition hasn't 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. The coverage endpoint listed 35,758 state statute sections for Colorado on 2026-10-12, and the Colorado statutes board declared a monthly cadence.

What cadence on a state statute board really means

Forty-four state statute boards declare cadence: "monthly" and three declare quarterly. The declared cadence is how often the source is meant to be read, and it is also the interval past which silence from that source becomes a problem worth alerting on.

Read cadence together with lastRetrievedAt, always:

Compare the two yourself. A lastRetrievedAt older than the cadence allows means silence on a watch is uninformative rather than evidence that nothing changed. That distinction is the entire value of reading the two fields together. A watch that hasn't fired because the source hasn't been retrieved on schedule looks exactly like a watch that hasn't fired because the law didn't move, unless you check.

Check freshness yourself instead of taking a number on trust

The useful thing a data vendor can give you here isn't 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 (they need an API key and are rate-limited), 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 lets you catch an overdue source or a coverage drop 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?limit=500" \
  -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

# Allowed age in days before a board is flagged, by declared cadence.
MAX_AGE_DAYS = {"daily": 3, "weekly": 10, "monthly": 40, "quarterly": 120}

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["data"]["boards"]:
        state = f"/{b['state']}" if b.get("state") else ""
        name = f"{b['label']} ({b['corpusType']}{state})"
        last = b.get("lastRetrievedAt")
        if not last:
            problems.append((name, "no lastRetrievedAt"))
            continue
        age = (now - dt.datetime.fromisoformat(last.replace("Z", "+00:00"))).days
        if age > MAX_AGE_DAYS.get(b.get("cadence"), 40):
            problems.append((name, f"{age}d old, cadence={b.get('cadence')}"))
    return problems

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

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

We ran this script on 12 October 2026 against the live boards and coverage responses. It parses both shapes and flags boards by age, and when we edited one jurisdiction's count in a copy of the file to simulate a drop, it printed a DROP line. Run it as python3 freshness-diff.py coverage-today.json coverage-yesterday.json boards-today.json.

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. Past text is a separate read.

A citation with no date carries the text in force now. Add asOf=YYYY-MM-DD to the section body call and the response names the engine that answered in asOf.engine. On stored_edition, which covers the CFR annual editions, the US Code, the Copyright Compendium and OFAC FAQs, you get an edition we hold, and a date between held editions comes back unavailable; for the US Code most historical dates currently fall outside the editions we hold. On observed_change, every other corpus, the earlier text is rebuilt from changes we observed, and asOf.isBounded set to true means we saw no change affecting your date, which is not the same as there having been none, because capture began after the corpus did. For a litigation argument that turns on wording as of a past date, check asOf.engine and asOf.isBounded first and fall back to the publisher's own edition where the bound bites.

Alongside it: amendment history and a lastAmendedYear per section, a yearFrom/yearTo filter, 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."

Be careful with the year filters. They read the last amendment year the publisher credits (else the effective year, else the publication year for corpora dated that way), so they follow the law rather than our rebuild date. Sections with none of those dates drop out of results once either bound is set. Amendment History and Point-in-Time Law takes that filter apart properly.

Why a frequent pull is often enough for rules, and when it isn't

The claim that a rule's effective date is rarely inside a week of publication rests on a rule you can read. Under the Administrative Procedure Act, "the required publication or service of a substantive rule shall be made not less than 30 days before its effective date," except for three categories: a rule that "grants or recognizes an exemption or relieves a restriction," interpretative rules and statements of policy, and cases where an agency finds good cause and publishes that finding with the rule (5 U.S.C. 553(d)).

So the 30-day cushion is the default, and the exceptions are where a pull can be late. A rule that relieves a restriction can take effect sooner than 30 days, and so can a rule that carries a good-cause finding. If your customers act on same-week deadlines, check the effective date on every rule you surface rather than trusting the pull schedule to leave room.

Which cadence should you build on

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 isn't the same as how often the law changes, and it isn't 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 about 50 lines.

Why do the Arkansas, Georgia and Tennessee statute boards say quarterly?

Their boards on GET /boards declare quarterly, where the other state statute boards declare monthly. Treat the declared value as that board's schedule, and read lastRetrievedAt for the actual age of each one.

Does Vaquill AI publish an uptime or freshness SLA?

Contractual uptime or freshness terms are a conversation for contact@vaquill.ai. What is published today is per-source retrieval timestamps on a free endpoint, so you can measure the real thing rather than rely on a percentage.

Which US legal corpora update daily?

Two boards declare a daily cadence: the Code of Federal Regulations, and the Federal Register (which also carries Presidential Documents such as executive orders). The US Code and federal local court rules are weekly. Federal agency guidance from 53 named sources, Statutes at Large, and state insurance bulletins from 49 jurisdictions are monthly.

What happens when a state repeals a section?

On a pull-whole 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 swept 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 daily or 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, a scheduled pull isn't 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 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.