Ifc Core Ifcx Architecture

IFC Core : IFCx Architecture

IN DEVELOPMENT : subject to change. IFCx is not a released or ratified specification. It is developed in the public buildingSMART/IFC5-development repository, whose own examples are explicitly labelled "preliminary and will be updated." Every fact in this skill is a moving target. NEVER teach IFCx as a stable target and NEVER recommend it for a production exchange.

IFCx is the JSON data encoding of the IFC5 generation : the .ifcx file format and its ifcx.dev schema host. This skill explains what an .ifcx file is, how its composition graph works, and how IFCx relates to IFC5. It is the format-side counterpart to ifc-core-ifc5-architecture, which covers the IFC5 standard.

Quick Reference

What IFCx is

• IFCx is the JSON data encoding of the IFC5 generation. An IFCx file is, in the words of the IFC5 examples, "a JSON file, shared as .ifcx."
• The file extension is .ifcx.
• IFCx data is organised into objects delimited by { and } that "hold the data." These objects can be shared across multiple files, or within one file.
• Objects can refer to children and can inherit : "This is how you construct a tree." IFCx is a node-and-attribute composition graph.
• A consumer does NOT read a pre-resolved model : "An implementation needs to compose the scene from the available data."
• The JSON Schema for IFCx is published at https://ifcx.dev/@standards.buildingsmart.org/ifc/.
• The schema source is written in TypeSpec (.tsp files); the JSON Schema is generated from that TypeSpec source.
• ifcx.dev carries the tagline "The schema.org for IFC", signalling a web-native, semantic, graph-shaped data direction.

What IFCx is NOT

• IFCx is NOT a STEP format. The IFC5 examples state plainly : "There will not be STEP syntax in IFC 5." An .ifcx file has no ISO-10303-21 wrapper, no HEADER section, and no FILE_SCHEMA clause.
• IFCx is NOT finalised. The specification is in development; schema, objects, and structure will change before any release.
• IFCx is NOT the same thing as IFC5. IFC5 is the standard generation; IFCx is its file format. See the decision tree below.
• IFCx is NOT confirmed to be RDF or JSON-LD. The graph shape is verified; the specific linked-data serialisation is not. See the labelling pattern.

IFC5 versus IFCx

ALWAYS use "IFC5" for the conceptual standard and "IFCx" / .ifcx for the concrete file format. NEVER treat the two terms as interchangeable : they are routinely conflated and the distinction is the point of having two skills.

Decision Trees

Is IFCx the right target for this task?

Is this a production exchange another tool must reliably consume?
|
+-- YES --> NEVER use IFCx. It is in development and not finalised.
|           Target a released IFC version : IFC2x3 TC1, IFC4 ADD2 TC1,
|           or IFC4.3 ADD2 (STEP / ifcXML / ifcJSON). See
|           ifc-core-version-evolution.
|
+-- NO, this is research or prototyping against the IFC5-development repo
    --> IFCx is acceptable, WITH the explicit caveat that the .ifcx
        structure and schema will change before release.

Which term applies : IFC5 or IFCx?

What is being described?
|
+-- The composition / layering model, modular domain schemas, the
|   standard generation as a concept
|   --> "IFC5". See ifc-core-ifc5-architecture.
|
+-- A concrete .ifcx file, the JSON encoding, the ifcx.dev schema host
    --> "IFCx". This skill.

How to approach an .ifcx file

You have a file with the .ifcx extension.
|
+-- Parse it as JSON. It is a JSON document, not a STEP file.
|   NEVER look for ISO-10303-21 / HEADER / FILE_SCHEMA : they are absent.
|
+-- Read the data objects ({ ... }) and their child / inherit references.
|
+-- Compose the scene : resolve the composition tree yourself. The file
|   is not a pre-resolved graph.
|
+-- Validate against the JSON Schema at
    ifcx.dev/@standards.buildingsmart.org/ifc/ , accepting that the
    schema is a development version.

Patterns

Pattern : Treat IFCx as in-development at all times

ALWAYS state "IFCx is in development, subject to change" whenever IFCx is referenced. The IFC5-development examples are explicitly "preliminary and will be updated."

• NEVER present an .ifcx structure, key name, or object shape as stable.
• NEVER recommend IFCx for a real project deliverable.
• NEVER compare an IFCx detail to a released IFC version as if both were fixed : one side of that comparison is unfinished.

For a production exchange, route to ifc-core-version-evolution and target a released version.

Pattern : Distinguish IFCx (format) from IFC5 (standard)

IFC5 and IFCx are developed together but name different things. ALWAYS keep them separate :

