# Ifc Core Version Evolution

> Use when you need to know which IFC version added a feature, what changed between IFC2x3, IFC4, and IFC4.3, or how to handle an entity that was renamed, deprecated, or removed across versions. Prevents using an entity name from the wrong schema (the file-breaking IfcBuildingElement to IfcBuiltElement rename), assuming an IFC4 file is valid as IFC4.3, and treating IFC5 or IFCx as production-ready. Covers the full version ledger (IFC2x3 TC1, IFC4 ADD2 TC1, IFC4.1, IFC4.2, IFC4.3 ADD2, IFC5, IFCx), the IFC2x3-to-IFC4 and IFC4-to-IFC4.3 additions, the hard renames and breaking changes, the deprecated-entity inventory, and the IFC5 / IFCx next generation. Keywords: IFC version, IFC2x3, IFC4, IFC4.3, IFC5, IFCx, version evolution, breaking change, deprecated entity, IfcBuildingElement renamed IfcBuiltElement, IfcWallStandardCase deprecated, StandardCase removed, FILE_SCHEMA, schema identifier, which version added tessellation, entity not found, unknown entity, file will not open in newer tool, IFC4 vs IFC4.3 differ

- Skill: `impertio-studio/ifc-core-version-evolution` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add impertio-studio/ifc-core-version-evolution`
- Raw SKILL.md: https://api.skillmd.com/api/skills/impertio-studio/ifc-core-version-evolution/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: Impertio-Studio (https://skillmd.com/u/impertio-studio)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/impertio-studio/ifc-core-version-evolution

---


# IFC Core : Version Evolution

IFC has evolved across four published schema generations (IFC2x3, IFC4, the
withdrawn IFC4.1 / IFC4.2 stepping-stones, and IFC4.3) plus the in-development
IFC5 / IFCx. Each step added entities and, critically, introduced renames and
deprecations that break files across versions. This skill is the reference for
*what changed and when*. It is the read-side counterpart to
`ifc-impl-version-migration`, which covers the *how-to* of migrating a model.

## Quick Reference

### Version ledger

| Version | Schema identifier | ISO publication | Released | Status |
|---------|-------------------|-----------------|----------|--------|
| IFC2x3 TC1 | `IFC2X3` | ISO/PAS 16739:2005 | 2007-07 | Official (legacy) |
| IFC4 | `IFC4` | ISO 16739:2013 | 2013-02 | Retired |
| IFC4 ADD2 TC1 | `IFC4` | ISO 16739-1:2018 | 2017-10 | Official |
| IFC4.1 | `IFC4X1` | none | 2018-06 | Withdrawn |
| IFC4.2 | `IFC4X2` | none | 2019-04 | Withdrawn |
| IFC4.3 ADD2 | `IFC4X3` / `IFC4X3_ADD2` | ISO 16739-1:2024 | 2024-04 | Official (current) |
| IFC5 / IFCx | none | none | unreleased | In development |

ALWAYS target one of the three Official versions : **IFC2x3 TC1**,
**IFC4 ADD2 TC1**, **IFC4.3 ADD2**. NEVER target IFC4.1 or IFC4.2 : both are
Withdrawn stepping-stones, fully superseded by IFC4.3. NEVER target IFC5 or IFCx
for production : both are in development and subject to change.

Full per-release ledger with release purposes : `references/methods.md`.

### The hard renames (the breaking-change shortlist)

These changes mean a file written for one version is NOT automatically valid in
another. ALWAYS use the name that matches the file's `FILE_SCHEMA`.

| Item | IFC2x3 | IFC4 | IFC4.3 |
|------|--------|------|--------|
| Built-element supertype | `IfcBuildingElement` (abstract) | `IfcBuildingElement` (abstract) | `IfcBuiltElement` (non-abstract) |
| System supertype | `IfcSystem` | `IfcSystem` / `IfcBuildingSystem` | `IfcBuiltSystem` (`IfcBuildingSystem` deprecated) |
| `IfcRoot.OwnerHistory` | mandatory | optional | optional |
| `IfcSpace` interior/exterior | `InteriorOrExteriorSpace` attribute | `PredefinedType` (`IfcSpaceTypeEnum`) | `PredefinedType` |
| `IfcMonetaryUnit.Currency` | `IfcCurrencyEnum` | `IfcLabel` | `IfcLabel` |
| `IfcSIUnit.Dimensions` | DERIVED | explicit attribute | explicit attribute |
| Civil elements | n.a. | `IfcCivilElement` | `IfcCivilElement` deprecated |

`IfcClassification.Location` was renamed `Specification` in a later IFC4 edition.
See `references/methods.md` for the complete rename and attribute-change table.

### IFC2x3 to IFC4 : key additions

- **Tessellated geometry** : `IfcTessellatedFaceSet`, `IfcTriangulatedFaceSet`,
  and the `RepresentationType` value `'Tessellation'`. Absent in IFC2x3.
- **Advanced geometry** : NURBS, advanced B-rep, B-spline surfaces, new
  elementary surfaces and intersection curves (IFC4 ADD2).
- **4D / 5D workflows** : enhanced scheduling and cost support.
- **mvdXML and concept templates** : the technology for defining Model View
  Definitions, plus integrated ifcXML4.
- **Material refinements** : `IfcMaterialConstituentSet`,
  `IfcMaterialProfileSet`; the material-property subtypes
  (`IfcMechanicalMaterialProperties` and siblings) were deleted and consolidated
  into `IfcMaterialProperties`.

### IFC4 to IFC4.3 : key additions

- **Infrastructure domains** : Railways, Roads, Ports, Waterways, plus
  geotechnics and earthworks.
- **62 new occurrence entities** with corresponding type entities, and
  **294 new predefined types**, largely for infrastructure.
- **Alignment and Linear Placement** (per ISO 19148) and `IfcFacility` /
  `IfcFacilityPart`, introduced through IFC4.1 / IFC4.2 and consolidated in 4.3.
- **Facility restructuring** : `IfcBuilding` became a subtype of `IfcFacility`
  and `IfcBuildingStorey` a subtype of `IfcFacilityPart`. The inheritance chain
  itself moved, not just new entities added.

## Decision Trees

### Is a feature or entity available in my target version?

```
Which feature?
|
+-- Tessellation (IfcTriangulatedFaceSet, IfcPolygonalFaceSet)
|   --> IFC4 and IFC4.3 only. NEVER in IFC2x3 (use IfcFacetedBrep there).
|
+-- NURBS / advanced B-rep (IfcAdvancedBrep, IfcBSplineSurface)
|   --> IFC4 and IFC4.3 only. NEVER in IFC2x3.
|
+-- Infrastructure (IfcRoad, IfcRailway, IfcBridge, IfcAlignment,
|   IfcLinearPlacement, IfcCourse, IfcKerb, IfcRail)
|   --> IFC4.3 only. NEVER in IFC2x3 or IFC4.
|
+-- IfcFacility / IfcFacilityPart
|   --> IFC4.3 (introduced via IFC4.2). NEVER in IFC2x3 or IFC4.
|
+-- Buildings, walls, slabs, properties, materials, classifications
    --> All versions (with the renames in the table above).
