“Does the delivered model actually contain the information we need?” — fire ratings, classification codes, quantities, external/internal. Traditionally these requirements were written as prose (in a BEP and the like) and the received model was checked by eye. IDS (Information Delivery Specification) lets you state them in a form a machine can read, and check them automatically.
- IDS states “what information a model must contain” machine-readably (a buildingSMART standard).
- Each specification has an “applicability (which elements it applies to)” + “requirements (what they must have).”
- With an IDS, whether a model meets the requirements can be checked automatically — no more eyeballing prose requirements.
What IDS is
IDS is an open specification for information requirements defined by buildingSMART. The key idea is to write information requirements in a form a tool can interpret, not in human prose. For example, a requirement like “every external wall must carry a fire rating (FireRating)” is written machine-readably.
Then, by handing the IDS and the model (IFC) to a tool, you automatically get “which elements meet the requirement and which don’t.” Because the requirement and the check rest on the same single specification, there’s no drift from “said/didn’t say” or “different people apply different standards.”
The structure of IDS — applicability and requirements
An IDS is a collection of specifications, each made of two parts.
Applicability
- the filter that selects the targets
- e.g. type is “wall” / classification is “external wall”
- only elements matching this are checked
Requirements
- the condition the targets must meet
- e.g. carries a fire rating / has a classification code
- if not met → “non-conforming”
So you write target and requirement as a pair: “an 〈external wall〉 must carry a 〈fire rating〉.” What you can require includes the kinds of information a model should contain — properties (Psets), classification, materials, attributes, part-of relationships.
Why IDS — from prose requirements to machine-readable
Information requirements used to be written as prose in documents like a BEP (BIM Execution Plan) or EIR (Exchange Information Requirements). Documents are meant for humans to read, so they have weaknesses: ① interpretation drifts, ② they can only be checked by hand, ③ gaps are easy to miss.
Before: prose requirements
“External walls must record a fire rating” — readers interpret differently, checking is by eye.
IDS: machine-readable requirements
The same requirement, written in a form a tool can judge. No ambiguity.
Check automatically
Just hand over the model to test the whole thing at once. Gaps are made visible.
IDS aims to make the requirement itself executable. The moment you write the requirement, it is the check rule. Not relying on the eye, you can verify even a large model completely, quickly and to the same standard.
Its relationship to Psets, classification and model checking
IDS isn’t used in isolation — it sits on top of the mechanisms covered in earlier articles.
- Property sets & classification: the substance of the information IDS requires be present. The better your standard Psets and classification, the more straightforward the IDS requirements are to write and to meet.
- Model checking: IDS supplies the verification rules for “is the information present.” It’s a different axis (information completeness) from geometric clash detection; together they secure model quality.
- Quantities (QTO): whether quantities and the properties behind them are present as required can also be checked via IDS.
Where it fits in practice
IDS is a relatively new standard, with tool support still growing. In practice, a client or BIM manager defines the project’s information requirements as an IDS, and each party checks their own model against it before delivery. This heads off the rework of “information gaps discovered after delivery.”
It doesn’t make the BEP/EIR document disappear. The division is: why the information is needed and how it’s used stays in the document; the machine-checkable part becomes the IDS — so requirement communication and verification work together.
Summary
- IDS is a buildingSMART standard for specifying required model information machine-readably.
- Each specification is an applicability (which elements) + requirements (what they must have).
- Unlike prose requirements, it becomes the automated check rule directly (no reliance on the eye).
- Psets & classification are the foundation that puts information in; IDS is the layer that defines and verifies its completeness — the information side of model checking.
A model that “has shape but lacks information” always jams downstream (quantities, checking, facilities management). IDS is the approach that makes information completeness executable at requirement time. The big picture is in what is IFC.