• "IFC5" is the standard generation : composition, layering, inheritance semantics, modular domain schemas. Architecture detail lives in ifc-core-ifc5-architecture.
• "IFCx" is the data format : the .ifcx JSON files and the ifcx.dev schema host.

NEVER write "the IFC5 file" when you mean an .ifcx file, and NEVER write "the IFCx standard" when you mean the IFC5 generation. When a statement is about bytes on disk, it is IFCx; when it is about the model concept, it is IFC5.

Pattern : Read the node-and-attribute composition graph

An .ifcx file is a JSON document of data objects. ALWAYS read it as a composition graph, not as a flat instance list :

• Data objects are delimited by { and } and "hold the data."
• An object can reference children and can inherit from another object. Together these construct a tree.
• Objects can be shared across multiple files, or reused within one file.
• The consuming application composes the scene from the available data : it resolves the child and inheritance references itself.

ALWAYS resolve the composition before interpreting a final value : a property may be defined on an inherited object or contributed by a layer, not stated inline. NEVER assume a single object carries the fully resolved state.

This composition / layering model is the IFC5 mechanic; for the multi-author layering detail (the non-destructive add-firerating example), see ifc-core-ifc5-architecture.

Pattern : Expect no STEP syntax in an .ifcx file

ALWAYS parse an .ifcx file as JSON. The IFC5 examples state : "There will not be STEP syntax in IFC 5."

• An .ifcx file has NO ISO-10303-21; wrapper, NO HEADER section, NO FILE_DESCRIPTION / FILE_NAME / FILE_SCHEMA, and NO #id=ENTITY(...) instance lines.
• NEVER apply STEP Physical File parsing logic to an .ifcx file.
• If an IFC5 example contains an originalStepInstance field, that field exists ONLY to show the relation to the original .ifc SPFF file in the example set. It is an example artefact, NOT a structural requirement of IFCx. NEVER treat originalStepInstance as a mandatory IFCx field.

In the IFC5 example set, .ifcx JSON files are paired with .ifc STEP files in IFC4 / IFC4.3 format purely for demonstration.

Pattern : Resolve the IFCx schema from the @org/path namespace

The IFCx JSON Schema is published at https://ifcx.dev/@standards.buildingsmart.org/ifc/.

• The @organization/path form is a package-registry / linked-data style addressing scheme : the @standards.buildingsmart.org segment identifies the publishing organisation, and the path segment identifies the schema.
• ifcx.dev is published via GitHub Pages from the https://github.com/buildingSMART/IFCx.dev repository.
• The schema is authored in TypeSpec (.tsp source files); the JSON Schema served at ifcx.dev is generated from that TypeSpec source. TypeSpec replaces EXPRESS as the schema definition language for this generation.

ALWAYS treat the ifcx.dev schema as a development artefact : it is generated from evolving TypeSpec source and changes with the IFC5-development work.

Pattern : Label graph-data and schema.org claims carefully

ifcx.dev carries the tagline "The schema.org for IFC", and the IFCx mechanics (named objects with attributes, inheritance, composition, cross-file sharing, external references to bSDD) are consistent with a web-native, graph-shaped data direction.

• ALWAYS describe what is verified : JSON encoding, node-and-attribute objects, composition, inheritance, external references.
• NEVER assert that IFCx is RDF or uses JSON-LD : the specific linked-data serialisation is not verified against an official source.
• NEVER assert a USD (Universal Scene Description) dependency : the composition mechanic is verified, a USD lineage is not. State the mechanic, not the lineage.

When asked about the "schema.org for IFC" tagline, ALWAYS present it as a stated direction, NEVER as an implemented, finalised technology choice.

Reference Links

• references/methods.md : the IFCx fact sheet : verified properties of the .ifcx format, the schema-publication namespace, the TypeSpec toolchain, the IFC5-versus-IFCx split, and the verified-versus-unverified boundary.
• references/examples.md : worked scenarios : recognising an .ifcx file, reading the composition graph, the IFC5-versus-IFCx wording test, deciding whether IFCx applies.
• references/anti-patterns.md : the IFCx mistakes this skill prevents, each with the reason it fails.

Official sources

• IFC5 development repository : https://github.com/buildingSMART/IFC5-development
• 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
• IFCx schema host : https://ifcx.dev/
• IFCx.dev repository : https://github.com/buildingSMART/IFCx.dev

Related skills

• ifc-core-ifc5-architecture : the IFC5 standard generation (composition, layering, modular domain schemas, TypeSpec).
• ifc-core-version-evolution : how IFCx relates to the released IFC versions.
• ifc-impl-library-selection : tooling that reads IFCx, including emerging Rust tooling.