Three openBIM signals landed in the same news window, and they line up cleanly. In Porto, the first buildingSMART openBIM Hackathon shipped — 47 participants, nine teams, 50 hours, working prototypes graded by judges (Helga Tauscher of HTW Berlin, David Delgado Vendrell of buildingSMART Spain, Mário Coelho at CCG/ZGDV, Daniel Changas at Esri) on “practical relevance, clarity of solutions, and genuine interoperability over complexity.” In Zurich, the bSI Domain Leadership Conference of 4–5 February declared IFC 4.3 the technical priority and pushed a governance reset toward 2030. And ISO/TC 59/SC 13, with buildingSMART as liaison, published a Compatibility Policy for ISO 16739-1 — the first formal framework defining what a breaking change to IFC actually is.

←TODAY: Porto shipped nine working prototypes in 50 hours; Zurich aligned the IFC 4.3 roadmap; ISO finally put in writing what counts as a breaking change to IFC.
→3012: By the Zurich-3012 horizon, IFC is the city’s substrate — every wall, ramp and façade panel queries against the same versioned graph.
Fulcrum: Stability without practitioner velocity is a museum; velocity without stability is technical debt. This week we got both.

The standard finally has rails

If you have ridden IFC through three Archicad upgrade cycles, you already know why the Compatibility Policy matters. Until now, “the schema might change” was a real reason firms hesitated on multi-decade openBIM investments. The ISO/TC 59/SC 13 policy, authored on the bSI side by Evandro Alfieri, defines four things in writing: what a breaking change is, how extensions and corrections are managed, how deprecation and removal must be handled, and how compatibility is assessed during revisions. Boring document, foundational consequence — vendors and asset owners now have predictable rules to plan against.

The Zurich Domain Leadership Conference reinforced the same posture from the governance side. Cross-Domain coordination, transparent funding, IFC 4.3 as anchor, Digital Product Passport as a cross-cutting opportunity — DPP is the EU’s ESPR-aligned pivot, and it will land as a Swiss FOEN equivalent within the decade. The institutional layer is finally organised enough to keep IFC honest long enough to bet a 40-year asset on it.

Porto: the practitioners run ahead of the standard

Porto then showed where the actual frontier sits. The patterns are worth shadowing. IDS got used not as a checker spec but as a workflow driver — requirements → validation → information exchange. IFC got treated as a data source with history, not an export snapshot. BCF was closed into feedback loops with AI-assisted resolution. 87% of participants reported improved understanding of openBIM, which is what happens when a standard stops being a PDF and starts being something you build with at 2 a.m.

The winner is the tell. “BCF Time Machine” — Greg Jackson, Louis Trümpler, Phuong Nguyen, Dennis Shelden, Geert Hesselink — built a tool that navigates historical IFC data to visualise BCF issues resolving over time. That is not a model viewer. That is treating the building itself as a versioned graph, and BCF as the commit log. Once you have seen IFC framed that way, you cannot un-see it.

Atelier: Practices that treat IFC, IDS and BCF as a programmable data layer will compound on every project. The ones still scripting “Export to IFC” as a one-way checkbox keep paying round-trip translation tax on every Bauleitung handover — and the cost stays invisible until the model and the site disagree about a column.

One risk worth naming plainly: hackathon prototypes are not productised tools, and “the community plans to encourage vendors to implement these features” is the same sentence written after every good hackathon. The Porto outputs will only matter if Graphisoft, Allplan, Solibri and the Speckle/Bonsai end of the stack pick them up. The Compatibility Policy makes that easier; it does not make it automatic.

From the late-2070s vantage I write from, the buildings that aged worst in my generation were the ones whose proprietary formats went dark and whose owners could not open the file. The Compatibility Policy is the precondition for that not being the story of IFC in 2070. Treat it like the foundational document it is.

Hack: This Hack teaches you to read IFC as a change log, not a snapshot. Every IfcRoot subclass carries an OwnerHistory — creation and last-modified timestamps per element. With IfcOpenShell installed (pip install ifcopenshell), you can walk a file and surface every element that has been touched, without opening Archicad. It is the same primitive the BCF Time Machine team built on.

import ifcopenshell
model = ifcopenshell.open("project.ifc")
for w in model.by_type("IfcWall"):
    h = w.OwnerHistory
    print(w.GlobalId, h.CreationDate, h.LastModifiedDate)

Pipe it to sort -k3 and you have an audit of which walls actually moved this week — a five-line answer to a question that usually takes a coordination meeting. Open one live IFC from a current project, run the snippet, and bring the output to your next coordination. If your team cannot agree on what those timestamps mean, you have found where your openBIM workflow leaks.

Source: buildingSMART