IDS (Information Delivery Specification) is a buildingSMART standard for writing information requirements in a way software can check automatically. An IDS file says, for example: “every door must have a fire rating, and it must be one of these values”. Then any IDS-aware tool can check an IFC model against it.
How an IDS is structured
An IDS file (XML) contains specifications. Each specification has two parts:
- Applicability — which objects it applies to. Example: all doors.
- Requirements — what those objects must have. Example: a property
FireRatinginPset_DoorCommon.
Both parts are built from facets:
| Facet | Checks |
|---|---|
| Entity | The IFC class (and optional predefined type) |
| Attribute | Built-in attributes such as Name |
| Property | A property in a property set, optionally with allowed values |
| Classification | A classification reference |
| Material | The assigned material |
| PartOf | A relationship, e.g. contained in a storey |
Why it matters
- Requirements become testable, not just written in a PDF.
- Delivery teams can check their own models before sharing.
- It supports the level of information need approach by stating exactly which data is needed.
Checking softwareAny IDS-capable tool
Accept or returnBefore sharing
Getting started
Begin small: take the required attributes for a few key elements (doors, fire-rated walls, plant) and express them as IDS specifications. The information requirements list in an LOD matrix is a good source.