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.

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

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

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 :

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/<PREFIX>/. Example :

@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 @<PREFIX> 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.