Why IFC GUIDs Are Not Always Enough for Reliable Model Comparison
IFC GlobalIds are extremely useful.
If an element keeps the same `GlobalId` between two revisions, a comparator has a strong identity signal.
But real model deliveries do not always preserve identity perfectly.
That creates one of the hardest problems in IFC comparison.
The ideal case
In the ideal workflow:
- an engineering object exists in Revision A;
- the same object exists in Revision B;
- its GlobalId is unchanged;
- its geometry or properties can be compared directly.
Matching is then straightforward.
The comparator can classify the object as unchanged, modified or moved.
What happens when IDs change?
A re-export, model reconstruction, copy operation, authoring workflow change or cross-software process can regenerate identifiers.
Now the same engineering object may appear under a different IFC GlobalId.
A strict GUID-only comparator may interpret this as:
- one deleted object;
- one added object.
That may be technically consistent with the IDs while being misleading from the engineering perspective.
Duplicate IDs are another problem
The opposite problem can also occur.
If identifiers are duplicated, matching becomes ambiguous.
A comparator should detect and report such cases rather than silently make an arbitrary match.
Model Bridge therefore keeps ambiguity information visible in the report.
Geometry as supporting evidence
Geometry can help when identity is unstable.
For example, two represented objects with similar shape and placement may be candidates for the same engineering object.
Geometry alone is not perfect either.
Two identical components can legitimately exist in different positions. A moved object can look geometrically identical to its earlier version. A source exporter can change tessellation while the engineering object remains unchanged.
That is why robust comparison should combine signals rather than depend on one field.
Source-specific engineering identity
The strongest matching evidence may come from the authoring source.
In AVEVA E3D workflows, source information such as DBREF, OWNER and TYPE can help interpret continuity.
In Revit workflows, names, IFC classes and exported metadata can provide additional context.
SolidWorks/3DEXPERIENCE may require stronger reliance on representation and geometry because exported semantics can be more generic.
The available evidence differs by source.
Stable comparison requires stable export practice
No algorithm can fully recover information that was never exported.
Projects can improve revision comparison by maintaining consistent export settings and preserving stable identifiers whenever possible.
A good comparator should still be resilient, but process discipline remains important.
Useful practices include:
- keeping export configuration controlled;
- documenting major exporter changes;
- avoiding unnecessary identity regeneration;
- maintaining consistent model splitting;
- preserving source identifiers where possible.
Why this matters for KPI history
Identity errors can distort progress metrics.
If every object receives a new GUID, a naive comparison could report thousands of deletions and thousands of additions even though the design changed only slightly.
That makes a timeline almost useless.
A multi-revision KPI therefore depends on sensible object identity and explicit ambiguity handling.
This is one reason Model Bridge reports both high-level trends and underlying comparison diagnostics.
A realistic goal
The goal is not to claim perfect object matching under every possible IFC export.
The goal is to make the comparison transparent.
Where identity is strong, use it.
Where identity is ambiguous, report the ambiguity.
Where geometry and source metadata provide additional evidence, use them carefully.
For engineering users, an honest confidence boundary is more valuable than a false impression of certainty.
IFC GlobalId is an important signal, but reliable revision comparison is an engineering identity problem, not only a GUID lookup.