IDS — Information Delivery Specification

Why it exists

In classical BIM workflows the client describes information requirements in an EIR or AIA — as a PDF, with tables, lists, examples. The contractor delivers an IFC model. Whether the model actually meets the requirements is checked at the end by a person with spot checks. Or not at all.

IDS flips this around: the requirement itself becomes a file that a checker tool runs automatically against an IFC model. Pass or fail comes with concrete pointers to which property on which component is missing or has the wrong value.

Practical consequence: EIR / AIA remain as legal contract text. The technical requirement definition moves into a versionable, checkable IDS file.

Version status

IDS 1.0 is the first final standard in this domain. Before it there were only informal XML schemas or proprietary solutions (Solibri rules, BIMQ, Plannerly templates).

What IDS can check

IDS addresses the alphanumeric layer of an IFC model. Geometry requirements remain the job of MVDs and LOIN. Concretely IDS can formulate requirements on:

• Entity types — e.g. “there must be IfcWall instances”
• Properties — e.g. “every wall must carry Pset_WallCommon.FireRating”
• Values — e.g. “with values from the list REI30 / REI60 / REI90”
• Quantities — e.g. “Qto_WallBaseQuantities.GrossArea is mandatory and greater than 0”
• Materials — e.g. “material assigned from list {masonry, concrete, steel}”
• Classifications — e.g. “eBKP-H code linked via IfcRelAssociatesClassification”
• partOf dependencies — e.g. “every window is part of a wall”

IDS therefore has four building blocks that are combined in every specification: applicability, requirement, reference to IFC version, and cardinality (required, optional, prohibited).

Structure of an IDS file

IDS files are XML, defined by a clear XSD schema. The root element is ids:ids. Example:

<ids:ids xmlns:ids="http://standards.buildingsmart.org/IDS"
         xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <ids:info>
    <ids:title>Fire-rating requirements, sample project</ids:title>
    <ids:version>1.0</ids:version>
    <ids:author>bauamt@example.org</ids:author>
    <ids:date>2026-04-15</ids:date>
    <ids:description>Mandatory requirements, detailed design phase</ids:description>
    <ids:purpose>LP4</ids:purpose>
  </ids:info>
  <ids:specifications>
    <ids:specification ifcVersion="IFC4X3" name="Walls need fire-rating value">
      <ids:applicability minOccurs="0" maxOccurs="unbounded">
        <ids:entity>
          <ids:name><ids:simpleValue>IFCWALL</ids:simpleValue></ids:name>
        </ids:entity>
      </ids:applicability>
      <ids:requirements>
        <ids:property dataType="IFCLABEL" cardinality="required">
          <ids:propertySet>
            <ids:simpleValue>Pset_WallCommon</ids:simpleValue>
          </ids:propertySet>
          <ids:baseName>
            <ids:simpleValue>FireRating</ids:simpleValue>
          </ids:baseName>
          <ids:value>
            <xs:restriction base="xs:string">
              <xs:enumeration value="REI30" />
              <xs:enumeration value="REI60" />
              <xs:enumeration value="REI90" />
            </xs:restriction>
          </ids:value>
        </ids:property>
      </ids:requirements>
    </ids:specification>
  </ids:specifications>
</ids:ids>

In plain English: “Every IfcWall instance must have the property FireRating in the set Pset_WallCommon, and its value must be one of REI30, REI60, REI90.” A checker loads the IDS file plus an IFC model and immediately shows which walls comply and which do not.

Relationship to bSDD

Property names like Pset_WallCommon.FireRating are human-readable — but language- and version-dependent. IDS specifications often additionally reference a bSDD URI:

<ids:property dataType="IFCLABEL"
              uri="https://identifier.buildingsmart.org/uri/buildingsmart/ifc/4.3/prop/FireRating"
              cardinality="required">
  ...
</ids:property>

The URI is language-neutral, unique, versioned and resolvable in multiple languages. That is exactly what bSDD is for.

Relationship to MVD, IDM, LOIN

In practice they work together: IDM describes the process. LOIN defines the depth. MVD sets the schema footprint. IDS makes it checkable.

Tool support (2026)

The tool landscape has grown significantly within 18 months of the IDS final release. When selecting: separate authoring from checking — many tools do only one of them.

Mapping to signed events

BIM-CVP models IDS specs as parameterised replaceable events:

kind:30810  IDS Specification (replaceable)
  d: <spec-guid>
  tags: [
    ["title",         "Fire-rating requirements, sample project"],
    ["a",             "<project-ref>"],
    ["ids-version",   "1.0"],
    ["ifc-version",   "IFC4X3"],
    ["purpose",       "LP4"],
    ["author-pubkey", "<client-npub>"],
    ["x",             "<sha256-of-ids-xml>"]
  ]
  content: the full ids-XML (for small specs)
           or a Blossom URL reference (for large ones)

Validation results are published separately:

kind:1180  IDS Validation Result (immutable)
  tags: [
    ["e",         "<ids-spec-event-id>"],     # which IDS
    ["e",         "<ifc-file-event-id>"],     # which IFC
    ["x",         "<report-sha256>"],
    ["result",    "pass"],                       # pass / fail / warning
    ["validator", "<tool-npub>"],
    ["summary",   "147/150 walls compliant, 3 warnings"]
  ]
  content: full report (JSON or Blossom URL)

Validation can be run by any accredited validator service.

Italian UNI 11337 mapping

The Italian BIM contract framework uses similar concepts under different names:

For Italian public tenders (DM 312/2021) the Capitolato Informativo is the binding document. IDS can be attached as the technical check layer.

Sources

• buildingSMART IDS standard page
• buildingSMART IDS repository
• IDS 1.0 XSD schema
• List of IDS-capable software