Level of Information Need (LOIN) Explained

"Level of Information Need" sounds like it should mean the same thing as the American LOD 100 to 500 scale everyone's seen on a BIM slide somewhere. It doesn't. LOIN is a distinct, standards-based methodology that replaced the UK's own earlier shorthand, and conflating the two is one of the most common, and most consequential, mix-ups in BIM information requirements.

What LOIN replaced, and what it didn't

LOIN replaced the UK's own earlier, informal Level of Detail and Level of Information shorthand that came out of BS 1192 and PAS 1192. The standard that formally defined it, EN 17412-1:2020, "Building Information Modelling — Level of Information Need — Concepts and principles," has since been withdrawn, on 4 July 2024, and superseded by BS EN ISO 7817-1:2024, which internationalizes the same methodology and aligns it more closely with ISO 19650. We're still using the EN 17412-1 name here because that's how most of the industry currently searches for and discusses it, but if you're citing the standard itself going forward, ISO 7817-1:2024 is the current one.

What LOIN did not replace is the American BIMForum/AIA LOD 100 to 500 convention. That system remains in parallel, separate use, and the similarity in name and intent between "LOIN" and "LOD" is exactly why people keep treating them as interchangeable when they're not the same framework at all.

The three components of LOIN

EN 17412-1 (and its successor) specifies LOIN across three categories, each defined independently against a stated use:

• Geometrical information, broken into five further facets: detailing, dimension, location, representation, and parametrics.
• Alphanumerical information, covering identification (what the object is) and content (its properties and attributes).
• Documentation, covering supporting material like reports, photos, sketches, and acceptance records.

The method works in two steps: first defining the prerequisites, why the information is needed, when, by whom, and for what, the "use," and only then defining the actual depth of information required across the three categories above.

How LOIN is actually used on a project

LOIN sits underneath ISO 19650-1's cascading information requirements: Organisational Information Requirements, Asset Information Requirements, Project Information Requirements, and Exchange Information Requirements. LOIN is the granular framework used to specify precisely what an Exchange Information Requirement actually demands, rather than leaving "enough detail" as a vague instruction. In practice, LOIN gets defined per named use, then rolled up per discipline, element, and project stage into the EIR, and operationalized through Task and Master Information Delivery Plans, with the project-specific definitions embedded in the BIM Execution Plan.

A worked example: a door

A commonly used illustration contrasts a door modeled two different ways. Modeled with low detailing, it might be nothing more than an opening in a wall. Modeled with the detailing a facilities management use actually requires, it's a discrete frame, leaf, handle, and threshold, each as separate, identifiable components. Neither version is "wrong" in isolation, the question LOIN forces you to ask first is what use that door model needs to serve, a planning visualization or a maintenance schedule, before deciding which version to actually deliver.

The mistakes that keep recurring

• Collapsing LOIN into a single shorthand number. Treating it like an old-style "LOD400/LoI5" rating defeats the point, which is purpose-driven detail per use, not one blanket figure for an entire model.
• Vague or missing "use" statements. Information delivery plans that don't clearly state why a piece of information is needed make it impossible to judge whether the specified detail is actually right.
• Client organizations under-equipped to define it themselves. LOIN is meant to be driven by the information requirements of the party that needs the data, but that party doesn't always have the skills or appetite to define it, and ends up delegating the decision inappropriately to designers or contractors instead.
• Both over-definition and under-definition carry real risk. Specifying far more detail than any use requires wastes effort and money; specifying too little leaves a use unsupported later. Neither failure mode is safer than the other.

Frequently asked questions