Somewhere in the exchange information requirements on your desk there is a line saying all models shall be LOD 300. It came from the last job, which took it from the one before that, and it is probably the most expensive sentence in the document. It reads like a specification. It behaves like a volume knob.

Two things follow, usually both at once. A task team models every bolt on a bracket at a stage that needed a bounding box, and leaves blank the one property the next decision actually turns on. Nobody involved is being careless. They were told to turn it up to 300, so they turned up the part they could see.

ISO 19650 was supposed to end that conversation. In place of the number it puts level of information need: the extent and granularity of information required for a named purpose, at a named milestone, for a named actor. Enough to decide. Not everything the authoring tool happens to be able to store.

Start with one sentence you already have

Take a single slogan out of the current EIR, BEP or TIDP — usually a number applied to a whole model — and rewrite it as a row: purpose, milestone, objects, geometrical information, alphanumerical information, documents, and what is deliberately out of scope. If the row still needs a meeting to interpret, it is still a slogan.

None of the standards will write those rows for you. ISO 19650 and the UK BIM Framework both assume somebody on the project can say what enough looks like, and the contract forms assume the same. In practice that somebody is an information manager working alone, three weeks before tender, working from a template inherited from an older job.

Three ladders, one cell

Ask three people in a coordination meeting what LOD 300 means and you will get three answers, each of them defensible, because the industry collapsed three separate ladders into one cell.

Level of detail is how fine the geometry looks: a box, a typed extrusion, a manufacturer's mesh. It is a graphics setting. It says nothing about whether the object can be bought, built, or maintained from.

Level of development is the AIA / BIMForum ladder — 100, 200, 300, 350, 400, 500. Those numbers are a claim about how far the element can be relied on, not a shopping list of properties. LOD 300 means specific assemblies with quantity, size, shape, location and orientation. It does not name a fire rating, a system, a warranty, or a document.

Level of definition is the PAS 1192-2 phrase. It split graphical level of model detail from non-graphical level of model information, often mapped to plan-of-work stages. UK appointments still quote that split. ISO 19650 does not.

So when an EIR says LOD 300, nobody in the room can say which ladder was meant. The appointed party prices a pretty model. The appointing party believes it bought reliability. Facilities inherit geometry with empty fields. That is not a software problem. It is a specification that never specified.

What ISO 19650 actually means by it

ISO 19650-1 defines level of information need as the framework that determines the extent and granularity of information (3.3.16). The definition exists as much to stop over-delivery as under-delivery — the over-modelled Stage 2 door, the fabrication-level steel at spatial coordination, the COBie dump nobody validated. Clause 11.2 puts the framework inside collaborative production, which is a formal way of saying you agree what is enough before anyone produces it.

Part 2 turns the idea into process. The information standard says how level of information need is assigned (5.1.4). Exchange information requirements and task information delivery plans carry it against containers, dates and authors (5.4.3 to 5.4.5). Shared containers are reviewed against it (5.6.4). Authorisation of the information model is reviewed against it again (5.7.1–5.7.2). A number in a footer cannot do any of those four jobs.

The UK BIM Framework, and the method later published as EN 17412-1 (and internationally as ISO 7817-1), break the framework into prerequisites and content. If you intend to quote either in an appointment, have the text open in front of you; secondhand clause numbers circulate freely and a fair number of them are wrong. The working grain, though, is stable and small:

  1. Purpose — the decision or action this information must support.
  2. Milestone — the exchange, stage or date when it must exist.
  3. Actor — who will use it, and who must author it.
  4. Then, for the objects in scope: geometrical information, alphanumerical information, and documentation.

Purpose first, content second. There is no number anywhere in that list, and in a room used to arguing about the number, that absence takes a while to land.

What a number cannot specify

LOD 300 cannot answer the questions a task team has to price.

For whom? Coordination, procurement, construction, or operations. The same air terminal is a bounding box to the ceiling coordinator, a duty and acoustic pack to the buyer, and a filter interval to the operator. One number pretends those three people want the same object.

