What problem IDS solves
Before IDS, "what must this model contain" lived in a PDF employer's information requirements document, interpreted differently by every modeller who read it, and checked — if at all — by a person clicking through the model by hand. Two structural problems follow from that: the requirement is not machine-readable, so it cannot be checked automatically, and there is no single source of truth, so a supplier and a client can honestly disagree about what "compliant" means.
IDS fixes both. A client (or a subcontractor writing their own internal standard) states requirements once, as XML, and hands that file to every supplier. Any IDS-capable tool — ClearIFC, Solibri, or others — reads the same file and produces the same verdict. The specification stops being a document you interpret and becomes a file you run.
IDS is a buildingSMART open standard, not a ClearIFC format. A file you build here works in any IDS-capable tool, and a file a client hands you from anywhere else works here. See buildingSMART's own IDS page for the formal specification.
The anatomy of a specification
An IDS document is one or more specifications. Each specification has exactly two parts:
- Applicability — which elements this rule applies to. "All
IfcWall", or "everything classified under a given Uniclass table". - Requirements — what must be true of every element that matches. "Must
carry
Pset_WallCommon.FireRating", or "must not exist at all" (see Cardinality below).
A checking tool reads applicability first to work out the population, then tests every element in that population against every requirement. Nothing outside the matched population is touched by that specification — a rule about walls has no opinion on doors.
The six facet types
Both applicability and requirements are built from facets — individual testable statements. The same six facet types serve both halves: in applicability they select a population, in requirements they test it.
entity
The IFC class, and optionally its predefined type. The most common applicability facet — almost every specification starts with one.
attribute
A direct IFC attribute such as Name or Tag, with an
optional value constraint.
property
A property inside a named property set, with an optional value, enumeration, pattern or numeric range constraint. The workhorse of most real specifications.
classification
A classification reference, optionally restricted to a named system (Uniclass, OmniClass...) and a code pattern.
material
The element's associated material, optionally matching a specific value.
partOf
The element's place in a decomposition or containment relationship — "must be part of an IfcElementAssembly", for example.
Cardinality: required, optional, prohibited
Every requirement facet carries a cardinality, which decides how a mismatch is judged:
| Cardinality | Meaning | An element with no value | An element with a wrong value |
|---|---|---|---|
| Required | Every matching element must satisfy this | Fails | Fails |
| Optional | If present, it must be correct — but absence is fine | Passes | Fails |
| Prohibited | Matching elements must NOT satisfy this | Passes | Fails (the prohibited thing exists) |
Population cardinality works the same way one level up: a specification can require at
least one matching element to exist (minOccurs), or forbid the population
from existing at all (maxOccurs="0") — useful for "no IfcProxy
elements are permitted in this delivery".
A worked example
A common real requirement: every external wall must declare a fire rating from Pset_WallCommon. As IDS:
Read it in two halves. Applicability narrows the population to walls where
IsExternal is true — not every wall, only external ones. Requirements then
demand FireRating be present on every wall in that narrowed population. A
checking tool reports every external wall missing a fire rating by GlobalId, type and
name — precisely what ClearIFC's IDS check does.
Two ways to build an IDS
- Write or receive the XML directly. If a client or head contractor has already issued an IDS, you do not need to build anything — upload it straight to ClearIFC's validator, or use the free Inspect tool to read what it asks for before you run anything against it.
- Use a form-based rule builder. ClearIFC's Professional tier includes a rule builder: choose an element type, a property set and property (or classification, attribute or material), pick a constraint, and the tool writes valid IDS XML for you — no hand-written XML required. The generated file is shown in full and is exportable, so it stays portable to any other IDS-capable tool rather than locking you into one product.
What a ClearIFC IDS report tells you
Each specification in an uploaded IDS becomes one row in the results dashboard, alongside the built-in schema/spatial/property/GUID/geometry/classification checks. For each one you get:
- How many elements matched the applicability, and how many of those were compliant
- Every failing element by GlobalId, IFC type and name, with the specific reason it failed
- The specification author's own instructions, if they wrote any, carried through to the failure message — so whoever fixes the model is told how, not just that
A specification whose applicability matches nothing in the model is reported as skipped rather than passed, so an empty population never masquerades as compliance.
Starter files and further reading
Three ready-to-use IDS files, and two sample IFC models to try them against, are free on the homepage — no account required. For the formal specification itself, see buildingSMART's IDS standard page and the reference schema on GitHub.