CFR Annual Editions API: Point-in-Time Regulations with corpusType=CFR_ANNUAL

The CFR you query today tells you what a regulation says now. It does not tell you what it said when the conduct happened, which is the version an enforcement action, an audit, or a contract dispute is actually about. corpusType=CFR_ANNUAL serves the Government Publishing Office's own printed annual editions of the Code of Federal Regulations, 31 editions from 1996 to 2026, all 49 titles. asOf=YYYY-MM-DD on a section body resolves a date through the CFR revision calendar to one of those editions and returns that edition's text as printed. This post covers how the resolution works, what each field of the asOf block claims, and the three limits that matter before you cite anything it returns.

TL;DR

• 312,132 distinct sections, held as 886,066 section versions and served as 2,844,809 retrieval passages. The section count is what enters the federal total; the version count is depth in time. They are not additive.
• This is not extra breadth. It is the same body of regulation as corpusType=CFR (222,251 sections), observed at published dates.
• asOf runs over two engines and says which answered. asOf.engine is stored_edition for CFR_ANNUAL, meaning a published edition held verbatim, and observed_change everywhere else, meaning a reconstruction.
• A title revises on a fixed quarter day. Titles 1 to 16 on January 1, 17 to 27 on April 1, 28 to 41 on July 1, 42 to 50 on October 1. So 40 C.F.R. on 2024-05-01 is answered by the 2023 edition.
• editionsObserved is an enumeration, never a range. A year missing from it is an edition nobody parsed, and a date landing there is reported out of coverage rather than answered from a neighboring year.
• The citation year is the volume's own revision statement, not the folder GPO filed it under. GPO reprints unchanged volumes forward without re-dating them.
• Every point in this corpus is superseded law by construction. All 312,132 sections carry actStatus: "superseded", and none is certified good law.

What CFR_ANNUAL is, and what it is not

Two corpora carry federal regulations, and they answer different questions.

The section counts do not sum, and the gap between them is not extra regulation. CFR_ANNUAL counts section addresses across 31 published editions, while CFR counts only what stands today, so the two answer different questions about the same body of law. Figures are from GET /us/statutes/coverage, measured 2026-09-07T06:39:48Z, which is free and authoritative over anything published here.

The storage model matters when you read a count. A section is stored once per distinct run of text across editions rather than once per edition, so a regulation reprinted unchanged for six years is one document that names all six years. That is why 886,066 versions cover 31 editions of 312,132 sections rather than the roughly 9.7 million rows a per-edition model would produce.

The revision calendar

The CFR is not revised all at once. Each title has a fixed annual revision day, and asOf resolves your date against the day for the title you asked about.

A date of 2024-05-01 against title 40 lands after the 2023-07-01 revision and before the 2024-07-01 one, so the 2023 edition answers it. The same date against title 17 lands after 2024-04-01, so the 2024 edition answers it. Two sections cited in the same memo, on the same date, can therefore resolve to different edition years, and that is correct rather than a bug.

The asOf block, field by field

Every asOf answer carries a provenance block whose whole purpose is to stop the text being over-read. Read engine first, because isBounded does not make the same claim on both engines.

The two source values you will see on this corpus are published and unavailable. published means an edition we hold answered, verbatim. unavailable means the date is out of coverage for that section, and outOfCoverageReason says which of the three ways. reconstructed never appears on CFR_ANNUAL, because nothing here is reconstructed; it belongs to the observed_change engine that answers every other corpus, and it is the value you should treat with the most care when you see it elsewhere.

A worked resolution

Search the corpus first. Section ids are opaque and assigned at ingest, so build them from a response rather than from a citation.

curl -s https://api.vaquill.ai/api/v1/us/statutes/search \
  -H "Authorization: Bearer vq_key_..." \
  -H "Content-Type: application/json" \
  -d '{
    "query": "hazardous waste generator testing and recordkeeping",
    "corpusType": "CFR_ANNUAL",
    "limit": 3
  }'

A hit comes back with an id of the form CFRANN_2017_T40_P268_S268_7 and a citation that names the edition:

{
  "actId": "CFRANN_2017_T40_P268_S268_7",
  "citation": "40 C.F.R. § 268.7 (2017 ed.)",
  "corpusType": "CFR_ANNUAL",
  "year": 2017,
  "titleNumber": "40",
  "sectionNumber": "268.7"
}

Now ask that section for a date.

curl -s "https://api.vaquill.ai/api/v1/us/statutes/section/CFRANN_2017_T40_P268_S268_7/body?asOf=2024-05-01" \
  -H "Authorization: Bearer vq_key_..."

The response returns the text of a different run than the one you started from, and says so:

{
  "actId": "CFRANN_2020_T40_P268_S268_7",
  "available": true,
  "source": "cfr_annual_edition",
  "asOf": {
    "requested": "2024-05-01",
    "engine": "stored_edition",
    "source": "published",
    "existed": true,
    "resolvedEditionYear": 2023,
    "scheduledEditionYear": 2023,
    "editionsObserved": [2020, 2021, 2022, 2023, 2024, 2025],
    "isBounded": true,
    "outOfCoverageReason": null
  }
}

Three things to notice. The returned actId is the run's own id, first observed in the 2020 edition, so the id you get back is not the id you asked with. editionsObserved says this exact text stood unchanged through six editions, which is a stronger statement than the single year in the citation. resolvedEditionYear and scheduledEditionYear agree here, which is the ordinary case and not the guaranteed one.

editionsObserved is an enumeration, not a range

This is the field most likely to be misread, and misreading it produces a confident wrong answer rather than an error.

Ask the same section for a date before coverage starts:

