The last three lessons named real gaps: a twin's dependence on handover data quality, the immaturity of IFC-sensor integration, and interoperability problems that persist underneath IFC's real success. This closing lesson looks at what's actually being built to address parts of that picture right now, grounded in what's genuinely public and confirmed rather than speculation, and then closes with the one thing worth carrying forward that no amount of better tooling changes.
IFC5 is real and in active, public development, confirmed directly on buildingSMART's own current standards page: alongside a minor IFC4.4 update, the organization describes working in parallel on IFC5, which it calls a significant technological leap forward. The current official version remains IFC4.3 ADD2, registered as ISO 16739-1 in 2024; IFC5 has no equivalent finalized status yet. Its architecture is being redesigned around modular, composable components, an entity like a wall assembled from separately combinable pieces, geometry, material, properties, rather than every concept treated as part of one fixed, monolithic schema. It's moving toward a JSON-based representation, with buildingSMART's own development repository describing a JSON schema to be published alongside the existing work. Its stated design goals explicitly include better native support for digital twins, GIS, and IoT integration, the exact gap 11.2 named as something current IFC only handles through external bridging. As of the most recent public consultation on the IFC5 Core project plan, buildingSMART's Standards Committee reviewed community feedback and directed the working group to proceed toward a final plan, addressing governance and standards-body collaboration directly. This is genuinely in progress, alpha-stage work, not a finished, widely adopted standard, and worth treating as exactly that.
Alongside IFC5, the ISO 19650 revision already flagged back in Module 8 continues in parallel. As of this writing, the Draft International Standard for Parts 1 and 2 has been open for public consultation since March 2026, Part 3 followed shortly after, and the current 2018 and 2020 editions remain the ones actually in force until a final revision is published, expected sometime after this consultation period concludes. Both efforts are moving at once: the technical schema IFC is built on, and the information-management framework that governs how it gets used on real projects.
IFC5's stated design goals map directly onto real, named gaps from earlier in this module. Its aim of better native digital-twin and real-time integration speaks directly to 11.2's finding that current IFC has no built-in concept for streaming, continuously updating data, everything bolted on externally through separate time-series systems and GUID mapping. Whether IFC5 actually closes that gap cleanly, or simply gives real-time integration a more native-feeling seam to attach to, is something that will only be genuinely known once real implementations exist and get tested against real projects, not from a design goal stated in advance. Separately, ongoing semantic web work, ifcOWL and related linked-data approaches, continues addressing part of the semantic gap named in 11.3, giving IFC data a form that can be reasoned about and cross-referenced against other ontologies more directly than a raw STEP file allows. None of this closes every gap named across this module. It's real, active movement on some of them, worth tracking rather than assuming finished.
This is where the series closes its central argument, and it's worth stating as plainly as the very first time it appeared back in Module 6. Better standards, better schemas, more native real-time integration, more modular architecture, all of it genuinely improves how information is structured, governed, exchanged, and observed. IFC5 succeeding completely at everything it's setting out to do would still not, by itself, guarantee that every value inside a specific file is true. A more modular schema can still carry a wrong quantity. A native real-time data layer can still be fed a stale or mismatched sensor mapping. A cleaner semantic representation can still misclassify a slab as a wall, just with better tooling potentially available to catch it faster, not a guarantee it won't happen.
This isn't simply a temporary limitation waiting for the next schema version to fix. It's a fundamental distinction between two different questions. Every layer this series has examined, schema validation, normative rules, IDS, ISO 19650 governance, digital twins, sensor mapping, cross-domain interoperability, addresses some part of how information is structured, governed, exchanged, or observed. None of them, by design, guarantees that every underlying value is true. That's not the same as saying correctness can never improve. Better provenance tracking, digital signatures, automated cross-checks, and commissioning data can all make correctness genuinely easier to establish over time. What can't be eliminated by any of that is the underlying distinction itself: "the system says X" is never automatically the same claim as "X corresponds to reality." That gap is exactly where verification and extraction correctness live, and closing individual instances of it takes someone actually checking, not a better standard alone.
This series opened with what BIM actually is, and closes eleven modules later with a distinction that turned out to run through every single one of them: presence is not correctness, and no layer of process, standard, or automation covered along the way, however well-built, was ever designed to close that specific gap entirely on its own. Seeing that distinction clearly, in a schema, in a validation report, in a governance document, in a digital twin's live dashboard, is worth more than any single tool or technique this series covered individually. It's the one thing that doesn't get outdated by the next standard release.
Comments use a free GitHub account — takes under a minute to create, and keeps discussions spam-free and permanently archived.