An IDS (Information Delivery Specification) is a buildingSMART XML standard, published as IDS 1.0, that describes which information an IFC model must contain — for example "every IfcWall must have a FireRating property in Pset_WallCommon". Because it is machine-readable, any conforming tool can check a model against it and get the same answer.

What are the six IDS facets?

Entity (the IFC class and predefined type), Attribute (a direct IFC attribute such as Name), Classification (a classification reference such as Uniclass or OmniClass), Property (a property inside a property set, optionally with a data type and value), Material, and PartOf (a relationship to a parent such as a storey, assembly or group). Each facet can be used to select elements (applicability) or to demand something of them (requirements).

Can I check an IFC against an IDS without installing software?

Yes. IFC Viewer Online reads the .ids file and the IFC in your browser, evaluates all six facets of IDS 1.0 locally, and highlights or isolates the failing elements in 3D. Neither file is uploaded to a server.

What is the difference between IDS and a model checker rule set?

A model checker rule set is usually proprietary to one tool and often tests geometry (clashes, clearances). IDS is an open standard that tests information only — classes, properties, values, classifications, materials and relationships — so the client can write it once and every supplier can run it in any tool.

Back to the BIM & IFC blog

Validation · 2026-10-01 · 12 min

IDS Explained: How to Check an IFC Model Against an Information Delivery Specification

IDS turns "the model must contain the fire rating" from a sentence in a PDF into a file a machine can check. Here is what the six facets actually test, where most IDS files go wrong, and how to run one against your IFC in a browser.

IDS Explained: How to Check an IFC Model Against an Information Delivery Specification — IFC Viewer Online article cover

Every EIR ever written contains a sentence like "all doors shall carry their fire rating". And on every project, that sentence is checked the same way: somebody opens the model, clicks on a few doors, and decides it is probably fine. The requirement is precise. The check is a vibe.

IDS — the Information Delivery Specification — exists to close that gap. It is a small XML format, standardised by buildingSMART as IDS 1.0, that states information requirements in a form a machine can test. Write the requirement once, hand the .ids file to every supplier, and "probably fine" becomes "412 of 418 doors pass; here are the six that do not".

Key takeaways

IDS checks information, not geometry: classes, attributes, properties, classifications, materials and relationships.
Every specification has two halves — which elements it applies to, and what those elements must have. Most broken IDS files get the first half wrong.
An IDS is a contract artefact. It belongs next to the BEP, versioned, and it is sent to suppliers before modelling starts, not after the first rejection.

The anatomy of a specification

Diagram of an IDS specification: applicability (entity, classification, partOf) selects elements, requirements (property, attribute, material) are tested on them — An IDS specification reads as one sentence: for every element matching the applicability, require the requirements.

An IDS file is a list of specifications. Each one reads like a sentence with a subject and a predicate: "for every element matching this, require that". The subject is the applicability; the predicate is the requirements.

<specification name="Doors carry a fire rating" ifcVersion="IFC4">
  <applicability minOccurs="1">
    <entity><name><simpleValue>IFCDOOR</simpleValue></name></entity>
  </applicability>
  <requirements>
    <property dataType="IFCLABEL">
      <propertySet><simpleValue>Pset_DoorCommon</simpleValue></propertySet>
      <baseName><simpleValue>FireRating</simpleValue></baseName>
    </property>
  </requirements>
</specification>

Read it aloud and it is exactly the EIR sentence: every IfcDoor must have a FireRating in Pset_DoorCommon, stored as a label. The minOccurs="1" on the applicability adds a second, easily-missed claim — the model must contain at least one door. Without it, a model with no doors at all passes, which is rarely what anybody meant.

The six facets, and what each one really tests

Facet	Tests	Typical requirement	Common trap
Entity	IFC class and predefined type	Walls are IfcWall, not IfcBuildingElementProxy	Forgetting subtypes: IfcWallStandardCase is an IfcWall in IFC2x3
Attribute	Direct IFC attributes (Name, Description, Tag…)	Every space has a Name and a LongName	An empty string is present-but-invalid, not absent
Property	A property in a property set, with data type and value	Pset_WallCommon.IsExternal is TRUE or FALSE	Right value, wrong data type (a label where a boolean was asked)
Classification	A classification reference and its code	Every element has a Uniclass Ss code	Checking the code but not the system it belongs to
Material	An associated material name or category	Structural columns declare a material	Materials on the type, not the occurrence
PartOf	A relationship to a parent element	Every element is contained in a storey	Confusing aggregation with spatial containment

