IFC Round-trip Validation
IFC Round-trip Validation checks that GUIDs, geometry, and standard buildingSMART Property Sets survive an IFC round-trip between tools such as Revit, ArchiCAD, Tekla, Solibri, and Bentley OpenBuildings. It validates IFC2x3 (ISO 16739:2005), IFC4 (ISO 16739-1:2018, Reference View 1.2 MVD), and IFC4.3 (ISO 16739-1:2024 by Labs scope) and reports losses on each leg, available now as a Labs engagement under MSA + Appendix.
- Element-by-element diff with GUID-stability tracking between IFC export and re-import, including explicit counts per IfcEntity class.
- Property Set losses flagged with the specific Pset (Pset_WallCommon, Pset_DoorCommon, etc.), entity class, and whether the loss occurred on export or re-import.
- Validation runs against IFC2x3 and IFC4 (Reference View 1.2 MVD) as production defaults; IFC4.3 (ISO 16739-1:2024) supported by Labs scope for infrastructure-heavy projects.
From hope-it-survived to verify-it-survived.
Workflow today
-
01
Authoring tool exports IFC
Day 1. A BIM Manager exports IFC from Revit, ArchiCAD, Tekla, Solibri, or Bentley OpenBuildings using office-standard presets. They pick IFC2x3 for legacy jobs or IFC4 Reference View for newer work, but rarely verify which Property Sets or quantity sets actually leave the model. Export logs stay unread until a coordination issue appears.
Day 1 -
02
Partner tool imports
Day 1–2. A partner discipline imports the IFC into their own authoring tool. Geometry looks acceptable by eye, so the team assumes the round-trip is safe. No one checks GUID stability, Pset completeness, or MVD compliance; BREP solids may have been tessellated, and precision drift across storey levels goes unnoticed.
Day 1–2 -
03
Issues surface in coordination
Week 1+. GUIDs reshuffle silently, so clashes in the coordination model no longer track back to the original elements. Pset_DoorCommon disappears on a subset of doors, window types collapse into a single type, and IfcSpace boundaries shift by a few millimetres. Each issue triggers a separate meeting and screen-share to diagnose which leg of the IFC round-trip failed.
Week 1+ -
04
Re-export, repeat
Week 2+. The team re-exports a new IFC, partners re-import, and a fresh set of issues appears. No one has a structured diff across the two legs, so they rely on screenshots and ad-hoc spreadsheets. Time that could go into Rhino to Revit translation or model QA instead goes into chasing why a door lost its fire rating on the last round-trip.
Week 2+
Workflow with VitruAI
-
01
Run the validation agent on the export
Day 1, calibrated per deployment. The validation agent reads the source model from Revit, ArchiCAD, Tekla, Solibri, or Bentley OpenBuildings and the exported IFC2x3 or IFC4 file. It builds an element-by-element diff with GUID-stability tracking, checks Property-Set completeness for buildingSMART Psets and quantity sets, and records geometry representation (BREP vs tessellated) for each entity.
Day 1, calibrated per deployment -
02
Run again on the partner re-import
Day 1. After the partner re-imports the IFC, the agent reads the re-imported model and compares it with the original export. It flags GUID drift, missing or truncated Property Sets, and geometry changes such as solids converted to meshes or precision drift across storeys. MVD compliance is checked per leg, Reference View vs Design Transfer View, with IFC4.3 by Labs scope when infrastructure objects are present.
Day 1 -
03
Review the validation report
Day 1–2. The BIM Manager receives a structured report: counts of preserved vs changed GUIDs, lists of elements that lost Pset_DoorCommon or Qto_WallBaseQuantities, and examples where IfcSpace boundaries moved beyond a configured tolerance. The report notes which IFC schema was used and highlights any bSDD URI mapping or IDS 1.0 rule that failed, so coordination teams can focus on specific exporter settings or modelling patterns.
Day 1–2 -
04
Re-export with fixes (optional IDS check)
Day 2+. The source model is adjusted to preserve the lost data, such as correcting shared parameters or export mappings before re-running IFC export. If the customer supplies an IDS 1.0 file, the agent validates the new IFC against that Information Delivery Specification and confirms which requirements now pass. The same round-trip pattern can then be applied to other exchanges, including IFC OpenBIM integrations and Rhino-to-Revit workflows.
Day 2+
IFC round-trip validation — detailed questions
-
Which IFC schema versions are supported?
The workflow supports IFC2x3 (ISO 16739:2005) as the production default for legacy projects and IFC4 (ISO 16739-1:2018) as the current ISO standard for buildings. Reference View 1.2 MVD is treated as the production target, with Design Transfer View evaluated per project posture. IFC4.3 (ISO 16739-1:2024) is supported by Labs scope only, primarily for rail, road, ports, and waterways where buildings still use IFC4.
-
Which Property Sets does the agent validate?
The agent validates standard buildingSMART Property Sets including Pset_WallCommon, Pset_DoorCommon, Pset_WindowCommon, Pset_SpaceCommon, Pset_BuildingStoreyCommon, Pset_SlabCommon, Pset_ColumnCommon, and Pset_BeamCommon. It also checks the standard quantity sets Qto_WallBaseQuantities and Qto_SpaceBaseQuantities for loss or change across the round-trip. Customer-defined custom Psets are added per Labs deployment so office-specific parameters are checked alongside the standard sets.
-
Does it validate against the bSDD or IDS?
Yes. bSDD alignment is available as an optional layer for firms working to OpenBIM mandates, with each relevant IFC property mapped to a buildingSMART Data Dictionary URI. The agent can then report where URIs are missing, mismatched, or changed between export and re-import. IDS 1.0 validation runs when the customer supplies an IDS file, and the report shows which Information Delivery Specification requirements fail for each round-trip leg.
-
Which authoring tools are supported as round-trip endpoints?
Current endpoints include Revit, ArchiCAD, Tekla, Solibri, and Bentley OpenBuildings, with the validation logic itself remaining tool-agnostic because it reads IFC. Additional endpoints are added per Labs engagement, often alongside VitruAI + Revit and VitruAI + ArchiCAD deployments. Firms already using the Interop Rhino–Revit Agent or IFC OpenBIM integration can extend the same validation patterns across their wider model exchange network.
-
How does a Labs engagement work?
A Labs engagement typically runs 4–8 weeks under MSA + Appendix. VitruAI calibrates the validation rule pack to the firm’s IFC export conventions, preferred schemas, and MVD posture, including which legs should use Reference View or Design Transfer View. The team then ships a working agent on one pilot project, tunes it against real Revit, ArchiCAD, Tekla, Solibri, or Bentley OpenBuildings exchanges, and folds the learnings into the productised release for broader rollout.