Somewhere between schematic design and the certificate of occupancy, a project quietly bleeds money. The Get It Right Initiative, a UK industry body, estimates that avoidable errors consume up to 21% of a project’s turnover once indirect costs are accounted for, and its research repeatedly finds that the largest share is attributable to one source: design. Autodesk and FMI put a global number on the same wound, estimating that “bad data” and miscommunication cost construction $1.85 trillion in 2020, including roughly $88 billion in rework. The cheapest moment to catch a code or coordination error is the moment it is created. The most expensive is on site.
For decades, the safety net for that error has been a human plan reviewer reading drawings against a code book. It is slow, it is inconsistent between jurisdictions, and it happens late. “AI code compliance” is the umbrella term for a set of tools trying to move that check earlier and make it repeatable, to evaluate a design against the rules while it is still a model on your screen, not a problem in the ground.
This guide explains what that actually means in 2026, how the technology works, where it genuinely helps, and just as importantly where it does not.
The cheapest moment to catch a code or coordination error is the moment it is created. The most expensive is on site.
What “AI code compliance” actually means (and what it doesn’t)
The phrase hides two very different things, and conflating them is the single most common mistake architects make when evaluating tools.
The first is text interpretation: an AI that helps a human read the code. You ask “what’s the minimum clear width for an egress door serving 60 occupants?” and it answers, ideally with a citation. This is the category most “AI for architects” tools fall into, and the better ones are genuinely useful research assistants.
The second is model evaluation: an AI (or rule engine) that checks your actual building model: the doors, walls, rooms, and stairs you’ve drawn, against those rules and tells you which specific elements fail. This is harder, rarer, and far more valuable, because it operates on the design itself rather than on prose about the design.
The distinction matters because the academic record is blunt about the ceiling on the first category. A 2023 study in the ASCE Journal of Management in Engineering by Zhang, Ma, and Nisbet found that automated compliance systems “can only deal with requirements that include quantitative metrics or specified properties,” leaving roughly half of all building requirements to manual checking, mostly because the language is too ambiguous to automate. An AI that reads code well is not the same as an AI that can certify a model is compliant.
An AI that reads code well is not the same as an AI that can certify a model is compliant.
Why manual code review breaks down on BIM projects
Manual review made sense when a building was a stack of drawings. On a coordinated BIM project it strains for three reasons.
- Volume. A modern commercial project answers to the building code, the fire code, accessibility standards (ADA in the US, Approved Document M in the UK), local zoning, and the client’s own requirements: thousands of discrete provisions, many cross-referencing other documents.
- Change. The model is not static. Every design iteration can invalidate a check performed two weeks earlier. Human review can’t keep pace with a model that updates daily.
- Inconsistency. Two reviewers, or the same reviewer on two different days, will reach different conclusions on the ambiguous provisions. The European CODE-ACCORD research project found that even trained experts annotating building-regulation text agreed with each other only modestly (a mean inter-annotator agreement of 0.37), a striking measure of how much interpretation real code requires.
The promise of automation is not to remove the human, but to handle the high-volume, unambiguous, repeatable checks so the human can spend judgment where judgment is actually needed.
How model-aware compliance checking actually works
Here is the part that demystifies the whole field: your model is a database, not a drawing. A rule engine doesn’t “look” at your building. It queries a structured set of typed objects, and that’s what makes checking possible.
Every meaningful element carries three things a rule can read:
- Classification what kind of object it is (a door, a railing, a space). In Revit these are categories; in the open IFC standard from buildingSMART they are entity types like
IfcDoor. This is the dispatch key: a rule says “for every door, check the clear width.” - Parameters the properties attached to it: fire rating, width, height, U-value, material.
- Relationships how it sits in space: which room it bounds, which storey it belongs to, what it’s adjacent to. This is how an engine computes things like travel distance to an exit or occupancy load.
The checking pipeline then runs a predictable loop: acquire the model (read the live Revit file via its API, or import an IFC export) → select a ruleset → filter to the relevant elements → evaluate each against the rule’s thresholds → score pass/fail per element → report it back, linked to the specific element so you can click the violation and jump straight to the offending door.
That last step traceability depends on a subtlety worth getting right. Revit’s everyday ElementId is only unique within one file and can change when models are synchronized; the durable handles are Revit’s UniqueId and, in IFC, the GlobalId a fixed 22-character identifier stamped on every object. Those persistent IDs are the thread that lets a violation flagged in a checker point back to exactly one element in your model. When a tool says “Door 2.14 on Level 3 fails egress width,” that plumbing is what’s working underneath.
Where AI compliance checking helps most and where it stops
The mature, trustworthy checks are the ones that reduce to a number or a required property. The immature ones require judgment.
| What gets checked | Maturity | Why |
|---|---|---|
| Door/corridor clear widths, headroom, guardrail heights | High | Pure dimensional comparison |
| Occupancy load, egress width, travel distance | High | Computed from area + geometry |
| Required properties present (every fire door has a rating) | High | Data-existence check (the IDS standard, official since June 2024, does exactly this) |
| Zoning envelope, setbacks, FAR | Medium | Geometric, but jurisdiction-specific |
| Accessibility route logic | Medium | Geometry plus conditional rules |
| Performance-based fire engineering, “adequate,” “where practicable” | Low | Requires analysis and professional judgment |
This is the 53% wall in practice: roughly the prescriptive, numeric half of a code is automatable today; the discretionary, performance-based, intent-laden half is not and that half is precisely where most real code disputes live. A good tool is honest about which side of the line it operates on.
It’s also worth separating three things the industry routinely confuses. Clash detection (a duct passing through a beam) asks do two things collide? Compliance checking asks does the design meet the rules? QA/QC asks is the model itself well-formed enough to be trusted? They stack you need a sound model before a compliance verdict means anything but they are not the same tool or the same question. (The companion piece to this article walks through a full QA/QC-plus-compliance workflow in Revit step by step.)
The honest limits: hallucination, jurisdiction, and liability
Any article on this subject that doesn’t address failure modes is selling something. Three caveats deserve to be stated plainly.
Large language models are confidently, measurably wrong about legal text. There is no published benchmark yet for LLM accuracy on US building codes specifically a real gap but the adjacent legal domain is a sobering proxy. Stanford’s RegLab found general-purpose models hallucinate on 69–88% of specific legal queries, and that even purpose-built, retrieval-grounded legal research tools from Westlaw and LexisNexis still hallucinated roughly 17–34% of the time despite “hallucination-free” marketing. Worse, models are overconfident regardless of accuracy and tend to agree with a user’s mistaken premise. For a reviewer looking for reassurance, that’s the most dangerous failure profile there is. The lesson: a credible compliance tool grounds every claim in a citation you can verify and a model element you can inspect it doesn’t ask you to trust a generated paragraph.
The jurisdiction problem is real and unglamorous. The ICC writes the model I-Codes, but they only become law when a state or city adopts them almost always with local amendments, and often a different edition than the next city over. Layer in ADA and local zoning and a single project may answer to four distinct rule sets. A tool’s coverage is only as good as its currency in your jurisdiction. Ask about that specifically, not in aggregate.
Automation transfers neither liability nor authority. The architect or engineer of record remains responsible for compliance under their seal the AIA is explicit that “professional judgment matters more than ever” in the AI era and the authority having jurisdiction still grants the approval. A green checkmark is a productivity aid, not a permit and not a defense. The right mental model is human-in-the-loop acceleration of the checkable work, never autopilot.
A green checkmark is a productivity aid, not a permit and not a defense.
What to look for in an AI code-compliance tool
If you’re evaluating tools, these five questions separate the substantive from the superficial:
- Does it evaluate the model, or just read the code? Text search is helpful; model evaluation against your actual elements is the harder, more valuable capability.
- Is every result traceable? A violation should link to a specific element (by its persistent ID) and to the specific provision so you can verify both the where and the why.
- How is its jurisdiction coverage maintained, and how current is it? Codes change constantly; UpCodes, for instance, reports tracking millions of code sections and tens of thousands of local amendments updated thousands of times a month. Currency is a feature.
- Does it work where you work? For most firms that means inside or alongside Revit and IFC, against real project geometry not a separate silo you have to feed by hand.
- Does it produce deterministic, auditable checks? A compliance verdict you can stand behind has to be reproducible the same model and the same rule giving the same answer every time, with a record of why. That favours tools that turn a rule into a fixed, inspectable check over ones that ask a language model to re-judge every element from scratch on each run (language models are powerful but non-deterministic, and a verdict you can’t reproduce is a verdict you can’t audit).
- Is it honest about the human-in-the-loop? The best tools are built around professional review, not around replacing it.
This is the design philosophy behind newer, model-aware entrants such as VitruAI, which evaluates Revit model elements against structured compliance rules and flags potential violations with their element IDs, so the architect reviews issues directly in the model context rather than in a chat window. It’s a useful illustration of the category direction: model evaluation over text interpretation, element-level traceability, and a workflow that assumes rather than removes the professional’s judgment.
What regulators are doing and where this is heading
The most telling signal isn’t coming from software vendors. It’s coming from the authorities themselves.
Singapore has run automated plan-checking longer than anyone; its new CORENET X platform became mandatory for large projects in October 2025 and reports cutting approval times by more than half by checking submitted BIM models against rules automatically. In the US, the shift is visible city by city: Symbium now issues fully automated, instant permits for residential solar across 270-plus California jurisdictions; Austin, Los Angeles, and Honolulu have deployed AI-assisted plan review (Honolulu reports reviewer time per plan dropping from 60–90 minutes to 15–20); and Seattle has committed to AI-assisted development review with a full rollout in 2026. Federal permitting-reform bills are moving in parallel.
The strategic consequence for designers is symmetry. If the people approving your drawings are checking them with automated logic, you’ll want to pre-clear your model against the same kind of logic before you submit. That is the real trend beneath the buzzwords the industry calls it “shifting left,” borrowing the software term for catching defects early. Compliance is migrating from a paperwork gate at the end of the project back into the act of designing. And the frontier of that movement is no longer a chatbot beside your model but agents that act on the model querying it, checking it, and flagging issues as you build.
The architecture profession has been cautious, and reasonably so: the AIA found in 2025 that only 8% of firms had implemented AI into practice, and the top concern, cited by 94%, was inaccuracy. That caution is exactly why the tools that win will be the ones that are accurate, citable, traceable, and honest about their limits not the ones that promise to do your job for you.
Beyond the single check: turning quality wisdom into a shared asset
Checking one model against the code is the visible win. The larger opportunity and where this technology is genuinely heading is using AI to capture how your best people check, and give it to everyone, on every project.
Start with what an AI layer actually sits across in a firm. There are three bodies of knowledge: the models your team is authoring; the project documentation the brief, the specifications, the design intent and client requirements that give those models meaning; and the codes and standards the work has to satisfy. A genuinely useful assistant reads all three. It converses with you in plain language, connects to the model to read it (and, increasingly, to help correct it), draws on the documentation for context, and the part that compounds accrues memory of every check it has ever run.
That memory is the difference between a tool and an asset, and it works as a loop. When a rule is first set up, a person and the AI reason through it once not just “what does the code say,” but how to check it well: what a real violation looks like, what would be a false alarm, and where the check tends to miss. (In testing terms, you’re deliberately pinning down the true and false positives and negatives, so the check is trustworthy before it ever runs in anger and you tune it so that missing a real violation, the dangerous error, is the one it’s least willing to make.) That reasoning is then compiled into a repeatable, inspectable check rather than something re-litigated from scratch on every run. Every check it performs, pass or fail, is logged, so the system learns where issues tend to recur and what deserves a closer look.
The richest input, though, comes from your QA managers. Today, when a reviewer catches something, that catch lives in their head and their inbox; the next engineer who has their own habitual blind spots is liable to repeat a version of the same mistake on the next project. Most firms only ever pass quality knowledge down by osmosis, seating junior staff beside senior ones, and they lose it wholesale when senior people leave a real and growing risk as the design workforce ages. Converting that knowledge into something explicit and reusable is the step almost everyone skips.
When a QA manager can simply tell the AI what they caught and how they checked it, that becomes a new rule and it joins the library every engineer can run at modeling time, before a model is ever sent to QA. The firm’s hard-won quality wisdom stops being tacit and individual and becomes formalised, shared, and compounding. It behaves like a regression-test suite in software, where every bug ever fixed becomes a permanent automated check so it can never silently return: the practice can no longer regress on any issue it has ever caught. That is the deeper meaning of “shifting left” not just catching code violations earlier, but catching your own firm’s recurring mistakes before they happen. The newer model-aware tools, VitruAI among them, are being built around exactly this loop.
Frequently asked questions
Can AI check building codes?
Partially. AI and rule engines can reliably check the prescriptive, quantitative portion of a code dimensions, clearances, occupancy, required properties by evaluating model elements against thresholds. The discretionary and performance-based provisions, roughly half of a typical code, still require professional interpretation.
Is automated code checking accurate?
For well-defined dimensional rules against a clean model, it is highly reliable. For interpreting code language, accuracy varies and unverified AI answers can be confidently wrong, so credible tools cite their sources and link to the specific model element rather than asking you to trust a generated answer.
Does AI code compliance replace plan review or the architect?
No. The architect or engineer of record retains legal responsibility under their seal, and the authority having jurisdiction still grants approval. These tools accelerate the work and reduce late-stage surprises; they don’t transfer liability or authority.
Which AI compliance tools work inside Revit?
Several operate on Revit and IFC models rule-based checkers like Solibri and the Autodesk Model Checker, and newer model-aware tools such as VitruAI that evaluate Revit elements against compliance rules directly. The key question is whether a tool checks your actual model and traces results back to specific elements.
Can AI learn my firm’s own standards and recurring mistakes?
That’s where the technology is heading. Beyond public codes, the more capable tools let a QA manager register the issues they catch as reusable checks, so a senior reviewer’s hard-won judgement becomes a check every engineer can run at modeling time. Over a few projects this turns your firm’s tacit quality knowledge into a shared, compounding library and reduces the chance the same mistake reaches QA twice.
Conclusion
The cheapest place to catch a code problem is the design model, and that is finally where the technology is moving. The realistic 2026 picture is neither the hype (“automated compliance, no humans needed”) nor the dismissal (“AI just makes things up”). It’s a more useful middle: automation that handles the prescriptive, repeatable, high-volume checks with full traceability, leaving architects to spend their judgment on the ambiguous provisions that actually require it and catching the expensive errors while they’re still cheap to fix.
If you want to see what model-aware compliance checking looks like inside a live Revit workflow, VitruAI offers a practical starting point and the companion guide to this article breaks the workflow down step by step.
