ISO 19650 · Level of information need

Enough detail. No more than that.

Q: Where does EN 17412-1 fit?

ISO 19650-1 introduces the concept; EN 17412-1:2020 is the European standard that makes it operable, and it is the one to reach for when writing the requirement rather than describing it. It gives the three kinds of information above and the determinants that set them. Using it does not replace ISO 19650 — it is what you write the EIR clause with.

Every requirement for information is really two requirements: what has to be there, and what does not. Most EIRs write the first one loosely and never write the second at all — so the supply chain guesses, prices its guess, and delivers something defensible that nobody wanted.

Part of the ISO 19650 toolkit.

What it is made of Who writes it Questions

Anatomy

Three kinds of information, and the four things that set them

ISO 19650-1 defines level of information need as the framework that sets the extent and granularity of information. EN 17412-1 is what makes it usable: it splits the requirement into three kinds, and it is determined per purpose, per milestone, per recipient and per object — never once for the whole project.

Geometrical information

Detail, dimensionality, location, appearance, parametric behaviour. This is the part everybody thinks the whole subject is, and it is the part that costs the most to over-specify: a wall modelled to a detail nobody will look at is paid for twice, once in modelling and once in every coordination cycle it slows down.

Alphanumerical information

The data attached to the object: identifiers, classification, performance values, warranty and maintenance attributes. Usually the part the appointing party actually needs at handover, and usually the part the EIR is quietest about — which is how an asset information model arrives geometrically beautiful and commercially useless.

Documentation

The drawings, schedules, reports and certificates that sit beside the model rather than inside it. Naming them as part of the requirement is what stops the argument about whether a deliverable "counts", and what lets a bidder price the document production rather than discovering it after appointment.

The four determinants

Purpose first: what decision is this information for? Then the milestone it lands on, the recipient who will act on it, and the object it describes. Change any one of those and the requirement changes — which is exactly why a single project-wide statement of detail cannot be right for more than one row of the delivery plan.

Responsibility

Written by the client. Priced, then delivered, by everyone else.

Level of information need is set in the EIR, which makes it a clause 5.2 output and the appointing party’s to write. The delivery team’s job is to answer it precisely enough that the answer is checkable — and to say so when what has been asked for cannot be produced at the milestone it is asked for.

Appointing party

What the EIR has to make measurable

The test is not whether the EIR mentions detail. It is whether two different bidders reading it would produce the same thing. The EIR Health Check scores this question directly.

Clause 5.2 · issued with the tender

A table per deliverable family, not a paragraph per project — "as required" is the phrase that costs the most money on this page
The purpose each deliverable serves, stated as the decision it supports
Geometrical, alphanumerical and documentation requirements separated, because they are priced by different people
The milestone each requirement applies at, and what it is allowed to be before then
The recipient, so a requirement written for the facilities team is not answered by the design team’s idea of enough
What is explicitly not required, which is the half almost nobody writes and the half that removes the padding

Score your EIR against this →

Lead appointed party

What the BEP has to commit to

A BEP that answers this with a number is answering a different standard. What is being asked for is a method: how your teams will produce exactly what was specified and stop there. The BEP Readiness Checklist covers the response side.

Pre-appointment, then confirmed

How each EIR row maps onto something a task team actually produces
Where you have had to interpret a vague requirement, written down as an interpretation rather than absorbed silently
The quality check that catches under-delivery and over-delivery before issue, not after
Which requirements you cannot meet at the milestone stated, and what you propose instead
How the requirement travels down to the task teams who never read the EIR
What the federated model is allowed to contain that no requirement asked for

Check your BEP against this →

The EIR asks for models and drawings but never says how much detail, in whose format, or for which decision. The supply chain guesses, prices its guess, and delivers something defensible that nobody wanted.

Questions

What people actually ask

Is this just LOD by another name?

No, and this is the misunderstanding worth spending a minute on. ISO 19650 defines no numbered levels at all. "LOD 300" comes from an American convention and describes geometry alone; level of information need covers geometry, data and documents together, and is set per purpose rather than per stage. A project can use an LOD table as shorthand inside its own requirement, but an EIR that says "LOD 350" and stops has not stated a level of information need — it has named a number from a different framework and left the data and document requirements unwritten.

Where does EN 17412-1 fit?

ISO 19650-1 introduces the concept; EN 17412-1:2020 is the European standard that makes it operable, and it is the one to reach for when writing the requirement rather than describing it. It gives the three kinds of information above and the determinants that set them. Using it does not replace ISO 19650 — it is what you write the EIR clause with.

Can we just ask for everything, to be safe?

It is the most expensive answer available. Over-specification is paid for in modelling hours, in coordination cycles slowed by detail nobody reviews, and in a bid price that carries the cost of the padding. It also hides the requirements that genuinely matter inside a list nobody can prioritise. The discipline the standard is asking for is subtractive: name the decision, then ask for what that decision needs.

We are mid-appointment and the EIR was vague. What now?

Write the interpretation down and get it agreed, rather than absorbing it. A short schedule saying "we have read requirement X as meaning Y, at milestone Z" converts a future argument into a present decision, and it is the cheapest document on the project. It also belongs in the confirmed BEP, which is the place the standard already provides for exactly this.

How does this relate to the CDE?

They are the two halves of a requirement being checkable. Level of information need says what has to be in a container; the common data environment is where the container has to get to, and in what state, before anybody can rely on it. An EIR that gets one right and the other wrong still cannot be answered precisely. The ISO 19650 hub covers the handover between the two documents that carry them.