IFC 4.4 and IFCX: Two Plans, Two Governance Tracks
Edition: 5 September 2026 · Category: BIM News
This source-only archived edition preserves the original English briefing. Time-relative statements refer to the edition date, not the website publication date. No public English video or original dated illustration has been verified for this edition.
Today's main signal is that buildingSMART has formally approved two openBIM development plans. The plan to integrate IFC 4.4 into the ISO process and the IFCX Core and modularisation project can proceed. This is an important governance decision, but it is not the release of a new production-ready IFC version.
The IFC 4.4 ISO integration plan received 93 percent approval.
Fact. On September 4, buildingSMART announced that 50 Standards Committee voters supported the IFC 4.4 integration project plan and four opposed it. Approval reached 93 percent, compared with the required threshold of 65 percent. The project is formally approved to proceed.
Why it matters to a BIM manager. This is a strong international mandate to continue the evolution of IFC 4.x and align it formally with ISO standardisation. However, project approval does not establish when the schema will become stable or when it will be properly supported by Revit, Civil 3D, Solibri, and other tools.
Action. Add IFC 4.4 to the technology radar. Assign an owner to monitor release candidates, change logs, test suites, and support in the software used by the organization.
An approved plan is not a released IFC 4.4 standard.
Fact. In buildingSMART's official specification database, IFC 4.4.x is still marked as development and currently under development. The current official infrastructure release remains IFC 4.3.2.0, published as ISO 16739-1:2024.
Why it matters. The word approved describes the decision on a project plan. It does not mean that the schema, documentation, test suites, ISO publication, and software certification are complete. Changing requirements too early could produce files that project partners cannot yet create or validate reliably.
Action. Do not change exchange information requirements, BIM execution plans, export configurations, or contractual deliverables to IFC 4.4 until an official release exists and the required tools have been tested. Label experimental files clearly and do not treat them as authoritative deliverables.
IFC 4.4 is positioned as a continuation of IFC 4.3, not a sudden ecosystem reset.
Fact. The buildingSMART technical database describes IFC 4.4 as an extension of IFC 4.3 that fixes identified issues and adds new functionality. This differs from the next-generation refactoring direction of the IFC Core work.
Interpretation. In the nearer term, IFC 4.4 may provide an evolutionary path for organizations that need compatibility with established IFC 4.3 infrastructure processes. Even so, compatibility must be demonstrated with specific exporters, validators, and project models.
Action. Prepare an IFC 4.3 regression suite now. When IFC 4.4 candidates appear, compare geometry, object classes, properties, coordinates, alignment data, identifiers, and IDS compliance. Record the authoring application and exporter build.
The IFCX Core and modularisation plan has entered the development phase.
Fact. Forty members voted for the IFCX plan and 16 voted against it. Approval reached 71.4 percent and exceeded the required 65 percent. buildingSMART states that the plan is approved to proceed into the development phase.
Why it matters. This begins an organized development effort rather than another conceptual discussion. The objective is a minimal, domain-independent, and extensible IFC Core. In the future, such a Core could separate common object identity, spatial structure, and referencing more clearly from building, road, rail, and other domain modules.
Action. In an innovation environment, monitor the Core boundaries, domain modules, continuity of object identity, references, serializations, and the future conformance model. Do not migrate production projects yet.
Practical relevance for a multidisciplinary team. One federated project may contain buildings, roads, utilities, and structures from different tools. A modular schema could let each domain evolve without changing the whole system. Exchange quality still depends on consistent identifiers, coordinates, classification, and cross-domain relationships. A pilot must check more than whether a file opens. It should verify whether the same object remains identifiable after an update, whether links between disciplines survive, and whether the receiving tool interprets values consistently.
For teaching, emphasize that a Core with domain modules is an architectural concept, not another export option. Students should explain which information is common to all built assets, which belongs to a domain, and what validation protects the relationships.
Sources: buildingSMART voting results and the IFC database.
Support for IFCX was substantially lower than support for the IFC 4.4 plan.
Fact. Both plans exceeded the same 65 percent approval threshold. However, IFC 4.4 received 93 percent support, while IFCX received 71.4 percent. Sixteen of 56 votes opposed the IFCX plan. The difference between the two approval rates is 21.6 percentage points.
Interpretation. The modular next-generation architecture has enough of a mandate to begin development, but there is more uncertainty around its direction than around the evolutionary IFC 4.4 plan. The vote totals do not explain the specific technical disagreements, so it would be wrong to invent whether criticism concerned modules, governance, compatibility, resources, or something else.
Action. When assessing IFCX, require public decision records, prototypes, test files, conformance criteria, and vendor implementation results. The approved label alone is not evidence of technical maturity.
An official two-speed openBIM path is taking shape.
Fact. buildingSMART is allowing work to continue simultaneously on IFC 4.4 integration with ISO and on the modular IFCX Core. The official specification database describes IFC 5 development as a next-generation refactoring of IFC 4.x content. Earlier project information also emphasized that the new Core would not immediately replace existing IFC 4.x parts.
Interpretation. The ecosystem is likely to have a mature IFC 4.x production path and a parallel IFCX innovation path for a considerable period. This is rational because construction projects and software certification cannot all switch at once. It will, however, increase the number of supported versions and test scenarios.
Action. Separate the production standard baseline from the innovation sandbox. Store experimental files in a distinct common data environment location, identify their schema explicitly, and prevent them from being confused with contractual submissions.
Dual-track openBIM governance, not immediate migration
Today's news ends several weeks of uncertainty because both voting outcomes are now official. In practice, however, they establish two different trajectories.
The first trajectory runs from current IFC 4.3 production through IFC 4.4 evolution and integration into the ISO process. The second starts from IFC 4.x experience, moves toward IFCX Core and domain modules, and eventually leads to next-generation implementations.
The biggest opportunity is that IFC 4.4 can fix IFC 4.3 problems and add functions while staying closer to today's software. IFCX could reduce the complexity of a monolithic schema, allow domains to evolve through clearer modules, and fit web, API, and artificial intelligence workflows more naturally.
The main risks are premature migration announcements, inconsistent vendor implementation, possible fragmentation between IFCX modules, and a larger test matrix while IFC 4.x and IFCX coexist. The biggest semantic risk is confusing approval of a project plan with approval of a technical release or certification of an application.
The recommended governance model has two lanes. In production, retain an approved IFC version, exporter build, model view definition or exchange scenario, IDS rules, and acceptance tests. In the innovation environment, use representative Revit, Civil 3D, and other application models. Measure preservation of object identity, coordinates, geometry, properties, and round trips. Label every result with the schema version, tool build, and test date.
For university teaching, use the votes as a standardization governance case. Students should distinguish a project plan, a development schema, an official ISO release, software support, and validation of a specific exchange scenario. A practical assignment could compare two exports of the same model using a defined test matrix.
Concrete next steps. First, document the current production IFC baseline and software versions. Second, prepare a small regression suite of IFC models with known correct results. Third, monitor IFC 4.4 release candidates, documentation, and conformance tests. Fourth, evaluate IFCX only in a separate experimental environment. Fifth, after the Implementers Assembly on September 9 and 10, look for real vendor implementation evidence, but do not change contracts based on roadmap slides.
Today's signal. IFC 4.4 and IFCX now both have a mandate to move forward, but the BIM manager's task today is not migration. It is to govern a dual-track standardization process and base decisions on official releases, tests, and verified tool support.
Original edition sources
- https://www.buildingsmart.org/ifc-4-4-integration-plan-for-iso-voting-results/ - https://technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/ - https://www.buildingsmart.org/ifc-x-core-modularisation-final-project-plan-voting-results/
Recommendations are editorial analysis, not reported product tests. Current availability and requirements should be checked before implementation.
