Understanding IDS 1.0 — what the standard is and what a first rule looks like

In most BIM projects the requirements specification is a Word document. Three to fifty pages stating which building elements have to be delivered, which properties have to be filled in, which classifications we use. Written for humans, checked on screen. That works as long as the reviewer stays focused. But anyone who has reviewed four IFC deliveries in a row against such a document knows: by the third file, the eyes start to wander.

The question is not whether the requirements specification is wrong. The question is how to make it machine-readable. There has been an open standard for exactly this since 2024: the Information Delivery Specification, or IDS. In this post I explain what IDS does, how an IDS file is structured, and what a first concrete rule looks like.

What IDS does

IDS is an XML language used to write down BIM requirements in a way that software can check automatically. It is standardised by buildingSMART International. Version 1.0 was approved as a final standard on 4 June 2024. Working with it today is no longer pioneering.

Three terms are often confused in everyday BIM work. Here is how to tell them apart:

• MVD (Model View Definition) — describes what a piece of software has to export to IFC. From the software vendor's perspective.
• IDM (Information Delivery Manual) — describes, in process terms, who delivers which information in which phase. From the project workflow's perspective.
• IDS — is the machine-readable bridge between IDM and IFC. What was agreed in the IDM in writing, IDS checks technically.

In practical terms: a client or general planner who writes "all load-bearing walls must have a fire rating" can phrase the same sentence in IDS so that every delivery is automatically checked against it. No more manual scrolling through the model.

How an IDS file is structured

At its core, an IDS file is XML. Not pretty to read, but stable to process. It consists of several so-called Specifications, and every Specification has two parts:

• Applicability — which model elements the rule applies to. Example: all IfcWall with LoadBearing = True.
• Requirements — what these elements must satisfy. Example: a FireRating property must exist and have a value from a defined list.

In simplified IDS-XML this looks like:

<specification name="Load-bearing walls — fire rating">
  <applicability>
    <entity name="IfcWall" />
    <property propertySet="Pset_WallCommon"
              baseName="LoadBearing" value="True" />
  </applicability>
  <requirements>
    <property propertySet="Pset_WallCommon"
              baseName="FireRating">
      <value>
        <enumeration values="REI30,REI60,REI90,REI120" />
      </value>
    </property>
  </requirements>
</specification>

Pset_WallCommon is a property set defined in IFC. LoadBearing and FireRating are standard properties within it. If you use your own or project-specific properties, simply specify the matching property set.

Two points worth highlighting:

• IDS checks structures and values, not geometry. The question "Does this wall have a FireRating?" maps cleanly. "Does this wall intersect the window?" does not. More on that below.
• IDS files are versionable and shareable. A maintained IDS library grows with every project. It is an asset you carry from one project to the next.

A first rule — step by step

Example: "Load-bearing walls must have a fire rating." Here is how it becomes a finished IDS rule.

Step 1 — phrase the requirement precisely. The specification typically says "Load-bearing walls shall be marked with a fire rating". For a machine-readable rule that is not enough. What does "load-bearing" mean in IFC terms? Which values are allowed? Where does the property live? The sentence becomes:

All elements of type IfcWall with Pset_WallCommon.LoadBearing = True must have a Pset_WallCommon.FireRating property whose value is in the list REI30, REI60, REI90, REI120.

Step 2 — express the rule as IDS. This is done either by hand in an XML editor (possible, but error-prone) or via a rule editor that produces the XML in the background. The result is a .ids file that any conformant tool can read.

Step 3 — check the rule against an IFC model. The .ids file is loaded together with the .ifc file. A validator iterates over all IfcWall instances, filters out the load-bearing ones, and checks whether FireRating is present and in the allowed range. The output: a report that lists, per element, what passes and what does not — with reasoning.

What used to take hours of manual sampling per IFC delivery now takes seconds. And, crucially, it is reproducible on every new delivery.

What IDS does not solve yet

As useful as the standard is — universal it is not. Three things are explicitly outside the scope of IDS.

• Geometric checks. Minimum height, minimum distance, door clearance — anything that has to be measured metrically cannot be expressed in IDS. That requires tools with their own geometry engine, often combined with BCF workflows.
• Clash detection. Clash detection is a related but separate topic. IDS says nothing about spatial relationships.
• Cross-domain logic. "A wall with FireRating REI90 should be at least 12 cm thick" combines geometry and properties — and is therefore outside IDS 1.0.

These gaps are, in my view, not failures of the standard but a deliberate boundary. IDS is the language for structured requirement checks. For everything else there are other tools — usually the ones already running in the BIM stack anyway.

Conclusion

Since the 1.0 release, IDS is no longer a research topic. The standard exists, the tooling does too. The transition from a Word specification to an IDS library is not a one-off project, but a gradual process. Most of the projects I support start with ten to fifteen rules and grow step by step with experience.

If you want to try a first rule yourself, you can do so directly in the browser at ifclint.com. Upload an existing IFC model, supply an IDS file or click together a rule in the editor — and let it run. The result comes out as a BCF report, ready to hand over to designers and trades.

For background on the underlying quality questions, see "Why IFC quality assurance decides whether BIM projects succeed or fail" and "The 10 most common errors in IFC models".