Welcome back to BIM Business, where we cut through the noise of digital construction and focus on what actually drives value, efficiency, and profitability in our industry.
Today, we need to have a candid conversation about one of the most misunderstood acronyms in our space: LOD.
We all use it, we all put it in our contracts, and yet, half the time, we are talking completely past each other. Let’s break down where LOD came from, what it actually means, why it exists, and why we need to stop drowning in spreadsheets and start focusing on trust.
The concept of standardising information levels didn’t just appear overnight. It has been a global, iterative effort to solve a massive communication problem in digital construction.
2004 - Vico MPS: Vico Software began work in 2004 on a Model Progression Specification (MPS). The core of the MPS was a set of descriptions detailing the steps a BIM element logically progresses through, from conceptual approximations (100) to fabrication (400) and as-built (500).
2006 - Danish Information Levels: In Denmark, a package of 3D working method guidelines was published. These guidelines defined seven levels of information that corresponded roughly to traditional construction phases
.
2008 - The AIA Standardises LOD: In 2008, the American Institute of Architects (AIA) formally developed its first set of Level of Development definitions in AIA Document E202™-2008 Building Information Modeling Protocol
.
2010 - US Veterans Affairs: To facilitate BIM development, the US Veterans Affairs provided a comprehensive Object Element Matrix to track properties and attributes by classification and LOD
.
2011 - BIM Forum: In 2011 the BIMForum initiated the development of this LOD Specification and formed a working group comprising contributors from both the design and construction sides of the major disciplines. The working group first interpreted the AIA’s basic LOD definitions for each building system, and then compiled examples to illustrate the interpretations
.
2013 - The UK initiatives: In the UK, the BSI published PAS 1192-2, which separated graphical and non-graphical content. This introduced new terminology to clearly distinguish the visual model from the embedded data.
Over time, the acronym “LOD” has been stretched to mean many different things, leading to massive friction between architects, engineers, and contractors. Some examples:
Level of Detail (or Level of Geometry): This is essentially how much detail is included in the model element. Think of this as the input; a measure of graphical complexity. In the UK framework, this was referred to as “Level of Model Detail,” though the industry frequently started calling it the “Level of Geometry” to explicitly distinguish the 3D physical shape from the data.
Level of Information (LOI): Emerging prominently from the UK’s framework, LOI describes the non-graphical content of models at each stage. It cleanly splits the alphanumeric data out from the visual geometry.
Level of Definition: This is often used as an overarching term that combines both the graphical (Level of Model Detail / Level of Geometry) and non-graphical (Level of Model Information) requirements into one comprehensive milestone target.
Level of Development (LOD): In the BIMForum specification, LOD is the degree to which the element’s geometry and information has been thought through. It is the degree to which project team members may rely on the information when using the model. This is the reliable output.
Level of Information Need: A more recent evolution, formalised in ISO 7817-1:2024, which specifies the quality, quantity, and granularity of geometric, alphanumeric, and documentation information required in a deliverable.
When the BIMForum took the AIA’s definitions and expanded them into a comprehensive specification, they were trying to solve a massive liability and collaboration problem.
In the old days of CAD, hand drawings ranged from pen strokes on a napkin to hard lines with dimensions called out, making it easy to infer the precision of the drawing from its appearance. But in a 3D BIM environment, a generic component placed approximately can look exactly the same as a specific component located precisely, so we need something besides appearance to tell the difference.
Because it’s possible to infer or extract information from a BIM that the author doesn’t intend, authors historically sidestepped the issue with all-encompassing disclaimers stating: “Since some of the information in the model is unreliable, you may not rely on any of it”.
That completely defeats the purpose of collaborative BIM.
The BIMForum LOD framework (and its predecessors) changes this paradigm. It allows model authors to clearly state the reliability of given model elements, shifting the concept to: “Since some of the information in the model is unreliable, you may only rely on it for what I specifically say you can”. Exchanging data and using Information Levels is not about the amount of information in a model, but about the level of trust that can be assigned to a model.
Let’s look at a common trap: over-modelling with library objects.
Imagine a structural engineer working on an early design phase. They drag and drop a complex steel truss or a highly detailed concrete column family from a manufacturer’s digital library into the model. Visually, it looks completely finished. It has nuts, bolts, material properties, weight data, and exact geometric dimensions.
It looks like an LOD 400 element, graphically represented with detail sufficient for fabrication.
However, the engineer hasn’t actually run the load calculations yet. The element is just sitting there as a placeholder to reserve space. Developmentally, it is only an LOD 200 element; generically and graphically represented with approximate quantity, size, shape, location, and orientation.
If the MEP coordinator downstream doesn’t understand this and assumes the structure is locked in simply because it looks highly detailed, they will spend hours routing ductwork tightly around that specific truss configuration. When the structural engineer finally runs the math and changes the truss depth by two feet, all that MEP coordination is wasted.
The model looked precise, but it was just a “sketch.” If the team had properly utilised LOD definitions, the MEP coordinator would have known it was only LOD 200 and planned their work accordingly.
The AEC industry is not the only one wrestling with how to communicate the reliability of a digital model. In the geospatial and GIS world, standards like CityGML utilise their own LOD framework (ranging from LOD 0 to LOD 4) to define the progression of city models from simple regional footprints to fully detailed architectural interiors.
However, it is the industrial product development and manufacturing sectors that truly nailed the concept of “trust.” In Product Lifecycle Management (PLM), mechanical engineers don’t typically argue over “levels of detail.” A 3D CAD model of an engine component often looks perfectly detailed and geometrically complete from the very first day it is sketched. Instead of relying on visual completeness, the manufacturing supply chain relies on explicit Maturity States or Lifecycle Statuses; such as “In Work,” “Released for Tooling,” or “Released for Production.” They explicitly decoupled visual detail from engineering trust decades ago.
The AEC industry is attempting to achieve this exact same gating of trust using the LOD framework. BIM Forum explicitly states that there is no strict correspondence between LODs and design phases. For some reason, we keep obsessing over how a model looks rather than what it is actually approved to do.
Despite the fundamental purpose of the LOD framework being to establish a clear baseline of trust and reliability for model elements, this core principle is frequently forgotten in everyday practice.
Instead of having meaningful conversations about what information a project team can actually depend on to move their work forward, engineers and BIM managers often bypass the overarching methodology and dive straight into the accompanying Excel spreadsheets. While tools like the Model Element Table are provided to help collect and correlate LOD information across a project, most practitioners lose themselves in the tedious process of filling out these huge spreadsheets without actually thinking about why they are doing it.
Consequently, the industry ends up treating LOD as a rigid, box-checking administrative chore rather than a vital communication tool designed to mitigate risk and clearly state the reliability of the model.
But if we look back at the history of these standards, the central theme is undeniable. Since the very first BIMForum specification was published, and even in the foundational AIA E202 document, Vico’s MPS, and the 2006 Danish guidelines that preceded it, the explicit goal of LOD has always been to establish the extent of reliance that may be placed on an element. The framework was built so model authors could clearly state the reliability of given model elements, effectively saying: “Since some of the information in the model is unreliable, you may only rely on it for what I specifically say you can”.
The main issue during the discussion about the LOD concept is, or at least should be, about trust. Exchanging data and using Information Levels is not about the raw amount of geometric or alphanumeric information stuffed into a model; it is fundamentally about the level of trust that can be assigned to that model so a teammate or project partner can perform a specific task.
We could probably rename the entire concept to “Level of Trust.” It would instantly clarify the intent and stop the endless debates over graphical granularity. But let’s be real: the absolute last thing the AEC industry needs right now is yet another three-letter acronym to argue about. So, we should stick with LOD, but we must radically use it with the original principles.
When we stop treating LOD as a rigid, box-checking administrative chore and start using it as a contractual communication tool, the business impact is massive. Properly applied, it reduces the risks of miscommunication among project teams and creates greater predictability regarding the level of effort required to create deliverables. It facilitates a pull-planning process that limits the development of model elements to only what the team actually finds useful (in that phase), entirely avoiding the massive failure costs associated with over-modelling and rework.
Our industry loves to go wild with Excel, debating whether a door handle is LOD 300 or 350. It’s time to close the spreadsheet, look at your project partners, and ask the only two questions that actually matter: what do you need for your task? And what do I have that you can rely on for that task?
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.