The easy version of AI for building code is a chatbot that reads the codebook and answers questions in plain language. It is fluent. It is fast. It is almost always wrong in the ways that matter.
The harder version is a system that surfaces issues with a citation a reviewer can verify. That is the system architects need.
Why the chatbot shape is wrong for the problem
Building code is not advisory. It is the legal basis a project is permitted against. An answer that paraphrases the code shifts the work of verification onto the person reading the answer — at a moment when they are designing, not auditing.
Summaries also hide their failure modes. A summary that is wrong by one occupancy class, one threshold, or one exception reads exactly the same as a summary that is right. The architect has no signal.
What a real citation looks like
For a flagged issue to be useful, the citation has to be specific enough that a reviewer can open the codebook and verify it without help. That means, at minimum:
- The adopted code edition (IBC 2021, CBC 2022, etc.)
- The chapter, section, and paragraph or table
- The specific element in the model the issue is tied to
- The values the system used to reach the conclusion
"Egress capacity is insufficient" is not a citation. "IBC 2021 Table 1004.5, applied to a Group B occupancy at 150 sf/occupant for the 2,400 sf assembly area shown on Level 02, requires 16 occupant capacity at this exit" is a citation.
The local amendment layer
Every jurisdiction adopts the model code with modifications. Sometimes a single section is struck. Sometimes a whole chapter is replaced. Sometimes a state amendment is overridden by a city amendment.
A useful citation has to surface both layers. The model code section that applies, and the local amendment — if any — that modifies it. Without that layering, the architect cannot tell whether they are looking at the rule that actually governs the project.
What this constraint rules out
Once "every issue has to cite a verifiable source" is a hard requirement, several common approaches stop working:
- Models that generate code language from scratch
- Pipelines that paraphrase a section before evaluating against it
- Systems that mix the model code and local amendments into a single blended text
- Anything that cannot show its work
What remains is a system that treats the licensed code text as the source of truth and reasons over it directly.
Auditability is the product
Architects do not want to be told they are out of compliance. They want to be able to confirm that a flagged issue is real, decide how to resolve it, and stand behind that decision with a stamped set.
That means every issue the system surfaces has to be defensible — to a colleague, to a client, to a plan reviewer. The citation is what makes that possible.
"The system told me" is not a defense. "Here is the section, here is the value, here is the element" is.
What the system has to do
To produce that kind of output, the system has to:
- Translate code text into structured rules tied back to the section they came from
- Carry the citation forward through every evaluation step
- Track which amendments apply to which project, by jurisdiction
- Surface the values it used, not only the result
None of that is something a model does on its own. It is a property of the pipeline around the model.
Where we landed
Kestrel translates licensed code text into structured logic, keeps the citation attached at every stage, and runs the evaluation against the model itself. The output is a list of flagged issues, each one tied to the element that triggered it and the section that governs it.
We wrote about the underlying approach here: AI building code compliance in Revit →
If you want to see what cited issues look like on your own model: Schedule a demo →