For which decision? Freeze a ceiling zone, place an order, pour a slab, populate an asset register. If you cannot name the decision, you cannot name enough.

Which objects? "The MEP model" will not do. IfcFlowTerminal on Level 03 will, or door type D-FR-01 in the stair cores.

Which geometry? A clearance envelope, a nominal size, a connection point, a fabrication mesh. "Specific" is not a geometry instruction.

Which fields? Name, definition, unit or allowed list, example, author. LOD 300 has none of those.

Which documents? A data sheet, a test certificate, a manufacturer's declaration, nothing. Silence here becomes a binder at handover, assembled in a hurry by whoever is left.

What is out of scope? The most useful line on a level-of-information-need row is the one that forbids work. No manufacturer geometry at Stage 3. No asset tags before the equipment schedule is frozen. No bolt groups from the structural engineer when the steelwork contractor holds the fabrication model. Leave that line out and "enough" quietly collapses back into "everything".

Four objects, four purposes

Copy the grain, not the project. Each example below is one object type at one milestone, because that is the grain a row works at; a whole-model LOD is how that writing gets avoided.

A fire door at two stages

Stage 3, purpose: coordinate openings and the fire strategy. Actor: architectural task team, read by structures and fire. Geometry: leaf and frame as a typed opening with clear width, swing and fire-compartment face — not ironmongery meshes. Alphanumerical: fire rating from the project enumerations, leaf type, accessibility clear opening, Uniclass (or the project classification) for the type. Documents: none, or a strategy extract that already exists. Out of scope: manufacturer, closer model, warranty, asset tag.

Handover, purpose: operate and maintain the door. Actor: the same type, now authored so a facilities team can find it. Geometry: as-installed location is enough; a photorealistic leaf is not required. Alphanumerical: asset identifier, manufacturer and product code, fire rating as installed, inspection interval, warranty end date. Documents: the door data sheet and the third-party certification the health and safety file will be asked for. Out of scope: a second "LOD 500" remodel of every hinge.

LOD 300 at Stage 3 would have modelled the closer and still omitted the fire rating. LOD 500 at handover would have rebuilt the geometry and still omitted the inspection interval. The two rows above specify enough for each decision, once each.

An air terminal for coordination, not for buying

End of Stage 3, purpose: freeze the Level 03 ceiling zone. Geometry: a clearance box and a neck connection that the ceiling and the duct can clash against. Alphanumerical: SystemName from the project system list, nominal size, and fire rating where the terminal sits in a compartment line. Documents: none. Out of scope: manufacturer geometry, acoustic data, filter type, BMS point lists.

The characteristic LOD failure is the opposite pair: a catalogue family with every vane modelled, and FireRating blank. The clash report then finds twelve thousand pretty collisions, and the fire strategy still cannot see the terminal.

Procurement is a later row, for a later actor. Duty, acoustic performance and the accepted product belong on that row. Do not drag them into the coordination exchange because the family already has the parameters.

Steel that is coordinated, not fabricated

Spatial coordination, purpose: confirm member zones against services and the envelope. Geometry: member size, alignment and a clash envelope at connections — not every bolt group. Alphanumerical: section designation, steel grade if the specification has frozen it, grid and level. Documents: none beyond the structural model and the clash report the EIR already named. Out of scope: plates, welds, shop marks, NC data.

Fabrication issue, purpose: cut and drill. Different actor: the steelwork contractor. Geometry and alphanumerical information now include connections, bolts, welds and marks. Documents: the fabrication package the appointment already required.

Asking a consulting engineer for "LOD 400 steel" at Stage 3 is specifying everything. It also takes over the contractor's job, and then surprises everyone when the shop model disagrees with the design model. Keeping the two exchanges apart is deliberate.

A fire damper the golden thread can find

Coordination: location, size, and the duct it sits in — enough to prove it fits the riser and the ceiling.

Design risk and pre-construction information: the residual that cannot be designed out — access for inspection, a damper over a live kitchen, a location that needs a mobile platform. The pointer has to land on the object and the issued sheet rather than a line of prose in a register; there is a method for that in the design risk register that can find the object.

