IFC & openBIM

IFC is best understood as a *shared vocabulary and grammar* for describing a building. It defines, in an open and documented way, what a wall is, what a door is, what a duct is — their geometry, their properties, and the relationships between them — so that this meaning can be written by one tool and read by another without a private translator.

Crucially, IFC carries both halves of the object we met in Module 3: the geometry *and* the data (property sets, classifications, identity). That is what separates it from a dumb geometry exchange — an IFC door can still know its fire rating and its type. IFC is an international standard (formally ISO 16739), and its governance by buildingSMART, a neutral not-for-profit, is precisely what makes it trustworthy as a long-term, vendor-independent language. When people say a model is 'in IFC', they mean it has been written in this shared language that any conforming tool can understand.

IFC keeps growing. The milestone worth knowing is IFC 4.3, which became an ISO-certified standard in 2024 and extended IFC beyond buildings into infrastructure — roads, railways, bridges, ports — along with better georeferencing (placing a model correctly on the earth). That matters enormously for a country building metros, highways and airports at scale, because it brings the same open-exchange discipline to infrastructure that buildings have had for years.

But openBIM is bigger than the IFC file. It is a whole *approach* built on a family of open standards from buildingSMART — IFC for the model, and (in the next lesson) BCF for coordination issues, bSDD for shared definitions, and IDS for checkable requirements. The philosophy is consistent: information should be exchanged and owned freely, in formats no vendor controls, so that collaboration is open to all tools and the data outlives any product. openBIM is not anti-software or anti-vendor — you still author in commercial tools — it is anti-*lock-in*. You work in whatever tool suits you, and you exchange and archive in the open.

Here is the truth that keeps IFC useful instead of over-trusted: IFC is an exchange format, not a working format, and a round trip is not lossless. When you export a native model to IFC and open it elsewhere, the geometry and the structured data come across well, but some things typically do not survive intact — a vendor's *parametric intelligence* (the rules that made an object update itself), certain proprietary features, and fine authoring behaviour. An IFC wall is a faithful description of the wall; it is not a living clone of the original tool's editable object.

This is why serious openBIM work uses Model View Definitions (MVDs) and, increasingly, IDS (next lesson): agreements about *which* subset of information a given exchange must carry, so both sides know what to expect and can check it. The practical rule is simple and important: use IFC for what it is for — coordinating, checking, exchanging, archiving, handing over — not as a way to keep editing someone else's parametric model in your tool. Judged as a lossless clone, IFC disappoints. Judged as an open, durable, checkable *exchange* of a building's information, it is the backbone of the whole open-BIM world — freedom from lock-in, bought at the honest price of a little fidelity.