# Ifc Core Data Model

> Use when you need to understand or explain how the IFC schema is organized, decide which conceptual layer an entity belongs to, judge whether one schema is allowed to reference another, or work out why an entity does or does not carry a GlobalId. Prevents the upward-reference mistake (a lower-layer schema pointing at a higher-layer entity), the assumption that every IFC entity has a GUID, and the error of treating a serialized .ifc / .ifcXML / .ifcJSON file as the schema instead of a derived encoding. Covers the four-layer architecture (Resource, Core, Interoperability/Shared, Domain), the downward-only referencing rule (ladder principle), the EXPRESS schema as the single canonical model, and the GlobalId presence rule across IFC2x3, IFC4 and IFC4.3. Keywords: IFC layered architecture, four-layer schema, Resource layer, Core layer, Interoperability layer, Domain layer, ladder principle, downward reference, IfcKernel, IfcProductExtension, GlobalId, GUID, IfcRoot, EXPRESS canonical model, ISO 16739-1, ISO 10303

- Skill: `impertio-studio/ifc-core-data-model` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add impertio-studio/ifc-core-data-model`
- Raw SKILL.md: https://api.skillmd.com/api/skills/impertio-studio/ifc-core-data-model/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- License: MIT
- Author: Impertio-Studio (https://skillmd.com/u/impertio-studio)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/impertio-studio/ifc-core-data-model

---


# IFC Core : Data Model and Schema Architecture

The IFC schema is one large EXPRESS model split into many named sub-schemas,
each assigned to exactly one of four conceptual layers. The layering and its
downward-only referencing rule are the load-bearing structure of the entire
standard. Get the layer of an entity wrong, or reference upward, and the model
is invalid IFC.

## Quick Reference

### The model in one sentence

IFC is a single canonical data model written once in the EXPRESS language
(ISO 10303-11), organized into four conceptual layers, and serialized into
derived encodings (.ifc, .ifcXML, .ifcJSON).

### The four conceptual layers

Bottom to top. Each individual schema is assigned to exactly one layer.
Chapter numbers are the IFC4 and IFC4.3 documentation chapters.

| Layer | Doc chapter | Holds | GlobalId | Example schemas |
|-------|-------------|-------|----------|-----------------|
| Domain | Chapter 7 | Discipline-specific products, processes, resources | Yes | `IfcArchitectureDomain`, `IfcHvacDomain`, `IfcRailDomain` |
| Interoperability (Shared) | Chapter 6 | Cross-discipline product / process specializations | Yes | `IfcSharedBldgElements`, `IfcSharedFacilitiesElements` |
| Core | Chapter 5 | Kernel plus core extensions ; most general entities | Yes | `IfcKernel`, `IfcProductExtension` |
| Resource | Chapter 8 | Reusable building blocks (geometry, material, units) | No | `IfcGeometryResource`, `IfcMaterialResource` |

Full member-schema lists for every layer are in `references/methods.md`.

### The two hard rules

RULE 1 : The ladder principle. A schema ALWAYS references schemas in the same
layer or a lower layer only. A schema NEVER references a schema in a higher
layer. References point downward (or sideways), never upward.

RULE 2 : GlobalId presence. Every entity defined at the Core layer or above
ALWAYS carries a globally unique id (and optional owner / history information).
Entities defined at the Resource layer NEVER carry a globally unique id and
NEVER stand on their own : a resource instance is always referenced by a
definition declared at a higher layer.

### EXPRESS is the single source of truth

ALWAYS treat the EXPRESS schema as canonical. The `.ifc` (STEP Physical File),
`.ifcXML` and `.ifcJSON` files are derived encodings of the same EXPRESS model.
NEVER reason about the data model from a serialized file alone : the file omits
DERIVE and INVERSE attributes, which exist only in the EXPRESS schema.

### Why the layering exists

The layering isolates stable, broadly reused concepts at the bottom and
volatile, discipline-specific concepts at the top. This serves three goals :
change management (a Domain change cannot ripple down into Core or Resource),
reusability (one geometry resource serves every discipline), and domain
independence (no Domain schema depends on another Domain schema).

### Version note

The four-layer architecture and the ladder principle are invariant across
IFC2x3, IFC4 and IFC4.3. What changes is membership : IFC4.3 added the
infrastructure schemas (`IfcSharedInfrastructureElements`, `IfcRailDomain`,
`IfcRoadDomain`, `IfcPortsAndWaterwaysDomain`), which do not exist in IFC2x3 or
IFC4. The schema lists in this skill are the IFC4.3 set ; see
`references/methods.md` for the version-by-version differences.

## Decision Trees

### DT1 : Which layer does an entity belong to?

```
Open the entity's lexical page in the official IFC documentation.
Read the breadcrumb / "Table" heading : it names the schema (e.g. "5.1 IfcKernel").
  |
  +-- Schema name ends in "Resource"            -> Resource layer (Chapter 8)
  +-- Schema is IfcKernel or *Extension         -> Core layer (Chapter 5)
  +-- Schema name starts with "IfcShared"       -> Interoperability layer (Chapter 6)
  +-- Schema name ends in "Domain"              -> Domain layer (Chapter 7)
```

ALWAYS read the layer from the schema name, NEVER guess it from the entity name.
`IfcWall` lives in `IfcSharedBldgElements` (Interoperability), not in a "wall"
schema. `IfcElement` lives in `IfcProductExtension` (Core). `IfcRoot` lives in
`IfcKernel` (Core).

### DT2 : May schema A reference schema B?

```
Determine the layer of A and the layer of B (use DT1).
  |
  +-- layer(B) is BELOW layer(A)        -> ALLOWED (reference points downward)
  +-- layer(B) is the SAME as layer(A)  -> ALLOWED (sideways within a layer)
  +-- layer(B) is ABOVE layer(A)        -> FORBIDDEN : violates the ladder principle
