From Two IFC Files to a Complete Multi-Revision History

Most IFC comparison workflows begin with two files.

That is logical: an earlier model is the baseline and the newer model is the revision.

But a real project may generate dozens of IFC deliveries. Once those files exist, treating every comparison as an isolated A-versus-B operation wastes a valuable source of information.

Every revision is a data point

An IFC revision is not only a file to be opened.

It is a dated representation of the state of an engineering model.

Placed in chronological order, multiple revisions form a measurable design history.

That history can show:

• total represented 3D-element growth;
• changes in individual engineering categories;
• additions and deletions per revision;
• periods dominated by modification rather than new modelling;
• unexpected decreases;
• discipline-specific development patterns.

This turns model comparison from a one-time quality-control operation into a form of design analytics.

Why chronology matters

Revision files are not always delivered with perfectly sortable names.

Names such as `FINAL`, `FINAL2`, `Issue_A`, `Rev10` and `Rev9` are common enough to make filename ordering unreliable.

A multi-revision comparator therefore needs to establish chronology from the model and file evidence rather than blindly sort text strings.

Model Bridge reconstructs the revision sequence and presents the analysis on a time axis.

This provides a much clearer project story.

The difference between state and activity

A model state tells you what exists at a given date.

A revision comparison tells you what changed between two states.

A revision history gives you both.

That distinction is important.

For example, two revisions may both contain approximately 10,000 represented elements. At first glance the model appears stable.

But if 1,200 elements were deleted and 1,250 added, the modelling activity was actually very high.

Conversely, a model may grow by 1,000 elements through a straightforward addition of new scope with relatively little rework.

The final object count alone cannot distinguish those situations.

A timeline for BIM and design management

Design Managers often need trend information rather than element-by-element detail.

The full change list remains essential for coordination, but management decisions benefit from a compressed view.

A timeline can indicate:

• increasing modelling activity;
• prolonged stability;
• late-stage redesign;
• sudden scope reduction;
• concentration of changes in one discipline;
• repeated instability across several deliveries.

These signals can then be investigated in the detailed comparison report.

Multi-revision does not mean automatic completion percentage

It is tempting to convert every graph into a percentage complete.

That should be avoided unless the project has a reliable planned final scope and an agreed measurement method.

A revision timeline based only on delivered IFC content measures model development, not contractual project completion.

That is still highly valuable.

It provides an objective record of what the models themselves show.

The distinction keeps the KPI technically honest.

Revit, AVEVA and SolidWorks revision series

The current Model Bridge release is being tested against revision sequences exported from three major engineering authoring environments:

• Autodesk Revit;
• AVEVA E3D;
• SolidWorks/3DEXPERIENCE.

The goal is not merely to parse valid IFC syntax. The comparator must cope with the way different applications structure engineering content in practice.

That includes differences in class usage, naming, property sets, hierarchy and use of generic proxies.

A revision history becomes useful only when the counted and compared objects remain meaningful from one delivery to the next.

From history to project intelligence

Once the revision-series concept works reliably for one model, a natural next step appears.

Instead of analysing only one subcontractor or one discipline, a future system could analyse all IFC models of the project.

Architecture, structure, piping, HVAC, electrical and equipment packages could each maintain their own revision timeline while also contributing to a project-level view.

That is a future direction, not a feature of the first release.

But it follows directly from the same principle:

if every IFC delivery is a data point, the collection of all project IFC deliveries becomes a measurable design process.

The first release starts at the model level.

The long-term opportunity is project-level engineering visibility.