Why Raw IFC Object Counts Can Produce Misleading BIM Progress KPIs

Counting objects sounds like the simplest possible BIM KPI.

Open the IFC file, count everything and plot the result.

Unfortunately, that number can be surprisingly misleading.

An IFC file contains more than visible model elements

IFC represents both engineering objects and the data structures required to describe them.

A file can contain:

• spatial hierarchy;
• sites, buildings and storeys;
• engineering products;
• assemblies;
• relationships;
• representations;
• geometry items;
• property structures;
• classification data;
• objects without their own visible 3D representation.

A raw count of all entities therefore measures file structure rather than engineering model content.

Even `IfcProduct` can be too broad

Restricting the count to products improves the result but does not automatically solve the problem.

Some product objects are containers or hierarchy nodes.

Others may exist without independent geometry.

An engineering team looking at the model may perceive one meaningful component where the IFC hierarchy contains several related objects.

That is why KPI design needs an explicit counting policy.

Model Bridge: unique represented 3D elements

The main Model Bridge progress KPI focuses on unique represented 3D elements.

The intention is to count the engineering content that is actually represented in 3D rather than every object participating in the IFC data model.

This produces a more understandable revision timeline.

It also makes cross-revision trends less sensitive to hierarchy noise.

Why the counting rule must be consistent

No KPI is useful if its definition changes from one revision to another.

The same counting policy must therefore be applied to every file in the series.

If Revision 01 includes empty hierarchy containers and Revision 02 does not, those differences should not be interpreted as engineering progress.

Likewise, exporter changes that alter representation structure need to be recognised.

Consistency matters more than producing the largest possible number.

Categories improve interpretation

A total unique-element count tells us how the represented model changes.

Categories tell us where.

For example:

• piping increases;
• equipment remains stable;
• structure decreases;
• other represented objects increase.

This gives the project team a much more useful explanation than one overall figure.

The KPI is evidence, not contractual completion

A represented-element count is still not a direct percentage of design completion.

One equipment item may require more engineering effort than dozens of small components.

Some design work changes properties without changing object count.

Some disciplines naturally contain many more elements than others.

The KPI should therefore be interpreted as model-development evidence.

Used correctly, it can show trends, detect anomalies and guide review.

Used incorrectly, it could create a false precision.

Why this matters for project-wide analysis

The counting-policy problem becomes even more important when analysing all IFC files of a project.

Different disciplines and authoring systems have very different object structures.

A future project-level dashboard cannot simply sum raw IFC entity counts across all files.

It will need normalised rules for represented engineering objects, discipline classification and model ownership.

The work done now on unique represented 3D elements is therefore a prerequisite for credible whole-project KPIs.

Before plotting a BIM progress graph, first decide what the number actually represents.