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 section numbers, section titles, chapter structure, which codes a jurisdiction has adopted and in which edition, permit requirements and fees, and the full text of public agency publications such as state DOT specifications.

Section numbers and titles are factual references to those publications. Where you need the code language itself, every section page links to the official source at the publisher.

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 7,109 sections across 15 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 8,576 sections from 43 documents across 49 of the 50 states. HI has no coverage yet, and that gap is computed from the data rather than maintained by hand — a coverage claim that counts its own holes cannot quietly become false.

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 schedules.A jurisdiction’s fee schedule counts as verified only when it carries both a source URL and a verification timestamp. 450 jurisdictions meet that bar. A larger number — 215 — carry fee data of some kind, and we do not describe that larger number as verified anywhere on this site.
• DOT specification sections. Each section carries a verification flag set explicitly at ingest, never inherited from a database default. 8,562 of 8,576 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.