For most of the last two decades, openBIM has been a principled argument. Vendor lock-in is bad for clients. Data should outlive software licences. Buildings are long-lived assets and their models should be too. All correct — and largely ignored in practice, because the proprietary stacks worked well enough inside their own ecosystems and the open alternatives felt like compromise.
That era is ending. In January 2024, IFC 4.3 was ratified as ISO 16739-1:2024 with 100% member approval — formally extending the standard to roads, rail, bridges, ports, waterways, and geotechnics. In June 2024, the Information Delivery Specification 1.0 became an official buildingSMART standard, turning project information requirements into machine-checkable contracts. Singapore’s CORENET X platform mandates IFC submissions from October 2025. Dubai Municipality’s Circular 9-1-2 made BIM submission in IFC format compulsory from January 2024. IFC 5 — a ground-up architectural redesign — is in active alpha development with a component-based, JSON-native schema and a formal alignment with Universal Scene Description (USD).
And underneath all of this sits the AI question. Every major AI use case being explored in AEC — clash intelligence, automated quantity surveying, natural-language model querying, generative design, scan-to-BIM, code compliance checking — depends on machine-readable, semantically rich, vendor-neutral building data. OpenBIM is not competing with AI adoption in AEC. It is the prerequisite for it.
The Lock-In Problem Is Not Rhetorical
Closed BIM — a single-vendor workflow where Revit feeds Navisworks feeds Autodesk Construction Cloud — has a real technical advantage: tightly controlled internal APIs mean data flows cleanly within the ecosystem. The cost is structural dependency. If the vendor changes pricing, sunsets a product, or simply fails to implement a workflow your project requires, you have no exit. More acutely, when an asset owner needs model data in year 30 of a 60-year building lifecycle, the authoring software from year 1 may no longer exist.
OpenBIM’s answer is the IFC file. But the IFC export button conceals a significant gap between intention and reality. The problems are well-documented. When software exports walls, beams, doors, and windows as generic IfcBuiltElement entities, the file is technically valid but semantically empty — the equivalent of labelling every item in a supermarket as “stuff.” Property sets frequently fail to survive round-trips between authoring tools. Geometric representations degrade, particularly when curved B-Rep geometry is translated across kernels. Infrastructure models routinely exceed 1 GB, overwhelming most free viewers. And the schema itself — over 1,300 entities in IFC 4.3 — is too complex for direct machine-learning consumption.
The bottleneck, in other words, has shifted from the openBIM concept to the quality of implementation. The schema is sound. The discipline to use it correctly is the challenge — and the regulatory pressure now arriving from multiple directions is forcing that discipline to become contractual.
The Format Landscape: A Practitioner’s Map
Understanding where openBIM is heading requires clarity on which formats do what — because they are layers, not competitors.
IFC: The Contractual Semantic Source of Truth
Industry Foundation Classes remains the load-bearing standard for building data exchange. IFC 4.3 — now ISO 16739-1:2024 — adds linear positioning for rail, cant handling, bridge geometry, port infrastructure, and waterway elements, closing the long-standing gap where IFC applied only to vertical construction. The documentation continues to evolve through maintenance releases (currently IFC 4.3.2) without schema change.
IFC 5 is the most consequential revision in two decades. The monolithic STEP/EXPRESS file format is being abandoned in favour of an Entity-Component-System (ECS) architecture — where a wall is no longer a single object but a composition of independently addressable components for geometry, material, spatial relationship, and properties. The serialization format shifts to JSON (IFCX). A modular core-plus-extensions structure replaces the current monolith. The IFC 5 Core Project Plan was put to the buildingSMART Standards Committee for vote in August 2025, with active alpha development visible on GitHub and a web viewer already running at the buildingSMART technical portal. The architecture has also been designed with explicit AI accessibility as a goal — buildingSMART has acknowledged the need to revise the schema to enhance compatibility with machine learning.
BCF: Issue Management as a First-Class Data Object
The BIM Collaboration Format turns coordination issues into structured, persistent objects linked by IFC GlobalId rather than email threads and screenshots. BCF originated in 2009 (Tekla, Solibri, and the Technical University of Munich) and is now a buildingSMART standard in its 3.0 release, supporting cloud REST API workflows alongside the original XML file format. The shift to BCF API — rather than file exchange — is critical: it makes issue data consumable by external systems, AI agents, and dashboards without file-handling overhead. BIMcollab, Catenda Hub, Newforma Konekt, and OpenProject all implement BCF API natively.
IDS: Information Requirements as Machine-Checkable Contracts
The Information Delivery Specification, ratified on 1 June 2024, is arguably the most immediately practical addition to the openBIM stack. An IDS file is an XML document that specifies exactly what information an IFC model must contain — for example, that every IfcWall must carry a Pset_WallCommon.FireRating value of REI30, REI60, or REI90, or that every structural beam must have a material classification from bSDD. This replaces the project-specific EIR/BEP in PDF or Excel with a computable specification that tools can validate automatically. BIMcollab, Solibri, ACCA usBIM, and the open-source ifctester (part of the IfcOpenShell ecosystem) all support IDS checking.
CityGML and CityJSON: The Urban Scale
CityGML (OGC standard) and its JSON encoding CityJSON 1.0 represent 3D city models from LOD0 terrain through LOD4 interior spaces. CityJSON achieves roughly six-times compression versus CityGML/GML and is designed explicitly for developer accessibility. The semantic gap between IFC and CityGML — IFC is far richer at the building element level than CityGML — is an active research area, with LOD4 mapping workflows (via FME and Python) being published in 2024. The convergence of these two standards is what makes building-to-city-scale digital twins possible.
COBie, gbXML, and the Specialist Formats
COBie (Construction Operations Building Information Exchange) focuses on the FM handover: spaces, equipment, warranties, spare parts, maintenance schedules. It addresses a well-documented problem — research consistently shows significant losses of building lifecycle data in paper-based handover — but industry uptake has been uneven, particularly in markets where FM procurement is disconnected from design and construction.
gbXML bridges BIM authoring tools and building energy modelling (BEM) software. It is supported by Revit Insight, DesignBuilder, IES-VE, and EnergyPlus. Its limitation is geometric: gbXML uses surface boundary representation only, and geometry exported from BIM tools frequently contains malformed space boundaries — gaps, non-airtight volumes — that cause simulation failures. For many BIM-to-energy workflows, the direction is now towards direct IFC-to-energy pipelines, with gbXML remaining the path of least resistance for Revit-to-DesignBuilder workflows today.
USD: Scene Composition, Not a Replacement
Universal Scene Description originated at Pixar and is now governed by the Alliance for OpenUSD (AOUSD), founded in August 2023 by Pixar, Adobe, Apple, Autodesk, and NVIDIA. AOUSD and buildingSMART International are in formal liaison. NVIDIA Omniverse uses USD as its native engine. The relationship between USD and IFC is complementary: USD excels at scene composition, layer-based overrides, and real-time visualization — the layer structure that makes collaborative immersive review of a federated model practical. IFC carries the contractual semantic depth that USD was not designed for. The narrative that USD will “replace” IFC misreads both standards; the more likely outcome is that IFC 5’s IFCX serialization and USD’s composition model will be used together, with IFC as the semantic source and USD as the visualization layer.
Nine AI Use Cases That Run on OpenBIM Data
The reason open, machine-readable building data matters beyond regulatory compliance is that AI needs it. Every application described below depends on accessing structured, semantically labelled building information outside the proprietary ecosystem of the authoring tool.
1. Intelligent Clash Detection and Resolution
Traditional clash detection — geometric intersection testing across federated models — produces thousands of flagged clashes on a complex project, the majority of which are irrelevant duplicates, acceptable conditions, or artefacts of modelling tolerance. Machine learning trained on historical clash-resolution data can filter these with significantly higher accuracy, reducing coordinator review time on large projects. More recent research (2025) is extending this from filtering to resolution suggestion: AI systems that propose alternative MEP routings or structural member placements to resolve clashes automatically, with real-time deviation detection when laser scans are compared against the IFC model during construction.
2. Automated Quantity Takeoff
IFC-based quantity takeoff algorithms — traversing the entity hierarchy to extract volumes, areas, and counts by element type — are well established in research and increasingly in practice. Platforms like VIKTOR allow engineers to build IFC-ingesting applications that generate material quantity dashboards and apply cost rates without specialist estimating software. The real productivity gain is iterative: when design options change, AI QTO regenerates quantities in seconds rather than days. The critical dependency is model quality — IFC files with incomplete property sets or incorrect material assignments produce unreliable outputs, which is precisely why IDS-validated models are the necessary precondition.
3. Predictive Construction Scheduling (4D/5D)
Linking BIM geometry to construction schedules — 4D simulation — has been possible for over a decade. What AI adds is the connection between element properties (type, volume, location, sequence constraints) and historical project performance data to generate realistic duration estimates, predict delay risks, and optimise resource allocation. Research published in 2024 and 2025 demonstrates frameworks combining NLP for cost-code mapping from WBS, computer vision for construction progress tracking, deep reinforcement learning for schedule optimisation, and Monte Carlo simulation for uncertainty quantification — all reading from IFC-federated models.
4. Energy Performance Simulation and Optimisation
The IFC-to-BEM pipeline is one of the most active research frontiers in sustainable design. AI is being applied at multiple points: ML classification of IFC spaces for energy zone assignment, geometric enrichment to repair malformed space boundaries before simulation, surrogate model training to replace computationally expensive EnergyPlus runs, and LLM-based interfaces that translate natural language instructions (“increase glazing on the north façade, apply ASHRAE 90.1 baseline”) into simulation parameters. A 2025 paper published in Energy and Buildings demonstrates a user-facing LLM system that converts natural language and image inputs into Honeybee/Ladybug parameters without requiring specialist knowledge of simulation tools — effectively democratising energy modelling.
5. Generative Design from BIM Data
Generative design in AEC has historically meant parametric scripting: Grasshopper, Dynamo, or custom Python. Hypar — co-founded by Ian Keough, the original developer of Dynamo, and Anthony Hauck, former Revit product manager — demonstrates what happens when generative logic is cloud-hosted, IFC-exporting, and accessible through natural language. A prompt specifying a mixed-use building typology, site constraints, and programme generates a coordinated structural and spatial model in seconds. AEC Magazine has observed that reconfiguring a fully detailed building option from L-shaped to U-shaped in Revit could take three weeks of manual work; in parametric cloud tools it takes seconds. Hypar 2.0 has refocused on space planning with Revit interoperability, making it a practical complement to existing authoring workflows rather than a replacement.
6. Digital Twins Powered by OpenBIM Data Feeds
A building digital twin requires a semantic model (IFC), real-time sensor data (IoT/SOSA ontology), and a queryable interface. The openBIM stack — IFC converted to ifcOWL or the Building Topology Ontology (BOT), federated with sensor data via SPARQL endpoints — provides all three components without vendor lock-in. For city-scale twins, IFC models are mapped to CityJSON for urban context. Singapore, Helsinki, Seoul, and Dubai have all demonstrated operational urban digital twins built on these open standards. Dubai Municipality’s January 2024 mandate is explicitly in support of the emirate’s broader digital twin programme.
7. Natural Language Querying of BIM Models
This is the most rapidly evolving frontier. Three architectures have emerged in 2024–2025. ASK-BIM (developed at IAAC Barcelona and published in Automation in Construction) converts IFC to a knowledge graph, parses natural language questions, generates SPARQL queries, and achieved 91% accuracy across 225 queries on a multi-storey office building. BIMConverse uses GraphRAG over Label Property Graphs derived from IFC, powered by GPT-4o. MCP4IFC — published as a preprint in late 2024 — exposes over 50 BIM tools through the Model Context Protocol, allowing large language models to create, edit, and query IFC models directly from natural language instructions, including generating a small house from scratch. These systems perform well on explicit retrieval — “how many fire-rated walls are on level 3?” — and less well on spatial reasoning and nuanced modification tasks, an important limitation that calibrates realistic expectations.
8. Automated Code Compliance Checking
The gap between a building regulation expressed in natural language and a computable rule has historically required specialist knowledge to bridge. LLMs are now being used to perform that translation automatically — converting plain-language fire egress requirements, accessibility standards, or structural span limits into executable rule sets that can be tested against IFC models. Multiple 2025 papers report F1 scores above 95% for rule classification and execution in controlled test environments. Singapore’s CORENET X is the most advanced operational deployment: from October 2025, projects above 30,000 m² GFA must submit in IFC+SG format, with automated rule-checking across architectural, structural, and M&E disciplines replacing over 20 previous regulatory touchpoints. The semantic web approach — converting IFC to ifcOWL and running SPARQL-based compliance rules — provides a complementary and auditable pathway alongside LLM-based checking, as explored in this MDPI Buildings framework.
9. Scan-to-IFC: AI-Driven As-Built Model Generation
Point cloud data from laser scanning or photogrammetry has existed for years; converting it to a semantically correct IFC model has remained a labour-intensive manual process. Cloud2BIM — an open-source Python pipeline published in Automation in Construction in 2025 — achieves up to seven times faster conversion than manual scan-to-BIM workflows, handles non-orthogonal walls, and exports directly to IFC. BIMStruct3D, published as a preprint in early 2025, is described as the first end-to-end framework that converts noisy, incomplete point clouds into IFC-compatible models using a hybrid of deep learning and classical geometry processing. These pipelines are particularly significant for renovation, heritage documentation, and infrastructure asset management — contexts where an authoritative as-built model does not exist and needs to be created efficiently.
The OpenBIM Tooling Layer Has Matured
The practical openBIM ecosystem has expanded substantially beyond the authoring tools. Speckle provides an open-source, object-based data platform with a GraphQL API and connectors to Revit, Rhino, Grasshopper, AutoCAD, Civil3D, Tekla, and Archicad — exposing BIM data to AI pipelines and dashboards without file exchange. Catenda Hub (formerly Bimsync) is a cloud-native CDE built entirely on IFC and BCF, without any proprietary format layer. BIMcollab combines BCF issue management with native IDS validation. xeokit-sdk provides a high-performance, open-source web BIM viewer capable of rendering large IFC, CityJSON, and point cloud models in the browser. IfcOpenShell — the de-facto open-source IFC geometry engine — powers the Bonsai authoring add-on for Blender, IfcClash, IfcDiff, IfcCOBie, and increasingly serves as the parsing backend for AI research pipelines. Hypar’s open-source core libraries allow developers to build parametric design functions that output IFC without licensing any proprietary tool.
Autodesk’s position has become more nuanced than a simple open-versus-closed binary. Autodesk Platform Services (APS), formerly Forge, exposes model data via REST and GraphQL APIs, and Autodesk has published Model Context Protocol server examples for Revit. The more useful framing for practitioners may be: proprietary authoring tools are likely to persist for some time because their modelling workflows are genuinely superior within their ecosystems — but the strategic risk of keeping data locked inside proprietary formats is now clearly understood by procurement bodies, asset owners, and regulators.
The Global Mandate Landscape in 2025
OpenBIM has moved from voluntary best practice to regulatory requirement across a significant portion of global public procurement. Germany has mandated BIM on all federally funded infrastructure since January 2021. The UK’s ISO 19650-aligned framework governs public-sector projects. Italy reduced its BIM mandate threshold to public contracts above €1 million from January 2025. Spain requires BIM for public projects above €10 million from 2025, with broader coverage by 2030. France’s Plan BIM 2022 has evolved into Plan BIM 2030. Singapore’s CORENET X rolls out in phases: mandatory for projects above 30,000 m² GFA from October 2025, above 5,000 m² from October 2026. Brazil’s Decree 10.306/2020 established a national BIM implementation strategy. Dubai Municipality’s circular, effective January 2024, mandates IFC-format submissions as part of the emirate’s digital infrastructure programme.
buildingSMART International’s 2025 Global openBIM Mandates report tracks these requirements across more than 30 countries. The direction of travel is consistent: openBIM submission in IFC, validated against IDS, coordinated with ISO 19650, is becoming a condition of procurement participation rather than a differentiator.
Practical Recommendations for BIM Managers and Architects
The following actions reflect where openBIM practice is heading and where the highest-leverage investment lies for teams working on complex projects today.
Make IDS your project information contract. Stop treating IFC export as a publish step with no feedback mechanism. Author IDS files that specify exactly what property sets, classification codes, and element types are required at each project stage, and run automated validation at every milestone. Tools like BIMcollab, ACCA usBIM, and the open-source ifctester make this practical without specialist development.
Treat IFC export quality as a contractual obligation, not an afterthought. Establish regression testing using IfcDiff to verify that GUID stability, IfcPropertySet survival, and geometric volume parity are maintained across exports. Many interoperability failures are not schema failures — they are avoidable modelling discipline failures.
Adopt BCF API workflows, not BCF files. The shift from BCF-XML file exchange to cloud BCF API — via BIMcollab, Catenda Hub, or Newforma Konekt — makes issue data consumable by AI agents, project management tools, and dashboards. This is a low-friction change with significant downstream value.
Pilot one AI use case now, matched to your team’s bottleneck. For coordination-heavy teams, ML clash filtering is the highest-ROI starting point. For estimators, IFC-based AI quantity takeoff is mature enough to prototype. For design teams working on early-stage massing, generative cloud tools with IFC output are worth evaluating. For projects in regulated jurisdictions, LLM-based compliance checking against your local code is an active research area approaching production readiness.
Invest in IFC-to-graph competency. The most reliable pattern for applying LLMs to BIM data is not feeding raw IFC files to a language model — it is converting IFC to a knowledge graph (ifcOWL, BOT) and using Graph-RAG or SPARQL for structured retrieval. The ASK-BIM and BIMConverse research projects both demonstrate that this architecture achieves meaningful accuracy on real building models. This is a skill set worth developing now.
Track IFC 5 development and plan for the transition. IFC 5’s component-based architecture will require significant retooling of IFC-handling codebases. Firms building custom BIM integrations should monitor the buildingSMART/IFC5-development repository and the IFCX JSON format. The transition will not be overnight, but the direction is clear: the monolithic STEP file is the past.
Understand USD coexistence, not competition. For immersive review, real-time collaboration, and digital twin visualisation, USD pipelines — particularly NVIDIA Omniverse — offer capabilities that IFC was not designed to provide. Keep IFC as the semantic source of truth and contractual data format. Use USD for the visualisation layer. These are complementary architectures, and firms that understand both will be better positioned as digital twin requirements grow.
The Bigger Argument
The case for openBIM used to rest on principle: data sovereignty, long-term asset value, procurement fairness. Those arguments remain valid. But the more compelling argument in 2025 is functional: open, structured, machine-readable building data is the substrate on which AI in AEC actually operates at scale.
Every proprietary model locked in a native format is a model that an AI system cannot read without a vendor API. Every project that delivers a PDF instead of an IDS-validated IFC is a project that contributes nothing to the industry’s accumulating dataset of building knowledge. Every firm that treats IFC export as a compliance gesture rather than a precision deliverable is producing data that ML systems will misclassify, misread, or ignore.
The convergence of regulatory mandate, standards maturity, and AI demand has shifted openBIM from a philosophical position to an operational requirement. IFC 4.3’s ratification, IDS 1.0’s launch, IFC 5’s architecture, and a growing ecosystem of open tools have collectively closed the credibility gap that once made the proprietary stack a rational choice for technical practitioners. The question is no longer whether to adopt openBIM workflows — it is how quickly, and with what level of data discipline, to make the transition.
The firms that build that discipline now — in modelling practice, information management, and AI integration — will have a structural advantage as both mandates and AI capabilities continue to advance.
