Checking a building against regulations is still mostly a person reading a document and a model side by side. Slow, expensive, and error-prone in the specific way that human checking always is: fine on the clauses you remembered to look at.
Every previous attempt at automating this hit the same wall. Somebody had to hand-translate the regulations into machine-readable rules first, and that translation was itself months of specialist work that went stale the moment the code was amended.
What this paper did differently
It let the model read the regulation directly. No intermediate human translation step. The LLM interprets the text, extracts the relevant BIM data, executes the checks, and writes reports that include its own step-by-step reasoning.
The work is framed as four sub-questions, which is a useful way to think about the whole problem: interpret the rule, prepare the building model, execute the rule, report the result.
- 1
Structure the code
The building code is converted to JSON, segmented by clause, and validated against a JSON Schema so the structure is guaranteed before anything reasons over it.
- 2
Map dependencies
Clauses that depend on other clauses are identified, and query strings are generated for the model.
- 3
Classify checkability
Each rule is assessed for whether BIM can answer it at all. Does it involve geometry, or is it a procedural requirement no model can settle?
- 4
Filter by relevance
BIM metadata decides which clauses actually apply to this building, rather than checking everything against everything.
- 5
Extract and check
Geometry is pulled according to the model's interpretation of the applicable clauses.
Why these numbers are less exciting than they look
Those are strong figures and they measure the front half of the problem. Interpretation, preparation and tool selection.
What they do not measure is whether the checks then run correctly against a messy real model and produce findings a coordinator would agree with. The paper is honest about this framing, and the authors' own conclusion is the interesting one: the hard part that remains is reliable execution and reporting.
We have spent a decade automating the part that turned out to be easy.
That reframing is worth more than the percentages. The industry's assumption has been that rule translation was the bottleneck, which is why so much effort went into rule languages and standardised requirement formats. If a language model can now read a regulation and correctly decide what it applies to, the bottleneck moves downstream to execution against imperfect models.
The companion study that got the design right
Worth pairing this with a 2026 EC3 paper from TUM, because it solves a problem this one does not: how do you know the agent is right?
Their approach was to run Solibri rule sets against IFC models, extract the GUIDs of the violating elements from the resulting BCF reports, and use those as ground truth to benchmark an LLM agent. They also gave the agent a classify_spaces tool so it was working with the same information the commercial verifier had.
That is the cleanest agent-versus-incumbent comparison design I have seen in this area. The industry tool becomes the reference answer, the agent is given equal footing rather than being handicapped, and the comparison is on identical models. Anyone evaluating a compliance product should be asking their vendor for exactly this.
What to do with this if you run a practice
- Stop waiting for perfect machine-readable regulations. The evidence here is that models can work from the text. Structuring the code as JSON helped, but it is a preparation step rather than a prerequisite years away.
- Ask vendors what their ground truth is. If a compliance tool cannot tell you what it was measured against, it has not been measured.
- Watch the reporting, not the detection. A finding that does not say which element, which clause and why is a finding nobody actions.
- Assume a person still signs it off. Nothing in this literature supports unsupervised regulatory approval, and the liability question has not moved at all.