IDS Explained: How Machines Check If Your BIM Model Is Actually Compliant

Everyone talks about information requirements. Fewer people can explain how anyone actually checks that a model meets them. For years the honest answer was that someone opened the model, opened the requirements document, usually a PDF or an Excel sheet, and compared the two by eye. IDS exists to close that gap, turning information requirements into a file a computer can check automatically, instead of a document a person has to interpret correctly every time.

What is IDS in BIM?

IDS stands for Information Delivery Specification. It is a buildingSMART standard for defining information requirements in a way that is easily read by humans and interpreted by computers. In practice, that means an XML file that spells out exactly what a BIM model needs to contain, which properties, which quantities, which classifications, on which types of objects, so that meeting or missing those requirements becomes something a piece of software can check, not something a reviewer has to remember to look for.

The standard was developed with input from over 200 people across 34 countries, clients, modellers, software vendors, and governments, and was approved as a final buildingSMART standard, version 1.0, on 4 June 2024, with more than a dozen stable implementations already available at the time of release.

The problem it actually solves

Information requirements have traditionally been shared as Excel sheets or PDFs. That works fine until a project has dozens of these documents spread across an appointing party, a lead appointed party, and a chain of task teams, each interpreting slightly ambiguous wording their own way. A requirement like "every door must have a fire rating" is clear to a person reading it carefully. It is not something software can enforce, because nothing about a PDF tells a validation tool what to look for or where.

IDS solves this by giving that same requirement a structured, machine readable form. Once it is written as an IDS file, checking a delivered model against it stops being a manual review task and becomes something that runs automatically, the same way a spell checker catches a typo instead of relying on someone reading every word.

What IDS can and cannot specify

IDS lets you require that specific properties, quantities, attributes, materials, classifications, entity types, and relationships, including part of relationships between objects, exist on a model. What it deliberately does not do is define design rules or specific values.

• What IDS can enforce: that every window in the model carries a property defining its glass type.
• What IDS cannot enforce: that a specific window, say in a bathroom, must use opaque glass rather than clear glass.

That distinction matters. IDS checks that the information is there and structured correctly. It does not, and is not meant to, replace design judgement or project specific rules about what that information should say.

IDS versus the buildingSMART Validation Service

It is easy to confuse IDS with buildingSMART's free IFC Validation Service, but they check different things. The Validation Service, available at validation.buildingsmart.org, checks whether an IFC file is structurally sound: correct STEP syntax, conformity with the current IFC schema, and compliance with normative IFC rules. It is a general check that applies to any IFC file, regardless of project.

What the Validation Service explicitly does not check is project specific, organisation specific, or national specific requirements, and buildingSMART's own documentation points to IDS as the way to cover exactly that gap. In short, the Validation Service asks whether a file is a valid IFC file at all. IDS asks whether this particular model contains what this particular project actually needs.

How IDS relates to IFC and MVD

IDS works with data structured according to IFC, the open, vendor neutral BIM data format behind openBIM. Before IDS existed, the closest equivalent for defining what a model exchange should contain was the Model View Definition, or MVD, a more rigid, harder to author mechanism aimed at software implementers rather than project teams. IDS is widely regarded as an evolution of that idea: a lighter, more flexible way for a project team, not just a software vendor, to define and check its own exchange requirements.

Results from an IDS check can also be shared using the BIM Collaboration Format, BCF, the same open format used to track issues and clashes, so a failed requirement can flow into the same workflow a team already uses for coordination.

Why this matters for your information management workflow

None of this requires you to become a standards expert. What it means in practice is that the information requirements your project already writes down, in an Exchange Information Requirement, a BIM Execution Plan, or a client brief, can eventually stop being a document someone has to remember to check against, and start being something that gets verified automatically, every time a model is delivered. That is the same shift towards structured, checkable information that runs through ISO 19650 and the Common Data Environment, and IDS is the piece that makes the checking part of it real rather than aspirational.

Frequently asked questions