ifc-core-data-model

name	ifc-core-data-model
description	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-11, what layer is this entity, why has no GlobalId, can schema A reference schema B, how is IFC organized, IFC schema structure, where does IfcWall live, schema layers explained, "entity has no GlobalId", "upward reference rejected", "schema reference not allowed", getting started with the IFC schema, how does IFC fit together.
license	MIT
compatibility	Designed for Claude Code. Requires IFC IFC2x3,IFC4,IFC4.3.
metadata	{"author":"OpenAEC-Foundation","version":"1.0"}

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