Plan Review Comments and Code Corrections as AI Training Data

What a plan-check correction record must contain to train a model

A plan-check correction becomes training data only when it is tied to the rule, the drawing and the resolution, not when it is a free-text remark on its own. A typical correction letter from a building department lists numbered comments by discipline (building, structural, fire and life safety, accessibility, energy, mechanical, plumbing) with a sheet reference such as "A2.1" and a citation like "IBC 1011.5.2" or a local amendment. The designer then answers in a comment-response matrix: comment number, response text, revised sheet, revision cloud or delta number, and sometimes "no change, see calc page 14."

For model work, the unit of record is one comment, carried through every review cycle until it is closed or withdrawn. Without the response and closure, you can train comment generation but not evaluate whether a generated correction was valid. Without the code edition and local amendments, a comment citing "Section 1004" is ambiguous, because occupant load tables and amendment numbering differ across the 2018, 2021 and 2024 IBC cycles and across cities that amend them.

The comments also drift by reviewer. Two plan checkers in the same department may phrase the same accessibility deficiency differently, or one may cite the chapter while another cites the subsection. A dataset that records reviewer role (in-house versus contract plan reviewer) and discipline lets you control for that drift; it does not need the reviewer's name.

Where plan review correction data actually comes from

The public supply is thin, and most of the useful records are held by firms on the applicant side of the counter. Seattle publishes a Plan Comments dataset of reviewer remarks on building permit plan sets, usually many per plan set, in CSV, JSON and other formats under separately specified terms [1]. A third-party mirror reports it at about 26,299 rows and 8 columns [2]. That is useful to prototype a schema, but it lacks code-section labels and designer responses.

Richer holders, each with a different slice:

• Architecture and engineering firms keep correction letters, response matrices and revised sheet sets in project folders (Procore, Newforma, Bluebeam Studio sessions, SharePoint). These are the only source that routinely holds the drawing context.
• Permit expediters see many jurisdictions and project types and often maintain their own trackers of recurring comments by city.
• Third-party plan review firms that perform review under contract to AHJs hold the reviewer's side, including internal checklists and closure notes, but their contracts with the jurisdiction may restrict reuse.
• Electronic plan review systems (Bluebeam-based workflows, Accela, ProjectDox and similar) store markups and comment status, which makes the export format matter more than the source.

Some jurisdictions release correction letters through public records requests. Public-records status of the letter does not settle rights in the drawings it references or in a contract reviewer's work product. Firm-internal QA comments are a related but different record; see design QA/QC review comments and markups.

Copyright in adopted codes, comments and drawings

Assume code text does not travel with the comments, because model codes such as the IBC are copyrighted by their publishers and sold under license, alongside companion products like plan review checklists [3]. Courts have treated the adopted law differently from the model texts behind it, but those disputes concerned public access to the law, not commercial model training. License code text separately from the publisher, or train against citations and your own paraphrased rule representations.

The comments themselves can carry rights as well. In September 2026, the Third Circuit affirmed in Thomson Reuters v. Ross that Westlaw headnotes were copyrightable and that copying them to build a non-generative legal research tool was not fair use [4]. A plan reviewer's annotated checklist or a firm's curated library of recurring comments is a closer analogue to headnotes than a raw correction letter is, so treat curated compilations as licensed content.

Drawings belong to the design firm and, under many owner-architect agreements, carry owner use rights. A correction that says "see detail 5/A5.02" is incomplete without the sheet, so the rights review has to cover both the comment set and the referenced sheets. As of October 2026, if you offer a generative AI system to Californians, California AB 2013 requires posted training-data documentation, first due January 1, 2026 [5], which is easier when provenance is recorded per record.

Mapping comments to code sections and jurisdictions

Normalize every citation to a canonical key of jurisdiction, code, edition and section, and keep the reviewer's raw citation beside it. A practical key looks like US-WA-Seattle | SBC | 2021 | 1011.5.2 where SBC is the locally amended code, with a pointer to the base IBC section when the amendment modifies rather than replaces it. ICC sells plan review record checklists keyed to IBC sections [3], which can serve as a label taxonomy once licensing allows.

