Methodology

BuildSpec is a reference. The only thing that makes a reference worth using is knowing where its contents came from and what it does when it is not sure. This page describes how data gets in, what the word “verified” means when we use it, and what the system refuses to serve.

Every number on this page is queried from the production database when the page is generated, and refreshed at least hourly. None of them are typed in. That is a direct consequence of an audit that found three published figures wrong at once — the one recorded in the corrections log.

This page is the mechanics. If you want the reasoning behind them — why we let AI assistants read the whole site, and why the corrections log is public — that is on our stance page.

What BuildSpec publishes

BuildSpec publishes the full text of the 2021 ICC model codes (IBC, IRC, IFC, IPC, IMC, IFGC, IECC) to signed-in members; the full text of public agency publications — state DOT standard specifications and federal documents such as the MUTCD, FP-24, PROWAG and 29 CFR 1926 — free to everyone; and section numbers, section titles, chapter structure, which codes a jurisdiction has adopted and in which edition, and permit requirements and fees.

The code text is the model code as published by the ICC, attributed to the ICC, with no state or local amendments applied and no claim about what your jurisdiction has adopted. Adoption is tracked separately, in the jurisdiction records described below, and the two are not the same thing: read the model text for what the model says, and the jurisdiction record for what is in force. Every section page links to the official ICC publication as well. BuildSpec does not publish NFPA text, and does not reproduce proprietary standards incorporated by reference into the public documents it carries (AASHTO, ASTM, ACI, AISC, ASHRAE, NDS, TMS, AREMA, NFPA).

Ingestion

Model codes and jurisdiction adoptions

Code structure is ingested per code type and edition, then linked to the jurisdictions that adopt it, with the adopting ordinance or statute recorded as a citation where one exists. Adoption is not assumed from a state baseline: a jurisdiction inherits the state record only when it has no record of its own, and the page says which it is showing. The corpus currently holds 23,395 sections across 1,419 code editions.

Permit rules and fees

Permit requirements, department contacts, portals and fee schedules are collected per jurisdiction from the jurisdiction’s own published material, with the source URL stored alongside the value. 2,208 jurisdictions are tracked; 615 have permit rules recorded.

State DOT specifications

State transportation agency specifications are extracted from the agency’s published documents. These are public agency publications rather than licensed model code, so BuildSpec carries their full text and Code AI may quote them directly. Coverage is 9,215 sections from 45 documents across 50 of the 50 states.

Ingestion runs behind a structural guard that rejects documents whose shape indicates they were generated rather than extracted — a fixed section count with no section reaching a plausible length. The guard runs before embedding, so a bad document costs nothing, and it exists because a templated ingest once produced 880 fabricated sections that read as confident engineering guidance and were wrong on real safety parameters.

Verification

“Verified” is a specific claim, not a mood. It means a human or a checked process confirmed the value against the issuing authority’s own published material, and that both the source and the date of that check are stored with the record.

• Fee amounts. A jurisdiction counts as carrying a verified fee schedule only when a permit rule holds actual fee amounts and a fee source URL and a verification timestamp. 184 jurisdictions meet that bar. A larger number — 217 — carry fee amounts of some kind, sourced or not, and we do not describe that larger number as verified anywhere on this site. This is not the same measurement as the fee-schedule-document counts on /why-buildspec, which count jurisdictions whose fee schedule document we have located and dated, and the subset of those that also have rules and amounts. Four counts answering four different questions; each surface names which one it is showing.
• DOT specification sections. Each section carries a verification flag set explicitly at ingest, never inherited from a database default. 9,201 of 9,215 sections are verified.
• Dates, not adjectives.Where a page can show when a value was last checked, it shows the date rather than the word “current”. Permit fees change without notice; a verification date lets you judge the risk yourself.

The verified retrieval gate

This is the part most worth understanding. Unverified data in BuildSpec is not shown with a warning label — it is withheld from retrieval entirely.

The semantic search behind Code AI filters on the verification flag inside the database function itself, not in application code. Serving unverified content requires passing an explicit flag that the product never sets. The consequence is that an unverified section cannot be retrieved, cannot enter the model’s context, and therefore cannot be paraphrased into an answer — not even with a caveat attached. Putting the gate in the query rather than in the rendering layer is deliberate: a filter you have to remember to apply is a filter that will eventually be forgotten.

14 DOT sections currently sit behind that gate. They remain in the database as an audit trail and as the diff against future re-extraction, and they are invisible to retrieval and to search.

Content that was published and later found to be wrong goes further: it is deleted, and its URL returns 410 Gone permanently rather than 404. 410 is the correct signal to a search engine or an AI crawler that a page was withdrawn on purpose and should be dropped rather than retried.

Calculators

Each calculator states the code provision it implements. The calculation logic lives in tested modules separate from the interface, covered by hand-worked cases that encode the provision itself rather than the current implementation, and those cases run in continuous integration on every change. Where a calculator applies a simplifying assumption, the page says so. They are screening tools and are not a substitute for a design professional.

When we get it wrong

Errors are logged publicly at /corrections — what was wrong, how it was found, and what changed — whether a user reported it or we found it ourselves. The most recent entry is dated August 17, 2026. Entries are never quietly revised to look better.

Found something wrong? Email support@buildspec.codes.