From information requirements to IDS: making them checkable
Quick answer: Information requirements state what a project must deliver; the BIM execution plan says how the team will deliver it. The part that concerns model data — which elements carry which properties, classifications and materials — can be written as an IDS file. That turns a requirement in a PDF into a rule any software can check automatically against every delivered IFC model.
On many projects the real effort is not modelling but proving: does the delivered model actually contain everything the requirements ask for? As long as the requirements exist only as a document, the answer is “open the model and look” — and gaps surface late, often at handover.
Where the requirements come from
Under ISO 19650, the client’s information needs are defined through information requirements, including project information requirements (PIR). These are translated into exchange information requirements (EIR), specifying what information must be delivered and when. The delivery team responds with a BIM Execution Plan (BEP) describing how information will be produced, managed, and exchanged, including responsibilities, processes, and tools. In Germany, the corresponding documents are commonly known as AIA (Auftraggeber-Informationsanforderungen) and BAP (BIM-Abwicklungsplan), as described in VDI 2552 Blatt 10.
Both documents cover far more than model data: responsibilities, dates, approval processes, exchange formats. But one part of them is very concrete — and that is the part that can be automated.
Which part becomes IDS
Anything that can be phrased as a statement about elements can be checked:
- “Every door has a fire rating from this list.”
- “Every space has a number matching the pattern
R-000.” - “Every load-bearing wall is flagged as load-bearing and assigned to a storey.”
- “There are no proxy elements.”
That is exactly what an IDS file expresses: each specification selects elements (its applicability) and states what they must contain (its requirements) — with values, lists, patterns, ranges and the cardinalities required, optional and prohibited. More in the glossary.
Geometric rules (clearances, clashes), process rules (who approves) and anything that compares several models do not become IDS.
From document to IDS file
In practice there are three routes:
- Export from a requirements tool. Requirements-management tools write IDS files straight from the properties they maintain.
- Generate from a spreadsheet. Many teams keep their property lists in Excel, and there are tools that turn them into IDS.
- Write it in an IDS editor. For smaller sets of requirements, an editor that builds the specifications step by step is enough.
Whichever route you take, the IDS file should become part of the information requirements and be referenced in the execution plan. Then it is unambiguous which rules a model is delivered and checked against.
Check before delivery, and on receipt
Once the IDS file exists, both sides can run the same check:
- Each author checks their model before delivery and fills in what is missing.
- The BIM manager checks every delivered model on receipt against the same file.
Because both use the same rules, there is no argument about what was meant — only about what is missing.
Where Bimlyte fits
Bimlyte checks IFC models against IDS 1.0 files for free in the browser — no upload, no account, no installation. The report shows, per specification and per element, what is missing, next to the values the model actually holds. The result can be coloured on the 3D model and handed to anyone without BIM software as an Excel workbook.
Bimlyte does not create IDS files — it checks against them. It does show any IDS file as readable sentences and flags rules no model could satisfy, which helps to sort out a faulty file before the first delivery.