In a new jurisdiction, expect some comments to need human mapping, because reviewers often write "provide guardrail per code" without a section. Label those as "uncited" rather than guessing; a model trained on guessed citations learns to hallucinate section numbers, which is the failure mode plan checkers notice first. Separate administrative comments (missing stamp, fee, special inspection form) from technical code corrections, since they inflate apparent accuracy.

Illustrative record schema for a comment-response pair

The schema below shows how one correction can be delivered with its resolution and context in a single JSONL record.

Illustrative example: invented to show structure; it does not describe an available dataset.

{
  "comment_id": "PRJ-0412-C1-017",
  "review_cycle": 1,
  "jurisdiction": "US-XX-Example City",
  "adopted_code": {"code": "IBC", "edition": 2021, "local_amendment": "EC 1011.5.2 amended"},
  "discipline": "building",
  "reviewer_role": "contract_plan_reviewer",
  "occupancy": "B",
  "construction_type": "V-B",
  "sheet_ref": "A3.10",
  "detail_ref": "4/A3.10",
  "comment_text": "Stair riser height exceeds maximum. Revise detail 4.",
  "code_citation_raw": "IBC 1011.5.2",
  "code_citation_norm": "US-XX-Example City|IBC|2021|1011.5.2",
  "comment_type": "technical",
  "designer_response": "Riser revised to 7 in. max; see revised detail 4/A3.10, delta 2.",
  "revised_sheet_ref": "A3.10 rev 2",
  "resolution": "closed_cycle_2",
  "pii_treatment": "reviewer and owner names removed; site address generalized to city",
  "rights_basis": "firm and owner approval recorded"
}

Fields that buyers most often regret omitting are review_cycle, resolution and adopted_code. Without them, you cannot build an evaluation set that asks "would this comment have been upheld?"

Privacy, security and redaction in permit records

Remove reviewer names, applicant contact details and residential owner names and addresses before delivery, and generalize parcel numbers. Title blocks on sheets carry stamps, license numbers and owner names, so redaction must cover the image layer, not only the comment text. For critical facilities, ask whether sheets show security systems, egress routes in detention or health occupancies, or utility details the owner considers sensitive; those sheets may be excluded even when the comments can be released.

Buyer checklist before you license plan review data

Use this checklist in procurement and counsel review; each item maps to a common failure in plan-review model projects.

Illustrative example: invented to show structure; it does not describe an available dataset.

For comparable "finding plus response" records in other domains, see construction submittal review data and critique and revision data for generative verifiers.

Using the data for generation, evaluation and RAG over adopted codes

Split the data by use: comment generation needs volume, evaluation needs closure labels, and retrieval needs licensed code text. A held-out evaluation set should be partitioned by project and jurisdiction, not by comment, or the model will see sibling comments from the same plan set. Retrieval-augmented review works best when the index holds your licensed code text plus local amendments keyed by the same canonical citation, so retrieved sections and comment labels align. Keep a version field per jurisdiction so a code adoption change does not silently invalidate older comments.

SourceX sources operational datasets from US companies and manages licensing and ongoing purchases; buyers describe the records they need and SourceX looks for businesses that hold them. You can describe your plan review data requirement on the buyers page. For broader context, start at the industry-specific operational data hub or the AI data guide, and see owner pages for architecture firm buyers, CAD and engineering drawings and construction project records.

Sourcing plan review comments datasets with SourceX

SourceX sources plan review and other operational records on request from US businesses that hold them; a request does not guarantee a match, and every release is approved by the supplying company. Each dataset is rights-reviewed for ownership and consents, personal details are removed or replaced before delivery, and data is delivered under a license defining records, uses, term and delivery. Tell SourceX what plan review data you need.

This page is general information, not legal advice. Confirm requirements with counsel for your jurisdiction and use case.