Get in touch with us

Revit Guides

Data Management

Dictionary

Level of Information Need: Getting Your BIM Data Just Right

Ever feel like you’re drowning in BIM data you don’t need, or scrambling for details that should’ve been there? Enter the concept of Level of Information Need. It’s a straightforward idea buried behind a not-so-straightforward name (looking at you, BS EN ISO 7817-1:2024). In plain English, a Level of Information Need defines exactly what information should be delivered – no more, no less – for a given BIM use case or project stage. Think of it as the Goldilocks principle for project data: not too little, not too much, but just right. This notion has been formalized in the latest international BIM standards (the ISO 19650 series and the new BS EN ISO 7817-1), but let’s skip the dry jargon and unpack why it matters for you as a client or contractor.

What Is a "Level of Information Need"?

In a nutshell, a Level of Information Need is a framework for specifying the exact amount and detail of information you require at a particular point in a project. It defines the breadth and depth of information to be exchanged, covering geometrical details, alphanumeric data, and documentation. In other words, it spells out the needed 3D geometry (shapes, dimensions, locations), the data and properties (the alphanumeric info) attached to your model elements, and any supporting documents (like drawings, schedules or manuals). By clearly articulating these requirements, everyone knows what to deliver or expect – avoiding the guesswork of “I assumed you’d include that drawing set” or “Why on earth did they model every bolt and screw?”.

Crucially, a Level of Information Need focuses on the information itself. It does not dictate the purpose for that information, who provides or uses it, or which specific object it relates to. Those context aspects – the why, who, and what for – are decided elsewhere in your project framework. The LoIN (we won’t acronym it beyond this once, promise) is purpose-agnostic and actor-agnostic. For example, you might decide you need a door’s fire rating and geometry for a safety analysis; the Level of Information Need would define “provide the door’s fire resistance value and a basic 3D form,” but it wouldn’t itself state that this is for a safety check, assign it to the fire engineer, or even single out the door object by name. It’s simply a structured description of information requirements. (The standard even explicitly warns against using a catchy acronym for it, lest we oversimplify the idea. So yes, we spelled it out for a reason.)

Why Bother? Avoiding Data Overload and Data Drought

In BIM projects, information is power – but too much information can be as bad as too little. The Level of Information Need concept was born to strike a balance. One purpose of defining these levels is to prevent the delivery of far too much data. We’ve all seen models bloated with every conceivable detail, or endless spreadsheets of asset data that no one asked for. It’s wasteful, and frankly, no one has time to sift through irrelevant properties or supersized files. By clearly agreeing on the right level of information needed at a certain time, teams can avoid drowning each other in superfluous details.

On the flip side, having a set Level of Information Need also guards against getting too little information. It sets a minimum benchmark of what’s required, so you’re not left high and dry searching for critical data that should have been provided. The goal is a Goldilocks sweet spot: deliver all the information that is needed, and nothing that isn’t, at each stage of the project. This sharp focus not only cuts out waste, but also boosts trust – everyone knows they’re getting exactly what was agreed, no nasty surprises or gaping holes.

Structured Information, Not Random Deliverables

Another benefit of using Level of Information Need is the structured way it breaks down information requirements. It forces clarity by specifying needs in three categories: Geometry, Alphanumerics, Documentation. This structure acts like a menu checklist for each deliverable. For example, if the client needs a model for a planning submission, the Level of Information Need might state: Geometry: massing model of the building exterior; Alphanumerics: basic area schedules and planning application data; Documentation: rendered elevations and a planning report. By formally partitioning requirements this way, there’s little room for ambiguity about what “deliver BIM Level X” actually means – it’s spelled out in pieces that make sense.

Equally important, the Level of Information Need stays out of prescribing the project specifics. It doesn’t tell you why you need that exterior massing model or who must produce it or which building it applies to – it simply says that if you need an exterior massing, here’s the detail it should have. This separation of concerns keeps things flexible. You can reuse the same information requirement for multiple purposes or across different projects without rewriting it each time. The standard emphasizes that the purpose of the information, the milestone when it’s needed, the actors responsible, and the object involved should all be considered when defining a requirement – but none of those live inside the Level of Information Need definition itself. In practice, this means you can slot a well-defined information requirement into any scenario, and pair it with the context (purpose, timeline, responsibility) separately. The result is a more modular and reusable way to define what data gets delivered in BIM, avoiding one-size-fits-none specifications.

Human-Readable, Machine-Checkable Requirements

One of the slickest aspects of the Level of Information Need framework is that it’s meant to be understood by both people and software. The requirements are intended to be human-readable and machine-interpretable by design. For busy professionals, this human-friendly clarity is a relief – you can skim a well-written Level of Information Need description and quickly grasp what’s expected (no PhD in jargon needed). But behind the scenes, the structured nature of these requirements means a computer can parse them too. And that opens the door to some powerful efficiencies.

Imagine reaching a key project milestone – say the design freeze or handover – and being able to automatically verify that the delivered models and documents meet the agreed information need. This is not sci-fi; it’s exactly what the standard envisions. Because the Level of Information Need is explicit and structured, you can use software to check, for example, that every required property is present and filled in, that the geometry provided matches the level of detail specified, and that all requisite documents are attached. The standard even specifies that the Level of Information Need should be written to allow manual or automated validation processes. In plain terms, you can point a checking tool at the submitted BIM data and let it flag any missing pieces or extras – saving you the tedious task of hunting for them. By making the requirements machine-interpretable, it reduces human error and speeds up those labour-intensive review sessions.

The end result? A smoother check at each milestone, where you can confidently tick off that yes, the architect’s model includes exactly what we need for coordination, or yes, the asset data delivered will serve the FM team’s purposes. No more last-minute surprises or finger-pointing, because the expectations were crystal clear from the start and easily verified. It brings a little peace of mind to the otherwise chaotic crunch points in a project.

From Contracts to Digital Twins – A Glimpse of the Future

If all this sounds a bit theoretical, consider how it plays out in real life project management. By defining information needs so clearly, you’re actually improving how projects are contracted and executed. When you include a Level of Information Need in your appointment or contract, you’re precisely specifying the deliverable – in effect, ensuring you get what you pay for. This common language for information requirements means tender documents and BIM execution plans become much sharper and less open to “creative interpretation”. In fact, the international push for this standard arose from a need to make BIM deliverables more comparable and procure-able on a global scale. It helps cut through regional jargon and conflicting definitions, getting everyone on the same page about what a “BIM deliverable” actually includes.

Looking a bit further ahead, this concept also lays groundwork for the era of digital twins and advanced asset management. A digital twin is only as good as the information it contains – and feeding it with just the right data is vital. The discipline of using Level of Information Need ensures your digital twin isn’t starved of key information nor overfed with clutter that slows it down. In other words, it’s poised to give clients and owners confidence that their digital replicas have exactly the information needed for operations, without the fluff.

In summary, the Level of Information Need is about delivering sharp, purposeful information in BIM – nothing more, nothing less. It might sound like another buzzword, but behind it is a genuinely useful framework to avoid information overkill, fill the gaps, and streamline verification. Embrace it, and you’ll spend less time wading through unnecessary data and more time using the right data to drive project success. And who knows? Nail this approach now, and you’ll be ahead of the curve when it becomes the backbone of BIM procurement and digital twin strategies in the near future. (But that, as they say, is a topic for another day.)

On this Page

    Leave a Reply

    Your email address will not be published. Required fields are marked *

    share this page