IFC — Industry Foundation Classes

Current versions

The public IFC 4.3.2.0 documentation is semantically identical to the ISO release, but includes additional examples, clarifications and typo fixes — not a different schema version, just a more precise documentation layer.

Four layers

IFC is not flat. buildingSMART organises the schema into four conceptual layers, from generic to domain-specific:

The core entities that matter

Anyone working with IFC should know roughly a dozen entities and relationships by heart — that is how model structures become readable.

Identity

IfcRoot is the abstract base of all relevant objects above the Resource Layer. Provides four mandatory attributes: GlobalId (22-char compressed UUID), OwnerHistory, Name, Description. The GlobalId is stable across the entire model life — tools must not regenerate it without reason.

Project + spatial structure

IfcProject is the root of every model. Below it:

• IfcSite — site / location
• IfcBuilding — building (or, since 4.3, IfcFacility / IfcFacilityPart for infrastructure)
• IfcBuildingStorey — storey
• IfcSpace — room

Linked via IfcRelAggregates (whole-part relationship).

Assigning components

• IfcRelContainedInSpatialStructure — primary spatial assignment (a wall is contained in a storey). Components have exactly one primary assignment.
• IfcRelReferencedInSpatialStructure — secondary reference (a heating system references a storey but is not primarily contained there).

Typing

IfcRelDefinesByType links types to occurrences (1-to-N). An IfcDoorType defines a door kind, then many IfcDoor instances are derived from it. Clean attribute reuse.

Properties

IfcRelDefinesByProperties links property sets to objects (N-to-N). An IfcPropertySet can be bound to many objects, an object can carry many property sets. Structured attributes go through IfcPropertySet + IfcProperty, quantities through IfcElementQuantity.

Typical property sets are Pset_WallCommon, Pset_DoorCommon, Pset_SpaceCommon. Typical quantity sets: Qto_WallBaseQuantities, Qto_DoorBaseQuantities.

Systems and groups

IfcSystem bundles components into functional systems (HVAC system, electrical system, structural system). Assignment via IfcRelAssignsToGroup.

Material and classification

• IfcRelAssociatesMaterial links materials to objects
• IfcRelAssociatesClassification links classification systems (Uniclass, OmniClass, eBKP-H, ETIM)

Placement

• IfcLocalPlacement — relative placement, classical for buildings (wall sits relative to the storey plane)
• IfcLinearPlacement — linear referencing, new in 4.3, essential for infrastructure (bridge relative to alignment)
• IfcAlignment — lead object for linear works such as road, rail, bridge

File formats

What changes between IFC4 and IFC 4.3?

Both have the same four layers, the same core-entity logic. The difference is not cosmetic — IFC 4.3 structurally extends the schema to linear infrastructure:

A graph, not a tree

One of the most common misconceptions: IFC is a tree. It is not. IFC is a directed relationship graph in which components, rooms, types, properties and materials are linked via relationship entities. This has consequences for every CDE and every importer:

• Properties must not be flattened into a single table — type properties and occurrence properties must remain distinct.
• Spatial assignment is not duplicated — primary and secondary have different meanings.
• Classification, material and quantities are separate relationship domains, not fields.
• A GlobalId identifies an object uniquely across all views — tools must not change it between exports without reason. This discipline is the prerequisite for stable BCF issues across multiple model versions.

Mapping to signed events

BIM-CVP treats IFC models not as a stream of individual entities but as a signed file container with a metadata event. The reason: millions of IFC entities in millions of events would be unusable — and semantically unnecessary, because IFC is already a complete self-contained model format.

Per IFC file, two events are created:

kind:1063  NIP-94 File metadata
  tags: [
    ["url",   "https://blossom.example/<sha256>"],
    ["m",     "application/x-step"],
    ["x",     "<sha256>"],
    ["size",  "<bytes>"],
    ["schema",         "IFC4X3_ADD2"],       # IFC4_ADD2_TC1, IFC2X3_TC1
    ["mvd",            "ReferenceView"],     # AlignmentBasedView, IFC4Precast
    ["authoring-tool", "Revit"],             # ArchiCAD, Allplan, Tekla, …
    ["discipline",     "architecture"],      # mep, structural, electrical, civil, …
    ["iso19650-state", "Shared"],            # WIP / Shared / Published / Archive
    ["ifc-project",    "<IfcProject-GUID>"],
    ["a",              "<project-ref>"]
  ]
  content: { ifc_project_name, entity_count, notes }

kind:30904  File reference (parameterised replaceable)
  d: <file-guid>
  Links the NIP-94 event and adds project-specific fields
  (IfcSpatialStructureElement, replacement version, stage)

The IFC file itself lives on Blossom or another storage adapter. The hash guarantees integrity, the signature guarantees provenance.

Practical pitfalls

• GUID churn — if authoring tools regenerate GlobalIds on re-export without reason, BCF issues and FM references lose their component bindings. Define tool-specific GUID stability rules in the BAP, run regression tests before publishing.
• Type vs occurrence drift — properties get set on both the type and the occurrence at once, then conflict. Separate them clearly in the modelling guide.
• Wrong spatial assignment — an element ends up in the wrong spatial structure. Filters, reports and evaluations break quietly. Automate IfcRelContainedInSpatialStructure checks.
• Reference vs full confusion — the recipient expects editable authoring data but receives a Reference-View model with no editable intelligence (or vice versa). Name the exchange MVD explicitly in the AIA / BAP.
• Infrastructure without alignment — bridge or trace models are only placed locally instead of linearly referenced. For infrastructure projects, make IfcAlignment + IfcLinearPlacement mandatory in the BAP.

Tool compatibility (vendor-self-reported, 2026)

These claims are vendor-self-reported and not verified by buildingSMART. For real tenders, always verify via a productive proof-of-concept with reference models, IDS test cases and BCF round-trip.

Sources

• buildingSMART IFC 4.3 documentation
• buildingSMART technical IFC standards
• ISO 16739-1:2024
• IFC 4.3.x development repository