Level of information
need.
There is no such thing as an LOD 300 model. You ask for the information of each element, for a purpose and at a milestone.
What is an LOD 300?.
The contract asks for an “LOD 300 model”. Whoever asks has one thing in mind; whoever models, another. Nobody knows what is delivered until it arrives.
As much as needed.
And as little as possible. The information needed is not set by a number, but by four prior questions.
Three kinds of information.
What is drawn, what is written and what is attached. Each one is requested separately and at its own level.
Shape, in five questions.
“More detail” says nothing. You specify how much detail, how many dimensions, how exact the position, what appearance and whether it can be modified.
First, know what it is.
Data has two parts: identifying the object unambiguously and describing it with properties that have a name, a value and a unit.
Drawn is not decided.
A door can be drawn down to its handle and still not be decided. Detail is what goes in; development is what you can rely on.
From 100 to 500.
From 100 to 400 the reliability of each element grows; 350 coordinates trades and 500 is not more, it is what was verified on site. Tap and see a door.
Each element, its own level.
At the same milestone the structure can be settled while the furniture is barely sketched. That is why it is requested element by element, in a matrix.
More is not better.
Every piece of data requested has to be created, checked and maintained. What nobody will use is wasted work and noise for whoever is searching.
Information matures.
You ask for what can be decided at each milestone. Asking early for data that is not yet known forces someone to make it up.
What is measured has a tolerance.
If the model comes from a survey, the level also states how far what is modelled deviates from reality.
From number to requirement.
Pick an object and a purpose: the level of information need comes from that pair, not from one label for the whole model.
From LOD to LOIN.
It began as a software vendor's scale and has ended up as an ISO standard. Along the way it changed its name three times.
The standard in one diagram.
Four prior questions and three kinds of information, each with its own aspects. It does not define numbered levels: it defines how to describe them.
It goes into the contract.
The organizational requirements cascade down to the project and the exchange. There, in each requirement, the level of information need is set.
The LOD dictionary.
It defines what each level means for each element type, with illustrations. Since 2025 it maps each level to the aspects of ISO 7817-1.
Each country, its acronyms.
The same concept is called LOD in the United States, LOG and LOI in Germany and NDI in Chile. Europe is converging on the level of information need.
So that “fire” means the same.
Asking for a property is of little use if everyone names it differently. Dictionaries fix the name, type, unit and allowed values.
Guidance and digital format.
Part 1 explains the concept. Part 2 will show how to apply it with examples and Part 3 turns it into a file that machines can read.
“Fine” is not LOD 400.
Programs have a view detail level that only decides which lines are drawn at each scale. It says nothing about what the element is worth.
Each program, its own drawer.
Parameters, properties, attributes: the name changes, the idea does not. What matters is defining them once and reusing them across the whole project.
From parameter to IFC.
A value well filled in the program does not reach the IFC if nobody says which property set it must go into. That is configured in the exporter.
The requirement goes into the program.
Several programs already import an IDS and create the properties it asks for. That way you model knowing what will be checked.
The matrix, in a database.
A spreadsheet falls short with hundreds of objects and milestones. Some platforms store the requirements and export them for modelling and checking.
The cloud still lags behind.
Cloud viewers filter by property, but checking an IDS inside the platform is still the exception and is usually paid for separately.
A place for every value.
IFC already has a slot for almost everything a level of information asks for. Using the standard one before inventing your own gets you halfway.
Half a requirement in one file.
The IDS carries the purpose and the milestone in its header and demands IFC data. Geometry stays out: it cannot ask for it.
What the maintainer needs.
When construction ends you do not need all the geometry: you need to know what equipment there is, where it is and how to maintain it. COBie is that subset.
Four questions per delivery.
Is it there, does it have a value, is the value valid and does the shape match what was asked for? The first three can be automated; the fourth, not entirely.
Three doors, one passes.
An IDS asks every door for its fire resistance in the European classification format and whether it is external. We test it on three sample doors.
One IDS, several judges.
Because IDS is open, whoever delivers and whoever receives can check it with different tools and get the same result.
Shape is reviewed separately.
No open standard yet checks whether a geometry has the requested detail. You combine rules, measurement and a sample-based review.