BIM requirements and IDS

Definition of an IDS, compared with a BIM charter and a brief

An IDS (Information Delivery Specification) is an XML file standardized by buildingSMART that describes, in a form software can check, the information an IFC model must contain. The file uses the .ids extension. Version 1.0 was published as a final standard by buildingSMART in June 2024, and its documentation is public on GitHub.

The BIM charter and the brief remain documents written for people. They explain the why: who models what, at which phase, with what level of detail, under which naming conventions. A human reader interprets them, and two readers may interpret them differently.

The IDS takes over the checkable part of these documents. "Walls must carry their fire rating" becomes a precise rule: objects of class IFCWALL must have the FireRating property in the Pset_WallCommon set, with a defined data type. Whatever belongs to explanation, organization or geometry stays in the charter. An IDS therefore does not replace the brief; it gives a version of it that a machine can check on every delivery.

What an IDS file contains: specifications, facets and cardinality

An IDS file holds metadata (title, author, version) followed by one or more specifications. Each specification states the IFC versions it targets, among IFC2X3, IFC4 and IFC4X3_ADD2, and splits into two parts. Applicability says which objects the rule is about. Requirements say what those objects must carry.

Both parts are built from the same blocks, called facets. There are six: entity (the IFC class, possibly with its predefined type), attribute (a native attribute such as Name or Description), classification (a system and a reference), property (a property in a property set), material (an associated material) and partOf (membership of a parent, for example a storey or a group). The buildingSMART user manual details each of them.

Cardinality changes the meaning of a rule. On applicability, "required" means at least one matching object must exist in the model; "optional" checks the objects present without demanding any; "prohibited" forbids those objects, and the requirements are then ignored. On a requirement facet, "required" means the information must exist with the right type and a non-empty value, "optional" that it must comply if present, "prohibited" that it must not exist.

Values can be fixed or constrained by a restriction: a list of allowed values, a pattern (a regular expression in XML Schema format), numeric bounds or a length. Measures are expressed in SI units. IDS cannot require a length to be entered in a given unit, only check its value.

What the standard does not cover matters just as much. An IDS does not check geometry, does not compute values and does not fetch data from outside the model. It also assumes a valid IFC file: a malformed file must be fixed before any requirement check, which is the subject of the IFC model quality audit topic.

IDS in SeveUp App

Requirement sets live in the "BIM requirements" library. The "Import IDS files" button accepts .ids files and workbooks based on the IDS Excel template (.xlsx). A workbook is converted to .ids, and the original is kept. Import runs in three steps, "Files", "Names" then "Link", the last one attaching each set to existing folders. Each file becomes a separate requirement set.

When requirements only exist in documents, the "Create BIM requirements" task starts from those documents: Word, Excel, PDF, CSV or text. AI extracts rules from them and spots conflicts, meaning rules that target the same thing with different constraints. The "Axes" step lets you adjust the zones, disciplines and phases that drive the split into several IDS files. You then approve, reject or edit each rule. A rule whose quote cannot be found in the source document is left out of "Approve all": it has to be validated by hand.

The rule form mirrors the notions of the standard. You pick the rule type ("Property (pset)", "IFC attribute", "Classification", "Material", "Part of (partOf)" or "IFC class"), the cardinality ("Required", "Optional (checked if present)" or "Prohibited") and the expected value, from presence only up to a threshold. The "Required in the model" box matches required applicability: when checked, the model must contain at least one targeted object, otherwise the check fails. The "Compile IDS files" button finally produces files validated with ifctester, the open-source tool from IfcOpenShell.

Once an IDS is attached, the audit runs on model revisions. A folder's "IDS conformity" view averages the scores over applicable requirements only and lists the most-failed requirements in the batch. Results also feed the "BIM compliance" dashboard, whose "BIM requirements" step lets you leave a set out, and the data export, which offers the "IDS validity by model" and "IDS validity by entity" tables.

Enlarge

From requirement to report, step by step

The shortest route starts from an existing IDS. The help guide check BIM requirements with IDS shows every screen; here is the sequence.

1. Open "BIM requirements", then "Import IDS files". Drop one or more .ids or .xlsx files.
2. At the "Names" step, check the name and description of each set. At the "Link" step, attach them to the relevant folders.
3. Without an IDS, go through "Tasks", then "Create BIM requirements": upload your documents, launch the extraction, review the axes, validate the rules, then click "Compile IDS files".
4. Upload or update your IFC models in the folder. Each revision is checked against the attached sets.
5. Read the result in the folder's "IDS conformity" view, then generate a report with "Create a dashboard", keeping the requirements you want at the "BIM requirements" step.

Enlarge

Common mistakes in an IDS

The most costly one comes from a list of property sets. In IDS 1.0, when a requirement names several Psets, the property must be in each listed Pset present on the object, not in one of them. These requirements fail even when the model carries the property. SeveUp App flags this case on a requirement set's page and offers "Fix: one Pset per property", which publishes a new version while keeping the previous one in the history.

Inheritance is another surprise. The entity facet does not reach subclasses automatically: targeting IFCWALL does not cover IFCWALLSTANDARDCASE in an IFC2X3 file, you have to list both. Abstract classes such as IfcBuildingElement are not meant for this. In the rule form, a class name unknown to the IFC2X3, IFC4 and IFC4X3 schemas raises a warning.

The Pset_ and Qto_ prefixes are reserved for buildingSMART standard sets. A custom set starting with Pset_ creates a rule that cannot be met cleanly; the form flags this too. On values, an imposed value requires a data type, written in capitals (IFCLABEL, IFCLENGTHMEASURE). And a bound is given in base SI units: metres, not millimetres.

Regular expressions often trip people up. The pattern DT. accepts DT1 but rejects DT01, and .*DT.* accepts "DT" on its own. For a fixed length, a length restriction reads better than a pattern. The last case concerns cardinality: an optional rule on a model that contains no targeted object is "not applicable". It does not count as a failure, but it checked nothing. If the object must exist, tick "Required in the model".

Going further

The article IDS, the file that makes BIM requirements checkable looks at where the format comes from and its place in a project. Once deviations are found, the right people need to fix them: the BCF and collaboration topic covers exchanging issues between tools. And for the health of the file itself, before any requirement, see IFC model quality audit. To find a non-compliant object in the scene, the IFC viewer page shows what you can do there. If your client expects asset data at handover, COBie explains what that format contains, and our IFC 2x3 vs IFC 4 comparison helps you target the right IFC version in a requirement.