An IDS file is an XML file, ending in .ids, that lists the information an IFC model must contain — which elements must have which attributes, properties, classifications, materials or relationships, with which values. Software can check a model against it automatically.

Which IFC versions does IDS support?

IDS 1.0 covers IFC2X3, IFC4 and IFC4X3_ADD2. Each specification in an IDS file states which of these schemas it is written for.

Does IDS check geometry?

No. IDS describes the information a model carries, not its shape. Clashes, clearances and other spatial rules are checked in a model-checking tool, not with IDS.

How can I check an IFC model against an IDS file for free?

Bimlyte checks IFC models against IDS 1.0 files in the browser for free, without uploading the model, and shows the result as a report, as colours on the 3D model and as an Excel export.

← Blog

October 31, 2026

What is IDS? The Information Delivery Specification explained

Quick answer: IDS (Information Delivery Specification) is the buildingSMART standard for writing information requirements in a form software can check. An IDS file says which elements of an IFC model must carry which information — a property, a classification, a material — and a checker reports, element by element, whether the model delivers it. IDS 1.0 was approved as a final standard in June 2024.

Every BIM project has information requirements. The client needs fire ratings on doors, a classification code on every space, a load-bearing flag on every wall. For years those requirements lived in PDFs and spreadsheets, and checking a model against them meant opening it and looking, property by property.

IDS changes the format of the requirement, not its content. The same rules are written once as a file, and from then on any IDS-capable tool can check any delivered IFC model against them in seconds.

What is inside an IDS file?

An IDS file is XML, defined by an XSD schema that buildingSMART publishes. It contains a short header — title, author, version — and a list of specifications.

Each specification is one rule with two halves:

Applicability — which elements the rule is about. For example, every IfcDoor, or every element classified as an external wall.
Requirements — what those elements must have. For example, a FireRating property in Pset_DoorCommon, with a value from a fixed list.

Both halves are built from the same six facets:

Facet	What it describes
Entity	The IFC class, and optionally its predefined type
Attribute	A direct IFC attribute such as `Name` or `Description`
Property	A property in a property set, with its data type
Classification	A classification reference, such as a Uniclass code
Material	The material assigned to the element
PartOf	Where the element belongs — an assembly, a storey, a group, a void

Values, restrictions and cardinality

A facet can ask for an exact value, or for a restriction:

an enumeration — the value must be one of a list;
a pattern — the value must match a regular expression, which is how naming conventions are checked;
bounds — a number must sit within a range;
a length — text must have an exact, minimum or maximum number of characters.

Requirements also carry a cardinality. Required means the information must be there; optional means it may be missing but, if present, must be right; prohibited means it must not be there at all. The same three words apply to a whole specification: a required specification fails if no matching element exists, and a prohibited one fails if any does — which is how an IDS forbids, for instance, proxy elements.

Which IFC versions does IDS cover?

IDS 1.0 covers IFC2X3, IFC4 and IFC4X3_ADD2. Each specification declares which of these it is written for, so one IDS file can carry rules for models in different schemas.

Properties and classifications can also point to a definition in the buildingSMART Data Dictionary (bSDD) through a URI. That link documents where a requirement comes from; it is not itself checked.

What IDS does not do

IDS checks information, not geometry. It cannot express that a duct must clear a beam, that a corridor must be wide enough, or that two models must not overlap. Those are jobs for a model checker.

IDS also does not define a result format. Tools present their results in their own way — as a report, as colours in a viewer, as a spreadsheet or as BCF issues.

Who uses IDS, and where it comes from

IDS is maintained by buildingSMART International, the body behind IFC and BCF. After a candidate phase, IDS 1.0 was approved as a final buildingSMART standard in June 2024, and buildingSMART is collecting feedback for later versions.

To make sure tools agree on what a rule means, buildingSMART publishes an official set of test cases: pairs of IDS and IFC files with the expected result for each. A separate IDS Audit tool checks whether an IDS file itself is valid — it audits the requirement, not the model.

In practice, an IDS file usually comes from the client or the BIM manager, often derived from the project’s information requirements, and is handed to every team that delivers a model.

How to check a model against an IDS file

You need two things: the IFC model and the .ids file. Then:

Open the model and the IDS file in an IDS-capable tool.
Run the validation.
Read which specifications pass and which elements fail, and why.
Fix the model — or the export settings — and run it again.

Bimlyte does this in the browser, for free: it supports all six facets and every restriction, passes all 334 official buildingSMART IDS test cases in its own tests, and keeps the model on your device. The report shows the values each failing element actually holds next to the value the IDS requires, colours the result on the 3D model and exports to Excel.