An Exchange Information Requirement can say, in plain prose, that every structural column in a delivered model must carry a recorded material grade. That sentence is completely unambiguous to a person reading it, and it's binding, part of a signed appointment contract. But a sentence in a document isn't something software can run. Nobody can point a checking tool at a PDF and get a pass or fail answer back. This lesson covers the format built specifically to close that gap, and where it fits against the requirements cascade this module has been building throughout.
Information Delivery Specification, IDS, is buildingSMART's own standard for writing information requirements in a form software can check automatically rather than a person interpreting by eye. It's a machine-readable file, built around the IFC schema, that specifies what has to be true about a model, which elements need which data, in what location, matching what value. IDS itself is the specification format. Checking a real IFC file against it and producing a pass or fail result is the job of separate, IDS-compliant validation software. IDS became an official buildingSMART standard on June 4, 2024, and a requirement written once, in one IDS file, gives every compliant validator a standardized specification to interpret consistently, rather than each reviewer working from their own reading of a prose document.
IDS doesn't replace the EIR, and it doesn't sit above or below it in the cascade this module has walked through, OIR narrowing into AIR, into PIR, into a binding EIR. It sits alongside the EIR, as a technical encoding of part of what that document already says. buildingSMART's own documentation describes this directly: IDS can be used in combination with other standards specifically to capture Exchange Information Requirements from the ISO 19650 series, turning a portion of that prose document into something a machine can verify.
The word portion matters. A real EIR is a heavier document than any single IDS file could ever be. It covers managerial and commercial terms, delivery deadlines, review processes, software requirements, and the technical content specifying exactly what data a model needs to contain. IDS was built for one narrow slice of that whole document, the part expressible as a checkable fact about a model. Everything else in a real EIR, who's responsible for delivering it, when it's due, how disputes get resolved, has no IDS equivalent and was never meant to have one.
Worth naming directly, since it's easy to picture this the wrong way. Nobody feeds a whole EIR document into a tool and gets an IDS file out the other end. The actual workflow runs the other direction, and it's selective rather than automatic: start with the EIR, identify which individual clauses inside it are checkable facts about model data, express each of those clauses as its own IDS specification, then validate a real IFC file against the resulting set.
Most of a real EIR never makes this trip at all. That's expected, not a shortfall of the process. IDS was never meant to absorb an entire EIR, only to give the checkable fraction of it a machine-readable form.
The part of an EIR that translates well into IDS is anything expressible as a fact about a model's data: an element type needing a specific property, a value needing to match a pattern, an element needing to sit within a particular part of the spatial structure. This is precisely the kind of requirement the six IDS facets, Entity, Attribute, Property, Material, Classification, and PartOf, were built to check.
What doesn't translate is anything that isn't, at its core, a checkable fact about the model itself. A delivery deadline isn't a property IDS can verify. A clause specifying which named individual is responsible for review isn't something an IFC file carries any trace of. IDS also does not provide a mechanism for validating geometric characteristics such as shape, dimensions, or spatial accuracy. A requirement like "all structural columns must be modeled with accurate cross-sectional geometry" has no IDS equivalent whatsoever, not because IDS is incomplete, but because that kind of requirement sits outside what IDS was ever built to check.
Take a plausible clause from a real-shaped EIR: "All structural columns shall be assigned a material grade consistent with the project's structural specification, and shall be located within their correct building storey."
That single sentence actually contains two separate, checkable claims, and translating it into IDS means splitting it into two specifications rather than forcing it into one.
The first claim, material grade, needs a closer look before picking a facet. If the requirement is genuinely asking whether a column has a specific material assigned, by name, that's a Material facet check: applicability narrows to every IfcColumn, and the requirement checks that each one carries a material association matching the specified grade. But an EIR clause phrased differently, something like "concrete shall have a compressive strength class of C30/37," is often really asking about a property value associated with that material, compressive strength class, rather than the material assignment itself, and depending on how that value is structured in the file, it may need a Property facet pointed at the right property set instead. Reading the actual clause carefully enough to tell these apart is part of the translation work, not a detail to skip past.
The second claim, correct storey placement, becomes a PartOf facet check on the same applicability, every IfcColumn. The requirement checks that each column participates in a containment relationship placing it inside an IfcBuildingStorey, rather than floating unassigned in the model's spatial structure.
Running both specifications against a real delivered file produces two independent pass or fail results. A column can pass the material check and fail the storey check, or the reverse, and knowing which one failed tells a reviewer exactly what to go back and ask for, rather than a vague "the model doesn't meet requirements" with no indication of which requirement.
This is worth stating plainly now that both sides of the connection are on the table. The requirements cascade, OIR through AIR through PIR into a binding EIR, governs what has to be delivered and when, and makes that requirement contractually real. IDS takes the checkable portion of that requirement and lets a validator verify, with a repeatable result, whether the required data is present and structured the way the specification demands.
Neither one checks whether the value itself is true. A column can pass an IDS Material check because it carries a material association with the exact right name, while the actual concrete grade poured on site was something else entirely. A column can pass a PartOf check because it's correctly linked to a storey, while its recorded position within that storey is wrong. IDS confirms structure and presence against a stated specification. It doesn't establish that the underlying value is a correct description of reality, and neither does any layer of the ISO 19650 cascade sitting above it. That gap, between a file that satisfies every written requirement and a file that's actually correct, is real, it's documented, and it's the exact seam where this module's material connects to what validation and extraction correctness have to cover instead.
Comments use a free GitHub account — takes under a minute to create, and keeps discussions spam-free and permanently archived.