7.4 IDS vs Traditional EIR/Spec Documents

Introduction

The previous lessons in this module covered what IDS is, how it's structured, and how to build one. This lesson puts a traditional, prose-based requirements document and an IDS specification side by side and asks what each can express that the other can't. It's not a comparison between an old way and a new way. It's between two genuinely different kinds of artifact, and the difference between them matters more than picking a winner.

What a Traditional Requirements Document Actually Is

Before any standardised checking format existed, and in most projects still today, information requirements live in a document a client or lead party writes and issues contractually. In ISO 19650's language, this is the Exchange Information Requirements, a written specification of what information a project needs, produced by whom, and checked how. Its defining trait: it's read and interpreted by people. A reviewer opens it, opens the model, and judges by eye whether the model satisfies what was asked.

The Same Requirement, Written Two Ways

A prose requirement might read: "every reinforcing bar shall have its nominal diameter specified." The same requirement as an IDS specification is the exact file built in the previous lesson:

<ids:specification ifcVersion="IFC2X3" name="Rebar must have NominalDiameter">
  <ids:applicability>
    <ids:entity><ids:name><ids:simpleValue>IFCREINFORCINGBAR</ids:simpleValue></ids:name></ids:entity>
  </ids:applicability>
  <ids:requirements>
    <ids:attribute cardinality="required">
      <ids:name><ids:simpleValue>NominalDiameter</ids:simpleValue></ids:name>
    </ids:attribute>
  </ids:requirements>
</ids:specification>

Both say the same thing. One needs a person to check it. The other runs, and returns the same verdict regardless of who runs it.

What Prose Can Express That IDS Currently Cannot

This asymmetry is real. A project team documenting their own experience with IDS, published on buildingSMART's own site, put it directly: IDS operates at the IFC information and data-structure level, checks aren't applicable to geometric information such as dimensions, and checks requiring complex logical assessment are difficult to implement.

Worth being precise about where that line actually falls, since one common example gets it wrong if stated carelessly. "If the element is load-bearing, it must carry a fire rating" sounds like a conditional, but it's actually a case IDS handles cleanly: applicability narrows to elements where LoadBearing is TRUE, and the requirement, fire rating present, only applies to that narrowed set. That's an applicability constraint, not procedural logic, and it's well within what a specification can express.

What genuinely falls outside is logic that depends on something other than a single element's own attributes, project process state, aggregate facts across the whole model, or a comparison between two different elements' values. "The model shall be reviewed monthly" is a process requirement with no IFC content to check at all. "Dimensions shall be coordinated within 5mm of the architectural model" reaches into geometry IDS was never built to touch. Neither of these is expressible as an applicability filter, because neither reduces to a fact about one element's own data.

What IDS Can Do That Prose Alone Cannot

A prose requirement has no repeatable, tool-independent way to be checked. Two reviewers can read the same sentence and reach different conclusions about the same file. An IDS specification produces the same verdict every time, from any compliant tool, trading expressive range for something prose never had.

Why They Coexist Rather Than Compete

buildingSMART's own documentation states plainly that IDS is meant to be used in combination with other standards, specifically naming ISO 19650's Exchange Information Requirements, not as a replacement for the EIR but as a way to capture the parts of it that can be expressed in machine-checkable form. A project doesn't choose one over the other. It uses IDS for the subset of its requirements facets can express, and keeps the human document for everything still outside that boundary, process requirements, geometry, and logic that depends on more than one element's own data.