LOD vs LOIN — practical reading of ISO 19650

The "LOD 300 by Stage 4" Contract Argument

You have seen it in hundreds of scopes of service. It appears in RFPs from government agencies and private developers alike. It sits in BIM Execution Plan templates that were copied from another project, which was copied from another project before that. The clause reads something like this:

All design disciplines shall deliver BIM models at a minimum of LOD 300 at the completion of Stage 4 (Construction Documentation). Structural and MEP coordination models shall achieve LOD 350 before the first coordination meeting.

On the surface, this reads like a reasonable, measurable contractual commitment. The team knows what level means what. The client can point to a number. If there is a dispute, there is a reference standard — the BIM Forum LOD Specification — that defines what LOD 300 actually requires geometrically. Clean. Auditable. Defensible.

Except for one thing it does not cover.

LOD 300 tells you that the structural steel members are modeled at their correct size, shape, location, and quantity. It tells you nothing about whether those members carry the steel grade, the connection type, the fire rating, the fabricator identifier, the Uniclass classification code, the cost code alignment, or the maintenance inspection interval. Geometry is there. Information — the kind that actually drives downstream decisions in procurement, construction administration, and facilities management — is a separate conversation that LOD was never designed to address.

This gap has always existed. BIM practitioners have long known that a LOD 300 model can be informationally empty: a precisely positioned collection of geometry with no meaningful attributes attached. But in the early days of BIM adoption, when simply getting consultants to model in three dimensions was the hard problem, the geometry-first framing of LOD was appropriate. Getting shapes right before worrying about data richness was a reasonable sequencing decision.

That sequencing decision hardened into contract boilerplate. And the boilerplate survived long enough to collide with ISO 19650.

The ISO 19650 series — the international standard for information management using BIM, published by ISO with British Standard adoption in 2018 — introduces a different organizing concept: the Level of Information Need, universally abbreviated as LOIN. Where LOD describes what a model element looks like at a given stage of development, LOIN describes what information — geometric, alphanumeric, and documentary — a specific recipient requires from a specific element at a specific project milestone in order to perform a specific function.

LOIN is not a replacement for LOD in the sense that you rip out one set of numbers and replace them with another. It is a different question. LOD asks: how developed is this model element? LOIN asks: what does the person who needs this model element actually need to know?

Those are not the same question. The gap between them is where BIM contracts fail.

This article is an extended reading of both frameworks — their origins, their mechanics, their limitations, and what translating from a LOD-centric contract to a LOIN-aligned specification actually requires in practice. The audience is BIM managers, information managers, and contract leads who are already working with one or both frameworks and want to understand where they complement each other and where they conflict.

We will cover the AIA E202 origin of LOD, the BIM Forum's maintenance of the specification, the ISO 19650 introduction of LOIN and its codification in BS EN ISO 7817-1:2024, a side-by-side translation exercise by discipline, anti-patterns that appear in the wild, and illustrative case scenarios. At the end, there is a LOIN specification sample in YAML and a LOD-to-LOIN translation table that you can adapt for your own EIRs.

LOD in Depth

The AIA E202 Origin

The Level of Development concept did not arrive fully formed. Its roots are in a Model Progression Specification developed by Vico Software — then an independent company, now part of Trimble — in the mid-2000s. Vico needed a way to define what information was in a model at each stage of the design process so that its cost estimating and scheduling tools could consume that information reliably. The Model Progression Specification was internal scaffolding for a software workflow problem.

That scaffolding caught the attention of Jim Bedrick, who brought the underlying concept to the AIA's Integrated Project Delivery Task Force. In 2008, the American Institute of Architects published AIA E202-2008, Building Information Modeling Protocol Exhibit — the first widely adopted contractual document to define LOD in a consistent, referenceable way. The exhibit was designed to be attached to an AIA owner-architect agreement or owner-contractor agreement, giving the concept legal standing within a project contract rather than existing only as professional guidance.

The AIA E202 document established five levels — LOD 100 through LOD 500 — and defined each level in terms of what the model element communicates about the physical thing it represents. The framework was explicitly focused on the degree to which a model element's geometry and attached non-geometric information could be relied upon. "Level of Development" was chosen deliberately over "Level of Detail" to signal that the framework was about reliability and completeness, not just visual resolution.

AIA E202-2008 had a clear purpose: to give project teams a shared vocabulary for communicating what a model element means at each stage, so that downstream users would know whether they could rely on it for coordination, estimation, or construction. The exhibit included a model element table where the team could assign LOD designations to elements by discipline and stage.

In 2013, the AIA updated the document as AIA G202-2013, Building Information Modeling Protocol Form. The G202 form refined the LOD definitions and introduced the concept of the "Model Author" — the party responsible for maintaining an element at a given LOD. This was a meaningful contractual clarification: not only was the LOD defined, but responsibility for authoring and maintaining elements at that LOD was assigned.

What LOD 100 Through LOD 500 Actually Define

The BIM Forum took over maintenance of the LOD Specification in 2013, publishing an initial reference document and updating it annually through the current 2024 edition. The BIM Forum Specification is not a contractual document itself — it is a reference that projects incorporate by pointing to it. The distinction matters: BIM Forum publishes the detailed interpretations by system and discipline; the AIA documents provide the contractual structure.

Here are the six LOD levels as currently defined, grounded in the BIM Forum 2024 Specification and AIA G202:

LOD 100 — Conceptual The element may be graphically represented with a symbol or other generic representation. All information associated with it must be considered approximate. This is the pre-design phase level, appropriate for area-based cost allowances and conceptual massing. A structural column at LOD 100 might be a vertical cylinder of roughly correct height with no meaningful dimensional accuracy.

LOD 200 — Approximate Geometry The element is represented as a generic system, object, or assembly with approximate quantities, size, shape, location, and orientation. Non-graphic information may be attached but all values are approximate. LOD 200 is typical for schematic design. An HVAC air handling unit at LOD 200 is a box of approximately correct volume sitting in approximately the right location, with no manufacturer information attached.

LOD 300 — Specific Geometry The element is represented as a specific system, object, or assembly in terms of quantity, size, shape, location, and orientation. Non-graphic information may be attached. The element is modeled with sufficient precision to derive accurate quantities and to perform geometric clash detection. LOD 300 is the standard target for design development and construction documentation. A door at LOD 300 has its correct dimensions, swing direction, frame type, and location — but may or may not have fire rating, hardware set, or manufacturer specification attached.

LOD 350 — Precise Geometry with System Interfaces This level, added by BIM Forum in 2015 and widely adopted since, extends LOD 300 by requiring that the element include interfaces with other building systems. A structural beam at LOD 350 includes the connection geometry at each end — web stiffeners, bolt patterns, weld extents — that affects how adjacent elements are modeled. LOD 350 is the practical minimum for meaningful MEP and structural coordination.

