Information Delivery Specification
A buildingSMART open standard that expresses BIM requirements as machine-readable rules, replacing prose-based compliance with automated model validation.
What is an Information Delivery Specification?
An Information Delivery Specification (IDS) is an open, machine-readable standard published by buildingSMART that expresses BIM information requirements as testable rules. Where a BIM Execution Plan states requirements in prose ("walls shall include U-value and fire rating"), an IDS translates that requirement into a rule that a checker can run automatically: open an IFC model, test each wall, and report pass or fail for each one. This shift from prose to machine-executable is the defining strength of IDS.
The standard is maintained by buildingSMART and published as a public specification. It works within the openBIM ecosystem, operating on IFC files that are vendor-neutral and freely shareable. IDS removes the human argument from compliance: either the model meets the specification or it does not, checkable by software without interpretation.
How does IDS differ from a BIM Execution Plan?
Both document information requirements, but they operate at different levels. The BEP is a written agreement, typically 5-50 pages, where the team and client negotiate what information is needed, who produces it, and by when. Compliance is argued: a team member says "we supplied thermal properties", the receiver checks and disputes or agrees. The dispute is resolved by email or meeting.
An IDS takes the same requirement ("thermal properties required") and encodes it as a rule: "for every wall entity, a property named U-value must exist and its value must be a number between 0.1 and 2.0". A machine runs this rule against the model and reports: five walls pass, two walls fail (missing U-value), three walls fail (value out of range). There is no argument; the data is either there or it is not.
| Aspect | BIM Execution Plan (Prose) | IDS (Machine-Readable) |
|---|---|---|
| Format | Written document, agreed before work begins | Structured XML/JSON rules, machine-checkable |
| Compliance check | Manual review, often subjective | Automated scan of IFC model, binary result |
| When checked | Typically at handover or dispute | Before each model issue, in the coordination workflow |
| Effort to create | Moderate; requires writing and negotiation | Higher initially; requires translating BEP prose into rules, but saves time later |
| Result clarity | Text report, open to interpretation | Pass/fail per element, unambiguous |
In practice, IDS complements rather than replaces the BEP. The BEP remains the contract and project rulebook. An IDS is a tool that automates one part of BEP enforcement: the information completeness and naming conventions parts.
What structure does an IDS specification define?
Every IDS rule has two parts: applicability and requirements. Applicability answers "which entities does this rule apply to?" Requirements answer "what must be true of those entities?"
Applicability filters by IFC entity type, classification, or property. For example: "apply to all elements classified as thermal insulation" or "apply to all walls in storey number 2". Requirements then specify what information must accompany those entities: minimum and maximum values, required properties, allowable materials, or relationships to other elements. A rule might say: "any insulation element must have a Thickness property (numeric, millimetres, minimum 50)", checked against buildingSMART Data Dictionary property definitions so the naming matches across models from different tools.
| Part of Rule | Example | Checked By |
|---|---|---|
| Applicability: entity type | "All IfcWall entities" | Software counts the walls in the model |
| Applicability: classification | "All elements with classification 'thermal insulation'" | Software finds classified elements and filters |
| Requirement: property exists | "Property U-value must be present" | Software checks each wall; reports missing properties |
| Requirement: value in range | "U-value must be between 0.1 and 2.0 W/m²K" | Software compares actual values to the range; reports out-of-range |
| Requirement: enum (choice) | "FireRating must be one of: A1, A2-s1, d0, B-s1, d0, etc." | Software checks if actual value matches the approved list |
Why does IDS only work when naming actually matches?
Here is the hard constraint: IDS rules reference property names and classifications. If your architectural model names a thermal property "U_Val" and the rule looks for "U-value", the checker sees nothing, marks it as fail, and no human judgment can override it. The property exists but under a different name, so the rule is technically correct: the required property does not exist.
This is why IDS and buildingSMART Data Dictionary (bsdd) must work together. The bsdd is a registry of property definitions, grouped by domain, each with a standardized name. When an IDS rule says "property U-value (from bsdd code PSet_WallCommon.U-value)", it is saying: this must exist, under this exact name, with this exact definition. Every consultant's software must then export to IFC using bsdd property names, or the check fails.
For a solo practice coordinating external consultants, enforcing this requires including the bsdd reference in the BEP and asking consultants to confirm their software can export using it. Many tools now support this; some still do not. This is why adoption of IDS in Slovak practice is still early: the ecosystem must align naming before IDS checks become reliable.
Where does IDS sit in the workflow?
An IDS rule set is typically agreed with the client at the outset, alongside the BEP. It lives in the Common Data Environment as the project's quality gate. Each time a consultant issues a model update (weekly, bi-weekly, or at milestones), the model is submitted to the CDE and a checker (software or human using software) runs the IDS rules. Results are fed back to the team: "the MEP model passes all rules", or "the architectural model fails: 12 walls missing U-value".
The results then flow into the coordination process: clashes are detected, IDS failures are logged as issues in the coordination tool, assigned to the responsible party, and resolved before the next issue. BIM coordination becomes more structured because the information quality is verified, not assumed. Teams catch incomplete or misnamed data early, not at handover.
What are the practical limits of IDS adoption today?
IDS is an excellent idea, but in Slovak residential practice adoption is still early. Several reasons:
- Tooling support varies. Not every BIM platform exports IDS, and not every checker reads it reliably. Support is improving, but many small practices still use older software versions without IDS capability.
- bsdd alignment is incomplete. Many European property libraries are still being migrated to buildingSMART definitions. Until that aligns, enforcing naming via IDS is difficult.
- Consultant buy-in is needed. A structural engineer working on multiple projects cannot adopt IDS for one client and ignore it for another. Industry-wide adoption of the standard must happen first.
- IDS cannot judge design. A wall can pass every IDS rule and still fail its thermal target, or a duct can be correctly named but undersized. IDS validates data presence and formation, not correctness or performance.
For solo practices, the pragmatic approach is to start with small, high-value rules (e.g., "every wall must have a type and a thickness") and expand only when your consultants demonstrate support for both the standard and bsdd naming. The BEP remains the primary tool; IDS is a growing companion that automates part of quality control as the ecosystem matures.
Frequently asked questions
- Do I need IDS for a small residential project?
- Rarely, unless your client explicitly requires it or you are coordinating multiple consultants. IDS is most valuable when you need to enforce naming and data standards across a team and automatically verify that models comply before each issue.
- Can IDS prevent design errors?
- No. IDS checks whether declared information is present and correctly formed; it cannot judge whether the design itself is good, safe, or efficient. A wall can pass an IDS check and still have poor thermal performance or structural capacity.
- What software can create or validate IDS files?
- Tooling support varies. Some BIM platforms export IDS natively; others require third-party validators like the buildingSMART IDS Audit Tool or Solibri. In Slovak practice, adoption is still early, so check your software vendor's roadmap before assuming IDS is available.
- Does my structural engineer need to use IDS?
- Only if you require it in the project brief or coordination plan. IDS compliance can be mandated in the BIM Execution Plan, but it adds overhead if your consultant is not already familiar with the standard. Early agreement is essential.
- How does IDS differ from clash detection?
- Clash detection checks for geometric interference (pipes hitting beams). IDS checks information completeness (whether a pipe is tagged as fire-rated and has a rated thickness). They test different properties of the model.
- Can IDS check if materials are sustainable?
- Only if the material data is declared in the IFC model's properties and the IDS rule references those properties. IDS validates that data is present; it does not source or verify the data's accuracy independently.