LOD vs LOI: Why Level of Information Matters More Than Geometry

Here's a scenario that plays out on projects everywhere, and it's worth sitting with because a real argument — sometimes a contractual one — hides inside it.

A design team issues a model at detailed design. The geometry is convincing: the pump has a manufacturer-plausible shape, the wall has its layers, the steel connections look fabricated. The reviewer opens it, orbits it, declares it "very developed." Then someone clicks the pump. The property panel offers a name, a level, and almost nothing else — no duty, no electrical load, no maintenance clearances, no classification code the asset system can ingest. The model looks like detailed design. Informationally, it's a sketch wearing a suit.

Now invert it. Another model's pump is a grey box — honest placeholder geometry — but the box carries flow rate, head, power, weight, the spec section, and the classification the client's systems require. Which model is worth more? To a clash detective, perhaps the first. To the cost planner, the procurement team, the commissioning engineer, and the owner who'll operate this asset for forty years: the grey box, and it isn't close.

That inversion is the whole subject of this article. Our industry learned to see model development as a single dial — "what LOD is it?" — when it's two dials, and the one we talk about less is the one most of the money rides on.

Two dials, not one

Level of Detail (geometric detail — LOD in its everyday usage) describes how refined the shape is: placeholder box, generic component, specific product, fabrication-ready. It's the dial you can assess by looking.

Level of Information (LOI) describes what the element knows about itself: the structured data attached — performance values, materials, classifications, asset codes, the property sets a downstream system will query. It's the dial you can only assess by clicking, which is precisely why it gets under-reviewed: geometry is inspected at a glance; information must be interrogated element by element.

Modern frameworks bind the two into a single specification — the Level of Information Need: for each element type, at each milestone, for each use, what geometry and what information are required. The phrase "for each use" is the load-bearing part. A model isn't developed in the abstract; it's developed for cost planning, or coordination, or procurement, or handover — and each use consumes different things. Coordination consumes geometry. Almost everything else consumes data.

Why information carries the money

Walk the downstream uses and count which dial each one reads:

• Cost planning prices what elements are — types, materials, specifications, quantities derived from classified objects. A beautifully shaped wall with no type data prices as "wall, unknown."
• Procurement buys from schedules extracted from element data. The schedule doesn't care that the pump's impeller was modelled; it cares that the duty point is a queryable property.
• Construction planning sequences by zone, level, and system — attribute data.
• Commissioning and handover is entirely information: asset registers, O&M links, warranty data, classification codes mapping into the owner's asset management system. The geometry's job at handover is mostly to help someone find the asset the data describes.
• Coordination — genuinely geometry-hungry, and the reason detail exists at all. One use among many; the loudest, not the largest.

Follow the value and the asymmetry is stark: geometry serves the design phase, information serves the asset's life. An owner-operator extracting decades of facility management value from a model is extracting LOI. Which makes the standard failure — models that over-deliver detail and under-deliver information — exactly backwards from the client's point of view: teams burn hours refining shapes nobody downstream consumes, while the properties that feed cost, procurement, and operations arrive empty.

Where the confusion becomes contractual

The single-dial habit does real damage in appointments and disputes, because "LOD 300" (or any bare level number) gets written into contracts as if it settled the information question. It doesn't. Two parties can both sign "LOD 300 at detailed design" holding entirely different assumptions about the data attached — and each will feel wronged when the exchange happens.

The sharper version of the trap: because geometric detail may genuinely not change much between two milestones (the wall was LOD 300-shaped at developed design and is still LOD 300-shaped at the construction issue), a party can argue that the later milestone adds nothing — so why not skip it? The answer lives entirely on the second dial. Between those milestones, the geometry held still while the information was supposed to mature: generic types becoming specified products, performance placeholders becoming selected values, classification fields filling for the uses the later stage exists to serve. Same shapes, different model. A milestone defined only by geometry is skippable; a milestone defined by information need is not — and only the second kind of definition survives an argument.

Pro tip: If you write BIM requirements, specify the two dials separately and per element type — a table beats a slogan: element class × milestone × required geometry × required properties (named, with the property set they live in) × the use that consumes them. Naming the consuming use does double duty: it justifies every required property (nothing survives the table without a customer) and it converts review from opinion to audit. If a required property can't be named, it can't be checked — and if it can't be checked, it won't be delivered.

Reviewing the dial nobody looks at

The practical consequence for anyone receiving models: review by clicking, not by orbiting. A credible information review doesn't need the authoring software — a free browser viewer exposes every property the export carries:

1. Open the IFC in the BIM Model Viewer and pick the element classes that matter for the current milestone's uses — the ones your table (or the project's information requirements) names.
2. Sample elements across each class and read the property panels against the required list: present, populated, plausible.
3. Distinguish the two failure modes. Properties absent across the board usually means export settings (recoverable in an hour — see why a consultant's IFC export looks wrong); properties present but empty means the data was never authored (a milestone problem, worth escalating now, because retrofitting information is the most expensive way to acquire it).

Ten minutes of clicking routinely tells you more about a deliverable's real maturity than an hour of admiring its geometry — because the geometry was built to be admired, and the information wasn't.

The reframe worth keeping

None of this demotes geometry — coordination needs it, and coordination failures pour concrete in the wrong place. The point is narrower and more useful: detail and information are separate promises, matured on separate schedules, consumed by different customers — and the information promise is the one most of the project's value chain is waiting on. Teams that internalise the two-dial view write cleaner requirements, run reviews that catch what matters, and — when someone proposes collapsing a milestone because "the LOD doesn't change" — know exactly which dial to point at.

Next model you receive, spend the first ten minutes clicking instead of orbiting:

Open it in the BIM Model Viewer → — free, in your browser, every property the export carries on display.