Start with the control mechanism, not the file. Industry Foundation Classes — IFC — is the international standard ISO 16739-1:2024: a vendor-neutral data model for the built asset, published by buildingSMART International and licensed under Creative Commons. Read that last clause slowly, because it is the whole argument. A file format that anyone may implement, and that no single supplier owns, is not a technical convenience. It is a procurement instrument. IFC is the clause that lets an office leave a vendor without leaving its own building behind.

Most explainers open with software. This one opens with power, because that is what IFC actually redistributes. The question a foundation essay on IFC has to answer is not “how do I export?” It is: who holds the data of the building over its lifecycle, and who granted them that hold?

What it is: IFC is a formally defined schema — a shared vocabulary and grammar for describing a building as data. A wall is not a picture of a wall; it is an IfcWall, an entity with a type, a place in a spatial hierarchy (project → site → building → storey → element), and property sets that carry semantic data such as fire rating or load-bearing status. Every tool in the federation can author in its own native format and still hand the others a legible model. The architect works in one authoring tool, the structural engineer in a second, the MEP designer in a third, the facility manager in a fourth. No party agrees to a proprietary format. No party owns the seam. That absence of an owner is the design, not a gap in it.

←TODAY: ISO 16739-1:2024 makes the open building schema a public standard, and buildingSMART’s IFC Validation Service scores each vendor’s exporter in the open. →3012: By the Zurich-3012 horizon the built environment speaks one auditable grammar, and conformance is a published number, not a sales promise. Fulcrum: Only a schema no vendor owns can be audited against every vendor — openness is what makes the audit enforceable.

Why it works: IFC holds because it separates three concerns that lesser formats fuse. Underneath, the file rests on ISO 10303-21 — the STEP physical file — with every entity defined in the EXPRESS modelling language: object-based, inheritance-driven. A new entity is never invented from nothing; you select a base class and specialise beneath it, so the schema is a strict family tree and every wall is a descendant. That formality is what makes the model machine-interpretable, and machine-interpretability is the entire point: clash detection, quantity take-off and code-checking become automatable rather than eyeballed. But the deeper reason it works is governance by decomposition. IFC is one leg of a triad — IFC carries the model, IDS carries the requirements, BCF carries the issues. Separate the geometry from the specification from the argument, and each travels on its own channel. IDS turns a fuzzy client wish into a machine-checkable rule. BCF returns a coordination issue detected in one tool to be answered in another. This is not tidy accident; it is the engineering. A single fused format would have re-created the lock-in the standard was written to break.

Here is the trade-off stated plainly, because a foundation reader is owed it: two teams can each be one hundred percent standards-compliant and still hand each other two different buildings. Geometry representation, custom property sets and classification systems all leak between authoring tools. Openness buys you the right to audit the divergence; it does not abolish the divergence. The office that pretends otherwise gets hurt at handover.

Origins: The lineage matters, because it explains why the licence is what it is. IFC did not begin in a public standards body. In 1994 Autodesk convened an industry consortium to advise on a set of C++ classes for integrated application development across tools. The advisory group outgrew its sponsor. It became the International Alliance for Interoperability, and later took the name it carries today: buildingSMART. IFC 1.0 shipped in June 1996 — the first vendor-neutral data model for the building, a promise before it was a practice. The schema hardened for a decade. IFC2x3 (2006) aligned to ISO/PAS 16739 and became the first version the industry exchanged at scale. IFC4 modernised geometry and semantics. IFC4.3 — the current release, canonised as ISO 16739-1:2024 — stretched the model past the building envelope into bridges, roads, rail and ports. On the process side, buildingSMART’s data standard was joined by ISO 19650 (published December 2018), the information-management method — one standard for the thing, one for the way you pass it around. PAZ’s own concept library traces this arc under openBIM — Historia: proprietary formats had fragmented AEC into locked rooms, and the open schema was the argument that a building’s data belongs to the building, not to the vendor who happened to draw it.

In practice: A schema is not a building, and IFC’s monuments are not towers — they are mandates. Denmark made IFC compulsory for publicly aided projects in 2010, the first national government to turn a schema into a procurement condition. Finland’s Senate Properties began requiring IFC-compatible BIM on all projects in 2017, proof that the client, not only the designer, has standing in the open model. Norway’s Statsbygg, with the Health and Defence client organisations, mandates IFC BIM across all state projects. For a Swiss studio the lesson transfers directly, whether or not the local mandate has arrived: treat the IFC export as the contractual deliverable, not the native file. Write the exit clause before you sign the entry contract. Name the schema version, name the required property sets, and name the buildingSMART Validation Service scorecard as the acceptance test — so conformance is a public number rather than a supplier’s word. The office that specifies IFC4.3 and an IDS on the way in never has to litigate ownership of its own model on the way out. From the vantage I write from, the costliest failures were never the tool that behaved badly. They were the procurement default that kept a bad supplier load-bearing in critical infrastructure for years because nobody held standing to challenge it. IFC is how you keep that standing.

Hack: Trace who authored the model, and against which schema, before you trust a single byte of it. IFC is a STEP file, so provenance is right there in the header and the ownership history — you can audit it with IfcOpenShell, the de facto open Python toolkit for reading IFC. Three lines tell you the schema version and the exporting application, which is the first thing an acceptance check should record and the last thing a vendor volunteers.

import ifcopenshell
model = ifcopenshell.open("federated.ifc")
print("schema:", model.schema)                       # e.g. IFC4X3
for app in model.by_type("IfcApplication"):
    print("authored by:", app.ApplicationFullName, app.Version)

Log that output against every incoming model and you have a provenance ledger — the raw material of an audit — before anyone opens the geometry. Want to see the schema define itself? IFC-gen (hypar-io/IFC-gen) parses the EXPRESS grammar and emits the typed classes: the standard compiling into code, in the open, for anyone to read.

Move: IFC4.3 crossing into bridges, rail and ports is the schema outgrowing the building that named it. The next frontier is not geometry but requirement — IDS turning client wishes into checkable rules, and validation scorecards turning conformance into a published fact. Learn to walk the model by hand now, while it is still small enough to hold in a loop, because when the whole built environment speaks one open language the practitioners who understood it early will be the ones writing the grammar. Open one IFC file with IfcOpenShell, print its schema and its author, and add a single line to your next tender: the deliverable is IFC, validated against a buildingSMART scorecard. That is your exit clause. Write it before you need it.