# Ifc Core Ifc5 Architecture

> 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, I

- Skill: `impertio-studio/ifc-core-ifc5-architecture` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add impertio-studio/ifc-core-ifc5-architecture`
- Raw SKILL.md: https://api.skillmd.com/api/skills/impertio-studio/ifc-core-ifc5-architecture/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-ifc5-architecture

---


# 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:

1. The monolithic file is hard to edit collaboratively: every change
   rewrites the whole snapshot. IFC5 layering fixes this.
2. STEP Part 21 is an ageing, AEC-specific encoding with no mainstream
   tooling. IFC5 JSON fixes this.
3. The `IfcRel*` objectification is verbose and unfamiliar outside AEC.
   IFC5 composition and inheritance address this.
4. 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

- IFC5-development repo: https://github.com/buildingSMART/IFC5-development
- IFC5 README: https://raw.githubusercontent.com/buildingSMART/IFC5-development/main/README.md
- IFC5 Examples FAQ: https://raw.githubusercontent.com/buildingSMART/IFC5-development/main/Examples_FAQ.md
- IFC5 schema readme: https://raw.githubusercontent.com/buildingSMART/IFC5-development/main/schema/readme.md
- IFC5 viewer: https://ifc5.technical.buildingsmart.org/viewer/
- IFCx schema host: https://ifcx.dev/@standards.buildingsmart.org/ifc/