{
  "available": false,
  "note": "1994-01-01 resolves to the 1993 edition of title 40, earlier than the first edition we hold (1999)",
  "asOf": {
    "requested": "1994-01-01",
    "engine": "stored_edition",
    "source": "unavailable",
    "scheduledEditionYear": 1993,
    "resolvedEditionYear": null,
    "editionsObserved": [1999, 2000, 2001, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022, 2023, 2024, 2025],
    "isBounded": false
  }
}

2002 is absent from that list. It sits between the first and last year held, so anything that treats the array as a span would report 2002 as covered. It is not: a date resolving to the 2002 edition of this section comes back out of coverage rather than answered from 2001 or 2003. Treat the array as a set membership test, never as a minimum and a maximum.

The folder year is not the citation year

GPO reprints an unchanged volume into the next year's folder without re-dating it, and the staleness is per volume rather than per title. So the year in the publication path is not the revision year of the text inside it. In title 26, 167 versions sit in the 1997 folder carrying a 1990 revision statement. The schema's own example is 4 C.F.R.: the 2024 printing is the January 1 2019 revision.

That is why two year fields exist. resolvedEditionYear is read from the volume's own printed revision statement and is the one to render. scheduledEditionYear is what the calendar computed, and it is exposed so the disagreement is auditable rather than so it can be displayed. Rendering the scheduled year would publish a citation to an edition that does not say what you claim it says.

Honest limits

State these to your users before they find them.

The quarterly granularity is the one that surprises people. If you need to know the day a rule changed rather than the edition it first appeared in, the annual editions are the wrong tool and the Federal Register API is the right one, because that is where the effective dates and the amendatory instructions live.

Where this sits against the rest of the corpus

Point-in-time law comes in two forms with different guarantees, and this corpus is one of them. A published edition is text a government printed on a date and you can cite it as such. A reconstruction is assembled from changes we observed, reaches back only as far as capture began for that source, and cannot be cited the same way. Amendment history and point-in-time law works through when each applies and what to build when neither is available.

For the current CFR, its title and part hierarchy, and the daily refresh behind it, see the CFR API post. For why every point here comes from GPO rather than a commercial mirror, see legal data provenance. For learning that a section you snapshotted has moved since, see how legal change detection works.

FAQ

What is corpusType=CFR_ANNUAL?

It is the token for GPO's officially published annual editions of the Code of Federal Regulations, 31 editions from 1996 to 2026 across all 49 titles. It holds 312,132 distinct sections as 886,066 section versions. It is distinct from corpusType=CFR, which is the CFR as it stands today and is what you should query for current law.

How does asOf pick which edition answers my date?

It looks up the fixed annual revision day for the title you asked about, then selects the most recent edition revised on or before your date. Titles 1 to 16 revise on January 1, 17 to 27 on April 1, 28 to 41 on July 1, and 42 to 50 on October 1. A request for 2024-05-01 against a title 40 section therefore resolves to the 2023 edition, because title 40 revises on July 1.

What is the difference between asOf.engine and asOf.source?

engine names which backend answered and is the field to read first: stored_edition for CFR_ANNUAL, observed_change for every other corpus. source is the detail within that engine, so on CFR_ANNUAL it is published when an edition we hold answered and unavailable when the date is out of coverage. reconstructed and live only appear on the observed_change engine, where the earlier text is rebuilt rather than printed.

Why is editionsObserved a list rather than a first and last year?

Because a year between the first and last can be an edition nobody parsed, and treating the array as a range would silently claim coverage of it. A live example: a title 40 section lists 1999, 2000, 2001, then 2003, with 2002 absent. A date resolving to the 2002 edition of that section is reported out of coverage rather than answered from 2001 or 2003.

Can I cite text returned by asOf on this corpus?

You can cite it as the text GPO printed as of the revision date the response names in resolvedEditionYear, which is what the citation string on the section already says, for example "40 C.F.R. section 268.7 (2017 ed.)". Cite that year, never scheduledEditionYear, because GPO reprints unchanged volumes forward and the two can disagree. Do not cite it as current law: every section in this corpus carries actStatus: "superseded".

Does this corpus tell me whether a regulation is still good law?

No, and it is not built to. Every point is superseded by construction, and none carries a certified good-law verdict. For what is in force today, query corpusType=CFR, and for the rulemaking that changed it, query corpusType=FEDERAL_REGISTER.

What happens if I ask for a date before coverage begins?

The response comes back with available: false, asOf.source: "unavailable", asOf.isBounded: false, and an outOfCoverageReason sentence naming the earliest edition held for that title. No text is returned, and the call is refunded because you asked for a historical text and did not get one. A date that does not exist on a calendar, such as 2026-02-30, is rejected as a 422 and is not charged.

Why did the response come back with a different actId than the one I sent?

Because a section is stored once per distinct run of text rather than once per edition, and the id names the first edition of the run. Asking a 2017 run for a 2024 date returns the run that actually covered 2024, so CFRANN_2017_T40_P268_S268_7 can answer with CFRANN_2020_T40_P268_S268_7. Both are stable ids for the same citation at different points in time, and the editionsObserved array tells you which years the returned run spans.

Is the section count in CFR_ANNUAL additional coverage?

No. It is the same body of regulation as the CFR corpus, observed at published dates, so the 312,132 sections here and the 222,251 in CFR must never be added together. Depth in time is the 886,066 version count, not a larger section total.

Start here

GET /us/statutes/coverage is free, returns the live count and scope note for every corpus type including this one, and is authoritative over any figure published on this site. The edition resolution rules and the full field reference live in the point-in-time documentation and the federal coverage page, and the token list is at corpus types.

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.