IFC (Industry Foundation Classes) is an open, vendor-neutral data model for the built environment, standardized as ISO 16739-1. This skill establishes what IFC is, what it is NOT, which version to target, and how the buildingSMART ecosystem is organized. It is the orientation layer beneath every other IFC skill.
Quick Reference
What IFC is
- IFC is a standardized digital description of the built environment : buildings AND civil infrastructure (roads, rail, bridges, ports, waterways).
- IFC is an open, international, vendor-neutral data model, published by buildingSMART International under a Creative Commons license.
- IFC is the primary technical deliverable of buildingSMART International and the cornerstone of openBIM (interoperable, vendor-neutral building information modeling).
- IFC is registered with ISO as ISO 16739-1. The current schema (IFC4.3 ADD2) is ISO 16739-1:2024.
- The IFC4.3 schema carries over 1300 entities and types, roughly 2500 properties, and over 750 property sets. IFC is intentionally foundational : it is designed to be extended with domain-specific classes and properties.
What IFC is NOT
- IFC is NOT a single file format. IFC is a data model (an EXPRESS schema). The
.ifcfile is one encoding (STEP Physical File); ifcXML and ifcJSON are others. - IFC is NOT a runtime, application, or behavior model. It stores data; it does not execute.
- IFC is NOT a geometry kernel. It records geometry definitions; the consuming software computes, tessellates, and renders them.
- IFC is NOT a library or API. IfcOpenShell, web-ifc, xBIM, and IFC++ are libraries that read and write IFC; they are not IFC itself.
- IFC is NOT a security or permissions model. It has no access control;
OwnerHistoryrecords authorship, NEVER authorization.
The three data dimensions
IFC codifies three dimensions of built-environment data :
| Dimension | What it captures | Examples |
|---|---|---|
| Identity and semantics | names, machine-readable identifiers, object types | GlobalId, object type |
| Characteristics and attributes | physical and functional properties | material, color, thermal properties |
| Relationships | how things relate to each other | locations, connections, ownership |
These dimensions describe physical objects (columns, slabs), abstract concepts (performance, costing), processes (installation, operations), and people (owners, designers, contractors).
Version ledger (compact)
| Version | ISO publication | Status |
|---|---|---|
| IFC2x3 TC1 | ISO/PAS 16739:2005 | Official |
| IFC4 | ISO 16739:2013 | Retired |
| IFC4 ADD2 TC1 | ISO 16739-1:2018 | Official |
| IFC4.1 / IFC4.2 | none | Withdrawn |
| IFC4.3 ADD2 | ISO 16739-1:2024 | Official (current) |
| IFC5 / IFCx | none | IN DEVELOPMENT |
Full release ledger : see references/methods.md.
The three officially-supported versions
ALWAYS target one of the three versions buildingSMART certifies software for :
- IFC2x3 TC1 : the legacy interoperability baseline (ISO/PAS 16739:2005).
- IFC4 ADD2 TC1 : the modern building schema (ISO 16739-1:2018).
- IFC4.3 ADD2 : the current schema, the ONLY version covering infrastructure (ISO 16739-1:2024).
NEVER target IFC4.1 or IFC4.2 : both are Withdrawn, superseded by IFC4.3. NEVER target IFC5 or IFCx for production : both are in development and subject to change without notice.
Decision Trees
Which IFC version to target
Does the project include infrastructure
(roads, rail, bridges, ports, waterways)?
|
+-- YES --> IFC4.3 ADD2 (ISO 16739-1:2024)
| ONLY IFC4.3 models infrastructure.
|
+-- NO (buildings only)
|
+-- New project, modern toolchain?
| --> IFC4 ADD2 TC1, or IFC4.3 ADD2 to future-proof.
|
+-- Must exchange with a tool that only reads IFC2x3?
--> IFC2x3 TC1 (legacy baseline).
NEVER pick IFC4.1 / IFC4.2 (Withdrawn) --> use IFC4.3 instead.
NEVER pick IFC5 / IFCx for production (in development).
Is the task actually about IFC?
What does the task need?
|
+-- Store / exchange built-environment data between tools
| --> IFC is correct.
|
+-- Compute, tessellate, or render geometry
| --> NOT IFC. Use a geometry kernel or a library
| (IfcOpenShell, web-ifc, xBIM).
|
+-- Enforce who may edit what
| --> NOT IFC. IFC has no access control.
|
+-- Run application logic or behavior
--> NOT IFC. IFC is a static data model.
Which ISO designation maps to which IFC version
ISO/PAS 16739:2005 --> IFC2x3 TC1 (Publicly Available Specification)
ISO 16739:2013 --> IFC4 (first full ISO standard)
ISO 16739-1:2018 --> IFC4 ADD2 TC1
ISO 16739-1:2024 --> IFC4.3 ADD2 (current)
Patterns
Pattern : Describe IFC correctly
ALWAYS describe IFC as an open, vendor-neutral data model standardized as
ISO 16739-1, NEVER as a file format and NEVER as software.
ALWAYS distinguish the schema (the abstract model, written once in EXPRESS) from
its encodings (the .ifc STEP file, ifcXML, ifcJSON).
NEVER say "the IFC format" when you mean the .ifc STEP Physical File : that
conflates the model with one of its encodings.
See ifc-core-data-model for the layered schema architecture and ifc-syntax-express
for the EXPRESS language.
Pattern : Cite the standard precisely
ALWAYS cite IFC as ISO 16739-1 with the publication year, because the number alone
is ambiguous across four publications.
ALWAYS state the IFC version AND its addendum or corrigendum : "IFC4" and
"IFC4 ADD2 TC1" are different schemas.
NEVER write "ISO 16739" without the -1 part designation for IFC4 and later : the
-1 suffix was introduced with ISO 16739-1:2018.
The ISO standardization status is itself version-specific : early IFC versions were
NOT ISO standards, IFC2x3 TC1 was a Publicly Available Specification (PAS, not a full
standard), and IFC4 onward are full ISO standards. See references/methods.md.
Pattern : Select the target version deliberately
ALWAYS choose from the three officially-supported versions only.
ALWAYS pick IFC4.3 ADD2 when the scope includes infrastructure : it is the only
version that models roads, rail, bridges, ports, and waterways.
ALWAYS check the receiving party's import capability before choosing : many production
tools certify IFC2x3 and IFC4 but not yet IFC4.3.
NEVER assume a version rename is harmless : IFC4.3 renamed IfcBuildingElement to
IfcBuiltElement and deprecated 24 entities (including IfcBuildingElement,
IfcCivilElement, IfcBridgePart). An IFC4 file is NOT guaranteed valid as IFC4.3.
See ifc-core-version-evolution for the full breaking-change matrix.
Pattern : Use the buildingSMART ecosystem
The IFC ecosystem has four pillars. ALWAYS route to the correct one :
| Need | Pillar | Where |
|---|---|---|
| Confirm a tool reads or writes IFC correctly | Software Certification | buildingsmart.org/compliance |
| Confirm a specific file is valid | Validation Service | validate.buildingsmart.org |
| Read the authoritative machine-readable schema | Schema source repos | github.com/buildingSMART |
| Read the human-readable specification | Documentation site | ifc43-docs.standards.buildingsmart.org |
- Software Certification is per-version and split into Import and Export. Export certification aggregates real-user file uploads into scorecards; Import certification uses accredited testers following a public checklist. Certification for IDS and BCF is NOT yet available.
- The Validation Service checks a file against three normative levels. See the next pattern.
- The authoritative IFC4.3 schema lives in
buildingSMART/IFC4.3.x-development. The olderbuildingSMART/IFCumbrella repo was archived on 2024-03-31 and is read-only : NEVER treat it as the current source.
Pattern : Read a Validation Service result
A file is valid only when it conforms to three normative levels :
- STEP Syntax : the STEP Physical File (ISO 10303-21, Part 21) syntax.
- IFC Schema : the EXPRESS schema, including EXPRESS-encoded propositions and functions.
- Normative IFC Rules : the remaining normative rules, split into Implementer Agreements (ratified among software implementers) and Informal Propositions (not ratified but still mandatory for validity).
The service also runs non-normative checks : Industry Practices (sensible defaults : these NEVER make a file invalid) and bSDD Compliance.
NEVER assume a file is valid because it opens in a viewer : a viewer is permissive,
the Validation Service is normative. See ifc-core-validation and
ifc-errors-schema-validation.
Reference Links
references/methods.md: full version ledger, ISO standardization matrix, validation-level taxonomy, certification model, schema repositories, documentation pipeline.references/examples.md: worked scenarios : identifying a file's version, ISO-to-version mapping, version selection, interpreting validation output.references/anti-patterns.md: the failure modes this skill prevents, each with the reason it fails.
Official sources
- buildingSMART technical hub : https://technical.buildingsmart.org/standards/ifc/
- IFC schema specifications : https://technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/
- IFC release notes : https://technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/ifc-release-notes/
- IFC4.3 documentation : https://ifc43-docs.standards.buildingsmart.org/
- Software certification : https://www.buildingsmart.org/compliance/software-certification/
- Validation service : https://validate.buildingsmart.org/
- Schema source repo : https://github.com/buildingSMART/IFC4.3.x-development
Related skills
ifc-core-data-model: the four-layer schema architecture and the ladder principle.ifc-core-version-evolution: version-by-version additions and breaking changes.ifc-core-validation: how IFC validity is defined and checked.