A schema is broader than an exchange
IFC defines a rich structure for describing built assets, but an individual exchange usually needs only part of that structure. A model view definition describes a selected set of concepts and exchange expectations for a particular use. It shapes what information an implementation supports and what a receiving workflow can reasonably expect.
This helps explain why two files both labeled IFC may behave differently. Before comparing exports, ask what task and exchange view each one was prepared to support.
Start from the receiving question
Imagine a hypothetical structural design team sending a model to a coordination consultant. The receiver may need physical members, openings, spatial placement, and identifiers to compare with architecture and services. A structural analysis exchange may need analytical connectivity and member properties instead.
An asset handover may require maintainable component data that is irrelevant to a coordination review. Write the recipient's questions first, then identify which IFC concepts and fields answer them. This prevents teams from treating file size or visual richness as a proxy for usefulness.
Understand implementation boundaries
A schema can define a concept that a specific authoring or checking application only partly supports. Export options may expose named views or mapping settings, but labels alone do not prove correct implementation. Ask vendors or project teams what is supported, then test with representative objects. Include common members, unusual connections, openings, and property sets.
Compare the file in the receiving software and inspect its data structure when needed. Record known limitations so reviewers do not mistake a tool boundary for a design decision.
Read diagram notes
- Intended task
- What must the recipient do?
- Exchange scope
- Required concepts and properties
- Implementation test
- Test the actual exporter and reader
Do not confuse geometry with semantics
A beam-shaped solid may look convincing while having no useful beam identity, type, material, or relationship to the project structure. Conversely, an object may carry a meaningful class and properties but display differently because of representation choices. Validate geometric and semantic expectations separately.
For example, a coordination recipient may need a column's location and shape, while a quantity process also needs a reliable measurable quantity and classification. State which of those requirements are in scope for each exchange.
Define what is outside the view
A good exchange definition says what it omits. An IFC for coordination may exclude analysis-only nodes, temporary erection aids, or documentation graphics, provided recipients know that boundary. Omissions can create dangerous assumptions if people interpret a partial model as a complete design. Add a cover note or delivery metadata describing excluded systems and intended use.
For a hypothetical frame, a coordination IFC that omits reinforcement should not be used to infer bar congestion or construction readiness.
Validate with a task scenario
A useful test is to ask a receiver to perform the intended operation using only the exported file and its delivery notes. Can they identify the member at a location, compare its envelope, filter by discipline, and retrieve required properties? Can an analysis recipient recover the intended analytical objects and assumptions?
Define a pass/fail criterion for each task. A viewer screenshot is not enough; a successful open is merely the beginning. Record failures by concept and application so the team can isolate whether the issue is mapping, export, or expectation.
Use fit-for-purpose exchanges
A project may need multiple IFC deliveries, each with a distinct purpose and date. That is manageable if filenames, metadata, and delivery notes make the role clear and source revisions traceable. Avoid creating parallel exports with nearly identical names and undocumented settings.
A controlled exchange matrix can map recipient, use, schema, required content, and validation evidence. The matrix should stay small enough for teams to maintain. It is better to have two tested exchanges than one universal file whose limitations nobody understands.
Set a boundary on conclusions
Model view definitions and exchange checks define what a file is intended to carry; they do not verify every design assumption. A coordination view cannot confirm structural capacity, and an analysis view cannot prove that a construction detail is coordinated. Keep technical approvals with the accountable discipline.
Use the exchange definition to make data expectations explicit, then use engineering review to judge the design. This separation makes openBIM more useful because recipients know what they can safely conclude from the information they received.