```

### How to handle a version-specific entity name

```
Read the file's FILE_SCHEMA in the STEP header.
|
+-- FILE_SCHEMA = 'IFC2X3'
|   --> Use IfcBuildingElement, IfcBuildingSystem.
|       OwnerHistory is mandatory on every IfcRoot subtype.
|
+-- FILE_SCHEMA = 'IFC4'
|   --> Use IfcBuildingElement (still abstract), IfcBuildingSystem.
|       OwnerHistory is optional.
|
+-- FILE_SCHEMA = 'IFC4X3' or 'IFC4X3_ADD2'
    --> Use IfcBuiltElement (non-abstract), IfcBuiltSystem.
        IfcCivilElement and IfcBuildingSystem are deprecated.
```

### Additive change or breaking change?

```
Did the version add a NEW entity / type / property?
|
+-- YES, and nothing existing was renamed or removed
|   --> ADDITIVE. An older file stays valid; the new feature is
|       simply unavailable to older readers.
|
+-- An entity was RENAMED, made abstract/non-abstract, or REMOVED
|   --> BREAKING. The file is NOT valid across the boundary without
|       migration. Route to ifc-impl-version-migration.
|
+-- An attribute changed (DERIVED <-> explicit, type changed,
    cardinality changed, reordered)
    --> BREAKING at the attribute level. A blind attribute copy fails.
        Route to ifc-impl-version-migration.
