SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsifc-core-ifc5-architecture

ifc-core-ifc5-architecture

Coding & development

View repository

Updated 10-16 05:48

About this skill

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