IFC support is not a lossless handoff verdict
buildingSMART maintains Industry Foundation Classes as an open, vendor-neutral schema for built-environment information. A provider claim still needs release, model-view, field, identity, relationship, validation, and round-trip evidence for the project exchange.
Editorial figure by Contractor Systems Index. Source context: buildingSMART Industry Foundation Classes.
IFC support needs a named exchange target
The term IFC can refer broadly to a maintained standard programme, while a project exchange depends on a specific release, schema, model-view or information requirement, software version, export configuration, and receiving workflow. A product may import or export some IFC content without supporting every entity, property, relationship, geometry, classification, or project use.
A procurement record should identify the sending and receiving applications, versions, IFC release, exchange requirement, included disciplines and objects, required properties and relationships, coordinate basis, classification, validation rules, and accountable parties. A generic IFC compatible field is orientation, not evidence that the intended handoff works.
File acceptance is not information preservation
An application can open a file while dropping, flattening, remapping, duplicating, or visually misrepresenting important information. Buyers need to test semantics and relationships alongside visible geometry. Stable identifiers, property sets, units, classifications, systems, spaces, materials, issue references, and document links may be as important as the model's appearance.
A useful demonstration should compare the source, exported file, receiving view, validation report, and any round-trip result. Missing, transformed, unsupported, and inferred fields should be listed rather than hidden. The team should decide which losses are acceptable for the stated purpose and preserve that decision with the tested software and configuration versions.
Validation must follow project information requirements
Schema validity can show that a file meets structural rules without proving that it contains the information the project requires or that the information is accurate. Conversely, a project may deliberately exchange a bounded subset. Validation should therefore connect formal checks to the contract, information requirements, delivery milestone, model purpose, and approved exceptions.
Construction systems should retain the submitted artifact, checksum, origin, export settings, validation rules and versions, findings, responsibility, correction, waiver or acceptance, and superseding submission. Automated issue generation can accelerate review, but authorized project participants still decide whether the exchange satisfies contractual and professional obligations.
Handover needs operational identity and provenance
Information that supports design coordination may not be sufficient for construction control or owner operations. Handover can require approved asset identity, installed condition, serial and location data, commissioning and warranty records, document links, maintainable-asset scope, and alignment with the owner's target systems. An IFC export alone does not establish that transition.
Buyers should test a representative asset from authoring through coordination, field change, validation, acceptance, and operations import. They should verify correction, versioning, access, and future export as well as initial ingestion. buildingSMART's official programme gives the common reference; the configured project evidence determines whether the exchange is fit.
Enterprise buyer test
Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.
A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.
What we will watch next
Contractor Systems Index will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.