```

## Patterns

### Pattern : Detect a file's schema version before anything else

ALWAYS read `FILE_SCHEMA` from the STEP header before interpreting any entity.
The header's third clause names the exact schema the file claims to follow :

```
FILE_SCHEMA(('IFC4'));
```

ALWAYS branch entity-name choices on that value. NEVER assume a `.ifc` file is
IFC4 : a file with a `.ifc` extension can be any of IFC2x3, IFC4, or IFC4.3.
NEVER trust the file extension or a viewer's label over `FILE_SCHEMA`.

For ifcXML the schema is named in the document's schema reference instead of
`FILE_SCHEMA`; for ifcJSON it is a metadata key. See `ifc-syntax-step-physical-file`.

### Pattern : Honour the hard renames

`IfcBuildingElement` was **renamed to `IfcBuiltElement` and made non-abstract**
in IFC4.3. The official IFC4.3 CHANGE note states verbatim : *"The entity has
been renamed from IfcBuildingElement and made non abstract."* The old name
`IfcBuildingElement` returns HTTP 404 in the IFC4.3 lexical documentation.

- ALWAYS use `IfcBuildingElement` for IFC2x3 and IFC4 content.
- ALWAYS use `IfcBuiltElement` for IFC4.3 content.
- NEVER write `IfcBuildingElement` into an `IFC4X3` file : it is a file-breaking
  error, not a harmless alias.
- In IFC4.3, `IfcBuiltElement` is non-abstract and MAY be instantiated directly
  when no concrete subtype fits. In IFC4 and IFC2x3, `IfcBuildingElement` is
  abstract and NEVER instantiated directly.

The same discipline applies to `IfcBuildingSystem` to `IfcBuiltSystem`
(IFC4.3), and to `IfcSpace.InteriorOrExteriorSpace` becoming `PredefinedType`
in IFC4. The full table is in `references/methods.md`.

### Pattern : Treat deprecated entities as import-only

An entity marked **Deprecated** still exists in the schema and a reader MUST
still parse it, but a writer MUST NOT emit it.

- `IfcWallStandardCase` is **Deprecated since IFC4 ADD2 TC1** (schema version
  4.0.2.1). Its IFC4 changelog entry reads *"Status changed to Deprecated"* and
  the documentation states *"This definition may be imported, but shall not be
  exported by applications."* It is **still present in IFC4.3**, still marked
  deprecated, with the note *"This definition will be removed in a future major
  release of this standard."*
- ALWAYS author plain `IfcWall` (with `IfcMaterialLayerSetUsage` for layered
  walls) instead of `IfcWallStandardCase`.
- The `*StandardCase` pattern is deprecated across element types :
  `IfcBeamStandardCase`, `IfcColumnStandardCase`, `IfcMemberStandardCase`,
  `IfcPlateStandardCase`, `IfcSlabStandardCase`, `IfcDoorStandardCase`,
  `IfcWindowStandardCase`, `IfcOpeningStandardCase`. ALWAYS annotate
  per-version : some existed in IFC4 and were removed later in the IFC4.x line.
  NEVER blanket-state "all StandardCase entities are removed in IFC4.3" :
  `IfcWallStandardCase` is still in the IFC4.3 schema as a deprecated entity.
- NEVER use `IfcBuildingElementProxy` as a spatial or void placeholder in
  IFC4.3 : the IFC4.3 CHANGE note directs use of `IfcVirtualElement` instead.

IFC4.3 deprecated **24 entities**, explicitly including `IfcBuildingElement`,
`IfcCivilElement`, and `IfcBridgePart`. The deprecated-entity inventory and the
per-version status of each `*StandardCase` entity are in `references/methods.md`.

### Pattern : Cover IFC4.1 and IFC4.2 as stepping-stones, not skips

IFC4.1 and IFC4.2 are **Withdrawn**, but they are where infrastructure support
entered the schema : IFC4.1 introduced alignment description (horizontal and
vertical) and Linear Placement per ISO 19148; IFC4.2 introduced `IfcFacility`,
`IfcFacilityPart`, `IfcBridge`, `IfcBridgePart`, `IfcBearing`, and
`IfcDeepFoundation`. These were consolidated into IFC4.3.

- NEVER describe IFC4.3 as jumping straight from IFC4 : the alignment and
  facility model matured through 4.1 and 4.2 first.
- NEVER produce or request files with `FILE_SCHEMA(('IFC4X1'))` or
  `(('IFC4X2'))` : target IFC4.3 instead.

### Pattern : Position IFC5 and IFCx as the next generation

IFC5 and IFCx are **in development and not released** : every claim about them
is a moving target and MUST be labelled as such.

- **IFC5** is the next-generation standard : a composition / layering model with
  prim-style inheritance, multi-author non-destructive layers, and **TypeSpec**
  as the schema language replacing EXPRESS.
- **IFCx** is the JSON data encoding of the IFC5 generation (the `.ifcx`
  extension). It uses a node-and-attribute graph and is **not** a STEP format.
- IFC5 / IFCx break from STEP entirely : no `ISO-10303-21` syntax, no
  `FILE_SCHEMA` header.
- ALWAYS state "IFC5 / IFCx are in development, subject to change" when
  referencing them. NEVER present an IFC5 entity name or an IFCx structure as
  stable. NEVER recommend IFC5 / IFCx for a production exchange.

For the architecture of these, see `ifc-core-ifc5-architecture` and
`ifc-core-ifcx-architecture`.

### Pattern : Decide whether a change is the migration skill's job

This skill is **reference** : what changed and when. The moment the task is
*transforming a model from one version to another*, route to
`ifc-impl-version-migration`, which covers the two-stage entity-then-attribute
remap, the lossy nature of migration, and why upgrade is more stable than
downgrade. NEVER attempt an attribute-level remap from this skill alone.

## Reference Links

- `references/methods.md` : full release ledger, complete rename and
  attribute-change table, deprecated-entity inventory, `*StandardCase`
  per-version status, `FILE_SCHEMA` identifier table.
- `references/examples.md` : worked scenarios : reading `FILE_SCHEMA`,
  resolving an entity name per version, classifying a change as additive or
  breaking, spotting a wrong-version entity.
- `references/anti-patterns.md` : the version mistakes this skill prevents,
  each with the reason it fails.

### Official sources

- IFC release notes : https://technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/ifc-release-notes/
- IFC schema specifications ledger : https://technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/
- IFC4.3 documentation : https://ifc43-docs.standards.buildingsmart.org/
- IfcBuiltElement (IFC4.3) : https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcBuiltElement.htm
- IFC4.3 introduction (backward incompatibilities) : https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/content/introduction.htm
- IFC5 development : https://github.com/buildingSMART/IFC5-development

### Related skills

- `ifc-core-standards-overview` : what IFC is and which version to target.
- `ifc-impl-version-migration` : how to migrate a model between versions.
- `ifc-errors-version-mismatch` : diagnosing wrong-version-entity errors.
- `ifc-core-ifc5-architecture` : the IFC5 composition model.
- `ifc-core-ifcx-architecture` : the IFCx JSON encoding.