IDS Explained: Defining Information Requirements for BIM Models

Introduction

A BIM manager sends a subcontractor a two-page PDF listing every parameter their door models must carry: fire rating, manufacturer, classification code, warranty period. The subcontractor reads it, models the doors, exports IFC, and submits. Three weeks later, QA opens the model and finds half the doors are missing the fire rating field, a third have the classification code typed as free text instead of the required Uniclass value, and nobody notices until the fire strategy consultant asks why their schedule is empty.

This is not a modeling failure. It is a communication failure, and it is the exact failure that IDS (Information Delivery Specification) exists to close. Where a PDF requirement list depends on a human reading it correctly, an IDS file is a machine-readable specification that any IFC-checking tool can run automatically, the moment a model is exported, before it ever reaches a human reviewer. It is the newest and least understood piece of the openBIM stack, and it is quietly becoming one of the most useful tools a working BIM professional can pick up. This guide covers what IDS actually is, how the file is structured, the tools that read it, a worked example against a real Revit export, and the mistakes that stop teams from getting value out of it.

What IDS Actually Is

IDS is an open standard from buildingSMART International, the same body behind IFC and BCF. An IDS file (.ids, an XML document) describes a set of rules that an IFC model must satisfy. Each rule has two halves:

• Applicability: which elements the rule applies to. “All elements of type IfcDoor”, for example, or “all elements classified as Uniclass Pr_25_31.”
• Requirements: what must be true about those elements. “Must have a property called FireRating in the Pset_DoorCommon property set” or “the FireRating value must be one of 30, 60, 90, or 120.”

Run an IDS file against an exported IFC model and you get a pass/fail report, element by element, rule by rule. No human has to remember what the requirement list said. The check is the requirement list.

This matters because BIM information requirements have historically lived in prose: an Employer’s Information Requirements (EIR) document, a BIM Execution Plan (BEP) appendix, a spreadsheet somebody maintains alongside the model. Prose requirements get interpreted differently by every modeler who reads them, and nobody finds out about the gap until a schedule comes up empty or a facilities manager can’t find an asset tag six months after handover. IDS turns that prose into something a computer checks in seconds.

Where IDS Fits: IFC, BCF, EIR, BEP

IDS is the newest leg of what used to be a two-legged openBIM stool. It is worth being precise about how the pieces relate, because they solve different problems and get confused constantly.

Standard	What it moves	Question it answers
IFC	The model geometry and data	What does the building look like, and what data sits on each element?
BCF	The conversation about the model	Where is the problem, and who is fixing it?
IDS	The information requirements	What data is this model supposed to contain, and does it?
EIR	The client’s information demands (prose)	What does the appointing party need, in plain language?
BEP	The delivery team’s response (prose)	How will the team meet those demands, and with what standards?

The chain in practice: the client’s EIR states, in prose, what information the project needs at each stage. The delivery team’s BEP commits to specific standards and formats to meet that EIR. IDS is where those commitments become an executable file, so instead of “the BEP says all doors need a fire rating,” you have a rule a checker can run against every IFC export on every submission. IDS does not replace the EIR or BEP. It is the machine-readable expression of the parts of those documents that describe data requirements, and it is what turns “we agreed to this” into “we can prove this.”

Anatomy of an IDS File

An IDS file is built from specifications, and each specification pairs an applicability filter with one or more requirement facets. The facets are the building blocks, and there are five of them worth knowing:

1. Entity: filters by IFC class, such as IfcWall, IfcDoor, or IfcSpace.
2. Attribute: checks a native IFC attribute, like Name or Description.
3. Classification: checks that an element carries a classification reference (Uniclass, OmniClass, MasterFormat) and, optionally, a specific code or code prefix.
4. Property: checks a property set and property name exist, and optionally constrains the value (a fixed list, a numeric range, a pattern, or simply “must not be empty”).
5. Material: checks that a material or material layer is assigned.

A specification reads roughly like this in plain language: “Applicability: all IfcDoor elements classified under Uniclass Pr_25. Requirement: must have Pset_DoorCommon.FireRating populated, and the value must be one of 30, 60, 90, or 120 minutes.” Written as IDS XML, that becomes a rule any IDS-reading tool can evaluate without a human interpreting it twice.

IDS files also carry a specification-level cardinality, meaning you can mark a rule as required (must be present) or prohibited (must not be present), and you can scope requirements to a project phase or exchange, since what a model needs at Stage 3 design coordination is not what it needs at Stage 6 handover.

