A guide to recognizing when a visually usable model has lost the spatial structure, containment, relationships, classifications, or properties needed for BIM work.

When Geometry Arrives but BIM Meaning Does Not

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, zone, or other container	Which container owns a visible object
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

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.

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.