A model can display walls, slabs, equipment, and spaces while being unusable for the task that motivated the exchange. Visible geometry answers where surfaces are drawn. It does not necessarily answer what an object is, where it belongs in the project, which system it relates to, or which properties a recipient can rely on.
Separate the information layers
Treat semantic preservation as a set of questions rather than a single “BIM” checkbox.
| Layer | What the recipient may need | What visible geometry does not prove |
|---|---|---|
| Geometry | Shape, placement, and representation suitable for the task | That the shape has the intended object identity or classification |
| Object identity and type | A stable object, type, or occurrence identity | That two similar solids represent the same object or type |
| Spatial containment | Assignment to a site, building, storey, space, or other level in the project’s hierarchical structure | Which place in the project structure contains a visible object |
| Functional spatial zone | Association with a potentially overlapping functional grouping, such as a thermal, lighting, or occupancy zone | That the zone is another level in the project hierarchy or that its membership is preserved |
| Additional spatial references | Cross-level or served-space references in addition to primary containment | That a spanning element’s other spatial relationships survived, even when its primary container did |
| Relationships and aggregation | Connections, decomposition, assemblies, or related objects | How objects participate in a project structure |
| Classification | The classification system, edition, and reference applied to an object | What a local name or colour means outside the source application |
| Properties and quantities | Named values, units, allowable values, and property-set context | That a displayed label is a reliable property or quantity |
| Coordinate context | Units, frames, placements, and project or map relationships | That the model is located correctly in another project |
| Placement dependency | Alignment-relative or grid-relative position, direction, and offset when required | That flattened geometry retained the alignment, station meaning, grid axes, or placement relationship |
| Survey-area annotation | A declared survey-area quality field, such as an expected or obtained percentage | That a percentage is an independently measured positional accuracy, a per-object tolerance, or acceptance |
The IFC documentation illustrates these as distinct structures. IfcRelContainedInSpatialStructure relates elements to a spatial structure, while IfcRelAggregates can express an element assembly. IfcClassification identifies a classification source and references associated with objects. IfcPropertySet groups properties that can be assigned to occurrences or types. These are representational capabilities in the cited IFC documentation, not claims that every exchange preserves them.
IFC also distinguishes an element’s primary containment from additional spatial references. An element is primarily contained in one spatial structure element, while IfcRelReferencedInSpatialStructure can associate it with other levels where it is relevant. A curtain wall spanning several storeys is the useful example: its primary container and its cross-level references answer different questions. Checking only one relationship can therefore overstate what the delivered model retains.
Project hierarchy and functional zones are different
An IFC project hierarchy is a parent-child decomposition, such as site, building, storey, and space. A spatial zone represents a functional grouping instead: examples in the IFC documentation include thermal, lighting, occupancy, and ventilation zones. The documentation describes zones as non-hierarchical and potentially overlapping, so a zone is not simply another storey or container in the project tree. A zone-type label describes its intended function; it does not establish the zone’s geometry, which objects belong to it, or how a receiving application handles it.
IFC can also associate a group with spatial structure through a separate spatial-reference relationship. When a handoff depends on both project location and functional grouping, state and check primary containment, additional spatial references, and group relationships separately. These schema relationships describe possible BIM meaning; they do not prove a particular exchange preserved that meaning.
Placement relationships can be part of the meaning
A displayed XYZ position may not answer how a civil object is located. The IFC Working Draft documentation describes linear placement relative to a curve and grid placement relative to a grid intersection, with optional offsets and direction context. The grid-placement page also says that the entity is outside a standardized schema subset or implementation level. These pages describe representation concepts; they do not establish an official view or supported exchange route.
If a receiver needs station/measure, offset, curve direction, grid axes, or a parent placement, request those relationships explicitly. Flattening to coordinates can be an intentional loss for a reference view, but it cannot satisfy a task that depends on the relationship. See the civil-placement article for a placement requirement inventory.
The same model can be fit for one task and incomplete for another
A coordination viewer may need recognizable geometry, placement, and enough identity to discuss clashes. A quantity workflow may additionally require the right objects, classifications, property values, units, and quantities. An analysis or facilities handover can require still different relationships and property scopes. A downstream authoring workflow may need editable objects and design intent that a reference representation intentionally does not carry.
Do not turn this into a universal hierarchy of “better” BIM. Define the recipient task first, then state the layers needed for that task. The IFC exchange-scope article explains how release and model-view purpose constrain a delivery. The IDS article covers a machine-interpretable way to express selected requirements.
Ask for meaning explicitly
Replace “include all BIM data” with a bounded requirement. For each required layer, state:
- the object or population to which the requirement applies;
- the relationship or property that must be present;
- the vocabulary or classification system and version, where relevant;
- units and value constraints for measure-valued information;
- required spatial containment or aggregation levels;
- the IFC release and model-view scope;
- exclusions, such as design history, application-specific constraints, or unsupported domains; and
- the evidence the recipient will use to verify the requirement.
This also makes omissions legible. “Geometry only” can be an acceptable, honest delivery for a visual reference if that is the agreed objective. It is an incomplete delivery when the recipient was expecting classified objects, quantities, or facilities data.
Inspect more than the viewport
A visual inspection can answer whether something appears on screen. It cannot by itself establish:
- that every expected object is present;
- that objects belong to the correct spatial containers;
- that relationships and assemblies are complete;
- that classification references point to the intended system and edition;
- that property values have the expected names, units, and applicability; or
- that the coordinate and unit context was interpreted correctly.
A structured check must follow the declared purpose and requirements. An IFC model-view description or an IDS requirement can make the expected scope more precise, but neither document is proof that a particular sender produced the required information or that a recipient’s implementation interpreted it correctly.
IDS 1.0 can express structured facets such as entities, classifications, properties, and parts, but its manual explicitly places geometry checks, dynamic or calculated checks, external IFC data, and several domain-specific relationships outside that first-version scope. A passing structured requirement check is consequently not a geometry or project-acceptance result.
Preserve vocabulary context
A classification label or property name is not always meaningful without its source. If a requirement uses an external vocabulary such as bSDD, record the identifier and a fixed version when the requirement is contractual. A mutable latest reference can change when a newer active or preview version appears; it is not an immutable contract input. Tool support for resolving or preserving those references remains implementation-specific.
The same principle applies to property sets: a value without its property definition, unit, object applicability, and version context can be difficult to interpret or compare.
State the loss boundary plainly
Use language such as:
This delivery preserves the requested reference geometry and project placement. It does not establish preservation of parametric history, object relationships, classifications, or property sets.
That statement is more useful than calling the file “BIM-compatible.” It tells the recipient what the model can support and what must not be assumed. Detailed product relationships belong to Product Structure, Identity, and References, while engineering-document meaning belongs to Engineering Semantics and Documentation. Spatial context and information requirements belong here; acceptance evidence belongs to Validation, Exchange Control, and Long-Term Reuse.