During the summer of 2026, I spent six weeks at Granlund through the Adopt an AI Researcher programme implemented under AI Champion. I joined as a visiting researcher from TalTech and continued the work at GPT-Lab Seinäjoki in August.
The work focused on a familiar BIM problem. Construction workflows already use BIM, and these models can provide the basis for a digital twin. However, information is not always machine-readable when it moves between project stages, organisations or software products. When conventions or exports differ, an engineer may still need to read a note, interpret it and enter the result elsewhere. Automating that handover is one step towards end-to-end digitisation.
I tested whether an AI agent could inspect IFC files, locate attributes stored in inconsistent places and map them to a defined target. I also explored model routing and discipline splitting.
Mapping contractor IFC data to RAVA3Pro
RAVA3Pro published Finnish information-content requirements for IFC-based building-control and permit workflows. These requirements define the properties expected in a model and where they should be stored. In this pilot, they provided the target structure for the mapping task.
I tested five IFC models from five contractors. The files described similar building information in different ways. Names varied. Some values were stored in standard property sets, while others appeared in custom Psets or free-text descriptions.
Wall assemblies were a good example. An IFC wall can reference its material layers through a structured material-layer association. In some of the source files, however, the wall was represented as one object and its layers appeared only in short, project-specific text. A value could look like this:
US1 / KL13+MV150+TI130 / U0,17The abbreviations were often in Finnish, written in capital letters and stored without units. A person familiar with the project might read the example as:
Exterior wall type US1: 13 mm gypsum board, 150 mm mineral wool and 130 mm brick, with a thermal transmittance of 0.17 W/m²K.
The information is present, but its structure is implicit. A fixed validation rule cannot safely treat the string as four separate, typed values unless it already knows the project's abbreviations and conventions.
An IFC file is not a flat table. It is an object graph. A wall node can connect to type definitions, property sets, quantities, materials and spatial containers through different relationship classes. Relevant values may sit several edges away from the wall itself or appear in more than one connected cluster.
The agent interacted with the IFC file through inspection tools. It identified an object, followed its relationships, examined the connected properties and then chose the next part of the graph to inspect. What it found at one step changed the next step. It could then map values from different source nodes to the required target attributes. This graph traversal, tool use and change of action based on intermediate results made the workflow agentic rather than a fixed sequence of field lookups.
Across the five models, about 65% of the attributes in the input files could be mapped to the RAVA3Pro standard on average. When the input, output and semantic scope were sufficiently clear, the agent could locate the relevant values and map them across different naming conventions without a separate parser for every file.
The unresolved cases usually fell into two groups.
The value was missing
In some cases, the output mapping required information that was not available in the input file. The agent marked these attributes as information not available.
The semantic scope was unclear
In other cases, a value was present but its semantic scope was not narrow enough. A property called Length, for example, may refer to a clear span, a centre-to-centre distance or a fabricated length. Similar problems occur with gross and net area, or with material mass and shipping weight.
The beam in Figure 2 is an illustrative example of this problem. It is not enough for the source and target fields to share the same label. Their measurement rules must also match.
Length property represents, the mapping requires a project rule or human clarification.
When several interpretations are possible, the agent cannot know which one the target requires. A human engineer faces the same problem unless the project definition makes the scope explicit. The scope therefore has to be narrow enough for the mapping to have one defensible interpretation. Ambiguous fields were marked for review instead of being filled automatically.
Other workflows I explored
The RAVA3Pro mapping was the main pilot. I also tested two related IFC workflows.
Routing incoming IFC models
Large projects receive revised discipline models throughout the project. Their filenames are not always consistent. I explored classifying incoming files from their contents, including IFC entity types, property data and building-services elements, and then routing them to the architectural, structural, HVAC, sprinkler or electrical team.
This is a suitable automation task because the decision can be checked. The system can show which entities and properties led to the classification instead of returning only a label.
Splitting combined models by discipline
I also prototyped the reverse operation: identifying disciplines inside a combined IFC model and writing them to separate files. The difficult part is not selecting elements. It is preserving the spatial hierarchy, units, relationships and shared coordinate frame.
This type of workflow needs deterministic checks after the split. The output models should be compared with the source before they are used for coordination.
Where adaptive agents can help
Working inside Granlund made it easier to see the problem as part of a larger system. Granlund already uses established BIM processes and digital engineering tools. The remaining difficulty is that building data moves between many designers, disciplines, software products and project stages. Each participant may follow a different convention or export configuration, so even a well-developed digital workflow can require additional checking when files move from one system to another.
Standardisation therefore has several parts. Project participants need to agree on what each property means and where it belongs, while authoring tools, templates and export settings need to write the information to the agreed IFC structures. RAVA3Pro provides a shared target. Adaptive agents can support this process at two points: they can map existing files by walking the IFC graph and interpreting their current structure, and they can assist designers while models are being created by checking properties, suggesting the correct target fields and identifying missing or ambiguous information before export.
Once the information is machine-readable, the same data can support downstream work such as automated procurement, translating an engineering bill of materials into a manufacturing bill of materials, and linking building components to maintenance operations years later. The value of the agent is not limited to automating one task. It can help information move from design to manufacturing and operation with fewer format-specific corrections at each stage. At GPT-Lab Seinäjoki, I am continuing to study how these mapping and verification methods transfer across building types, IFC versions and related engineering formats.
If you work with IFC standardisation, BIM validation or engineering data pipelines, I would be glad to compare notes.
The researcher exhange or adapt the researcher is made possible by AI Champion.
About the author
