ifc-core-validation

name	ifc-core-validation
description	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 prefix, conformance, is my IFC file valid, IFC file will not validate, why does my IFC file fail validation, validation report errors, abstract entity instantiation, dangling reference, IFC2x3, IFC4, IFC4.3.
license	MIT
compatibility	Designed for Claude Code. Requires IFC IFC2x3, IFC4, IFC4.3.
metadata	{"author":"OpenAEC-Foundation","version":"1.0"}

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/<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.