AI-assisted plan review: what it can check and what it cannot

Reference article · 6 min read

Plan review automation is marketed heavily to permitting agencies, and the pitch usually compresses two very different activities into one word. The first is document handling: opening a submitted set, finding the right sheets, pulling numbers off a drawing, and comparing those numbers to a rule someone has written down. The second is code interpretation: deciding whether a design satisfies a provision that was written in language reviewers argue about. The first is largely tractable with current software. The second is not, and buying as though it were creates records and appeal problems that surface months later.

Drawing that line before procurement is cheaper than drawing it after go-live. The sections below describe what the technology can realistically check, what has to stay with a certified or licensed reviewer, and how to test a product against your own past decisions rather than a vendor demonstration.

What the software can check reliably

The dependable use cases are mechanical and verifiable. They share a common trait: a person could confirm the answer in seconds by looking at the sheet.

• Intake completeness. Whether the submittal includes the sheets, forms, calculations, and professional seals your checklist requires, and whether files open, are legible, and are scaled.
• Sheet indexing and classification. Sorting a large set into architectural, structural, civil, mechanical, electrical, plumbing, and landscape, and locating the site plan, code summary, and life safety sheets.
• Geometry and dimension extraction. Reading setbacks, building height, lot coverage, floor area, parking stall counts, aisle widths, and similar quantities, with much better results from vector PDFs, CAD, or model files than from scans.
• Deterministic numeric rules. Arithmetic checks such as occupant load from an area and a factor, required egress width, fixture counts, or zoning district dimensional standards that reduce to a comparison.
• Cross-sheet consistency. Flagging where a dimension, square footage, occupancy classification, or address differs between the code summary, the site plan, and the floor plans.
• Resubmittal differencing. Showing what changed between revisions so a reviewer is not rereading an entire set to find three modified details.

Accuracy degrades sharply on scanned raster sets, hand markups, photographed sheets, and unusual drafting conventions. Ask what share of your incoming volume is in the formats the tool handles well, because that single fact drives most of the value.

What stays with the reviewer

• Interpretation and equivalency. Alternate materials, designs, and methods requests, performance based approaches, and any provision that turns on approval by the building official.
• Discretionary land use. Design review, variances, conditional uses, compatibility and character findings, and conditions of approval. These are judgment reserved to a reviewer or a board.
• Existing buildings and unusual conditions. Alterations, changes of occupancy, historic structures, and site constraints where the applicable requirements depend on facts not stated on the drawings.
• Whole-design coherence. Conflicts across disciplines, constructability, and the question of whether the drawings describe a building that can actually be built as shown.
• The decision and the signature. Approval authority is assigned by statute and local ordinance to a person or office. Software output is information for that person, never the decision.

How to pilot on submittals you already decided

Run the tool backward before you run it forward. A retrospective pilot on closed permits gives you ground truth you already paid for.

1. Bound the scope to one permit type, one code edition, and your adopted local amendments.
2. Assemble a sample that deliberately includes messy inputs: scanned sheets, small residential projects, and at least a few sets that went through multiple correction cycles.
3. Freeze the answer key first, using the recorded reviewer comments and final disposition, and have a senior reviewer reconcile disagreements.
4. Score both error directions. Missed violations and false flags carry different costs, and false flags are what erode reviewer trust and applicant patience.
5. Measure the human time to verify the tool's output, not the tool's runtime. If verification takes as long as reviewing the sheet, the check is not saving anything.
6. Keep a shadow period in which nothing generated by the tool reaches an applicant.

What accuracy evidence to demand

• Per-rule results, not a headline number. A single overall accuracy figure hides that setback extraction and egress interpretation are different problems.
• A stated definition of correct. Who adjudicated the test set, against which code edition, and how disagreements were resolved.
• Test set composition. Vector versus scanned, project types, disciplines, and sheet counts. A clean sample from one design firm proves little.
• Local amendment handling. Whether the rule set reflects the code you actually enforce, and who maintains it when your jurisdiction amends or adopts a new cycle.
• Abstention behavior. A tool that reports it cannot determine a value is safer than one that always produces an answer. Ask how often it abstains and what happens downstream.
• Your own test set, before award and at renewal. Reserve the right to supply sealed sample sets and to repeat the test after updates.

Disclosure and the administrative record

Tell applicants plainly that automated checks assist intake and review, that a certified reviewer verifies findings, and that the code citation and the reviewer stand behind every correction. Do not let generated comments leave the office unread. Retain the machine output as a record subject to your retention schedule, since it may be requested or appealed, and confirm with counsel how public records exemptions apply to plan sets and to vendor rule logic. Several states and localities have adopted inventory, notice, or assessment requirements for automated decision systems, and these change frequently, so verify current obligations with the official source rather than relying on a vendor summary.

Contract terms worth insisting on

• Acceptance testing tied to the pilot metrics, with remedies if production performance drops below them.
• Transparency into the rule set, with the ability to see, edit, and export the logic applied to your code.
• Update obligations when you adopt a new code cycle, including regression evidence that prior rules still work.
• Data rights stating that your submittals are not used to train models without written consent, and that sensitive plans are protected.
• Exit provisions covering export of rules, results, and comment history in a usable format.
• Language stating the product is advisory and confers no approval authority.

HQT works with state and local agencies on systems engineering, software evaluation, and integration for permitting and regulatory workflows.

Frequently asked questions