# Ifc Core Standards Overview > Use when you need to explain what IFC is, choose which IFC version to target, or understand how the buildingSMART ecosystem (software certification, validation service, schema repositories) fits together before authoring or reading IFC data. Prevents treating IFC as a runtime, a geometry kernel, a library API, or a single file format, and prevents targeting a withdrawn or non-official version. Covers the IFC data-model definition, the ISO 16739-1 standardization history, the three officially-supported versions, the three built-environment data dimensions, and the certification, validation, and schema-repository ecosystem. Keywords: IFC, Industry Foundation Classes, ISO 16739-1, buildingSMART, openBIM, IFC2x3, IFC4, IFC4.3, IFC5, IFCx, IFC version selection, what is IFC, which IFC version should I use, is IFC a file format, IFC standard explained, ISO PAS 16739, validation service, software certification, my IFC file will not validate, which version did this tool export, openBIM cornerstone. - Skill: `impertio-studio/ifc-core-standards-overview` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add impertio-studio/ifc-core-standards-overview` - Raw SKILL.md: https://api.skillmd.com/api/skills/impertio-studio/ifc-core-standards-overview/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - License: MIT - Author: Impertio-Studio (https://skillmd.com/u/impertio-studio) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/impertio-studio/ifc-core-standards-overview --- # IFC Core : Standards Overview 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 `.ifc` file 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; `OwnerHistory` records 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** : 1. **IFC2x3 TC1** : the legacy interoperability baseline (ISO/PAS 16739:2005). 2. **IFC4 ADD2 TC1** : the modern building schema (ISO 16739-1:2018). 3. **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 older `buildingSMART/IFC` umbrella 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** : 1. **STEP Syntax** : the STEP Physical File (ISO 10303-21, Part 21) syntax. 2. **IFC Schema** : the EXPRESS schema, including EXPRESS-encoded propositions and functions. 3. **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.