Legal Data Provenance: How to Tell Where a Statute Actually Came From

Short answer: you tell where a statute came from by asking the API to show you, per section, the publisher's own URL and the date it was pulled. "We cover all 50 states" is a claim nobody can check. "This section came from leg.state.xx.us on 2026-08-14, and the publisher says the code is current through the 2026 regular session" is a claim you can verify in a browser tab. The gap between those two sentences is the whole evaluation. This post gives you a five-question test you can run against any provider in an afternoon, and shows how Vaquill AI answers each one.

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

TL;DR

• Coverage counts are unfalsifiable on their own. A provider can count sections it scraped from an aggregator, or counted twice, and the number looks the same from outside.
• Provenance is five yes/no questions: source URL per result, government publisher behind that URL, retrieval timestamp, a currency statement in the publisher's own words, and declared gaps.
• The fifth question is the one that separates real providers from marketing. A provider that never declares a gap either has none (impossible at this scale) or isn't looking.
• Labels are what make provenance checkable. A section from a government publisher says so. A section that comes from an unofficial copy should carry that label, and a link that cannot be shown should be null with a stated reason.
• Vaquill AI states its limits in the open. Where a source is an unofficial copy or a compilation with a stated edition, the section says so in currencyNote or sourceNote.
• A readable pipeline is a strong provenance signal. Vaquill AI's scrapers are open source under Apache-2.0 at open-us-law, so the collection code is auditable.

This is one post in our legal data infrastructure series.

For the machinery that produces the fields tested below, see From a State Website to an API Response: Every Layer a Legal Corpus Passes Through. For what happens after a source is verified, see Legal Data Freshness: What Refresh Cadence Actually Means, Source by Source.

Why coverage counts do not survive contact with an audit

A legal data vendor tells you it covers 50 states. You have no way to check that from the outside. You can't count sections you can't see, and you can't tell a section pulled from the Nevada Legislature's own site from one pulled from a free aggregator that mirrored it in 2021.

Both look identical in a JSON response. Both say "Nev. Rev. Stat. 41.032." One is current law from the publisher of record. The other might be four sessions behind.

So coverage size is the wrong first question. The first question is provenance: for this specific result, which publisher produced the text, and when did you fetch it? Everything else about a legal corpus is downstream of that answer.

A short history: the law, the annotations, and the word "official"

The idea that the law belongs to everyone predates the internet by a long way. In Georgia v. Public.Resource.Org, decided on April 27, 2020, the Supreme Court put it plainly: "The animating principle behind this rule is that no one can own the law." (opinion at supremecourt.gov). The dispute was over Georgia's Official Code. A state commission supervised annotations that a private publisher wrote under a work-for-hire agreement, and the whole package was published "by authority of the state." When a nonprofit, Public.Resource.Org, posted the code online, Georgia sued for copyright infringement over the annotations. Chief Justice Roberts, writing for the Court, held the annotations out of copyright because they were "authored by an arm of the legislature in the course of its legislative duties."

The opinion also shows how slippery "official" is. It notes that the district court saw the annotations as "an unusual case because most official codes are not annotated and most annotated codes are not official." So the notes on a popular site can come from a company with no official role and its own licence terms, while the official code itself may carry no notes at all. When you test a source's provenance, you are really asking which of those two things you are holding.

States have also tried to make "official" checkable. In 2011 the Uniform Law Commission promulgated the Uniform Electronic Legal Material Act. A Yale Journal on Regulation summary lists the worry behind it: "whether the legal material is official, authentic, government data, which has not been altered." The act asks states to authenticate official electronic legal material "by providing a method to determine that it is unaltered," to preserve it, and to keep it accessible. Question 4 of the test below is the buyer's version of the same worry.

The federal government labels its own sources with care. The National Archives calls federalregister.gov its "unofficial version" of the Federal Register in its About page. The eCFR's help page describes it as "an editorial compilation" maintained "as an informational resource." And the Law Revision Counsel says non-positive-law titles of the U.S. Code are "an editorial compilation of Federal statutes" (OLRC). Even free government sites tell you how much legal weight they claim. Keep that label next to the text in your own records.

A Hacker News commenter once boiled the federal version down to a sentence: "Only half of the US Code is authoritative (so called 'positive law titles'). For the rest, the original statutes are authoritative." (joshdata, Hacker News, October 2014). The "half" is his figure from 2014, and which titles count has to be checked title by title. The principle is what matters. A convenient copy and the authoritative text can differ, so you need to know which one you hold.

The five-question provenance test

Run these against any provider's live API. You need a key, a terminal, and about two hours.

Running the test, step by step

Step 1: pull one result and look for a URL

Search for a section you can independently verify.

curl -s -X POST https://api.vaquill.ai/api/v1/us/statutes/search \
  -H "Authorization: Bearer $VAQUILL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query":"deprivation of rights under color of law","corpusType":"USC","limit":3}'

