Ask a BIM model a simple question, such as "which load-bearing walls are above the third floor", and the answer is buried several relationships deep. In an IFC file the wall does not know which floor it is on. A relationship object says it is contained in a storey; another says the storey is part of a building; a property set, attached through a third relationship, says whether the wall is load-bearing.
That shape is why BIM data is slow to query in a relational database and awkward for AI to reason over. It is also why we project IFC models into Neo4j. This post explains how that projection works, what it unlocks, and where the limits are, drawing on the AI material recommendation engine we built for BioBuild, which runs on exactly this stack.
Why IFC data is slow to query
IFC models every link between elements as its own object. Four of them do most of the work:
- IfcRelAggregates breaks the project into site, building and storeys.
- IfcRelContainedInSpatialStructure places walls, slabs, columns and ducts in a storey or space.
- IfcRelDefinesByProperties attaches property sets, such as
Pset_WallCommon.LoadBearing. - IfcRelVoidsElement and IfcRelFillsElement link a wall to its openings, and the openings to doors and windows.
Stored in tables, each of those hops is a join, and a real question needs several of them, often recursively. A model of a mid-sized building holds hundreds of thousands of these objects. Queries that read naturally to an engineer become slow, hard to write, and easy to get subtly wrong. A wrong answer here is not an error message; it is a confident list that silently leaves out half the building.
Projecting an IFC model into Neo4j
In a graph the relationships are first-class, so the model's own structure becomes the query path. Our projection is deliberately plain:
- Every spatial element and every building element becomes a node, labelled with its IFC class:
IfcBuildingStorey,IfcWall,IfcDoor. - Containment, aggregation, voids, fills and connections become edges:
CONTAINS,AGGREGATES,HAS_OPENING,FILLS,CONNECTS_TO. - Property sets are flattened onto the element node, so
LoadBearingorFireRatingis a property, not another hop. - Every node keeps the element's IFC
GlobalId, which is what makes every answer traceable back to the model.
The question from the top of this post becomes one short query:
MATCH (s:IfcBuildingStorey)-[:CONTAINS]->(w:IfcWall)
WHERE s.elevation > 9.0 AND w.LoadBearing = true
RETURN w.globalId, w.name, s.name
ORDER BY s.elevationIt reads the way the engineer asked it, and it returns GlobalIds the viewer can highlight in the model.
Keeping the graph honest
The projection is not a second source of truth. In the BioBuild build, BIMserver holds the IFC models and their revisions. When a model is revised, the affected part of the graph is rebuilt from the new revision, matched on GlobalId. Three rules keep this safe:
- The IFC file wins. Nothing is edited in the graph and written back.
- Every answer carries GlobalIds, so a reviewer can check it against the model in one click.
- The graph records which revision it was built from, so an answer is never silently about last week's design.
What we built on it
For BioBuild, a sustainable home builder in Sweden, the graph is the layer the AI reads. When a designer changes the model, the engine walks the graph to find the affected elements and their loads, constraints and neighbours. It then scores candidate materials on cost, embodied carbon and structural fit, and returns a ranked shortlist per element.
Live since January 2025 on more than six projects, it cut material selection time by 40% and material cost by 20%, and shortened project timelines by 20%. The full story is in the BioBuild case study, including BioBuild's own verified review.
What a graph unlocks for AI on BIM data
Once the model is a graph, several things buyers ask us about become tractable. Here is how we would approach each, with a clear line between what we have delivered and what we have not.
AI component query. A language model translates the engineer's question into a graph query against a fixed schema, and the result comes back as GlobalIds. The model never answers from memory, so the failure to design against is a correct-looking query over the wrong subset. Showing the query and the element count next to every answer is the guard.
Session-aware BIM AI. Coordination is a conversation: show me the level four ductwork, then which of those clash with structure, then who owns them. Each question only makes sense after the last. In a graph, the session is simply the set of node ids the previous answer returned, and the next query starts from there.
AI issue navigation. Clash detection produces more issues than a team can read. The useful work is grouping and ordering them. Clashes that share a root cause, such as one duct run crossing a dozen beams, are connected in the graph and collapse into one issue. What remains can be ranked by what blocks work on site first.
AI-assisted BIM QA. Rule checks, such as missing property sets, naming conventions and orphaned elements, are deterministic and belong in graph queries, where results are reproducible. A model earns its place on the judgement calls, such as an element classified unlike every comparable element in the project.
We have shipped the graph projection and the recommendation engine on top of it. We have not shipped a natural-language query product, session-aware assistant or clash triage tool. Each of those should start as a proof of concept against your own model.
How to start
The risk in BIM AI is rarely whether a model can be trained. It is whether your model data is consistent enough to build on. A two-week proof of concept answers that before you commit to a build:
- Week one: project one of your IFC models into Neo4j and run your three hardest questions against it.
- Week two: measure the answers against what your engineers would have found by hand, and decide what to build.
Send us one model file and the question you most want answered. The options are on our engagement models page, and you can reach the team here.
Frequently asked questions
Should Neo4j replace BIMserver or our IFC files?
No. The IFC file stays the source of truth and BIMserver keeps handling versions and IFC parsing. Neo4j holds a projection that is rebuilt when the model is revised, keyed by each element's GlobalId, so any graph answer can be traced back to the file.
Can AI query BIM components in plain language?
Yes, and the hard part is not the language model. The model turns the question into a graph query against a fixed schema, and the answer comes back as element GlobalIds the reviewer can select in the model. Without the graph, the same question becomes a slow recursive search that is easy to get subtly wrong.
What is session-aware BIM AI?
An assistant that remembers the current review. The selected elements, active discipline and filters already applied persist across turns, so a follow-up narrows the previous answer instead of starting again. In a graph, that state is just a set of node ids the next query starts from.
How does AI help navigate BIM issues and clashes?
By ordering them, not finding more. Clashes that share a root cause, such as one duct run hitting a dozen beams, are connected in the graph and collapse into one issue. What remains can be ranked by what blocks work on site first.
How does AI-assisted BIM quality assurance work?
Two layers. Deterministic rules, such as required property sets, naming conventions and orphaned elements, run as graph queries and give reproducible results. A model then flags elements that look unlike every comparable element in the project, which is where judgement is needed.
Has Metwaves shipped this?
The graph projection, yes: it runs in production inside the AI material recommendation engine we built for BioBuild, live since January 2025. We have not shipped a natural-language BIM query product; that should start as a proof of concept against your own model.
Nikit Nandan
Strategy Director
Nikit is experienced in conducting in-depth research to stay abreast of industry trends and emerging technologies.
