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
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 :
STEP Syntax : the file is a well-formed STEP Physical File per ISO 10303-21.
IFC Schema : the instances satisfy the EXPRESS schema (types, cardinality,
WHERE rules, global rules, reference integrity, no abstract instantiation).
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.
