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
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
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.
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.
