Why IFC should be your project's data model, not just an exchange format

Most project teams meet IFC at the worst possible moment: a deadline, an export dialog, and a 400 MB file somebody has to open in a viewer. It gets treated as a container for geometry, something you hand over, not something you use.

That framing leaves most of the value on the table. An IFC model is a graph of typed objects with properties, relationships and classifications. That is a database. And once you start treating it as one, a lot of workflows that used to need manual spreadsheets simply become queries.

What changes when IFC is the data model

Quantities stop being a deliverable and become a view. Instead of a QTO export that goes stale the moment the model changes, quantities are computed from the model on every refresh. Power BI, a Python notebook or a lightweight web app can all read the same source.

Schedule and cost attach to the object, not to a row in another file. Link a 4D activity ID and a cost code as property sets and the model becomes the single place where scope, time and money meet. Planning dashboards update when the model does.

QA/QC becomes rule-based. LOD/LOI requirements, naming conventions and classification coverage can be checked automatically against the BEP, no more visual spot checks in a viewer.

A minimal stack that works

You do not need a data platform to start. The pieces I reach for:

1. IfcOpenShell to parse models and flatten the properties you care about into tables.
2. Parquet or a small SQLite database as the intermediate store, fast, portable, version-friendly.
3. Power BI for the people who make decisions, with a scheduled refresh so nobody has to re-export anything.

import ifcopenshell
import pandas as pd

model = ifcopenshell.open("federated.ifc")
rows = []
for el in model.by_type("IfcElement"):
    psets = ifcopenshell.util.element.get_psets(el)
    rows.append({
        "GlobalId": el.GlobalId,
        "Type": el.is_a(),
        "Name": el.Name,
        "Storey": ifcopenshell.util.element.get_container(el).Name,
        **{f"{p}.{k}": v for p, d in psets.items() for k, v in d.items()},
    })

pd.DataFrame(rows).to_parquet("elements.parquet")

Twenty lines, and you have a table any BI tool can read.

Where this is heading

The interesting part is not the dashboard, it is what becomes possible once the model is queryable. Natural-language questions over project data (“which walls on level 3 are missing a fire rating?”) stop being a research project and become a thin layer over a table you already have.

That is the direction I am working towards at Kolektor Koling: IFC as the source of truth, everything else as a view on top of it.