Checking whether an IFC file conforms to the IFC standard happens in stages. STEP Syntax asks whether it's a legally structured file at all. IFC Schema asks whether its content obeys the EXPRESS rules for its declared version. Normative IFC Rules ask whether it follows the community-agreed conventions layered on top of the schema. All three answer some version of the same question: does this file conform to the IFC standard? None of them, individually or together, can answer a different and more practical question: does this file contain what a specific project actually needs?
That's not a gap in how thoroughly those three stages were built. It's outside what they were designed to check in the first place. This lesson is about the gap itself, what it looks like in practice, and what kind of tool is actually shaped to close it.
Before any standardised way to check it existed, a project's information requirements lived, and often still live, as prose. A client or lead appointed party writes a document specifying what a delivered model needs to contain: which elements need which properties, which categories need quantities, what a name or classification needs to follow. In the ISO 19650 framework this document is the Exchange Information Requirements, a contractual specification of what information must be exchanged, by whom, when, and how it will be checked.
The checking part is where the gap opens up. A sentence in a document, "all structural elements must carry Base Quantities," is unambiguous to a person reading it. It has no standardised, repeatable way to be checked against an actual delivered file. Someone opens the model, spot-checks a handful of elements by hand, and either trusts what they see or doesn't. Two different reviewers checking the same file against the same sentence can reach different conclusions, and neither has a way to prove the other wrong. The requirement exists. The verification of it doesn't, not in any form a computer can run consistently.
A real Revit 2021 IFC2X3 export contains 18 strip footings, modelled as IfcFooting with PredefinedType STRIP_FOOTING, carrying zero IfcElementQuantity sets. Every column, beam, and slab in the same file carries a complete quantity set. That file was run through buildingSMART's own Validation Service: STEP Syntax passed, IFC Schema passed, Normative IFC Rules flagged two unrelated rule types, a geometry defect and a misattached property set, neither touching quantities at all. The file passed every stage of standard validation cleanly, with the missing-quantities pattern invisible to all three.
Now put a sentence like "all structural elements must carry Base Quantities" next to that result. Nothing checked so far has any way to evaluate that sentence against this file. Schema validation doesn't know the sentence exists, quantity sets are optional under the schema, so there's no rule to violate. Normative Rules check community conventions, not project-specific requirements a particular client wrote down for a particular delivery. The sentence and the file are sitting in the same room, and nothing built so far can put them side by side and produce a verdict.
That's the precise shape of the problem this module exists to solve. Not "is this file broken", every check so far has already answered that. The open question is "does this file satisfy what someone actually asked for", and nothing described so far has a mechanism to answer it at all.
Information Delivery Specification is buildingSMART's own standard for exactly this: specifying information requirements in a machine-readable form and checking an IFC model against them automatically. It became an official buildingSMART standard on the 1st of June 2024. buildingSMART describes it as a free, lightweight, standardised approach to model checking, deliberately built so that a requirement written once, in one file, produces the same pass or fail result regardless of which compliant tool runs the check.
That's the concept, and this lesson stops here deliberately. What an IDS file actually contains, its structure, its facets, how a requirement gets written, is real content with its own real depth, and belongs to the lessons built specifically to teach it. What matters at this point is narrower: a standardised, computer-checkable format now exists for the exact kind of sentence that, a section ago, had no repeatable way to be verified at all.
Worth stating plainly and early, since it shapes everything the rest of this module builds on: IDS checks whether specified information is present, correctly typed, and correctly located in a file. That's the entire scope of the promise. It answers, with a computer-repeatable verdict, whether a file satisfies a written requirement about what data it should contain.
It was never designed to check what happens to that data once its presence is confirmed. Whether a downstream tool reads a property correctly, computes the right value from it, or ignores it entirely after IDS has already marked it present, correct, and located exactly where it should be, is a separate question IDS was not built to answer. That boundary isn't a flaw in the standard. It's the edge of what "checking presence" can ever mean, and it's a distinction worth sitting with before this module goes any further, rather than discovering it as a surprise later.
Comments use a free GitHub account — takes under a minute to create, and keeps discussions spam-free and permanently archived.