You asked the architect for an IFC with the data in it, not just the shape. The file arrives, you open it, and half the doors have no width, a third of the walls carry no fire rating, and nobody can tell you why. The model looks finished on screen and answers almost nothing when you question it. IDS is the standard that was built to stop exactly this, by writing down what a model must contain in a form a computer can read and check, before the model ever leaves the modeller's desk.
IDS stands for Information Delivery Specification. It is looked after by buildingSMART, the same neutral body behind IFC, and on 1 June 2024 it became an official buildingSMART standard, version 1.0. Everything before that was a beta.
The problem IDS was built for
Anyone who has opened a handed-over model knows the feeling. Every wall is present, every door in place, and then you start asking questions. What is the fire rating of this partition. What is the clear width of that door. Which storey does this element belong to. Half the answers are blank. The model was drawn, not filled in.
For years the fix was a document. A spreadsheet or a PDF that listed the properties every element should carry. It described the requirement in plain words, and then it sat in a folder while people got on with modelling. Nobody could run it. There was no way to point a tool at a model and ask whether it actually met the list. Good data in was left to good intentions.
A specification a computer can read
IDS closes that gap. It is not prose about data, it is a check. An IDS is a short XML file, so it is text a machine reads the same way every time. In it you set out the rules: these objects must exist, they must carry these classifications and these properties, and those properties must hold values in the right units. buildingSMART describes it as strictly tied to the IFC schema, so a rule about a door means the same thing to every reader.
That last part is the quiet breakthrough. Because the specification is unambiguous and machine-readable, a pass in one checking tool is a pass in another. The requirement stops being one firm's house style and becomes something the whole chain can agree on and run.
From a hopeful email to a check you can run
Think about what changes on the ground. Before, the request went out as a sentence: please include fire ratings and door widths. After, it goes out as an IDS. Every door must carry a width and a fire rating, every load-bearing wall a material and a rating, and so on down the list. When the model comes back, you point a tool at it and the model reports on itself, rule by rule, red or green.
The question stops being "did they remember the data" and becomes "does the model pass its spec." One is a hope. The other is a check anyone can run.
That is a real shift in who carries the risk. The person delivering the model can check their own work against the same specification before they send it, instead of finding out weeks later that a field was empty when it was needed.
Why it matters for the Wkb and the kwaliteitsborger
This is not a Dutch standard, and that is the point. IDS is a vendor-neutral buildingSMART standard used across Europe, the natural companion to the open IFC format underneath it. As building control across the continent moves toward checking models instead of paper, being able to state information requirements in a form a computer can verify is the groundwork the whole idea rests on.
A model-based check is only as good as the data it reads
Under the Dutch Wkb the kwaliteitsborger has to satisfy themselves that the work meets the Bbl, and more of that work is moving onto the model. A model-based check can only read what is actually there. Agreeing up front, in an IDS, which properties the model must carry is how you make sure the model that lands is one a check can be run against, not an empty shell.
Where we come in
To be clear about the edges: BimDossier is not an IDS authoring tool, and it does not check a model against an IDS file today. What it does is live on the data an IDS protects. It reads the IFC you are sent, loads federated models from every discipline into one viewer, and runs its Bbl rule packs against the elements themselves. You pin a finding to an element by its own identifier, with a photo and an owner, and your certificates and your Wkb dossier hang off the same model.
So IDS and a tool like this pull in the same direction. IDS is how the industry makes sure the data is in the model before it is handed over. Everything you then build on top, the checks, the snags, the proof at gereedmelding, still sits on your model, and it holds up because the data underneath it does.