From LOD to LOIN — BIM regulations are changing their language

The right level of detail isn't a number. It's a question.

A contract asks you for a BIM model at LOD 300. You know how to do it; you’ve done it dozens of times. The problem is that the person on the other side of the table — the structural engineer, the client's BIM manager, the colleague who needs to extract schedules — imagines that same LOD 300 slightly differently than you do.

It’s not a matter of competence. Technically, neither of you is wrong. The point is that "LOD 300" on its own doesn't say what the model should contain — it just provides a number on a scale that, depending on who is reading it, is interpreted with different margins. And in a BIM project, a margin of interpretation on shared data is the exact point where rework begins.

It’s the same problem we face at the level of the individual family — I talked about this when discussing geometry, parameters, and information as three distinct levels of quality for a Revit Family. The same applies, on a larger scale, to an entire model. And the regulations realized this before we did — so much so that the very concept of LOD is being rewritten from within.

LOD, LOG and LOI: the Italian interpretation

Let's start with the basics, because it's what most BIM contracts in Italy are still built on today: the UNI 11337-4 standard.

Before moving on, a terminological clarification: when the standard talks about LOD, LOG, and LOI, it refers to "digital objects" — a deliberately neutral language that doesn't recognize Revit, Archicad, or Tekla. "Family" is the name we give that object when we work inside Revit. Same substance, different vocabulary.

The Italian standard defines LOD as the "level of development of digital objects" — it’s no coincidence that the acronym, in its local version, does not slavishly translate the English "Level of Development." It is a scale that goes from A to G, describing how deep and stable an object becomes as the project progresses: from a concept that is still indicative to a construction-ready model, updated as-built.

So far, nothing different from what you probably already know from direct experience with contracts. The interesting part — the one that often remains in the background — is that UNI 11337-4 does not stop at a single letter. It breaks down the LOD into two distinct components:

• LOG — Level of Geometry: how defined, dimensionally and formally, the geometry of the object is. It answers the question, "What shape is it, and how precise is that shape?"
• LOI — Level of Information: how many and what kind of alphanumeric data the object carries. It answers the question, "What do I know about this object, besides how it's made?"

Does that sound familiar? It should: it's exactly the same distinction between geometry and information that I discussed when talking about Revit Families as BIM assets — except that there we applied it to a single family in the Family Editor, while here the standard applies it to the entire model, with a standardized and contractually binding scale.

And this is where the first practical problem arises: LOG and LOI don't always grow at the same speed. An object can have highly detailed geometry and zero useful parameters for schedules. Or the opposite — simplified geometry, but a very rich LOI because that’s what is actually needed at that stage. The single letter of "LOD 300" hides this asymmetry. And it is precisely this crack from which, at the European level, something different has emerged.

This is no small detail: a LOG that grows unchecked — geometry imported directly from external software, sculptural details that no one will ever see in plan view — is exactly the type of choice that kills model performance. More detail is never a goal in itself: it only becomes one if it answers a real informational need.

Why we are starting to talk about LOIN

The limitation of the LOD/LOG/LOI system, at its core, is the same limitation as any letter-based scale: it compresses complex information into a simple symbol. Convenient for contracts, less convenient when the reality of the project doesn’t fit neatly into seven boxes.

At the European level, this limitation was tackled head-on. Since 2016, an international working group — led, among others, by an Italian expert — has developed a new framework: the LOIN, or Level of Information Need. The text was first formalized in the European standard EN 17412-1 (adopted in Italy as UNI EN 17412-1:2021) and subsequently elevated to an international standard: today the official reference is UNI EN ISO 7817-1:2024.

The underlying idea remains a clear shift in perspective: no longer "how much detail does this object have according to a standard scale," but "how much detail is really needed, by whom, to do what, at what stage." It’s no coincidence that at the European level, it was decided not to condense the concept into a catchy acronym — the risk, as openly stated by those who wrote the standard, was that everyone would simply replace "LOD" with "LOIN" without truly changing their approach.

