"This IFC file is valid" sounds like one claim. The Validation Service breaks conformity checking into three distinct stages: STEP Syntax, IFC Schema, and Normative IFC Rules. This lesson names each one precisely, using buildingSMART's own terminology, and then does something more useful than restating that files can pass all three and still be wrong: it goes mechanism by mechanism from the previous lesson and asks, honestly, which of the three stages would actually catch each one, rather than assuming the answer in advance.
Every IFC file is, underneath the entity names and attributes, a STEP Physical File, a plain-text format standardised as ISO 10303-21. This stage asks the most basic question possible: is the file even a legally structured document in that format? Balanced parentheses, correctly formatted entity references, a valid header section. This check has nothing to do with IFC's own rules specifically. It's shared with any exchange format built on the STEP standard.
This is the lowest bar there is, and none of the real files this series draws from illustrate a failure here. That's not a gap in the research; it's the expected result. A file that fails STEP syntax typically won't open in a tool like Bonsai at all, so every file detailed enough to cross-validate against raw geometry and Psets, the way this series does, has already cleared this stage by definition. Syntax failures exist in the wild, usually from a corrupted export or a manual text edit gone wrong, but they're rare enough that this lesson has no real example to show, and inventing one would violate the standard this whole series holds itself to.
This is where a file's content gets checked against the EXPRESS schema for its declared version: correct entity types, correct attribute types and cardinalities, and any WHERE rules the schema defines for a given entity. This is a stricter, more specific check than syntax, and it's also where all four mechanisms from the previous lesson survive cleanly, which is worth restating precisely rather than taking on faith.
An element with zero IfcElementQuantity sets attached violates nothing, because quantity sets are optional on any element. IfcQuantityVolume carries exactly two WHERE rules: its unit must be a volume-type unit, and its value can't be negative. Nothing compares a GrossVolume instance against a NetVolume instance with the same name on the same element, so two contradictory-looking values both pass. IfcComplexProperty is a fully legal entity with its own defined attribute set; it simply doesn't carry a NominalValue, and nothing in the schema requires classification data to live in any particular kind of property node. And Fraction on IfcMaterialConstituent is explicitly declared OPTIONAL, so a constituent set with no fraction values at all is, by the schema's own definition, correctly formed.
None of this is a loophole. It's the schema doing exactly what a schema is for: defining what's structurally legal, not what's semantically trustworthy.
This is the stage most people mean when they gesture vaguely at "business rules," and buildingSMART has a specific, narrower name for it: Normative IFC Rules, made up of two categories. Implementer Agreements are rules that have been formally ratified as official agreements among software vendors. Informal Propositions are rules the specification considers mandatory but that haven't gone through that same ratification process. Both categories are implemented as Gherkin rules, behaviour-driven test scenarios that run against a file automatically, and they're the actual logic behind buildingSMART's free Validation Service at validate.buildingsmart.org.
These rules are real, numbered, and named. Some examples that exist today: GEM052, checking for correct geometric subcontexts. SPS001, checking for a valid Model View Definition declaration. QTY001, added in May 2025, titled simply "Base Quantities." Alongside the normative rules, the Validation Service also runs a separate, non-normative pass called Industry Practices, checks against common conventions and sensible defaults, which never invalidates a file; issues there produce warnings, not failures.
Here's where this lesson earns its place rather than repeating the last one. The four failure mechanisms below are restated briefly so this stands on its own, then checked against each stage in turn, honestly, including the places where the honest answer is "unconfirmed" rather than a clean yes or no.
A category never exported. A real Revit IFC2X3 export contains 18 strip footings with zero IfcElementQuantity sets, while every other structural category in the same file carries complete quantity data.
Syntax: passes, the file opens and parses cleanly. Schema: passes, quantity sets are optional on any element, nothing to violate. Normative Rules: genuinely open. A rule named QTY001, "Base Quantities," exists specifically in this area, added to the Validation Service in 2025. Its precise checking logic, whether it flags absent quantity sets on a category where they're conventionally expected, isn't published in enough detail to state a verdict here honestly. This is the one mechanism in this lesson where a dedicated rule for the topic demonstrably exists; whether it actually catches this specific case is a real, open, checkable question, not a decided one.
A value present and inverted. A separate Revit IFC4 file shows a stair flight with GrossVolume smaller than NetVolume on the same element, the opposite of what both properties' own definitions describe.
Syntax: passes. Schema: passes, as shown above. Normative Rules: no evidence found of any rule comparing two named quantities against each other for relative magnitude. This is a comparative, cross-value check, and nothing in the rule categories or examples found for this lesson suggests that kind of check exists at this stage.
Data correct but vendor-specific. A real Allplan export stores its structural-versus-non-structural classification signal, a field called Gewerk, inside IfcComplexProperty nodes rather than a standard property.
Syntax: passes. Schema: passes, IfcComplexProperty is a fully legal entity. Normative Rules: no evidence found of a rule that reaches inside vendor-specific complex property structures. This class of check would need to know, in advance, that a specific vendor stores specific information in a specific nested location, which is a poor fit for a generic, software-agnostic rule set by design.
Data legally allowed to be incomplete. A real Revit IFC4 composite slab carries a material of type IfcMaterialConstituentSet with no Fraction values on either constituent.
Syntax: passes. Schema: passes, Fraction is declared optional. Normative Rules: no evidence found of a rule requiring Fraction values on constituent sets. Since the schema itself makes the field optional, a rule mandating it would be enforcing a stricter standard than IFC itself defines, which is possible in principle but nothing found here confirms it exists.
Three of the four mechanisms show no evidence of coverage at any of the three stages. The fourth, missing Base Quantities, has a named rule sitting right on top of the exact topic, and resolving whether it actually catches this specific pattern needs something better than documentation searching: running a real file through the tool and reading what comes back.
Three stages, and together they answer progressively stronger questions about whether an IFC file conforms to the standard, but none of them, by itself, establishes that the model satisfies a particular project's information requirements. IDS addresses a different question: whether the IFC contains the information required by a particular exchange specification. buildingSMART is explicit that its own Validation Service does not check project-specific, national-specific, or organisation-specific requirements, and states plainly that solutions like IDS pick up that question. Confirmed separately: IDS checks run as a distinct, later stage, after a file has already been checked against these three, and IDS needs a project-specific specification file to check against, something none of the three stages above require.
The open question this lesson leaves standing, whether QTY001 actually catches a category-wide missing quantity set, is exactly the kind of thing the next lesson can answer directly, by running a real file through the Validation Service and reading the result rather than guessing at it.
Comments use a free GitHub account — takes under a minute to create, and keeps discussions spam-free and permanently archived.