Each result should carry a source URL pointing at the publisher's own copy of that section, and the source format reference says which mirror each corpus keeps. Open it. You should land on the government page for the same citation, not a search page, not a paywall, not a 404. On 12 October 2026 a search for that query returned 42 U.S.C. § 1983 with a sourceUrl on uscode.house.gov. Where a source link is withheld under a licence, our sourceUrl is null and licenseNote says why, so a null needs reading, not just counting.

Do this ten times across different corpora. A source URL that is present on federal results and null on state results is a real finding, and it is the most common failure mode at scale. Nothing in a response's shape makes a null field visible. You have to count.

Run it on every corpus you actually plan to depend on, ours included, and run it per corpus rather than once. Source-URL coverage is a property of an individual corpus, not of a vendor, because each one was built against a different publisher with a different idea of what a stable URL is. A corpus that populates the column for statutes tells you nothing about the same vendor's regulations.

Sample a few hundred sections per corpus, count the nulls, and treat the result as the answer for that corpus only.

Step 2: classify the host, not the string

Write down the hostname from every source URL you collected. Sort them. Then ask, per host, whether the entity behind it is the government publisher of that law.

This is a boring exercise and it is the entire test. An aggregator host in that list means the vendor is willing to serve you a copy, and a copy has no publication date you can rely on.

Step 3: ask for retrieval times

Vaquill AI exposes this on a free endpoint. GET /boards lists every watchable source and answers question 3 with two fields read together: lastRetrievedAt, an ISO-8601 UTC timestamp of when we last pulled that source from its publisher; and cadence, the declared refresh schedule for the source.

curl -s https://api.vaquill.ai/api/v1/boards \
  -H "Authorization: Bearer $VAQUILL_API_KEY" | jq '.data.boards[] | {board: .label, cadence, lastRetrievedAt}'

The pairing matters. cadence alone tells you when we would look. lastRetrievedAt records when we last checked and makes no claim that the law is current as of that date. Compare the timestamp against the cadence yourself: if it is much older than the cadence implies, silence from that source says little about whether the law moved. A provider that gives you a cadence with no retrieval timestamp is giving you half the fact.

What each cadence value commits us to is covered in the companion post on legal data freshness and refresh cadence.

Step 4: read the currency statement, not the build date

GET /us/statutes/coverage is free, in that it costs zero credits (it still needs an API key), and the coverage endpoint reference lists its fields. It returns per-jurisdiction section counts by corpus and a measuredAt timestamp. What a section is current through travels with the section itself, as currentThrough in the publisher's own words where the publisher states one, with currencyNote carrying the same fact as prose.

That phrasing is deliberate. The United States Code corpus is served at the Office of the Law Revision Counsel's current release point. In a search we ran on 12 October 2026, 42 U.S.C. § 1983 carried currentThrough: 2026-09-18. That isn't our build date. It is the release point the Office of the Law Revision Counsel published, and federal law enacted after it lives in the session-law corpus.

The status and currency fields are documented one by one. Quoting the publisher rather than paraphrasing it is what keeps the field honest. A code that is 20 months behind reads as 20 months behind in the response.

Step 5: ask what is missing

This is the question that separates the two kinds of vendor. Ask directly: which jurisdictions do you not have, and why?

Vaquill AI answers this in the API and the docs. GET /us/statutes/coverage reports exactly what is held per jurisdiction and corpus, so a gap shows as an absent key. The coverage docs also name the jurisdictions that are covered but not watchable.

The sourcing policy behind all of this

The sourcing rule is the government publisher's own copy. Where a publisher's robots.txt or access policy prohibits automated access, we stop. Not throttle, not work around it, stop.

That rule has a cost, and the honest version of the cost is a label. Where the only machine-readable copy of a body of law is an unofficial one, the section says so. Our coverage docs name the cases. Massachusetts regulations come from a free copy the Commonwealth disclaims as unofficial, and each section carries that disclaimer in its currencyNote. Oklahoma regulations come partly from agencies' own copies and partly from an older third-party compilation, and currencyNote says which per section. In both, the documentation tells you to cite the official code where the controlling text matters. A coverage number that hides that distinction is not measuring provenance.

The declared limits

Here is what the policy produces. Our corpus is more than 5.3 million sections across 56 jurisdictions (the 50 states, DC, Puerto Rico, Guam, the Northern Mariana Islands, the US Virgin Islands and American Samoa) plus federal law. The limits below are published rather than hidden.

A cadence is a schedule, not a guarantee

A cadence is a schedule, and a schedule does not promise the last run worked. The stored text came from the publisher. To see how long ago we last pulled a source, read lastRetrievedAt on the free GET /boards call and compare it against cadence yourself.

Court rules

