Define an IFC Exchange Scope: Release, Model View, and Purpose
“Send an IFC” names a file family, not a complete exchange requirement. The recipient still needs to know which schema release, model-view scope, information layers, and downstream task the delivery must serve.
Start with the recipient task
Write the purpose before choosing the release or view. A coordination reference, a quantity workflow, a facilities handover, a one-way design transfer, and downstream authoring do not ask for the same information. A model-view name can narrow the scope, but it cannot decide the project’s requirements for you.
A useful request identifies:
- the recipient and the task the model must support;
- the IFC schema release and status;
- the model view or other declared profile scope;
- geometry and spatial context requirements;
- required structure, containment, classifications, properties, quantities, and relationships;
- units, coordinate context, and georeferencing expectations;
- excluded layers, such as parametric history or application-specific constraints;
- delivery encoding and any companion requirements artifact; and
- how the recipient will demonstrate that the result is fit for purpose.
Record the release, not just “IFC”
buildingSMART’s official release table distinguishes major, minor, addendum, and corrigendum components and assigns status to individual releases. In the table consulted for this category, IFC 4.3 ADD2 (4.3.2.0) and IFC 4 ADD2 TC1 (4.0.2.1) are listed as official, while IFC 4.2 and IFC 4.1 are listed as withdrawn. IFC 5 and IFC 4.4.x are shown as under development. IFC 2x3 TC1 is also listed as official. These statuses are properties of the cited release table and should be rechecked when a contract is prepared.
The release label is meaningful because changes between release components have different compatibility implications. It still does not establish that a particular application supports the release, the required view, or the specific entities used by the project.
Keep documentation status separate from release status. The IFC 4.3.2 entity pages used for the coordinate and placement examples in this category carry a generated IFC4X3_ADD2 under-development build label, while the official release table lists IFC 4.3 ADD2 (4.3.2.0) as official. Cite the exact documentation scope and use the official release table for the release-status claim; do not silently merge the two labels.
Treat model views as purpose-bound
The buildingSMART MVD material describes a Model View Definition as a purpose-specific interpretation of IFC. It can constrain which data is included or excluded and how entities, relationships, classifications, material assignments, and containment are used.
The official database gives concrete scope and status examples:
| Schema and view | Published status in the database | Stated scope |
|---|---|---|
| IFC4.3 ADD2 Reference View | Final | Reference View update for IFC 4.3 |
| IFC4 ADD2 TC1 Reference View 1.2 | Final | Simplified geometric and relational representation for design coordination |
| IFC2x3 TC1 Coordination View 2.0 | Final | Spatial and physical components for design coordination |
| IFC4 ADD2 TC1 Design Transfer View | Draft | Higher-fidelity one-way transfer, explicitly not a round trip |
These entries describe the defined scope of each view. They do not prove that an arbitrary exporter or importer implements it, nor that a project handoff meets the recipient’s acceptance conditions.
Separate four different claims
Avoid collapsing these statements into “compatible”:
- Schema capability: the release can represent a concept.
- View definition: the selected view defines a purpose-bound inclusion and interpretation scope.
- Implementation support: a named sender or receiver supports that release and view in a stated direction and version.
- Project acceptance: the delivered dataset satisfies this recipient’s requirements and checks.
The first two can be established from standards material. The third requires bounded implementation evidence. The fourth requires evidence from the actual delivery and acceptance process.
If the exchange includes an Information Delivery Specification, record its exact version and schema context as part of the request. The IDS 1.0 manual separates the model subset (Applicability) from the information it must satisfy (Requirements) and defines facets for entities, attributes, classifications, properties, materials, and parts. It supports structured requirements for particular IFC schemas, but it assumes valid IFC data and does not replace geometry, external-data, or project-acceptance checks. These boundaries are useful when deciding what the exchange request must ask for elsewhere.
Implementation checks need their own scope. The buildingSMART IDS developer guide on the repository’s development branch separates XSD validity from fuller IDS auditing, points checkers to the IFC/IDS test suite, and calls for disclosure when a checker cannot parse the IFC version named by a specification. Record those implementation and version boundaries alongside the delivery request; they do not establish that a chosen product supports the route.
Treat implementation directories as leads, not as support evidence. The official buildingSMART software directory says that its capability entries are vendor self-reports, are not verified by buildingSMART, and are not a list of certified tools. Confirm the exact product, version, direction, release, view, and test scope independently before calling a route supported.
A bounded exchange request
Use a request like this as a starting point. It is a planning aid, not an IFC file or an assertion that a tool can deliver it.
Purpose: coordination reference for architectural, structural, and MEP review
IFC release: [exact release and status]
Model view/profile: [exact view identifier and status]
Coordinate context: [local/project/map frames, units, and required placement]
Required layers: [geometry, spatial containment, identities, classifications, properties]
Required requirements artifact: [IDS version and fixed vocabulary references, if used]
Excluded layers: [for example, parametric history or application-specific constraints]
Direction: [sender -> recipient, including product versions]
Acceptance evidence: [checks, comparisons, and responsible recipient]
The IDS article explains how to express object, classification, property, value, and unit requirements. The BIM semantics article helps distinguish visible geometry from the structured layers that a task may need.
mvdXML and IDS are not interchangeable labels
buildingSMART identifies mvdXML 1.1 as its latest official mvdXML publication and describes limitations in the published implementation material. It recommends IDS for defining information requirements for IFC datasets. Community-developed mvdXML 1.2 and 1.3 versions are separately described as not having followed the buildingSMART process or received standards-committee approval.
This does not mean that an IDS document replaces the IFC release or model-view scope. It means that the requirements artifact and the delivery representation answer different questions and must be named separately.
Record what is not established
If you have only a schema page or MVD description, state that you have representability and purpose-scope information—not application support, preservation results, or project acceptance. Keep the release, view, direction, product versions, and intended task attached to any later implementation claim.