What IDS Actually Checks, With Examples

The gap between “IDS sounds abstract” and “IDS is obviously useful” closes the moment you see concrete rules. A few realistic examples from a typical UK or EU commercial project:

• Every door has a fire rating. Applicability: IfcDoor. Requirement: Pset_DoorCommon.FireRating exists and is one of an allowed set of values.
• Every space has a Uniclass classification. Applicability: IfcSpace. Requirement: classification reference present, code prefixed SL_25 (Uniclass spaces table).
• Every structural column has a load-bearing flag set correctly. Applicability: IfcColumn. Requirement: Pset_ColumnCommon.LoadBearing is TRUE.
• Every asset intended for the CAFM handover has an asset tag. Applicability: elements classified under agreed maintainable-asset codes. Requirement: a property named AssetTag, non-empty, matching a pattern like three letters and four digits.
• No element uses a generic, unclassified type. Applicability: all elements. Requirement: classification reference must be present (a prohibited-null check catching anything that slipped through without tagging).

None of these rules are exotic. They are exactly the kind of requirement that already lives in most EIR documents as a sentence. The difference is that an IDS-encoded version of the same requirement runs in seconds against a thousand-element model, and a prose version relies on someone remembering to check.

A Worked Example: Checking a Revit Export Against IDS

Here is what the workflow looks like end to end on a Revit-based project:

1. Author the IDS file (or receive one from the client or BIM manager) covering the requirements for the current stage: say, fire ratings on doors, classification on spaces, and asset tags on MEP equipment.
2. Model in Revit as normal, making sure the relevant shared parameters (FireRating, AssetTag) and classification fields (via Uniclass or the built-in Classification Manager) are populated as you go, not retrofitted at the end.
3. Export IFC using your project’s agreed IFC export setup, mapping Revit parameters to the correct IFC property sets. This step is where most IDS failures actually originate, not in the modeling itself. If the export mapping drops a parameter, the IDS check has nothing to read even though Revit shows the value clearly on screen.
4. Run the IDS check through an IDS-aware tool against the exported IFC file.
5. Read the report: a pass/fail per rule per element, usually with the failing elements listed by GUID so you can select them directly in Revit or a viewer.
6. Fix and re-export. Because the check is automatic and fast, this becomes a five-minute pre-submission habit rather than a QA milestone, and issues get caught before the model goes anywhere near the CDE’s Shared state.

The practical payoff shows up at handover. A project that has been running IDS checks throughout design and construction arrives at practical completion with an asset dataset that already conforms to the COBie or CAFM requirement, instead of a scramble to retrofit missing data into a model nobody wants to touch again after six months of construction changes.

Tooling: Where IDS Checking Actually Runs

IDS is still young compared to IFC and BCF, so tooling support varies, but it has grown fast since 2023 and the core options now cover most project needs.

Tool	What it does with IDS	Notes
buildingSMART IDS Audit tool	Free, open-source reference checker	Good for authoring and validating IDS files themselves before rolling them out
Solibri	Full IDS import and rule-based checking	Strongest for combining IDS checks with geometric and clash rules in one pass
BIMcollab	IDS support alongside its BCF issue workflow	Useful when your team already lives in BIMcollab for coordination
xbim Toolkit	Open-source library for building custom IDS checks	Fits teams with development capacity who want IDS checks in a CI pipeline
Revit / ArchiCAD plugins	Emerging native or third-party IDS validation before export	Check plugin coverage per authoring tool; native support is not universal yet

If your team is starting from zero, the workable sequence is: author and validate your IDS file with the free IDS Audit tool, run day-to-day checks through whatever coordination platform you already use for clash detection (Solibri or BIMcollab, most commonly), and only reach for a custom xbim pipeline once you have enough repeat projects to justify automating the check into a CI-style pre-submission gate.

Who Authors IDS, and When

IDS authorship needs an owner, and on most projects that owner is the BIM Manager or Information Manager, working from the EIR. The realistic sequence:

1. The appointing party’s EIR states information needs in prose, ideally stage by stage.
2. The BIM Manager translates the parts of the EIR and BEP that describe data requirements into one or more IDS files, one per exchange or project stage is a common pattern.
3. IDS files are issued to the delivery team alongside the BEP, not buried in an appendix nobody opens.
4. Each discipline runs the IDS check against their own model exports before submission, catching gaps before they reach the coordinator.
5. The IDS files get revised as the project moves stages, since requirements at concept design are lighter than requirements at handover.