Handover / golden thread: unique identity, fire rating as installed, cause-and-effect, inspection access, and the certificate. Geometry can stay ordinary. The information cannot.

A single LOD on "fire dampers" will produce a detailed family and an empty asset row. The Building Safety Act does not ask for a prettier damper. It asks whether you can show what was installed, and what it was for.

A row a task team can price

Put this on one line of the EIR or the TIDP. One object type, one milestone. Repeat the line; you do not need a manifesto in the front section.

  1. 01
    Purpose
    What you writeThe decision or actionnot "coordination" as a mood
  2. 02
    Milestone
    What you writeStageexchange identifieror a date the MIDP can hold
  3. 03
    Actor (use / author)
    What you writeWho reads itwho fills it
  4. 04
    Objects
    What you writeType or IFC classlocation or package — a count if it matters
  5. 05
    Geometrical information
    What you writeEnvelopenominal sizeconnectionor fabrication — pick one grain
  6. 06
    Alphanumerical information
    What you writeNamed fieldsunits or allowed listsan example
  7. 07
    Documentation
    What you writeNamed sheet or certificateor "none"
  8. 08
    Out of scope
    What you writeThe work you are forbidding
  9. 09
    Acceptance
    What you writeA pass/fail a controller can run without a meeting
  10. 10
    Reject if
    What you writeBlank required fieldextra geometry that was forbiddenwrong state or suitability

A tenderer can put hours against that. Nobody can put hours against "LOD 300 MEP", which is why the price you get back is a guess dressed as a rate.

If you already have an EIR, this row replaces the LOD column rather than arriving as another appendix nobody opens. How the surrounding exchange is structured — container, state, suitability, the test applied on receipt — is a separate piece of work, and it is covered in writing exchange information requirements that actually get answered.

A test you can run on Monday

You do not need a new appointment to find out whether the project is still working a volume knob.

  1. Find every sentence in the EIR, BEP or information standard that says LOD, LOI, "level of detail", or "level of development". Write them down. If there is no level-of-information-need language anywhere, that is the result.
  2. Pick five object types that will genuinely be coordinated or handed over this quarter — a door, a terminal, a structure, a damper, a plant item. For each, try to fill the row above for the next exchange. Time-box it. Twenty minutes per type is enough to see whether the ask exists.
  3. Open one shared model drop. For one of those types, count the objects that are geometrically richer than the purpose requires, then count the required fields left blank. Both counts are findings. Over-modelling and under-informing are the same failure: the need was never named.
  4. Ask whoever prices variations whether "LOD 300" has ever been a reason to accept or reject a drop. A shrug is a finding.
  5. Find one recorded rejection that cited too much information, or not enough, against an agreed need. If you cannot find one, the framework is decoration.

Five types will do. Nobody is asking you to rewrite the standard — only to replace a number with a purpose in five places.

Three translations that do not exist

The AIA LOD ladder does not map onto RIBA stages. People draw the table anyway, and it survives into the appointment because it looks tidy. It is a translation between a reliability claim and a workstage, and the two were never measuring the same thing.

Native families, IFC parameters and COBie sheets are not interchangeable either, however often they are treated as three views of one dataset. What survives an export, and in what shape, is a separate problem — the interoperability tax.

And level of information need is not a certification. There is no stamp to cite in a letter to make the argument go away. ISO 19650, CDM, the Building Safety Act, NEC, FIDIC, JCT, COBie and the Gulf mandates each have owners, and each assumes somebody on your side can say what enough looks like for one object at one milestone.

The appointing party is the one who can stop asking for LOD 300. At the next tender — or at the next EIR amendment if the appointment is already live — replace the LOD column with the row above for the object types that will actually be exchanged this quarter. The information manager can draft the five rows; only the appointing party can make them the acceptance test. Twenty minutes a type is the cheap version. The expensive version is a priced guess against a number nobody can fail a drop against, paid again at every variation.

Read next: Writing exchange information requirements that actually get answered, Why coordination breaks down at the handoff from design to construction, Clash detection found twelve thousand issues. Nobody fixed any of them..