AI code compliance checking: how it works and its limits

What is AI code compliance checking?#

AI code compliance checking is software that reads a design, from PDF drawings or a BIM model, and compares it against building code requirements to flag possible issues such as egress widths, travel distances, fire separations and accessibility clearances. It is a review aid: it narrows where a code reviewer looks, but it does not replace the architect's code analysis or the plan review by the authority having jurisdiction.

Tools in this category combine older rule-based model checking with newer language and vision models. Rule-based checkers test model objects against coded rules and give repeatable answers. Language models answer code questions, summarize sections and read drawing notes, which widens coverage but adds new ways to be wrong.

PDF drawings vs BIM models as inputs#

The input format decides what an AI code checker can actually see. The same tool can perform very differently on a well-structured model and on a scanned permit set.

In both cases, the design has to say what the code needs to know. A corridor drawn without a rating, or a room without an occupancy classification, cannot be checked reliably by any tool, however capable.

Which code requirements can software check well?#

Software checks quantifiable, geometric requirements best and interpretive requirements worst. The closer a requirement is to a measurement, the more a tool can help; the closer it is to a judgment, the more it depends on the professional.

Tools that answer code questions in plain language can also cite the wrong section or paraphrase a requirement inaccurately. Treat any citation as a pointer to check in the code text itself, not as the answer.

• 1Generally checkable: occupant load calculations, egress widths, travel distances, door clearances, plumbing fixture counts and many accessibility dimensions.
• 2Partly checkable: fire-resistance ratings and separations, which depend on assemblies and listings named in the documents.
• 3Hard to check: code official interpretations, alternative materials and methods, performance-based design and existing building compliance paths.
• 4Outside scope: whether the occupancy classification itself is right, which drives almost everything downstream.

Local amendments and the adopted code edition#

The adopted code edition and local amendments decide which requirements apply, and both vary by jurisdiction. Model codes such as the International Building Code are published in editions, and states, counties and cities adopt a specific edition, sometimes with amendments, on their own timelines.

A tool that checks against the latest model edition can flag requirements your jurisdiction has not adopted, or miss amendments it has. Before relying on any finding, confirm which edition and amendments the tool used, and verify the result against the code in force where the project is located. Fire codes, accessibility standards and energy codes add further layers with their own adoption cycles.

Common error modes to plan for#

AI code checkers fail in predictable ways, and each failure has a practical mitigation. Firms that pilot these tools should log errors by type, because the pattern shows where the tool can be trusted and where it cannot.

Questions to ask before adopting a code checking tool#

The questions to ask before adopting a code checking tool are mostly about transparency: what the tool checks, against which code, and what happens to your drawings. Vendor demonstrations tend to show clean models, so test on your own projects.

Ask each vendor the same questions in writing and keep the answers with the pilot results. That makes the decision easier to revisit when the tool, the code edition or the firm's workflow changes.

• 1Which code editions and which jurisdictions' amendments does the tool cover, and how is that shown on each finding?
• 2Which requirements are checked by coded rules and which by a language model?
• 3Does each finding cite a section the reviewer can open and confirm?
• 4What input formats does it accept, and what model or drawing standards does it expect?
• 5Are uploaded drawings retained, shared or used to improve the vendor's models?
• 6Can results be exported so the firm keeps a record of each review?

Illustrative: piloting a checker on a closed project#

Illustrative: Copperline Architects, a fictional firm designing offices and light industrial buildings, wants to test an AI code checker without risking a live permit. It picks a closed project that already went through plan review and has a code analysis sheet, the plan review comment letters and the firm's responses on file.

The team runs the tool on the permit set and compares its flags with the actual review comments. Some flags match real comments, some are false positives resolved by exceptions the firm had already documented, and a local amendment the reviewer cited is missed entirely. The firm adopts the tool as a pre-submission check only, with every flag verified by the project architect.

The pilot also shows the firm how useful its own records are: code analysis sheets, comment letters and responses form a tested set of questions and answers about real buildings.

Why plan review records matter for these tools#

Code checking tools are built and evaluated on examples of real code analysis: drawings, the issues reviewers found and how designers resolved them. Architecture firms hold that chain in code analysis sheets, plan review comment letters and response letters, often across many jurisdictions and editions.

SourceX treats these as candidate workflow records. They are reviewed in the Rights step of the SourceX five-step transaction for client confidentiality, quoted code text is treated as third-party content, project identifiers are removed in Preparation, and the SourceX Evidence Packet documents provenance and permitted use.