Digital Twins & BIM

What is the difference between LOD and level of information need?

Replace LOD numbers with purpose- and milestone-based information requirements.

Conceptual choice of geometry detail versus decision-relevant asset information for one HVAC asset.
On this page
  1. Why the numbers fell short
  2. What a specification contains
  3. Detailed geometry, poor data, and the reverse
  4. Requirements a supply chain can deliver
  5. Practical application
  6. Sources

Write "LOD 400" into a requirement and every party will read its own meaning into it. "LOD" is an older shorthand that has been used for level of detail, level of development or level of definition, depending on the country and the framework, and it typically assigns a single number, such as LOD 300 or LOD 4, to describe how developed a model element is.

Level of information need is the approach now used in the ISO 19650 series, standardised internationally as ISO 7817-1:2024. Instead of a number, it specifies the information required for a particular purpose, at a particular milestone, for a particular receiver, across geometry, data and documentation. Because it says exactly what is needed and why, it can be both produced and checked.

Why the numbers fell short

Guidance from the IMI Framework (formerly the UK BIM Framework) explains that "level of definition" in the UK was historically an aggregate of level of detail and level of information, with metrics from 1 to 7 used to indicate geometry and data. Those metrics, it notes, were too generic to check automatically whether deliverables met the appointing party's needs, and were detached from the purpose of the information. The level of information need framework was introduced in the ISO 19650 series to address both problems. The same guidance describes it as defining the quality, quantity and granularity of information for a purpose, no more and no less, and warns against requirements that generate wasteful information.

What a specification contains

According to its official abstract, ISO 7817-1:2024 specifies concepts and principles for specifying level of information need and information deliveries consistently, and applies to the whole life cycle of any built asset, from strategic planning to end of life. The UK guidance frames information requirements in four facets, namely purpose, content, form and format, and divides content into three kinds of information. Geometrical information is the shape, size and position the purpose requires. Alphanumerical information covers identification and properties, such as a fire rating or a cost limit. Documentation means the documents required.

To be usable, each requirement should also state when it is due (the information delivery milestone), who provides it, who receives it and which objects it applies to.

Detailed geometry, poor data, and the reverse

Geometry and data are independent qualities. An object can have detailed geometry but no reliable identifier; another can be a simple box carrying everything an operator needs. A realistic-looking model can still carry alphanumerical information that is incomplete or wrong.

Requirements a supply chain can deliver

Requirements written as prose invite loose reading. A concise schedule, structured as a spreadsheet or database, works better, especially with representative examples of compliant objects and defined permitted values and classifications where they matter. The schedule should also say how compliance will be checked; for IFC deliverables, buildingSMART's Information Delivery Specification can express many such checks in machine-readable form. And if a particular supplier still works in LOD terms, name the framework and define what each number means on your project.

Practical application

Where requirements still say "LOD 400", ask what task each element supports, and rewrite the requirement around that purpose.

Sources

This article connects to our work on Digital twin.

Related articles

Related service

Digital twin

We can discuss how this subject fits the project brief.

Contact Pagin Consulting