| name | ifc-core-ifc5-architecture |
| description | Use when asked about IFC5, the next generation of IFC, why IFC5 drops STEP, the composition or layering model, multi-author non-destructive editing, the .ifcx JSON format, or how IFC5 differs from IFC4.3. Prevents teaching IFC5 as a stable production target, inventing IFC5 entity or attribute names, confusing IFC5 the standard with IFCx the format, claiming IFC5 uses EXPRESS or STEP, and assuming the IFC4.3 objectified relationship pattern carries over. Covers the IN DEVELOPMENT status, the tree-based composition model, prim-style inheritance, multi-author layering, space boundaries as objects, TypeSpec as the schema language, external bSDD references, and what problem IFC5 solves versus IFC4.3. Keywords: IFC5, IFC 5, ifcx, .ifcx, composition, layering, multi-author, non-destructive editing, TypeSpec, tsp, prim, inheritance, JSON schema, ifcx.dev, bSDD, next-generation IFC, is IFC5 ready, can I use IFC5 in production, why does IFC5 drop STEP, what is the difference between IFC5 and IFC4, how does IFC5 work, IFC5 has no relationships, what is an ifcx file.
|
| license | MIT |
| compatibility | Designed for Claude Code. Requires IFC IFC5. |
| metadata | {"author":"OpenAEC-Foundation","version":"1.0"} |
IFC5 Architecture
IN DEVELOPMENT : IFC5 is NOT a released standard. The schema, the file
format, the entity names, and every concept in this skill are preliminary
and WILL change. The official buildingSMART/IFC5-development repository
states the examples are "preliminary and represent a direction of working
for IFC 5" and are "for educational and testing purposes only. They are
not suitable for production use without further refinement." NEVER use
IFC5 for a production deliverable. NEVER teach IFC5 as a stable target.
For production work use IFC4.3 (ISO 16739-1:2024) or IFC2x3.
This skill explains the architectural direction of IFC5 so that an IFC5
question gets an accurate, suitably-hedged answer. It covers the
composition model, multi-author layering, the .ifcx JSON format,
TypeSpec, and how IFC5 departs from IFC4.3. Every claim is verified
against the buildingSMART/IFC5-development repository (verified
2026-05-20).
Quick Reference
Status : preliminary, not ratified
| Aspect | State (verified 2026-05-20) |
|---|
| Standard status | IN DEVELOPMENT. Not ratified. Not released. |
| Source of truth | github.com/buildingSMART/IFC5-development |
| What the repo contains | "early-stage, preliminary examples", a viewer, a TypeSpec schema |
| Production use | Explicitly NOT suitable for production |
| Schema stability | "IFC 5 is still evolving"; schema changes expected |
| Replaces IFC4.3? | Not yet. IFC4.3 remains the current released standard. |
ALWAYS state the IN DEVELOPMENT status when answering any IFC5 question.
NEVER present an IFC5 detail as final.
IFC5 versus IFCx
IFC5 and IFCx are not synonyms.
IFC5 names the conceptual standard generation: the schema, the
composition semantics, the modular domain definitions.IFCx names the concrete data encoding: the JSON file format, the
.ifcx file extension, and the ifcx.dev schema publication host.
This skill covers IFC5 the architecture. The .ifcx format detail lives
in ifc-core-ifcx-architecture.
The five architectural departures from IFC4.3
| # | IFC4.3 (released) | IFC5 (in development) |
|---|
| 1 | STEP / ISO 10303-21 Part 21 encoding | JSON encoding, .ifcx extension. "There will not be STEP syntax in IFC 5." |
| 2 | EXPRESS schema language | TypeSpec schema language (.tsp source) |
| 3 | One monolithic authoritative file snapshot | Tree-based composition, multi-author non-destructive layers |
| 4 | Objectified IfcRel* relationships | Composition and inheritance; space boundaries are objects, not relationships |
| 5 | Monolithic schema, all domains in one spec | Modular domain schemas, external bSDD references |
Verified vocabulary
These terms are verified against the IFC5-development repository:
composition, layer, children, inherits, attributes, .ifcx, TypeSpec,
ifcx.tsp. The label "USD" / "prim" is widely reported as the lineage of
the composition mechanic but is NOT confirmed by an official IFC5 source;
describe the mechanic (composition, layering, inheritance), NEVER assert a
USD dependency. Likewise NEVER assert RDF or JSON-LD as the IFCx
serialization: it is not verified.
Decision Trees
Should I use IFC5 for this task?
What is the task?
|
+- A production model, a real deliverable, a client exchange
| -> NEVER IFC5. Use IFC4.3 (ISO 16739-1:2024) or IFC2x3.
| IFC5 is not released and has no certified tooling.
|
+- Experimenting with the IFC5 composition concept, building a
| prototype reader, contributing to buildingSMART
| -> IFC5 is acceptable, against the IFC5-development examples ONLY.
| Treat every detail as provisional. Pin the exact repo commit.
|
+- Answering a question about where IFC is heading
-> Explain IFC5 as a direction, always with the IN DEVELOPMENT
caveat. See the patterns below.
An IFC4.3 concept : does it carry to IFC5?
Which IFC4.3 concept?
|
+- A STEP physical file, #-numbered instances, EXPRESS
| -> Does NOT carry. IFC5 is JSON, no STEP, no EXPRESS.
|
+- An IfcRel* objectified relationship
| -> Does NOT carry as-is. IFC5 uses composition and inheritance.
| Space boundaries become objects, not relationships.
|
+- Entity semantics (a wall, a site, a project as concepts)
| -> The CONCEPTS carry. The IFC5 examples still show
| IfcProject, IfcSite, IfcBuilding as composed nodes. The
| encoding around them is what changes.
|
+- The IFC GUID, property sets, classifications
-> Direction is unsettled. Properties appear as node attributes
in the examples. NEVER assume the IFC4.3 encoding; verify
against the current IFC5-development examples.
Patterns
The snippets below are conceptual, drawn from the public IFC5-development
examples. Treat the exact field names as provisional. Full structure notes
are in references/methods.md; complete example excerpts are in
references/examples.md.
Pattern: the composition tree
IFC5 replaces the monolithic instance graph with a tree the consumer must
assemble. Objects (nodes) reference children and inherit properties. The
IFC5-development FAQ states an implementation "needs to compose the scene
from the available data" rather than read a pre-resolved graph.
A node is a JSON object identified by a path (a UUID). A node may carry:
children : a map of named references to child node paths.inherits : a map of references the node inherits attributes from.attributes : a map of property keys to values.
The example hierarchy follows IfcProject to IfcSite to IfcBuilding
and onward, but each level is a composed node, not a STEP instance.
ALWAYS describe IFC5 reading as "compose the tree, then resolve
inheritance". NEVER describe it as parsing a flat instance list.
Pattern: multi-author non-destructive layering
This is the headline IFC5 mechanic and has NO IFC2x3 or IFC4 equivalent.
A model is built from layers. A second author adds a file as a new layer;
that layer contributes new or overriding attribute values WITHOUT
rewriting the first author's data.
The verified add-firerating example: the base file hello-wall.ifcx
defines a wall node. A separate layer file
hello-wall-add-fire-rating-30.ifcx references the SAME node path and
adds only a FireRating attribute. Per the FAQ, the new layer "will
provide the new value (while the original ones from the first author are
also still in the original dataset)".
Consequence: an IFC5 model is a STACK of layer files, not one file.
NEVER assume a single .ifcx file is the complete model. ALWAYS treat the
ordered set of layers as the model. See references/examples.md.
Pattern: space boundaries as objects
In IFC4 a space boundary is the objectified relationship
IfcRelSpaceBoundary. In IFC5 the hello-wall example "contains an
example of a space boundary that is defined as an object instead of a
relationship", and the FAQ states "the intent is to keep it that way in
IFC 5".
This is a concrete, citable IFC5-versus-IFC4 difference. When asked how
IFC5 handles relationships, ALWAYS give this as the worked example: the
relationship-as-object move generalizes the IFC4 IfcRel* pattern away.
Pattern: TypeSpec schema and external references
The IFC5 schema is NOT written in EXPRESS. It is written in TypeSpec
(Microsoft's API definition language), with .tsp source files
(ifcx.tsp, ifcx-quantity-kinds.tsp) in the /schema directory of the
IFC5-development repo. JSON Schema is generated from the TypeSpec source
and published at https://ifcx.dev/@standards.buildingsmart.org/ifc/.
IFC5 also references content outside the core schema: the examples point
to classes published in bSDD (the buildingSMART Data Dictionary). Domain
semantics move partly out of the monolithic schema.
NEVER say IFC5 uses EXPRESS. NEVER say the IFC5 schema is monolithic.
Pattern: what problem IFC5 solves
When asked WHY IFC5 exists, give the four IFC4.3 limitations it targets:
- The monolithic file is hard to edit collaboratively: every change
rewrites the whole snapshot. IFC5 layering fixes this.
- STEP Part 21 is an ageing, AEC-specific encoding with no mainstream
tooling. IFC5 JSON fixes this.
- The
IfcRel* objectification is verbose and unfamiliar outside AEC.
IFC5 composition and inheritance address this.
- The schema is hard to extend per domain. IFC5 modular domain schemas
and external bSDD references address this.
ALWAYS pair this with the caveat that none of it is finalised.
Anti-Patterns
Full detail with the failure mechanism is in references/anti-patterns.md.
The five that matter most:
- Recommending IFC5 for a production model. It is not released and has no
certified import or export.
- Inventing IFC5 entity, attribute, or schema names. The schema is not
final; a guessed name is wrong by construction.
- Saying IFC5 uses EXPRESS or STEP. It uses TypeSpec and JSON; "There
will not be STEP syntax in IFC 5."
- Treating one
.ifcx file as the whole model. An IFC5 model is an
ordered stack of composition layers.
- Carrying the IFC4.3
IfcRel* pattern into IFC5 unchanged. IFC5 uses
composition and inheritance; space boundaries become objects.
Reference Links
This skill
references/methods.md : the IFC5 architectural concepts, the .ifcx
top-level structure, the node fields, and the TypeSpec toolchain.references/examples.md : verified excerpts from the IFC5-development
example files, with the layering mechanic shown end to end.references/anti-patterns.md : failure modes and their root causes.
Related skills
ifc-core-ifcx-architecture : the .ifcx JSON format in detail.ifc-core-version-evolution : the IFC2x3 to IFC4 to IFC4.3 to IFC5
timeline and the cross-version rename ledger.ifc-core-relationships : the IFC4.3 IfcRel* pattern that IFC5
composition departs from.ifc-impl-library-selection : which libraries can read which IFC
generation.
Official sources