```

A Domain schema may reference Core and Resource ; the Core may reference
Resource ; a Resource schema may reference only other Resource schemas. A
Resource schema referencing a Core entity is invalid IFC architecture.

### DT3 : Does this entity carry a GlobalId?

```
Determine the entity's layer (use DT1).
  |
  +-- Core / Interoperability / Domain  -> YES : it has GlobalId (inherits IfcRoot)
  +-- Resource                          -> NO  : resource entities have no GlobalId
```

If a Resource-layer instance appears to need its own identity, the model is
wrong : a Resource instance is shared by reference from a higher-layer entity
that does carry the GlobalId. See `references/anti-patterns.md`.

## Patterns

### Pattern 1 : Locate any entity's layer before using it

ALWAYS establish the layer of an entity before writing code that creates or
references it. The layer tells you immediately whether the entity has a
GlobalId, whether it can be referenced from where you are, and which official
documentation chapter defines it.

```
Task : place an IfcWall and give it a geometric representation.
  IfcWall                  -> IfcSharedBldgElements   -> Interoperability layer -> has GlobalId
  IfcProductDefinitionShape-> IfcRepresentationResource-> Resource layer        -> no GlobalId
  IfcExtrudedAreaSolid     -> IfcGeometricModelResource-> Resource layer        -> no GlobalId
Conclusion : the wall owns identity ; the geometry is shared resource data
referenced downward from the wall.
```

### Pattern 2 : Apply the ladder principle before adding any reference

When designing or extending a model, ALWAYS check the reference direction.

```
Adding a reference from entity A to entity B :
  1. Find layer(A) and layer(B) with DT1.
  2. If layer(B) is at or below layer(A) : the reference is sound.
  3. If layer(B) is above layer(A) : STOP. Redesign so the higher-layer entity
     holds the reference and points downward instead.
```

A worked example : a Resource-layer material must not point "up" to the wall
that uses it. The wall (Interoperability layer) points down to the material
through an `IfcRelAssociatesMaterial` relationship. The arrow always runs from
the higher layer to the lower layer.

### Pattern 3 : Test GlobalId presence from the layer, not from the file

NEVER assume an entity has a GlobalId because it appears in a `.ifc` file.
Determine GlobalId presence from the layer (RULE 2, DT3).

```
#41=IFCWALL('1a2B3c...',#5,$,$,$,#90,#120,$,$);   -> first field is GlobalId : Core+ entity
#90=IFCLOCALPLACEMENT(#88,#89);                     -> no GlobalId field : Resource entity
#89=IFCAXIS2PLACEMENT3D(#87,$,$);                   -> no GlobalId field : Resource entity
```

The first positional attribute of a Core / Interoperability / Domain instance is
its `GlobalId`. Resource instances have no such field.

### Pattern 4 : Treat EXPRESS as the source of truth

When the question is "what attributes does this entity have" or "what is valid",
ALWAYS answer from the EXPRESS schema, NEVER from a serialized file.

```
A serialized .ifc / .ifcXML / .ifcJSON file omits :
  - DERIVE attributes  (computed, recomputed by the reader)
  - INVERSE attributes (back-references, rebuilt by indexing forward references)
Only the EXPRESS schema lists every attribute. Encodings carry explicit
attributes only.
```

To convert between encodings, map both to the same EXPRESS model. The model
(entities, explicit attributes, references) is preserved ; the byte-level file
is not. See the cross-referenced syntax skills.

### Pattern 5 : Map documentation chapters to layers

When reading the official IFC4 or IFC4.3 documentation, ALWAYS use the chapter
number to know the layer.

```
Chapter 5  -> Core data schemas               (Core layer)
Chapter 6  -> Shared element data schemas      (Interoperability layer)
Chapter 7  -> Domain specific data schemas     (Domain layer)
Chapter 8  -> Resource definition data schemas (Resource layer)
```

Note the ordering : Chapter 8 (Resource) is the lowest layer despite the highest
chapter number. NEVER infer layer rank from chapter rank.

## Reference Links

- `references/methods.md` : verbatim layer definitions, complete member-schema
  lists per layer (Core 4, Shared 6, Domain 11, Resource 21), the `IfcRoot`
  top-of-tree structure, the GlobalId rule, and version-by-version differences.
- `references/examples.md` : worked classifications, ladder-principle checks,
  GlobalId checks, and EXPRESS-as-source-of-truth reasoning.
- `references/anti-patterns.md` : the upward reference, the missing-GlobalId
  surprise, editing an encoding as if it were the schema, and chapter-rank
  confusion, each with why it fails.

### Cross-references to other skills

- `ifc-syntax-express` : the EXPRESS language itself (TYPE, ENTITY, SELECT,
  SUBTYPE, DERIVE, INVERSE, WHERE, aggregations).
- `ifc-core-entity-hierarchy` : the inheritance tree below `IfcRoot`
  (`IfcObjectDefinition`, `IfcObject`, `IfcProduct`, `IfcElement`, and the
  type-versus-occurrence model).
- `ifc-core-standards-overview` : ISO 16739-1, buildingSMART, openBIM, the
  certification and validation ecosystem.

### Official sources

- IFC4.3 schema architecture : https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/content/introduction.htm
- IFC4.3 documentation chapters : https://ifc43-docs.standards.buildingsmart.org/
- `IfcRoot` (Core, IfcKernel) : https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcRoot.htm
- IFC2x3 IfcKernel : https://standards.buildingsmart.org/IFC/RELEASE/IFC2x3/TC1/HTML/ifckernel/ifckernel.htm