Each facet can appear in applicability (to select elements) or in requirements (to demand something of them).

Two of those traps deserve a longer look, because they account for most of the false failures people report when they first run an IDS.

Type versus occurrence

Diagram showing an IFC property set attached to an IfcWall occurrence and to its IfcWallType, whose properties every occurrence inherits — Properties can sit on the type rather than the occurrence. An IDS checker must follow the type, or it fails elements that are fine.

Revit, ArchiCAD and Tekla routinely write properties and materials on the type object (IfcWallType) rather than on each wall. The IDS semantics are clear that information inherited from the type counts for the occurrence. A checker that only looks at the occurrence will fail every wall in a perfectly good model. If an IDS run tells you that 100% of your elements are missing a property you can see in the properties panel, this is almost always the reason — and the fault is the checker's, not yours.

USERDEFINED predefined types

When a predefined type is USERDEFINED, the real type lives in ObjectType (on occurrences) or ElementType (on types). An entity facet asking for IFCWALL with predefined type PARAPET should match a wall whose PredefinedType is USERDEFINED and whose ObjectType is PARAPET. Checkers that compare the raw enum miss every one of them.

Five mistakes that make an IDS useless

Applicability that is too broad. "All elements must have a Uniclass code" sweeps in openings, annotations and spatial elements that nobody classifies. Scope specifications to the classes the requirement is really about.
Values without a data type. A requirement of FireRating = "EI 60" says nothing about how it must be stored; the same text stored as a description in another pset still fails. Say what you mean, including the data type.
Exact values where a pattern was meant. Real data has "EI60", "EI 60" and "EI-60". Use an xs:pattern or an enumeration, and agree the canonical form in the BEP.
One giant specification. Forty requirements in one specification produce one pass or fail per element and a report nobody can act on. One requirement per specification, named in plain language, is what makes the result readable.
Writing the IDS after the model. An IDS sent with the first rejection is a new requirement. An IDS sent with the appointment is a requirement. Only the second one is enforceable.

The contract side of that last point — which clauses make an IDS binding and what happens when a delivery fails it — is covered in BEP clauses that actually prevent bad IFC deliveries and IFC acceptance criteria.

Running an IDS against your model, step by step

Open the IFC Drag the model into the viewer. It is parsed in your browser; nothing is uploaded.
Load the .ids file Open the IDS panel and choose your file — or start from one of the bundled example specifications if you want to see the format first.
Run the check Every specification is evaluated with all six facets. Large models show progress by phase and can be cancelled at any time.
Read the result by specification, element or class Group failures the way you intend to fix them. Each failure carries the reason in plain words: missing property, wrong value, wrong data type, wrong class.
See it in 3D Highlight colours failing elements in the model; Isolate hides everything else. Both are one click, and they are how a list of GlobalIds turns into a conversation with the modeller.

IDS across revisions

A single IDS run is a snapshot. What a coordinator actually needs is the trend: did revision 7 fix the failures raised on revision 6, and did it introduce new ones? Because the result is keyed by GlobalId, the same specification can be compared across two versions of a model — which only works if your GlobalIds are stable between exports. If they are not, fix that first: why IFC GUIDs change on every export. The comparison itself is covered in how to compare two versions of an IFC model.

Where IDS stops

IDS does not check geometry. It will not tell you that two ducts clash, that a door is too narrow for a wheelchair, or that the model sits two kilometres from its survey point. It also does not check that an IFC is structurally sound — a file with duplicate GlobalIds or broken placements can pass an IDS perfectly.

That is not a weakness; it is scope. Use IDS for information requirements, a model checker for structure and geometry, and keep the two reports side by side in the delivery. The broader workflow is in how to validate an IFC file.

IDS Explained: How to Check an IFC Model Against an Information Delivery Specification