Do not treat IDS as a one-time artifact. An IDS file authored at RIBA Stage 2 and never touched again will not reflect the far more detailed asset-data requirements at Stage 6, and a team dutifully passing an outdated IDS check will feel falsely confident right up until handover.

IDS vs Model Checking: Not the Same Job

It is worth being clear about what IDS does not do, because teams sometimes expect it to replace their existing model QA process. IDS checks information, meaning whether the right data fields exist and hold valid values. It does not check geometry health (duplicate elements, disconnected walls, unresolved warnings) and it does not run clash detection. Those remain the job of your model checking workflow and your coordination tool’s rule sets. A model can pass every IDS check and still be geometrically broken, and a model can be geometrically flawless while failing every IDS rule because nobody populated a classification field. Run both. They catch different failure classes, and a mature QA process treats IDS as one lane of a three-lane checking process alongside geometry health and coordination clash checks.

Common Mistakes

Writing the IDS file once and never updating it. Requirements change by project stage; a static IDS file quietly becomes wrong.

Treating IDS as documentation instead of a gate. An IDS file sitting in a project folder that nobody actually runs against exports delivers zero value. Wire it into the submission process, even if that just means “run the free tool before you upload to the CDE.”

Skipping validation of the IDS file itself. A malformed or overly strict IDS rule will fail every submission for reasons that have nothing to do with model quality. Validate new IDS files with the reference tool before issuing them to the team.

Assuming Revit parameters survive IFC export automatically. The single most common real-world IDS failure is a parameter that is populated correctly in Revit but never gets mapped into the right IFC property set on export. Fix the export mapping, not the model, when this happens.

Writing rules too strict for the current stage. Demanding asset tags at concept design, before manufacturers are even selected, produces a check nobody can pass and teaches people to ignore IDS failures generally.

One IDS file for the whole project lifecycle. Split requirements by stage or exchange so early-stage models are not held to handover-stage standards, and vice versa.

No agreed owner. If nobody is responsible for maintaining the IDS files as the project evolves, they fossilize at whatever state they were authored in and stop being trustworthy.

Best Practices

1. Assign IDS ownership explicitly, usually the Information Manager or BIM Manager, and name them in the BEP.
2. Author one IDS file per project stage or exchange, not one file for the whole project.
3. Validate every IDS file with the reference tool before issuing it to the delivery team.
4. Run IDS checks locally before CDE submission, not as a surprise gate at the coordinator’s desk.
5. Pair IDS checks with your existing model QA and clash workflows, never as a replacement for either.
6. Keep rules achievable for the current stage and tighten them as the project matures.
7. Fix export mappings, not just models, when a value that looks correct in the authoring tool fails the IDS check.
8. Review and reissue IDS files at each stage gate, alongside the BEP review cadence.
9. Report failures by element GUID, so modelers can select and fix directly rather than hunting.
10. Pilot on one discipline before rolling out project-wide, the same way you would pilot a BCF round-trip, so tooling gaps surface while they are cheap.

Where IDS Fits in the Bigger openBIM Picture

IDS completes the openBIM triangle. IFC carries the model. BCF carries the conversation about problems in the model. IDS carries the specification for what the model is supposed to contain in the first place, and checks it automatically. Together, the three standards let a project run entirely on open, vendor-neutral formats: no single software vendor controls whether your data requirements get checked, your issues get tracked, or your models can be exchanged.

If your projects run under ISO 19650, IDS is where the EIR’s data requirements stop being a document people reference from memory and start being a specification a machine enforces on every submission. That is a meaningful upgrade for any BIM professional responsible for information management, because it moves quality control from “did someone remember to check” to “the check ran automatically and here is the report.”

IDS is still maturing, and tooling support will keep expanding over the next few project cycles. Getting comfortable with it now, while adoption is a genuine differentiator rather than table stakes, is a good investment for anyone building a BIM coordination or information management career. If you are building toward that kind of role, our BIM and Revit courses teach these openBIM workflows the way real project teams run them, taught by a working BIM Coordinator.

The Bottom Line

IDS turns information requirements from prose that everyone interprets slightly differently into a file a computer checks in seconds. Pair it with the IFC models it validates and the BCF conversations it can trigger when a check fails, author it stage by stage with a clear owner, and fix your export mappings when a value that looks right in the authoring tool comes back failed. Do that consistently and the gap between “we specified this” and “the model actually has this” closes before it ever reaches a schedule, a facilities manager, or a client asking why their handover data is empty.