# Ifc Core Validation > Use when you need to know whether an IFC file is valid, interpret a buildingSMART validation report, or understand what "schema-conformant" and "normative" mean before authoring or auditing IFC data. Prevents treating a file that opens in a viewer as valid, confusing project requirement checking (IDS) with standard conformance, treating industry-practice warnings as errors, and assuming an unratified Informal Proposition is optional. Covers the three normative conformance levels (STEP syntax, IFC schema, normative IFC rules), Implementer Agreements vs Informal Propositions, non-normative checks (Industry Practices, bSDD), the buildingSMART validation service pipeline and severities, the Gherkin normative-rule format, and the functional-part prefix taxonomy. Keywords: IFC validation, validate IFC file, buildingSMART validation service, schema validation, STEP syntax check, WHERE rule, global rule, normative rule, Implementer Agreement, Informal Proposition, Industry Practice, Gherkin rule, functional part pref - Skill: `impertio-studio/ifc-core-validation` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add impertio-studio/ifc-core-validation` - Raw SKILL.md: https://api.skillmd.com/api/skills/impertio-studio/ifc-core-validation/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - License: MIT - Author: Impertio-Studio (https://skillmd.com/u/impertio-studio) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/impertio-studio/ifc-core-validation --- # IFC Core : Validation An IFC file is "valid" only when it conforms to a defined set of normative levels. This skill establishes what IFC validity means, how the buildingSMART Validation Service checks it, how to read a validation result, and how the Gherkin normative rules and their functional-part taxonomy are organized. It is the conformance layer beneath every `ifc-errors-*` skill and beneath `ifc-agents-file-validator`. Applies to IFC2x3, IFC4, and IFC4.3 (the three officially-supported, certifiable versions). IFC5 / IFCx are in development and have no comparable validation pipeline. ## Quick Reference ### What "valid IFC" means A file is valid only when it conforms to **three normative levels**, in order : 1. **STEP Syntax** : the file is a well-formed STEP Physical File per ISO 10303-21. 2. **IFC Schema** : the instances satisfy the EXPRESS schema (types, cardinality, `WHERE` rules, global rules, reference integrity, no abstract instantiation). 3. **Normative IFC Rules** : the remaining normative rules, split into **Implementer Agreements** and **Informal Propositions**. ALWAYS treat all three levels as mandatory for validity. NEVER treat a file that passes only STEP syntax and schema as valid : normative rules are equally binding. ### The buildingSMART Validation Service pipeline The free public service at `validate.buildingsmart.org` runs **five stages**. The first three are normative (they decide validity); the last two are non-normative. | Stage | Category | Normative | Effect of failure | |-------|----------|-----------|-------------------| | 1 | STEP Syntax | Yes | File invalid ; later stages do not run | | 2 | IFC Schema (version + compliance) | Yes | File invalid | | 3 | Normative Checks (agreements + propositions) | Yes | File invalid | | 4 | Industry Practices | No | Warning only ; file stays valid | | 5 | bSDD Compliance | No | Informational ; currently disabled | ALWAYS run the Validation Service as the **first gate** of any IFC review, before any project-specific or geometry review. NEVER skip it because a file looks correct. ### Severity model | Severity | Meaning | |----------|---------| | `pass` | The check succeeded. Pass results are hidden by default. | | `warning` | Non-conformance with a non-normative check. Does NOT invalidate. | | `error` | Non-conformance with a normative check. Invalidates the file. | | `not applicable` | The check does not apply to this file or schema. | | `disabled` | The check is switched off (for example bSDD compliance). | ALWAYS read `error` as "the file is non-conformant" and `warning` as "the file is valid but deviates from common practice". NEVER escalate a `warning` to a blocker or downgrade an `error` to advisory. ### Normative checks : the two subcategories | Subcategory | Definition | Binding for validity | |-------------|------------|----------------------| | **Implementer Agreement** | A normative check ratified as an official agreement among software implementers. | Yes | | **Informal Proposition** | A mandatory check NOT yet ratified as an implementer agreement. | Yes | ALWAYS treat both as mandatory. NEVER read "Informal" or "not ratified" as "optional" : an Informal Proposition failure invalidates the file exactly like an Implementer Agreement failure. The word "informal" describes the ratification status, NEVER the obligation. ### Functional-part prefixes (compact) Normative rules carry a 3-letter **functional-part** prefix that names the area of the schema the rule covers. The most common prefixes : | Prefix | Functional part | |--------|-----------------| | `PJS` | Project definition (context, units, directory of objects) | | `GRF` | Georeferencing | | `BLT` | Built elements (walls, slabs, doors, columns) | | `GEM` | Geometry representation | | `OJP` | Object placement | | `SPS` | Spatial breakdown | | `MAT` | Materials | | `PSE` | Properties for object | | `QTY` | Quantities for objects | | `CLS` | Classification reference | | `POR` | Port connectivity and nesting | Full prefix table (27 functional parts plus geometry / placement sub-parts) : see `references/methods.md`. ## Decision Trees ### Is my IFC file valid? ``` Run the file through validate.buildingsmart.org. | +-- STEP Syntax fails (error)? | --> INVALID. Fix the file header / encoding first. | Later stages did not run. See ifc-errors-schema-validation. | +-- Schema check fails (error)? | --> INVALID. Wrong types, bad cardinality, WHERE-rule break, | dangling #id, or an abstract entity was instantiated. | +-- Normative check fails (error)? | --> INVALID. An Implementer Agreement or Informal Proposition | was broken. Both invalidate the file. | +-- Only Industry Practice warnings? | --> VALID. The file conforms ; it deviates from common practice. | +-- All three normative stages pass? --> VALID. ``` ### Which stage caught my problem? ``` What does the failing message describe? | +-- File header, FILE_SCHEMA, unescaped string, encoding | --> Stage 1 : STEP Syntax (ISO 10303-21). | +-- "unsupported schema version" / unknown identifier | --> Stage 2a : Schema Version check. | +-- Wrong attribute type, cardinality, WHERE rule, global rule, | dangling reference, abstract entity instantiated | --> Stage 2b : Schema Compliance check. | +-- A rule code like SPS001, GEM051, named "agreement" / "proposition" | --> Stage 3 : Normative Checks (Gherkin rules). | +-- "warning", sensible-default advice --> Stage 4 : Industry Practices (non-normative). ``` ### Validation vs IDS : which tool answers my question? ``` What am I checking? | +-- "Does this file conform to the IFC STANDARD?" | --> buildingSMART Validation Service. Schema + normative rules. | This skill. | +-- "Does this file meet THIS PROJECT's information requirements?" | --> IDS (Information Delivery Specification). NOT validation. | The Validation Service explicitly EXCLUDES project, | national, and organisational requirements. | +-- "Does this file follow common-practice defaults?" --> Industry Practice checks. Warnings only. ``` ## Patterns ### Pattern : Define validity by the three normative levels ALWAYS define a valid IFC file as one that conforms to **all three** normative levels : STEP syntax, IFC schema, and normative IFC rules. NEVER call a file valid on the strength of one or two levels. A file can be syntactically perfect, schema-clean, and still invalid because a normative rule fails. ALWAYS run the levels in order : a STEP syntax failure stops the pipeline, so schema and normative results are unavailable until syntax passes. See `ifc-errors-schema-validation` for the concrete error catalog. ### Pattern : Read a validation report correctly ALWAYS map each result to its stage and severity before acting : - An `error` at stage 1, 2, or 3 means the file is **non-conformant**. Fix it. - A `warning` at stage 4 means the file is **valid** but deviates from common practice. Record it ; do NOT block on it. - `pass` results are hidden by default. Their absence is not a failure. - `not applicable` and `disabled` are neutral : the check produced no verdict. NEVER report "the validation passed" when only stage 1 ran. NEVER report a file as broken because of stage-4 warnings alone. ### Pattern : Use the Validation Service as the first gate ALWAYS validate a file at `validate.buildingsmart.org` at the **outset** of any IFC review, before geometry inspection, property auditing, or project-requirement checks. The service is a foundational conformance gate. NEVER assume a file is valid because it opens in a viewer : viewers are permissive and routinely render technically non-conformant files. The Validation Service is normative ; a viewer is not. NEVER use the Validation Service to check project requirements : it explicitly excludes project, national, and organisational requirements. Use IDS for those. ### Pattern : Understand schema conformance The schema-compliance check (stage 2b) verifies, against the EXPRESS schema : - **Attribute types** : every explicit attribute holds a value of the declared type. - **Cardinality** : `OPTIONAL` attributes may be absent ; aggregate bounds (`LIST`, `SET`, `ARRAY` size limits) are respected. - **`WHERE` rules** : entity-local constraints (named propositions inside an entity declaration) evaluate true. - **Global rules** : schema-wide constraints (for example uniqueness rules) hold. - **Inverse attributes** : `INVERSE` links resolve and respect their cardinality. - **Reference integrity** : every `#id` reference resolves to an instance of the correct type ; no dangling references. - **No abstract instantiation** : no instance is written for an `ABSTRACT` supertype (for example `IfcBuildingElement` in IFC2x3 / IFC4, or `IfcBuiltElement` in IFC4.3). ALWAYS instantiate a concrete subtype such as `IfcWall`. - **SELECT / ENUM domains** : defined-type, `SELECT`, and `ENUMERATION` values stay inside their declared domain. ALWAYS treat a schema-compliance `error` as a hard failure : the file is not valid IFC. See `ifc-syntax-express` for the EXPRESS language constructs named here. Version note : the schema version identifier in stage 2a must be one of `IFC2X3`, `IFC4`, or `IFC4X3_ADD2`. A file whose `FILE_SCHEMA` names an unsupported version fails the version check before any compliance rule runs. ### Pattern : Read a Gherkin normative rule Normative rules that cannot be expressed in EXPRESS are implemented as Gherkin behaviour specifications in `buildingSMART/ifc-gherkin-rules` (Python, MIT). Each rule lives in a `.feature` file under `features/rules//`. Example : ```gherkin @implementer-agreement @SPS @version2 Feature: SPS001 - Basic spatial structure for buildings Background: Given A file with Model View Definition 'CoordinationView_V2.0' Given A file with Schema 'IFC2X3' Scenario: Agreement141 - maximum of one IfcSite Then There must be at most 1 instance(s) of .IfcSite. ``` Read a `.feature` file like this : - The **tag line** (`@implementer-agreement` or `@informal-proposition`) gives the normative subcategory. The `@` tag gives the functional part. `@versionN` scopes the rule by schema generation. - **`Background`** constrains applicability : a rule may apply only to a given MVD or schema. A rule never fires on a file outside its `Background`. - Each **`Scenario`** is one independently checkable proposition. ALWAYS classify a normative failure by its functional-part prefix to locate the schema area at fault (`SPS` = spatial breakdown, `GEM` = geometry, and so on). NEVER guess a rule's meaning from its number alone : read the `.feature` file. ### Pattern : Distinguish normative from non-normative ALWAYS separate the two non-normative checks from the three normative levels : - **Industry Practices** check sensible defaults and common-practice conventions. They emit `warning` only and NEVER invalidate a file. - **bSDD Compliance** checks classification and property references against the buildingSMART Data Dictionary. It is informational and currently disabled in the service. NEVER let an Industry Practice warning block a hand-off. NEVER claim a file is invalid for a non-normative reason. ## Reference Links - `references/methods.md` : the five-stage pipeline in detail, the full schema- conformance check list, the complete 27-entry functional-part prefix table with geometry and placement sub-parts, the Gherkin rule architecture, the severity table, schema version identifiers, and the validation-vs-IDS boundary. - `references/examples.md` : worked scenarios : interpreting a validation report, classifying an error by stage, reading and running a single Gherkin rule, deciding validity from mixed results. - `references/anti-patterns.md` : the failure modes this skill prevents, each with the reason it fails. ### Official sources - Validation service : https://validate.buildingsmart.org/ - Validation service user guide : https://buildingsmart.github.io/validate/ - Validation service overview : https://technical.buildingsmart.org/services/validation-service/ - Gherkin normative rules : https://github.com/buildingSMART/ifc-gherkin-rules - Functional parts list : https://github.com/buildingSMART/ifc-gherkin-rules/blob/main/features/Functional-parts.md - buildingSMART technical hub : https://technical.buildingsmart.org/ ### Related skills - `ifc-errors-schema-validation` : the concrete schema and normative error catalog. - `ifc-agents-file-validator` : an agent that runs the five-stage pipeline as a checklist. - `ifc-syntax-express` : the EXPRESS language : `WHERE` rules, global rules, `ABSTRACT`, `SELECT`, `ENUMERATION`, aggregate cardinality.