"Interoperability" gets treated as a solved problem in most industry conversation, largely because IFC exists and does genuinely solve one real, important piece of it: exchanging structured building data between different authoring tools without everyone having to use the same software. That's a real, hard-won achievement, and it's not the whole story. Several other interoperability gaps sit underneath that success, rarely named directly, and this lesson names them plainly rather than letting the existence of one open standard imply the whole problem is behind the industry.
Two files can both be perfectly valid, schema-compliant IFC and still mean different things by the same term, or represent the same real-world thing through different, mismatched elements. This isn't hypothetical. Documented research on automated BIM classification describes a concrete, real failure mode: an IfcSlab entity being used, by mistake or by convention drift in a specific authoring workflow, to represent what should have been modeled as a wall, because the two shapes were similar enough that the authoring choice didn't feel wrong at the time. The file opens fine. The schema check passes. The entity is exactly what it claims to be, structurally. It's still the wrong thing.
Classification compounds this same gap rather than resolving it. Multiple classification systems, Uniclass, OmniClass, MasterFormat, UniFormat, all coexist in active use across the industry, each with real intent to standardize, and their simultaneous existence is itself part of the problem: two projects can each be internally consistent, each following a real, recognized classification standard, and still be unable to compare directly, because they picked different standards to be consistent with. A file passing every check against its own chosen system tells you nothing about whether it means the same thing as a file passing every check against a different one.
Module 5 already covered why schema versions matter on their own terms. Worth naming here specifically as an interoperability problem, not just a technical detail: IFC2X3, IFC4, and IFC4X3 all coexist in active, everyday use. Different schema versions don't inherently make two systems unable to exchange data, conversion and mapping between versions is a normal, well-supported part of many real workflows. The more precise problem is this: two systems can both genuinely support IFC while still hitting real compatibility friction, because they support different schema versions, different Model View Definitions, different entity subsets, or different implementation conventions layered on top of the same nominal schema. Being IFC-compliant doesn't collapse to one single, unambiguous target. It's a family of related but not fully interchangeable targets, and assuming any two IFC-compliant tools automatically speak the same dialect is exactly the kind of assumption that produces silent, downstream mismatches.
This is worth extending one layer further, since it's the part most easily missed. Even two systems on the identical schema version aren't automatically interoperable with each other. IFC's schema is a large, general information model, and real exchanges typically rely on a specific subset of it, defined through exchange requirements, Model View Definitions, or project-specific implementation agreements. Two applications can both genuinely support IFC4 while each implementing a different portion of that same schema, or interpreting the same exchange requirement differently, since Model View Definitions and implementation agreements mean two systems that both support IFC4 can still implement different portions of the schema. "Supports IFC" is a considerably weaker statement than "supports the same exchange requirements as the system on the other end," and the gap between those two statements is where a lot of real integration friction actually lives.
Building and infrastructure models and geospatial systems often operate with genuinely different coordinate-reference practices and spatial assumptions, and bridging them is real, ongoing, partially lossy work rather than a settled conversion step. This isn't simply a matter of one side being local and the other global, IFC itself has real mechanisms for georeferencing. The friction is broader: BIM projects commonly use local engineering or project coordinate systems for authoring and coordination, while GIS workflows rely heavily on explicitly defined geodetic or projected coordinate reference systems built for a different purpose, accurately positioning things across a much larger scale. Moving between the two requires more than translating a file format. The coordinate reference system, the transformation applied, units, precision, orientation, and the semantic context around all of it have to stay consistent through that move, and formats like CityGML or IndoorGML exist specifically as bridges for this, not as evidence the gap has already closed.
"IFC solves interoperability" is technically true at one level, structured, tool-to-tool data exchange, and incomplete at another. Research looking at this more critically describes a less tidy underlying picture: IFC was designed primarily as an exchange-oriented information model rather than as a native framework for continuously changing, real-time information, and deeper limitations have been documented underneath that exchange capability. Research on this has identified several such limitations directly: distortions introduced when native, tool-specific authoring data gets mapped into the IFC representation in the first place, real difficulty adapting the schema cleanly to application domains it wasn't originally built around, and the genuine technical complexity involved in extending or working with a schema defined in EXPRESS, a language most third-party developers aren't already fluent in. None of this is secret or hidden. It's documented, published research. It just doesn't compress neatly into a sentence like "IFC solves interoperability," so it tends to surface less often than the achievement itself does.
Every one of these gaps shares the exact same shape this series has traced since Module 6, now generalized about as far as it can go. A file opens successfully. A schema check passes. A conversion completes without throwing an error. Every visible signal says the exchange worked. None of that confirms the two sides of that exchange actually mean the same thing by what was exchanged, whether that's a slab silently standing in for a wall, two projects each internally consistent under different classification systems, two tools each implementing a different slice of the same nominal schema version, or a coordinate reconciled numerically between BIM and GIS without anyone confirming it still represents the same physical location. Presence, structural validity, and successful transfer have never been the same claim as correctness. That gap doesn't close as systems get more sophisticated. It just moves to wherever the next handoff happens.
This lesson named the gaps as they stand today. The final lesson in this series looks forward instead, at where open standards, IFC and the ecosystem around it, are actually heading, and what of today's real limitations current work is genuinely trying to close.
Comments use a free GitHub account — takes under a minute to create, and keeps discussions spam-free and permanently archived.