Every jurisdiction in the corpus now carries court rules. Missouri and Vermont were the last two added, and a coverage claim from a vendor should be dated the same way: ask when each corpus was last measured.

Colorado is the case worth sitting with. Its last government compilation is from 2023, so the corpus builds on that base and applies the judiciary's later rule-change orders forward. Where an order could not be applied with confidence, the rule serves its 2023 text and says so in sourceNote. On 12 October 2026, C.R.C.P. 26 returned a sourceNote reading "Text from Colorado Court Rules, 2023 edition, published by the Colorado Office of Legislative Legal Services. Amended forward by Rule Change 2024(03)." That label is the thing to read before relying on one of those rules.

Reading the pipeline itself

The strongest provenance signal a vendor can offer isn't a field in a response. It is letting you read the code that produced the field.

Vaquill AI publishes the scrapers that collect and structure the data at open-us-law under Apache-2.0. If you want to know how a Nevada section became a row, you can read the code that made it.

This is the answer to a question no amount of API-surface inspection can settle. A source URL field can be populated by anything. A parser you can read tells you what actually populated it. For what that code does stage by stage, see every layer a legal corpus passes through.

What provenance does not buy you

Being honest about the limits is part of the same discipline.

Provenance and history are different properties. A source URL tells you where today's text came from; it says nothing about what the text said in 2019. That is what asOf=YYYY-MM-DD is for, and it carries its own caveat: read asOf.engine first, then asOf.isBounded. On a reconstruction, isBounded: true means we observed no change affecting your date, which is not the same as there having been none, because capture began long after the corpus did. On a held published edition it means your date fell inside an edition we hold. No amount of provenance metadata substitutes for reading those flags.

What does exist is adjacent and useful: amendment history and a lastAmendedYear per section, a yearFrom/yearTo currency filter that keys on the last amendment year the publisher credits, change events captured on each refresh, and per-section diffs on watched boards. That combination answers "when did this last move and what moved." For "what did it say in 2019" use asOf and its caveats. Which of the four fits which question is worked out in Amendment History and Point-in-Time Law: What a Legal API Can and Cannot Tell You.

A short scorecard you can copy

Score any provider out of 5. Anything below 4 and you are buying a coverage number rather than a corpus.

FAQ

What is legal data provenance?

Provenance is the documented chain from a piece of text in an API response back to the government body that published it. For a statute, that means the publisher's own URL, the date the text was fetched, and the publisher's own statement of what the code is current through. Without those three, a citation string is an assertion rather than a record.

Why does it matter whether a legal API sources from an aggregator?

An aggregator is a copy, and a copy carries the aggregator's update schedule rather than the legislature's. You inherit a lag you can't measure and can't fix. It also introduces a licensing question, because a commercial aggregator's compilation is often the thing being licensed, not the underlying public-domain law.

How can I verify a legal API's coverage claims myself?

Pull 50 results spread across the corpora you care about, extract the source URL from each, and check two things: that the field is never null, and that every hostname belongs to a government publisher. Then open ten of those URLs and compare the text on the page to the text in the response. That afternoon of work tells you more than any coverage table.

How do I tell how recently a source was pulled?

In Vaquill AI's API, GET /boards returns lastRetrievedAt and cadence for each watchable source. Compare the timestamp against the cadence yourself. Where a publisher states what its text is current through, that travels with the section as currentThrough.

Does an open-source ingestion pipeline actually prove anything?

It proves what the code does, which is the one thing an API response can't show you. You can read how a source is fetched, how the text is parsed, and what schema it lands in. It doesn't prove that the deployed system is running that exact code, so treat it as a strong signal rather than an audit, and pair it with the source-URL sampling above.

Can I query US statutes as they existed on a past date?

Yes, with a caveat. asOf=YYYY-MM-DD on the section body endpoint is answered one of two ways. Where we hold the publisher's printed editions (the CFR annual editions, and some US Code editions), it serves the edition that governs your date, and a date in a gap between editions comes back out of coverage. Everywhere else it reconstructs the earlier text from the first change we observed after your date, and isBounded marks an answer that rests on when capture began. Alongside it sits amendment history per section, a lastAmendedYear field, a yearFrom/yearTo filter on the publisher's credited amendment year, and per-section diffs on watched boards, which together tell you when a section last moved.

Does every state have court rules in the corpus?

Yes. Every one of the 56 jurisdictions carries court rules in the live coverage data as of 12 October 2026. Missouri and Vermont were the last two added. Colorado's rules are built from a 2023 compilation with later amending orders applied forward, and each rule's sourceNote says so.

What is the difference between a refresh date and a currency date?

A refresh date is when the vendor last fetched the source. A currency date is what the publisher says the law is current through, which can be much older. For example, a US Code section can carry a currentThrough of 2026-09-18 while the refresh ran weeks later. Design against the currency date, and monitor the refresh date.

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.