| name | ifc-core-version-evolution |
| description | 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 difference, what changed between IFC versions, how do I upgrade an IFC file, infrastructure entities.
|
| license | MIT |
| compatibility | Designed for Claude Code. Requires IFC IFC2x3, IFC4, IFC4.3, IFC5, IFCx. |
| metadata | {"author":"OpenAEC-Foundation","version":"1.0"} |
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
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.