The LOIN framework works alongside the UNI EN ISO 19650 series, which regulates the information management of BIM projects in Italy (BIM Execution Plan, exchange information requirements, and so on) — the 19650 states that an information need is required, and the 17412-1 explains how to specify it consistently: purpose of the information, actors involved, delivery milestones, and geometric and alphanumeric requirements.

And here is the most honest part to tell: in Italy, we are in a phase of transition, not substitution. UNI EN ISO 7817-1:2024 is already an Italian standard in all respects. But UNI 11337-4 — which we saw in the previous block, with LOD/LOG/LOI — is still working to align itself with this new framework. The practical result is that today, in real-world contracting, the two languages coexist: contracts that still ask for "LOD 300" exist alongside more advanced clients — often those accustomed to working with ISO 19650 — who are starting to specify information requirements in terms of LOIN.

This is not a flaw in the standard. It is simply the time it takes for an entire sector to change its vocabulary without breaking everything that is already in place.

A concrete example: the Kitchen Utensil Cabinet

Let’s take the same kitchen utensil cabinet I already mentioned in the article on BIM assets, and try to read it through the lenses of LOG and LOI instead of the generic "geometry, parameters, information."

In a conceptual phase (low LOD), that cabinet might exist in the model as a simple parallelepiped with the correct footprint — the LOG is minimal, just the space it will occupy in plan. The LOI, at this stage, may still not be zero: a simple classification or usage parameter is enough to start making it interact with the preliminary cost schedule. Low geometry, information already present. This is exactly the type of asymmetry that the single LOD scale tends to hide.

As the project progresses, the LOG grows: the two configurations appear — four containers or two, managed by the visibility parameter — the wooden structure takes real shape, and the wicker baskets become real geometry and not just a generic block. In parallel, but not necessarily at the same pace, the LOI also grows: top and frame materials as instance parameters, editable dimensions — top thickness, frame thickness, basket sliding — all data that feeds the schedules and allows the cabinet to respond to real coordination with other professionals.

Here the reasoning from a LOIN perspective becomes concrete. Who will use that model, and to do what? If the model is for a presentation render, high LOG and low LOI are needed — the form must be convincing; the data matters little. If the model is for a bill of quantities or future maintenance management, the opposite applies: high LOI is needed, with data on materials and components, while the LOG can remain more simplified without harming the end use. Asking "what LOD is needed" for this cabinet is an incomplete question. Asking "who will use this data, and for what purpose" is the question that the LOIN framework tries to place at the center — not higher detail by definition, but the right detail for the purpose.

The right level of detail isn't a number. It's a question.

When I started looking at the Kitchen Utensil Cabinet through the lenses of LOG and LOI, I realized one thing: the question I had asked myself for years — "what LOD does this family need?" — had never been the right question. It was just the most convenient one. A letter to put in a contract, easy to write, easy to check, difficult to interpret in the same way by both sides of the table.

LOIN does not add complexity to BIM standards. It removes it, moving it where it belongs — no longer "how much detail, generically," but "what detail, for whom, to do what, in what phase." It is a change in perspective that resembles what every modeler already does instinctively every time they decide whether a parameter should be an instance or a type parameter: it’s not about adding control on principle; it’s about giving just enough, where it's needed.

It applies to a single family in the Family Editor. It applies to an entire model in a contract. The question doesn't change — only the scale at which you ask it does.

One thing must be said honestly, and it's best to close on this: the Italian regulations on this front are still in motion. UNI 11337-4 has not yet definitively incorporated the LOIN framework, and until that work is finished (as of the writing of this article, October 2026, the final revision has not yet been published), LOD and LOIN will continue to coexist in the contracts we read every day. It's not a limitation to ignore — it's simply the state of things, and it is likely we will return to this in a future article, once the standard has taken its final form.

If you are interested in looking back even further, to those who first imagined a building object as a container of information and not just form, the starting point is The Prophet of BIM — Charles M. Eastman. Happy reading.