LOD 400 — Fabrication-Ready Geometry The element includes detailing, fabrication, assembly, and installation information. LOD 400 means the geometry is precise enough to fabricate from, and the attached information should include manufacturer details, assembly sequences, and installation requirements. A structural steel connection at LOD 400 can be taken directly to a fabricator. Precast concrete elements, curtain wall assemblies, and custom fabricated MEP equipment are common LOD 400 targets.

LOD 500 — Field-Verified As-Built The element is a field-verified representation of the as-built condition. LOD 500 is a quality designation, not a progression to higher geometry — it means that the element's geometry and attached information have been verified against field conditions. As the BIM Fix analysis noted, the BIM Forum LOD Specification actually addresses LOD 500 minimally, because field verification is not a modeling activity in the same sense as the levels that precede it. In practice, LOD 500 is frequently misused as a label for any as-built model regardless of actual verification rigor.

BIM Forum Maintenance and the US-Centric Ecosystem

The BIM Forum LOD Specification has been revised continuously since its first release in 2013. The 2015 edition introduced LOD 350 as a formally recognized level. Subsequent editions refined discipline-specific interpretations — the 2022 revision significantly clarified LOD 200, shifting from space-reservation volumes (a carryover from Vico's original framing) to recognizable geometry. The 2023 edition, which marked the 10-year anniversary of the specification, focused on resolving internal conflicts, eliminating vague language such as "major openings" in favor of defined dimensions, and restructuring content as checklists for easier contract incorporation.

The current edition is the BIM Forum 2024 LOD Specification, Part I (official English version, published November 2024). A Part II exists for landscape-specific interpretations. A Spanish-language version is available. The 2025 edition has since been released, continuing the annual revision cycle.

The BIM Forum ecosystem is deeply US-centric. The specification is organized around US construction practice — CSI MasterFormat divisions, AIA project stages, North American fabrication and procurement norms. It references AIA contract documents as the intended contractual home. It has no formal relationship with ISO 19650, PAS 1192 (the superseded UK standard), or European CEN standards.

This is not a criticism — it is a structural fact with contractual implications. When a US-based project team hands a LOD 300 model to a UK-based building operator, or when a US AEC firm works on a project in a jurisdiction where ISO 19650 is mandated (UK, Australia, Singapore, many European and Gulf states), the LOD reference points to a framework that the receiving party may not recognize as adequate.

The Geometric-Only Limitation — and Why It Matters

The most consequential sentence in the BIM Forum LOD Specification is the one that explicitly sets the boundary of what the specification covers. From the 2023 Part I: "non-geometric information is not addressed in Part I" since "any number of non-geometric attributes can be attached to a model element of any LOD."

Read that again. A LOD 300 model can have zero non-geometric information attached to any element and still fully comply with the LOD Specification. A LOD 400 model — fabrication-ready geometry — can have no manufacturer data, no material specification, no cost code, no maintenance interval. The geometry is controlled. The information is not.

This is not a bug in the specification — it was an intentional design choice. The BIM Forum recognized that information requirements are highly project-specific and that prescribing them uniformly across all disciplines and project types would make the specification unwieldy. The right call for a reference document. A serious limitation for a contract deliverable specification.

The practical consequence is that contracts which specify only LOD — even detailed LOD specifications — leave the information layer entirely unspecified. Teams can and do deliver geometrically complete, informationally empty models that technically satisfy every contractual LOD requirement. The contractor meets the spec. The owner cannot use the model for facility management. Nobody is lying; the contract just did not ask the right question.

This is the gap that LOIN was designed to address.

LOIN in Depth

ISO 19650-1 and the Introduction of Level of Information Need

The ISO 19650 series — formally titled "Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM) — Information management using building information modelling" — represents the consolidation of international BIM information management practice into a single coherent framework. Part 1 covers concepts and principles. Part 2 covers delivery phase. Part 3 covers the operational phase (asset management). Parts 4 and 5 address information exchange and security.

ISO 19650-1 was published in 2018 and adopted as a British Standard simultaneously as BS EN ISO 19650-1:2018. The UK adoption was direct and immediate because ISO 19650 was developed from PAS 1192-2:2013 — the earlier British standard for BIM information management — which means the UK industry had a decade of practice to build from.

The standard defines Level of Information Need (LOIN) as "the quality, quantity and granularity of information" required at a given point in a project or asset lifecycle. The definition is deliberately spare. LOIN is not a scale of levels like LOD 100 to LOD 500. It is a framework for specifying, precisely and purposively, what information a given recipient needs from a given model element at a given milestone in order to perform a given function.

The key shift in orientation is from description to prescription. LOD describes what an element has achieved. LOIN prescribes what an element must deliver, and for whom, and by when, and for what purpose.

The Three Dimensions of LOIN

ISO 19650-1 and the subsequently published BS EN ISO 7817-1:2024 — the dedicated LOIN standard that supersedes BS EN 17412-1:2020 — define LOIN across three dimensions of information:

1. Geometrical Information This dimension covers what most practitioners already think of as model content: the 3D representation of a physical element. But LOIN specifies geometrical information more precisely than LOD does, breaking it into sub-components:

Dimensionality: Is 2D, 3D, or a combination required?
Detail: What level of geometric complexity is needed? (This is where LOD-style thinking enters the LOIN framework.)
Location: Is absolute positioning required, or is relative positioning within an assembly sufficient?
Appearance: Are visual properties — color, texture, material finish — required for the purpose?
Parametric behavior: Must the element respond to parameter changes in a specific way (e.g., must a door object update clearance geometry when the door width changes)?

Critically, geometric requirements under LOIN are purpose-driven. A structural column needed for space planning has different geometric requirements than the same column needed for fabrication shop drawings, even though it is the same physical element. LOIN allows — and requires — that distinction to be stated explicitly.

2. Alphanumeric Information This dimension covers all non-geometric data: the property sets, attributes, classification codes, identifiers, and substantive data content attached to model elements. This is where LOD is entirely silent and LOIN does its most distinctive work.

Alphanumeric requirements might include:

Uniclass or OmniClass classification codes
Manufacturer name and product reference
Material specification and grade
Fire resistance rating
Acoustic performance rating
Installed cost or budgetary cost
Warranty period and terms
Maintenance interval and servicing requirements
Asset identification number for integration with CAFM/CMMS systems
Sustainability certifications (EPD reference, embodied carbon value)
BIM object GUID for persistent identification across CDE transactions

The specific alphanumeric requirements for a given element at a given stage depend entirely on who is receiving the information and what they are doing with it. A cost consultant at RIBA Stage 3 needs approximate unit costs and quantities. A facilities manager at handover needs the same element to carry the warranty reference, the service interval, and the maintenance contractor contact. These are different LOIN specifications for the same physical element, and both need to be in the EIR.

3. Documentation This dimension covers attached documents: manufacturer data sheets, test certificates, compliance declarations, O&M manuals, commissioning records, signed inspection reports, photographs, and similar artifacts. Documentation requirements are frequently the most operationally important and the most overlooked.

A fire damper at practical completion needs, at minimum: a commissioning certificate, a manufacturer's data sheet, a test certificate demonstrating compliance with the specified fire rating, and an installation photograph. These documents are not modeled — they are linked to the model element via the Common Data Environment. LOIN specifies what documents must be attached to which elements by which milestone.

Per-Element, Per-Stage, Per-Purpose Tailoring

The power of LOIN — and its implementation challenge — is that it operates at the level of individual element types at individual project stages for individual purposes. This granularity is what makes it genuinely useful and what makes it genuinely hard to write.

Consider a reinforced concrete column in a commercial office building. Here is how its LOIN specification might vary across the project lifecycle:

RIBA Stage 2 (Concept Design) — Purpose: Spatial feasibility and structural strategy

Geometric: 3D, approximate cross-section, correct floor-to-floor height, location approximate within 500mm
Alphanumeric: Structural system type, indicative size range, approximate floor load, Uniclass code
Documentation: None required at this stage

RIBA Stage 4 (Technical Design) — Purpose: Building regulations approval and cost planning

Geometric: 3D, specific cross-section dimensions, exact location, reinforcement schedule attached or referenced
Alphanumeric: Concrete grade, cover requirements, fire resistance class, cost code, structural element mark
Documentation: Structural calculation reference (not the calculation itself, but the reference number and author)

Construction — Purpose: Fabrication, construction sequencing, clash coordination

Geometric: Full LOD 350+ with connection geometry, rebar positions, embedment plates, blockout locations
Alphanumeric: Pour sequence number, pour date (to be populated post-pour), concrete supplier, delivery ticket reference
Documentation: Mix design certificate, test cube records (when available), inspection sign-off

Handover — Purpose: FM system integration and planned maintenance

Geometric: As-built position verified within 50mm, no fabrication detail required
Alphanumeric: As-built dimensions, actual concrete grade confirmed, asset ID for CAFM integration
Documentation: Structural completion certificate, any remediation records, O&M reference

This progression shows something that a LOD specification cannot show: the same physical element has different information requirements at each stage, and those requirements are not simply "more of the same." The handover LOIN specification for this column is not LOD 500 — it is a specific and limited set of geometric, alphanumeric, and documentary requirements calibrated to what a facilities management team actually needs.

EIR Linkage — How LOIN Connects to Contractual Information Requirements

LOIN does not float free as a specification tool. Within the ISO 19650 framework, it sits inside the Exchange Information Requirements (EIR) — the document issued by the Appointing Party (client) that specifies what information the Delivery Team must produce and deliver at each information exchange.

The ISO 19650 information cascade works as follows:

Organizational Information Requirements (OIR)

The client organization defines what information it needs across its asset portfolio to operate its business. This is strategy-level: "We need our asset register to be maintained in our CAFM system to enable preventive maintenance scheduling."

Asset Information Requirements (AIR)

For a specific built asset, the OIR is translated into concrete requirements: "The HVAC system in this building must be represented in the asset register with equipment type, manufacturer, model, serial number, service interval, and maintenance contractor."

Project Information Requirements (PIR)

At key decision gates during the project, specific information must be available to enable decisions: "At Stage 4, sufficient cost and specification data must be available to authorize a capital budget."

Exchange Information Requirements (EIR)

The EIR translates the above into the specific LOIN for each element type at each project milestone. The EIR is the document the Delivery Team responds to in its BIM Execution Plan (BEP).

LOIN is the technical expression of the EIR. When you write an EIR, you are writing LOIN specifications — even if you call them something else. The EIR says, in effect: for each element in this list, at each project stage in this list, you must deliver geometry of this type, attributes of these names and formats, and documents of these kinds. That is LOIN.

The BEP, in turn, is the Delivery Team's response: here is how we will meet your LOIN requirements, here are the tools and processes we will use, here is our quality assurance procedure. The BEP does not define LOIN — it responds to it.

BS EN ISO 7817-1:2024 — The Dedicated LOIN Standard

In July 2024, ISO published ISO 7817-1:2024, "Building information modelling — Level of information need — Part 1: Concepts and principles." This supersedes BS EN 17412-1:2020, which was the European precursor standard. The British Standards Institution adopted it simultaneously as BS EN ISO 7817-1:2024.

The transition from EN 17412-1 to ISO 7817-1 is largely one of international alignment rather than substantive revision. The core framework — three LOIN dimensions, purpose-driven specification, per-element per-stage granularity — remains intact. The international adoption means that LOIN is now the globally referenced framework, not a European regionalism, and that projects procured under ISO 19650 in any jurisdiction share a common reference.

ISO/CD TS 7817-2 (Part 2: Guidance for application) is in draft. When published, it will provide worked examples and application guidance that practitioners need to move from principles to practice.

Side-by-Side and Contract Implications

What LOD Covers and What LOIN Adds

The simplest way to understand the relationship between LOD and LOIN is to place them side by side at the level of a single model element.

LOD

LOIN

The LOD view tells you about the geometry. The LOIN view tells you what the geometry needs to carry. A model that satisfies LOD 350 but has no alphanumeric data satisfies the LOD specification and fails the LOIN specification.

Translating LOD Specs to LOIN — A Discipline-by-Discipline Walk-Through

The following examples work through how a LOD-based deliverable specification would be expanded into a LOIN specification for four major disciplines at two project stages. These are illustrative rather than prescriptive — actual LOIN specs are project-specific and should be developed from the EIR.

Discipline: Architectural — Doors and Windows

LOD specification (typical current practice): LOD 300 at Stage 4. All door and window elements modeled at specific size, swing, and location. Hardware groups referenced.

LOIN specification (ISO 19650 aligned):

Stage 4 (Technical Design):

Geometric: 3D, correct leaf count, swing direction, frame dimensions, threshold configuration, glazing sub-division. Accuracy: ±5mm on opening dimensions.
Alphanumeric: Door/window mark (from door schedule), fire rating (FD30, FD60, etc.), acoustic rating (dB Rw value), security rating (PAS 24 compliance Y/N), U-value, Uniclass code (Ss_25_16_25 or similar), ironmongery set reference, hardware supplier reference, room from / room to.
Documentation: None at this stage.

Handover:

Geometric: As-built position confirmed; no change to geometric detail if not modified.
Alphanumeric: All Stage 4 attributes retained; add: manufacturer name, model reference, warranty expiry date, maintenance interval (monthly / annually), CAFM asset ID.
Documentation: CE marking declaration of performance (or equivalent), hardware test certificate where required, installation certificate, maintenance manual reference (chapter and section within O&M manual, not the full document unless a standalone data sheet exists).

What changes contractually: At Stage 4, the architect cannot deliver a model that satisfies LOD 300 geometry with empty attribute sets. The LOIN specification requires fire ratings, acoustic ratings, and hardware set references to be populated — and those are data the architect must coordinate with the specification writer and the acoustic consultant. At handover, the contractor has a clear list of what must be attached to each door element in the CDE before a practical completion certificate can be issued. Disputes about whether a model is "complete" are resolved by checking the LOIN list, not by inspecting visual detail.

Discipline: Structural — Concrete Slabs

LOD specification (typical current practice): LOD 300 at Stage 4. All slabs modeled at specific thickness, extent, and level. Openings modeled at correct size and location.

LOIN specification:

Stage 4:

Geometric: 3D, exact plan extent, soffit level, finish level, all penetrations and openings at correct size and location (±10mm tolerance), falls to drainage indicated where applicable.
Alphanumeric: Slab mark/designation, concrete grade, nominal reinforcement description (mesh or rebar, bar size), design imposed load, fire resistance rating, structural element reference in the engineer's calculation set.
Documentation: Reference to structural calculation (document number, revision, author).

Construction:

Geometric: LOD 350 — reinforcement layout shown, post-installed fixings and blockouts included.
Alphanumeric: Add pour sequence number, specified mix design reference, pour contractor.
Documentation: Mix design certificate, pour record (populated post-pour).

Handover:

Geometric: As-poured geometry confirmed within 25mm of design intent, or as-built variations noted.
Alphanumeric: Add: as-built concrete grade confirmed by test cube results, any topping thickness variations, CAFM asset ID.
Documentation: Structural completion certificate, as-built survey certificate, test cube records.

What changes contractually: The structural engineer is no longer delivering only geometry. The design model at Stage 4 must carry calculation references and specified concrete grades. This creates an accountability chain: the model attribute must match the specification, and the specification must match the calculation. Discrepancies between model and specification — which are embarrassingly common in current practice — become auditable through the LOIN matrix. The contractor's handover obligations are equally specific: the test cube records must be linked to the slab elements, not submitted as a separate document pile.

Discipline: MEP — HVAC Air Handling Units

LOD specification (typical current practice): LOD 400 at construction stage. All AHUs modeled at fabrication-level geometry with duct connections at correct face locations.

LOIN specification:

Stage 3 (Spatial Coordination):

Geometric: 3D, envelope dimensions accurate to ±50mm, connection face locations accurate to ±25mm, maintenance access zones modeled as clearance volumes.
Alphanumeric: AHU mark, airflow rate (l/s), heating/cooling capacity (kW), electrical supply (kW, phases), weight (for structural loading), Uniclass code.
Documentation: Manufacturer's preliminary data sheet (if product selected) or generic design data from manufacturer's range.

Construction Stage:

Geometric: Actual manufacturer's model or equivalent BIM object at LOD 400. All connections at exact position. Access panel locations.
Alphanumeric: Manufacturer name, model reference, serial number (to be added post-delivery), refrigerant type (if applicable), coil configuration, filter type, BACnet/Modbus address (to be added post-commissioning), warranty period.
Documentation: Manufacturer's data sheet, CIBSE/ARI performance certification, electrical schematic reference.

Handover:

Geometric: As-installed position confirmed; no fabrication detail change required.
Alphanumeric: Add: serial number, commissioning date, first service due date, BAS/BMS point list reference, CAFM asset ID, energy consumption (measured at commissioning).
Documentation: Commissioning certificate, test and balance report, O&M manual (section reference), extended warranty certificate if applicable, refrigerant certificate of conformity.

What changes contractually: The LOD 400 requirement has always meant the geometry is fabrication-ready. The LOIN specification adds that the model element cannot be marked complete — in the CDE, status cannot move to "Shared" at handover — until the commissioning certificate is attached and the CAFM asset ID is populated. This is an enforceable, auditable requirement. The MEP contractor's final account cannot be certified for that equipment package until the LOIN list is complete.

Discipline: Civil / Site — Below-Ground Drainage

Below-ground drainage is one of the most overlooked areas in BIM specifications and one where LOIN adds disproportionate value, because below-ground assets are the hardest to verify post-construction and the most expensive to remediate if records are wrong.

LOD specification (typical current practice): LOD 300 at Stage 4. Drainage runs modeled at correct invert levels, pipe sizes, and manhole locations.

LOIN specification:

Stage 4:

Geometric: 3D, pipe centerlines at correct invert levels (±25mm), pipe OD and wall thickness at correct values, all manholes, inspection chambers, and rodding eyes at correct position and rim level.
Alphanumeric: Pipe material (VC, concrete, HDPE, etc.), pipe class/series, nominal bore, gradient, flow direction, connected to (upstream and downstream manhole marks), drainage area ID, Uniclass code.
Documentation: None required at Stage 4 design.

Construction:

Geometric: As-installed survey data. CCTV survey footage referenced by manhole-to-manhole run.
Alphanumeric: All Stage 4 attributes confirmed or updated to as-installed values. Add: installation date, contractor name, embedment material, CCTV survey reference number.
Documentation: CCTV survey report per run, pressure test certificates per section, Building Regulations completion certificate reference.

What changes contractually: Drainage models in current practice frequently carry no pipe class, no gradient confirmation, and no CCTV survey link. The LOIN specification creates an unambiguous checklist for the building contract practical completion inspection. The client and their FM team can audit the drainage asset register in the CDE before signing off practical completion — not by inspecting a pile of paper certificates, but by checking whether the model elements have the required attributes and document links populated.

How Procurement Language Shifts

The shift from LOD to LOIN in deliverable specifications requires corresponding changes in procurement language. The following comparison shows how a typical BIM scope of service clause transforms:

Current LOD-centric language:

The Design Team shall develop Building Information Models as follows:

Architectural: LOD 200 at RIBA Stage 2, LOD 300 at RIBA Stage 3, LOD 300 at RIBA Stage 4

Structural: LOD 200 at RIBA Stage 2, LOD 300 at RIBA Stage 3, LOD 350 at RIBA Stage 4

MEP: LOD 200 at RIBA Stage 2, LOD 300 at RIBA Stage 3, LOD 350 at RIBA Stage 4 All models shall be delivered to the CDE in accordance with the BIM Execution Plan.

This language is typical, widely used, and structurally incomplete. It specifies geometry. It says nothing about attributes, classifications, documents, or what the client will actually do with the model.

LOIN-aligned language:

The Delivery Team shall develop and deliver information in accordance with the Exchange Information Requirements (EIR) dated [date] and the BIM Execution Plan accepted by the Appointing Party. Information deliveries shall satisfy the Level of Information Need (LOIN) specified in Appendix [X] of the EIR for each element type at each project milestone. Compliance shall be verified by the Lead Information Manager prior to milestone payment certification. Elements failing to meet the specified LOIN shall be identified in the non-conformance register and remedied within [14] days of notification.

This language is different in kind, not just in vocabulary. It refers to a specific EIR. It includes a compliance verification mechanism. It creates a remedy period for non-conformance. It ties information delivery to payment certification. These are contractual teeth that LOD-only language does not provide.

Dispute Scenarios — Where the Gap Between LOD and LOIN Creates Problems

The following scenarios are illustrative composites drawn from patterns common in BIM-enabled projects. They are not accounts of specific legal cases.

Scenario 1: The informationally empty Stage 4 model

A contractor receives a Stage 4 Revit model from the design team that satisfies LOD 300 for all architectural elements and LOD 350 for structural and MEP. The contract specified LOD per the BIM Forum specification and referenced the BIM Execution Plan.

At handover, the building operator attempts to import the model into their CAFM system. It fails because no elements carry the required asset IDs, Uniclass codes, or manufacturer references. The operator requests that the contractor populate these attributes. The contractor argues that the contract specified LOD, not attribute population, and that the model satisfies every LOD requirement. The design team agrees with the contractor.

The operator has no recourse under the contract because LOD does not cover attributes. The CAFM import project costs six months and significant additional fees to complete manually.

If the EIR had specified LOIN — including the specific attribute requirements for CAFM integration and the requirement that those attributes be populated at handover — the contractor would have had a clear obligation, and non-compliance would have been grounds for withholding the final payment certification.

Scenario 2: The LOD 500 handover model that is not actually verified

A contractor delivers a model stamped "LOD 500 as-built" at practical completion. The contract requires LOD 500. Eight months later, during a fit-out project, the tenant contractor discovers that multiple structural column locations in the model are incorrect — in some cases by more than 150mm — because the as-built model was produced by updating the design intent model from construction photographs rather than from a measured survey.

The original contractor argues that the model was delivered at LOD 500 per the contract requirement, which they interpret as "as-built geometry reflecting the completed building." The client argues that LOD 500 requires field verification, which was not performed.

The underlying problem: "LOD 500" and "field verification" were not defined in the contract. The BIM Forum LOD Specification, which the contract referenced, does not provide a detailed LOD 500 definition or specify what field verification entails. Had the contract specified a LOIN requirement for the as-built model — including geometric accuracy tolerance (±25mm), survey method (total station or laser scan), and survey certification — the deliverable would have been defined and verifiable.

Scenario 3: The cross-border LOD/LOI mismatch

A US architectural firm delivers a BIM model for a building in Singapore at "LOD 300" per their standard US contract. The Singapore client, whose facilities management team works within an ISO 19650-compliant framework, sends the model to their information manager for review.

The information manager identifies that while the geometry meets what a US practitioner would recognize as LOD 300, the model has no COBie data, no IFC classification codes, no Singapore BCA classification references, and no maintenance data. From the client's perspective, the model is not a usable information deliverable.

The architect argues that LOD 300 was delivered as specified. The client argues that the deliverable is incomplete. Neither is wrong given the reference standard they are using. The contract failed to specify which framework — and the answer to that question is different in Singapore (ISO 19650 / IFC-aligned) than in the US (AIA G202 / BIM Forum LOD Spec).

The resolution required a post-contract scope extension for information enrichment. A LOIN specification in the EIR, agreed at appointment, would have defined the deliverable clearly regardless of which team's native practice the geometry originated from.

Anti-Patterns

Fifteen years of LOD contracts and a growing ISO 19650 adoption wave have produced a recognizable set of recurring mistakes. The following five are the most consequential.

Anti-Pattern 1: Citing Both LOD and LOIN with No Priority or Translation

A growing number of BIM Execution Plans include both a LOD schedule and a LOIN reference, typically as a result of combining a US-origin LOD table with an ISO 19650 compliance statement. The two frameworks are listed as parallel requirements with no articulation of how they relate or which governs when they conflict.

This creates a compliance problem that is not resolvable at delivery. If the LOD 300 definition says nothing about attributes and the LOIN reference requires attributes, which standard does the information manager audit against? If there is a dispute, which document governs?

The correct approach is to use LOIN as the primary specification framework and to express geometric requirements within the LOIN specification using LOD-style language where useful — "geometric detail equivalent to BIM Forum LOD 350" is a legitimate and communicative way to specify the geometric dimension of a LOIN requirement. LOD becomes a reference vocabulary within LOIN, not a parallel specification regime.

Anti-Pattern 2: Ignoring the Information Layer Entirely

This is the most common pattern: a contract specifies LOD, the team delivers geometry, and nobody asks about attributes until handover. At handover, the client's facilities management team discovers that the model is a geometrically accurate but informationally barren representation of their building.

The cost of retrospective information enrichment — going back to a completed project and populating attributes from O&M manuals, commissioning records, and manufacturer data sheets — is typically 15–25% of the original BIM modeling cost. It requires access to records that may have been archived, personnel who may have moved on, and software that may have changed. It is never as accurate as information captured in the workflow at the point of origination.

The information layer does not spontaneously appear when the geometry is complete. It must be specified in the EIR, assigned to responsible parties in the BIM Execution Plan, quality-checked at each information exchange, and verified before practical completion sign-off. None of this happens unless it is designed into the project information management workflow from appointment.

Anti-Pattern 3: Conflating LOD with Documentation Completeness

"We delivered a LOD 500 model" is a statement that teams make to indicate that their deliverable is complete, comprehensive, and fully verified. As the LOD 500 analysis in this article shows, this conflates three distinct things: geometric accuracy, attribute completeness, and documentation linkage.

A LOD 500 model — correctly understood — means that the geometric representation has been field-verified. It says nothing about whether attributes are populated, whether commissioning certificates are linked, whether test records are attached. A model can be LOD 500 and still be useless for FM integration because the information and documentation layers are missing.

This conflation appears most visibly in handover specifications that say "the contractor shall deliver a LOD 500 as-built BIM model" without any further definition. The contractor interprets this as a modeling instruction. The client expects it to encompass all project information. The gap is resolved at the contractor's discretion, not the client's requirement.

Anti-Pattern 4: Uniform LOD Across All Elements

Specifying the same LOD for all elements across an entire discipline — "all architectural elements at LOD 300 at Stage 4" — treats every element as equally important and equally needing the same level of detail. In practice, a structural steel column and a painted internal partition wall do not require the same specification depth at the same project stage for the same purposes.

Uniform LOD specifications create two problems simultaneously: they under-specify critical elements (the column should carry more attributes than LOD allows) and over-specify minor elements (the partition wall needs no more than its room-side finish and fire rating). The result is a model where significant modeling effort was spent on unimportant elements and critical information was never specified.

LOIN's per-element, per-purpose structure eliminates this problem by design — but only if the EIR author does the work of identifying which elements matter for which purposes at which stages. This is more work than writing a single LOD number. It is the work that a properly resourced information management function should be performing.

Anti-Pattern 5: Treating LOD as a Proxy for Design Stage Completion

LOD levels are sometimes used in contracts as stage gate criteria — "Stage 3 complete when all elements reach LOD 300" — as though LOD is a reliable indicator of design progress. It is not.

A designer can model every element to LOD 300 geometry while the specification remains incomplete, the consultant coordination remains unresolved, and the cost plan remains unvalidated. LOD is a model element attribute, not a project stage attribute. Design stage completion depends on far more than model maturity.

Using LOD as a stage gate criterion creates perverse incentives: designers focus on modeling to the LOD threshold rather than resolving design issues. A LOIN-based stage gate — which requires that elements carry the specific attribute set needed for the stage gate purpose, such as the information needed to validate a cost plan or to submit for building regulation approval — is a more honest proxy for design stage readiness.

Case Studies

Case Study A: Infrastructure Owner Transitioning from LOD-Only to LOIN Specification

A major transport infrastructure owner in a jurisdiction that has adopted ISO 19650 reviewed its BIM deliverable specification after a series of handover failures. In three consecutive major projects, the handover models delivered by contractors were geometrically complete but could not be imported into the asset management system because the attribute schemas did not match the system's data requirements.

The projects had all been specified with detailed LOD schedules. MEP and structural elements were required at LOD 350 or LOD 400 at practical completion. The geometric specifications were met. The asset management system required IFC-compliant data structures with specific property sets, and none of the models had been produced with those structures.

The owner's information management team undertook a 12-month project to develop an EIR that specified LOIN for each of the 47 element types that feed their asset management system. The LOIN specification addressed:

The exact IFC entity type required for each element
The required property sets (using buildingSMART Data Dictionary references)
The required attributes within each property set, with value types, units, and allowable values where applicable
The documents that must be linked to each element type at commissioning
The document format requirements (PDF/A for archival, native format for live documents)

On the first project procured under the new EIR, the contractor's delivery team flagged during BEP development that several of the required property sets were not supported in their primary authoring tool. This was discovered 8 weeks after appointment rather than at handover — enough time to agree a workaround using an intermediate data format. The LOIN specification had made the requirement visible before the work started rather than after it was finished.

At handover on that project, the asset management import success rate was 94% of required element types on the first pass, compared to 23% on the preceding LOD-only project. The improvement was attributable almost entirely to the LOIN specification providing a defined and auditable target.

Case Study B: Cross-Discipline Coordination Failure Caused by LOD/LOI Mismatch

A mixed-use development project in a jurisdiction with no BIM mandate used a LOD-based BIM specification. The architect, structural engineer, and MEP consultant each delivered models at the specified LOD levels — LOD 300 for design, LOD 350 for coordination, LOD 400 for MEP systems.

The mechanical engineer had a standard BIM object library for HVAC equipment. The library objects were geometrically detailed to LOD 400 but carried no MEP service connection attributes — no duct connection sizes, no pipe connection sizes, no electrical load data as model attributes. This information existed in the M&E engineer's calculation sheets and specification, but it was not in the model.

When the BIM coordination model was assembled, the coordinator identified that the ductwork connections to the AHUs were misaligned. The ductwork modeler had assumed connection face sizes based on the generic manufacturer data shown in the model — which in several cases did not match the actual specified equipment.

The coordination clash cost three weeks of rework. The root cause was that the MEP objects satisfied LOD 400 geometrically but the geometric information (connection face dimensions) needed by the ductwork modeler was not encoded as an attribute — it was in a document that the ductwork modeler had not accessed.

A LOIN specification would have required the AHU objects to carry duct connection face sizes as a named attribute at the coordination stage. The ductwork team would have been able to verify the attribute value rather than assuming it from visual inspection of the object. The coordination clash might still have been discovered, but it would have been discovered in the attribute verification step rather than the coordination review step — earlier and cheaper.

Case Study C: FM Integration Enabled by LOIN-Structured Handover

A healthcare client with a sophisticated in-house FM team commissioned a hospital extension under an ISO 19650-compliant EIR that included a detailed LOIN specification for the 83 MEP equipment types that feed their CAFM system.

The LOIN specification for medical gas outlets, for example, required:

Geometric: LOD 350, correct face size and orientation, zone identification modeled as a spatial boundary
Alphanumeric: Outlet type (oxygen, vacuum, AGSS, etc.), outlet pressure (bar), flow rate (l/min), zone ID, HTM 02-01 compliance reference, service outlet number matching physical label
Documentation: Commissioning certificate, pressure test certificate, compliance certificate from authorized person (medical gases)

The contract included a payment hold-back provision: 2.5% of the MEP contract value was withheld until the LOIN compliance audit confirmed that all 1,847 medical gas outlet instances in the CDE carried the required attributes and document links.

The hold-back provision changed the contractor's behavior during the project. Rather than treating FM data as a post-construction clerical exercise, the MEP contractor built the attribute population into the commissioning workflow. As each outlet was commissioned, the commissioning engineer populated the CAFM data fields and linked the commissioning certificate to the model element in the CDE. By practical completion, 91% of outlets met the LOIN specification, with the remaining 9% resolved within the 30-day defects period.

The FM team was able to import the asset data directly into their CAFM system at handover with no manual re-entry. The medical gas maintenance programme was live on day one of occupation. This outcome — unprecedented on previous projects at the same trust — was directly attributable to the LOIN specification and the payment incentive attached to it.

Limits and Caveats

Regional Adoption is Not Uniform

ISO 19650 has achieved wide formal adoption, but LOIN-structured EIRs remain concentrated in specific markets and project types. The UK, Singapore, Australia, New Zealand, and several European jurisdictions have active ISO 19650 adoption programmes with government mandates or strong industry guidance. In these markets, LOIN-aligned EIRs are increasingly expected on public sector projects.

In the United States, adoption is different in character. The US has no federal ISO 19650 mandate. The USACE's Advanced Modeling requirements reference LOD (via the M3 Minimum Modeling Matrix) rather than LOIN. The GSA BIM Guide Series, one of the most influential federal BIM references, predates ISO 19650 and uses LOD language throughout. The NBIMS-US (National BIM Standard, United States) has incorporated ISO 19650 concepts in its current version but LOD remains the dominant contractual vocabulary in practice.

This means that US practitioners working domestically may encounter LOD as the primary or only specification framework for the foreseeable future. The practical response is not to wait for federal adoption of LOIN, but to use LOIN thinking as an internal quality framework — specifying information requirements in the EIR / BEP even when the contract calls them LOD specifications — so that the information layer is managed regardless of the contract vocabulary.

Federal Contracts Have Specific Requirements

USACE contracts require compliance with the M3 Minimum Modeling Matrix, which defines LOD requirements by discipline and project phase. These requirements are prescribed and auditable. Adding LOIN language to a USACE-procured project without understanding how it interacts with M3 requirements creates contractual ambiguity.

GSA-procured projects operate under the GSA BIM Guide Series, which similarly uses LOD framing. Federal acquisition regulations (FAR) govern what can be included in the BIM specification scope, and non-standard requirements can create procurement problems if they are not clearly scoped and priced.

For federal projects, the practical approach is to satisfy the specified LOD requirements — which are the contractual minimum — and to add LOIN-structured information requirements to the BIM Execution Plan as supplementary commitments where the owner's program supports them. This approach is contractually safe and progressively advances information management practice without creating conflict with the base contract.

LOIN Writing is a Skill That Requires Investment

LOIN is not self-implementing. Writing a meaningful EIR with per-element LOIN specifications requires deep knowledge of: what information each downstream function actually needs (facilities management, cost management, regulatory compliance, health and safety), how that information will be used (what software, what workflows, what formats), and what is realistically achievable at each project stage given the tools and workflows the delivery team is using.

Most project teams do not have this knowledge concentrated in a single role. Information managers need input from FM teams, cost consultants, commissioning engineers, and regulatory compliance leads to write a genuinely useful LOIN specification. Producing a LOIN specification from first principles on a first project takes significant effort. The investment compounds: the second project using the same asset type benefits from the first project's LOIN development.

Organizations that treat LOIN development as a one-time overhead rather than an ongoing intellectual asset — building and refining LOIN templates by asset type, updating them as FM workflows evolve and tools change — will get disproportionate value from the framework.

LOIN Specification Sample (YAML)

The following is a simplified YAML representation of a LOIN specification for two element types at two project stages. It is intended as a structural reference for how LOIN might be encoded in a machine-readable format within a CDE or project information management tool.

# LOIN Specification - Hospital Extension Project
# Standard: BS EN ISO 7817-1:2024
# Project Stage Reference: RIBA Plan of Work 2020
# Version: 1.0 | Issued: 2026-06-02
 
loin_specification:
  project: "Hospital Extension - Block C"
  client: "NHS Trust"
  appointing_party_contact: "Information Manager - Client"
  standard_reference: "BS EN ISO 7817-1:2024 / ISO 19650-1:2018"
 
  element_types:
 
    - element_type: "Air Handling Unit"
      uniclass_code: "Pr_70_65_96_15"
      ifc_entity: "IfcUnitaryEquipment"
 
      stages:
 
        - stage: "RIBA Stage 3 - Spatial Coordination"
          purpose: "Space allocation, structural loading, service zone coordination"
          responsible_party: "Lead MEP Engineer"
 
          geometric:
            dimensionality: "3D"
            detail_reference: "BIM Forum LOD 200 envelope"
            location_accuracy: "±500mm"
            appearance: "Generic box with correct orientation"
            connection_faces: true
            maintenance_clearance_zones: true
 
          alphanumeric:
            required_attributes:
              - name: "AHU_Mark"
                type: "string"
                mandatory: true
                description: "Equipment designation from schedule"
              - name: "Airflow_Rate_ls"
                type: "float"
                unit: "l/s"
                mandatory: true
              - name: "Cooling_Capacity_kW"
                type: "float"
                unit: "kW"
                mandatory: true
              - name: "Heating_Capacity_kW"
                type: "float"
                unit: "kW"
                mandatory: false
              - name: "Electrical_Load_kW"
                type: "float"
                unit: "kW"
                mandatory: true
              - name: "Operating_Weight_kg"
                type: "integer"
                unit: "kg"
                mandatory: true
                description: "For structural loading check"
              - name: "Uniclass_Code"
                type: "string"
                mandatory: true
 
          documentation:
            required_documents: []
            notes: "No documents required at Stage 3. Manufacturer data sheet to be attached at Stage 5."
 
        - stage: "RIBA Stage 6 - Handover"
          purpose: "CAFM integration, planned preventive maintenance setup"
          responsible_party: "Mechanical Contractor"
 
          geometric:
            dimensionality: "3D"
            detail_reference: "Manufacturer BIM object or equivalent LOD 400"
            location_accuracy: "±25mm as-installed"
            appearance: "As manufacturer object"
            connection_faces: true
            maintenance_clearance_zones: true
 
          alphanumeric:
            required_attributes:
              - name: "AHU_Mark"
                type: "string"
                mandatory: true
              - name: "Manufacturer_Name"
                type: "string"
                mandatory: true
              - name: "Model_Reference"
                type: "string"
                mandatory: true
              - name: "Serial_Number"
                type: "string"
                mandatory: true
              - name: "Commissioning_Date"
                type: "date"
                format: "ISO 8601"
                mandatory: true
              - name: "First_Service_Due"
                type: "date"
                format: "ISO 8601"
                mandatory: true
              - name: "Service_Interval_Months"
                type: "integer"
                mandatory: true
              - name: "Warranty_Expiry"
                type: "date"
                format: "ISO 8601"
                mandatory: true
              - name: "CAFM_Asset_ID"
                type: "string"
                mandatory: true
                description: "Assigned by FM team; populate before handover milestone"
              - name: "BACnet_Device_ID"
                type: "string"
                mandatory: true
              - name: "Refrigerant_Type"
                type: "string"
                mandatory: false
                description: "Required only if AHU incorporates DX coil"
              - name: "Airflow_Rate_ls"
                type: "float"
                unit: "l/s"
                mandatory: true
                description: "As-commissioned measured value"
              - name: "Electrical_Load_kW"
                type: "float"
                unit: "kW"
                mandatory: true
                description: "As-commissioned measured value"
 
          documentation:
            required_documents:
              - type: "Commissioning Certificate"
                format: "PDF/A"
                issuer: "Commissioning Engineer"
                mandatory: true
              - type: "Test and Balance Report"
                format: "PDF/A"
                mandatory: true
              - type: "Manufacturer Data Sheet"
                format: "PDF"
                mandatory: true
              - type: "O&M Manual Reference"
                format: "string"
                description: "Document number and section reference, not the full manual"
                mandatory: true
              - type: "Extended Warranty Certificate"
                format: "PDF/A"
                mandatory: false
 
    - element_type: "Fire Door - FD30"
      uniclass_code: "Ss_25_16_25"
      ifc_entity: "IfcDoor"
 
      stages:
 
        - stage: "RIBA Stage 4 - Technical Design"
          purpose: "Building regulations application, fire strategy compliance, specification coordination"
          responsible_party: "Lead Architect"
 
          geometric:
            dimensionality: "3D"
            detail_reference: "BIM Forum LOD 300"
            location_accuracy: "±10mm opening dimensions"
            swing_direction: true
            threshold_configuration: true
            frame_rebate: true
 
          alphanumeric:
            required_attributes:
              - name: "Door_Mark"
                type: "string"
                mandatory: true
              - name: "Fire_Rating"
                type: "string"
                allowed_values: ["FD30", "FD60", "FD90", "FD120"]
                mandatory: true
              - name: "Acoustic_Rating_dBRw"
                type: "integer"
                unit: "dB"
                mandatory: false
              - name: "Ironmongery_Set_Reference"
                type: "string"
                mandatory: true
              - name: "Room_From"
                type: "string"
                mandatory: true
              - name: "Room_To"
                type: "string"
                mandatory: true
              - name: "Uniclass_Code"
                type: "string"
                mandatory: true
              - name: "Specification_Clause"
                type: "string"
                mandatory: true
                description: "NBS or equivalent spec clause reference"
 
          documentation:
            required_documents: []
            notes: "CE marking and performance data required at Stage 6 handover."
 
        - stage: "RIBA Stage 6 - Handover"
          purpose: "Fire safety record, FM maintenance planning, regulatory compliance file"
          responsible_party: "Main Contractor"
 
          geometric:
            dimensionality: "3D"
            detail_reference: "As Stage 4, updated if modified"
            location_accuracy: "As-installed, confirmed"
 
          alphanumeric:
            required_attributes:
              - name: "Door_Mark"
                type: "string"
                mandatory: true
              - name: "Manufacturer_Name"
                type: "string"
                mandatory: true
              - name: "Product_Reference"
                type: "string"
                mandatory: true
              - name: "Fire_Rating"
                type: "string"
                mandatory: true
              - name: "CE_Mark_Declaration_Number"
                type: "string"
                mandatory: true
              - name: "Warranty_Period_Years"
                type: "integer"
                mandatory: true
              - name: "Annual_Inspection_Required"
                type: "boolean"
                mandatory: true
              - name: "CAFM_Asset_ID"
                type: "string"
                mandatory: true
 
          documentation:
            required_documents:
              - type: "CE Marking Declaration of Performance"
                format: "PDF/A"
                mandatory: true
              - type: "Installation Certificate"
                format: "PDF/A"
                issuer: "Specialist Installer"
                mandatory: true
              - type: "Hardware Test Certificate"
                format: "PDF/A"
                mandatory: false
                notes: "Required if rated hardware specified"
              - type: "Maintenance Manual Reference"
                format: "string"
                mandatory: true

LOD-to-LOIN Translation Table (CSV)

The following CSV table provides a reference translation between LOD levels and the corresponding LOIN dimensions. It is intended as a starting point for EIR development — actual LOIN specifications must be element-specific and project-specific.

LOD_Level,LOD_Description,LOIN_Geometric_Equivalent,LOIN_Alphanumeric_Minimum,LOIN_Documentation_Minimum,Typical_Project_Stage,Notes
LOD 100,Conceptual symbol or mass,"3D approximate volume, correct general location, ±order of magnitude dimensions","Element type classification code, area/volume estimate","None","RIBA Stage 2 / SD","No information layer prescribed by LOD. LOIN should specify asset classification minimum."
LOD 200,Generic system with approximate geometry,"3D, recognizable geometry, approximate quantities ±20%, schematic position","System type, capacity estimate (area/volume-based), cost allowance code, Uniclass L2 code","None","RIBA Stage 2-3 / DD","LOD 200 geometry is sufficient for space planning. LOIN should add performance envelope data."
LOD 300,Specific system with precise geometry,"3D, exact dimensions ±10mm, specific product family or generic equivalent, correct location relative to project origin","Specification clause reference, performance criteria (fire rating, acoustic, thermal), classification code L3, responsible party","None at design stage; system test certificates at construction","RIBA Stage 4 / CD","LOD 300 does not mandate attribute population. LOIN must specify required property sets explicitly."
LOD 350,Precise geometry with system interfaces,"3D, LOD 300 plus connection geometry (bolt groups, flange faces, duct spigots, pipe branches), clearance/maintenance zones","All LOD 300 attributes plus interface dimensions as named attributes (not embedded in geometry only), connection type designation","Supplier data sheet where product specified","RIBA Stage 4-5 / CD-CA","Critical: interface dimensions must be attributes, not just geometry. LOIN enforces this."
LOD 400,Fabrication-ready geometry,"3D, manufacturer model or equivalent, all fabrication tolerances, installation sequence geometry where required","Manufacturer name, model reference, serial/batch number placeholder, all performance data as attributes, cost code, trade package ID","Manufacturer data sheet, preliminary commissioning data","Construction / CA","LOD 400 geometry is necessary but not sufficient. LOIN adds the information layer needed by procurement, commissioning, and FM."
LOD 500,Field-verified as-built,"As LOD 400 with as-installed survey confirmation; accuracy per LOIN spec (typically ±25-50mm), deviations from design noted","All LOD 400 attributes confirmed as-installed; add: serial number, commissioning date, CAFM asset ID, service interval, first service due","Commissioning certificate, test report, O&M manual reference, warranty certificate, compliance certificates","RIBA Stage 6 / Handover","LOD 500 is a quality designation not a geometry escalation. BIM Forum does not detail LOD 500. LOIN is essential to define what 'field verified' means contractually."

Sources and Further Reading

Primary Sources

AIA E202-2008, Building Information Modeling Protocol Exhibit — American Institute of Architects, 2008. The foundational document introducing LOD as a contractual concept. Superseded by AIA G202-2013.
AIA G202-2013, Building Information Modeling Protocol Form — American Institute of Architects, 2013. Current AIA LOD reference document, introducing the Model Author concept.
BIM Forum LOD Specification 2024, Part I — BIMForum, published November 2024. Current reference specification for LOD 100–500 by discipline. Available at bimforum.org. Previous editions (2013–2023) available in the same archive.
BS EN ISO 19650-1:2018, Organization and digitization of information about buildings and civil engineering works, including building information modelling — Part 1: Concepts and principles — ISO/BSI, 2018. Introduces LOIN as the framework for specifying information requirements. Available via BSI Knowledge.
BS EN ISO 7817-1:2024, Building information modelling — Level of information need — Part 1: Concepts and principles — ISO/BSI, July 2024. Supersedes BS EN 17412-1:2020. The dedicated LOIN standard aligning with ISO 19650. Available at thenbs.com publication index.
NBS BIM Toolkit and BIM Levels of Information — NBS (RIBA Enterprises), 2015–2022. UK practitioner tool for specifying LOD and LOI per building element. Discussion of evolution toward LOIN at thenbs.com/knowledge/bim-levels-of-information.
Symetri: ISO 19650 Level of Information Need — The Elephant in the Room — Symetri UK, blog post. Practitioner analysis of LOIN implementation challenges. Available at symetri.co.uk.
Catenda: Level of Information Need — Catenda, glossary article. Concise practitioner summary of LOIN definition, components, and implementation. Available at catenda.com/glossary/level-of-information-need.
BIM Corner: Exchange Information Requirements — The Rulebook of Your BIM Project — BIM Corner. Detailed breakdown of EIR structure and LOIN integration. Available at bimcorner.com.
BibLus / ACCA Software: Understanding LOD and LOIN in BIM — ACCA Software, technical article. Discipline-specific examples and comparison of LOD and LOIN frameworks. Available at biblus.accasoftware.com.

LOD vs LOIN: a practical reading of ISO 19650

Tools that pair with this post

Revit Tools — All Four

Family Library — Complete

Digital twins for O&M: COBie vs IFC vs vendor platforms — what actually survives PC2

4D BIM scheduling in 2026: Synchro vs Navisworks Timeliner vs Bexel Manager honest review

Autodesk Construction Cloud migration playbook 2026: from BIM 360 to ACC unified