{"id":1187,"date":"2026-04-23T08:22:34","date_gmt":"2026-04-23T08:22:34","guid":{"rendered":"https:\/\/www.srinsoft.engineering\/blogs\/?p=1187"},"modified":"2026-05-06T09:30:18","modified_gmt":"2026-05-06T09:30:18","slug":"understanding-bim-lod-100-500-a-step-by-step-guide-with-real-world-examples","status":"publish","type":"post","link":"https:\/\/www.srinsoft.engineering\/blogs\/understanding-bim-lod-100-500-a-step-by-step-guide-with-real-world-examples\/","title":{"rendered":"Understanding BIM LOD 100\u2013500: A Step-by-Step Guide with Real-World Examples\u00a0"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

BIM LOD is like image resolution.<\/em><\/strong> <\/p>\n\n\n\n

Low levels (100) show rough shapes. They are typically used in early conceptual design stages to convey massing and spatial relationships without detailed geometry.  <\/p>\n\n\n\n

High levels (500) show what actually gets built.  <\/p>\n\n\n\n

The real problem is teams not agreeing on it upfront. <\/p>\n\n\n\n

LOD 300 doesn\u2019t mean the same thing to the architect, the GC, and the MEP contractor. That gap is where coordination breaks and RFIs start stacking. <\/p>\n\n\n\n

This guide breaks down each level in real project terms. What\u2019s actually modeled, BIM modeling accuracy levels, what you can trust, and where things typically fall apart. <\/p>\n\n\n\n

Why LOD Fails in Practice<\/strong>\u00a0<\/h2>\n\n\n\n

Everyone uses BIM LOD 100 to 500. Almost no one actually agrees on what it means. <\/p>\n\n\n\n

That should bother us more than it does. <\/p>\n\n\n\n

The problem is actually contractual and behavioral. LOD gets declared in the BEP, tied to a milestone, and then essentially forgotten. No one audits it. No one pushes back. The model gets stamped LOD 300 and that stamp takes on a life of its own \u2014 quantity surveyors, fabricators, installers \u2014 all building on assumptions that nobody stopped to question. <\/p>\n\n\n\n

And then reality shows up on site. It’s expensive, it’s disruptive, and someone is about to have a very bad week. <\/p>\n\n\n\n

BIM Level of Development<\/strong><\/h2>\n\n\n\n

BIM\u00a0LOD\u00a0100 to 500\u00a0is\u00a0a declaration of what an element can be trusted to communicate and who should be acting on it.\u00a0<\/p>\n\n\n\n

LOD<\/strong> <\/td>What it means in practice<\/strong> <\/td>Who acts on it<\/strong> <\/td><\/tr>
100 <\/td>Massing and intent. Approximate geometry, no system assigned <\/td>Owner, PM <\/td><\/tr>
200 <\/td>System identified. Building\/elements are shown with approximate shape. Not yet documentable <\/td>Design team, early engineering <\/td><\/tr>
300 <\/td>Assembly documented and coordinatable. Geometry is accurate <\/td>All consultants <\/td><\/tr>
350 <\/td>Interfaces defined. Elements can be coordinated at connections and transitions <\/td>GC, trade coordination <\/td><\/tr>
400 <\/td>Fabrication and installation ready. Shop drawing level <\/td>Subs, fabricators <\/td><\/tr>
500 <\/td>Verified as-installed. As-built model. Reflects field conditions, not design intent <\/td>FM, owner handover <\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n

What is LOD in BIM \u2013\u00a0BIM LOD 100 to 500\u00a0explained<\/strong>\u00a0<\/h2>\n\n\n\n

LOD 100:\u00a0Concept Design\u00a0<\/h3>\n\n\n\n

Heavily pixelated. You see shapes, not detail.<\/em><\/strong> <\/p>\n\n\n\n

The model exists to answer one question: does this scheme work at all?  <\/p>\n\n\n\n

At this stage, the model represents intent, not decisions. You\u2019re working with basic geometry and parameters. Area, height, volume, location, orientation. It’s the sketch before the sketch.  <\/p>\n\n\n\n

Nothing here is coordination-ready. Nothing should be quantified with any real confidence. The model is showing you floor plates, core locations, rough vertical zones, not locking anything in. <\/p>\n\n\n\n

Real-world example<\/strong>\u00a0
A hospital massing model tested three site orientations against solar exposure, emergency access routing, and floor plate efficiency. No structure, no systems \u2014 just enough geometry to eliminate two schemes before\u00a0detailed design<\/a>\u00a0spent money on them.\u00a0<\/p>\n\n\n\n

What goes wrong<\/strong>\u00a0
An\u00a0MEP team<\/a>\u00a0runs clash detection on the same model and\u00a0flags\u00a0shaft conflicts. The shaft is a zone, not a design decision. Every change made in response gets undone at LOD 300. Real coordination effort spent resolving a problem that\u00a0didn’t\u00a0exist.\u00a0<\/p>\n\n\n\n

Bottomline<\/strong> 
Use it to align direction. Not to validate design. <\/p>\n\n\n\n

LOD 200:\u00a0Schematic Design\u00a0<\/h3>\n\n\n\n

Clearer, but deceptive. Forms take shape, but not enough to act on.<\/em><\/strong> <\/p>\n\n\n\n

This is where things start to get dangerous. <\/p>\n\n\n\n

Elements now have approximate size, shape, location, and orientation. You can attach non-geometric data. The model is starting to look like something.  <\/p>\n\n\n\n

Real-world example <\/strong> <\/p>\n\n\n\n

An office building MEP model has duct routes laid out with approximate sizing \u2014 enough to validate ceiling zones and floor-to-floor heights across three structural scheme options. A decision gets made. That’s LOD 200 working correctly. <\/p>\n\n\n\n

What goes wrong <\/strong> 
The procurement team sometimes extracts quantities directly from the LOD 200 model, but at this stage system routes are under coordination and element sizes are approximate. BOQs were revised twice before detailed design closed. The model was doing its job \u2014 procurement was using it for something it wasn’t built for.  <\/p>\n\n\n\n

Bottomline<\/strong> <\/p>\n\n\n\n

It’s directional. It’s saying roughly this, roughly here, roughly this big.<\/em> It is not making promises.  <\/p>\n\n\n\n

LOD 300:\u00a0Detailed Design\u00a0<\/h3>\n\n\n\n

Clear image. You can recognize and measure what\u2019s there. Still not everything is visible.<\/em><\/strong> <\/p>\n\n\n\n

Elements are defined. Systems are assigned. Size, shape, location, orientation. Teams across disciplines are pulling from the same model, coordinating against the same geometry. <\/p>\n\n\n\n

It \u201cfeels\u201d like things are under control. <\/p>\n\n\n\n

Real-world example <\/strong> <\/p>\n\n\n\n

Commercial fit-out, three disciplines at LOD 300. Beams\u00a0accurate,\u00a0duct routes planned against real clearances,\u00a0clash detection<\/a>\u00a0clean. The model is doing its job.\u00a0<\/p>\n\n\n\n

What goes wrong <\/strong> <\/p>\n\n\n\n

MEP had modeled primary runs; offsets were assumed. Structural tolerances inconsistently applied. Clash detection still ran clean. On site, ductwork hit a beam. Nobody misrepresented their submission. LOD 300 meant something different to each of them and nobody verified it. <\/p>\n\n\n\n

Bottom\u00a0line<\/strong>\u00a0
LOD 300 only works if all trades are actually at 300. Before moving on: can this model drive procurement without manual correction? If quantity data needs manual checking before anyone acts on it, the model\u00a0isn’t at\u00a0300 \u2014 regardless of what the stamp says.\u00a0
<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

LOD 350:\u00a0Construction\u00a0BIM Standards\u00a0Documentation<\/h3>\n\n\n\n

Sharper image. Edges, overlaps, and interactions become visible. Hidden issues start showing up.<\/em><\/strong> <\/p>\n\n\n\n

LOD 350<\/strong> \u2014 sheets submitted alongside the model. <\/p>\n\n\n\n

At LOD 300, things looked fine. Clashes were resolved, coordination signed off, everyone moved on. But LOD 300 was still leaving things out \u2014 connections, supports, hangers, access zones. The gaps were always there.  <\/p>\n\n\n\n

Interfaces get real here. Elements don’t just exist anymore \u2014 they connect, interact, and sometimes fight for the same space.  <\/p>\n\n\n\n

Real-world example<\/strong> <\/p>\n\n\n\n

Pipe racks clear clash detection at LOD 300. At 350, supports, hangers, and maintenance clearance zones get added. Conflicts with cable trays appear immediately. Caught here, it’s a coordination fix. Caught on site, it’s a variation order, a delay, and a very uncomfortable conversation. <\/p>\n\n\n\n

What goes wrong<\/strong> <\/p>\n\n\n\n

LOD 300 sign-off gets treated as the coordination finish line. Procurement moves, fabrication gets scoped, and nobody wants to reopen a package that was supposedly closed. <\/p>\n\n\n\n

Signal to watch for: <\/strong>If supports, hangers, and access zones aren’t in the model at 300 sign-off, the coordination isn’t finished \u2014 it’s deferred. <\/p>\n\n\n\n

Bottom line<\/strong> 
LOD 350 exposes the gaps that 300 hides. This is where coordination proves itself. Before sign-off: would a subcontractor trust this for installation? If the answer is anything other than yes, the coordination package isn’t closed. <\/p>\n\n\n\n

LOD 400:\u00a0Fabrication & Assembly\u00a0<\/h3>\n\n\n\n

High resolution. Fine details are defined and usable. Ready for execution.<\/em><\/strong> <\/p>\n\n\n\n

LOD 400<\/strong> \u2014 the model plus shop drawings <\/p>\n\n\n\n

This is execution territory.  <\/p>\n\n\n\n

Every element is a specific assembly. Details are resolved. The model is making commitments. And that shift in purpose changes everything about who should be driving it. <\/p>\n\n\n\n

Which is why ownership matters more here than at any other stage. <\/p>\n\n\n\n

When the wrong people are authoring LOD 400 content, the model doesn’t just become less useful \u2014 it becomes actively harmful. Design teams pushing into fabrication detail without contractor input are making decisions they don’t have the context to make. Constructability, shop constraints, sequencing \u2014 these aren’t design considerations. They belong to the people doing the building. <\/p>\n\n\n\n

Real-world example<\/strong> <\/p>\n\n\n\n

What goes wrong<\/strong> <\/p>\n\n\n\n

The model and shop drawings diverge quietly. No one flags it. Downstream trades keep coordinating against geometry that no longer reflects what’s being fabricated. <\/p>\n\n\n\n

Signal to watch for:<\/strong> If the fabricator is making revisions that aren’t being pushed back into the model, the model has already stopped being the source of truth. <\/p>\n\n\n\n

Bottom line<\/strong> <\/p>\n\n\n\n

LOD 400 must align with who is actually building it. Otherwise the model becomes irrelevant. The question to keep asking: what assumptions are embedded in this model that aren’t documented? Undocumented fabricator decisions sitting inside geometry that’s still being used for coordination are the fastest route to field conflicts nobody can explain. <\/p>\n\n\n\n

LOD 500:\u00a0As-Built<\/h3>\n\n\n\n

True-to-life image. What you see matches reality.<\/em><\/strong> <\/p>\n\n\n\n

LOD 500<\/strong> \u2014 the model plus as-built drawings <\/p>\n\n\n\n

This is the finish line. What’s in the model should match what’s in the building. Exactly. <\/p>\n\n\n\n

Actual size, shape, location, quantity \u2014 plus the data that keeps a building running. LOD 500 is for the people who will operate this building for the next thirty years. It’s a promise that the model reflects reality. <\/p>\n\n\n\n

And that promise gets broken more often than anyone admits. <\/p>\n\n\n\n

The assumption that a model becomes<\/em> LOD 500 at handover is one of the most expensive misconceptions in the industry. LOD 500 requires field verification. It requires update workflows. It requires someone, on site, confirming that what was installed matches what was modeled. And that process is unglamorous, easy to deprioritize, and almost always underfunded. <\/p>\n\n\n\n

Real-world example:<\/strong>\u00a0Hospital mechanical room handed over with a verified\u00a0as-built model<\/a>. Every piece of installed equipment \u2014 actual make, model, location, clearances \u2014 captured through a structured site verification process during construction. Two years into operations, the FM team needs to replace a chiller. They pull the model, confirm access routes,\u00a0identify\u00a0clashing services, and plan the lift sequence before anyone sets foot in the plant room. No surprises. No lost time.\u00a0<\/p>\n\n\n\n

Remember:<\/strong> LOD 500 is only as good as your site capture and update process. Get that right, and the model stops being a project deliverable and starts being a genuine operational asset \u2014 one that earns its keep long after the project team has moved on. <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Difference between LOD 100 200 300 400 500\u202f-\u00a0Mapping LOD to Actual Decisions\u00a0<\/h2>\n\n\n\n

The wrong question is\u00a0what LOD are we at?<\/em>\u00a0The right questions are: can we coordinate against this? Can we\u00a0quantify from\u00a0it? Can we\u00a0fabricate off\u00a0it? Can we\u00a0install from\u00a0it?<\/p>\n\n\n\n

LOD<\/strong> <\/td>Coordinate<\/strong> <\/td>Quantify<\/strong> <\/td>Fabricate<\/strong> <\/td>Install<\/strong> <\/td><\/tr>
100 <\/td>\u2717 <\/td>Gross only <\/td>\u2717 <\/td>\u2717 <\/td><\/tr>
200 <\/td>\u2717 <\/td>Approximate <\/td>\u2717 <\/td>\u2717 <\/td><\/tr>
300 <\/td>\u2713 <\/td>\u2713 <\/td>\u2717 <\/td>\u2717 <\/td><\/tr>
350 <\/td>\u2713 <\/td>\u2713 <\/td>\u2717 <\/td>\u2713 <\/td><\/tr>
400 <\/td>\u2713 <\/td>\u2713 <\/td>\u2713 <\/td>\u2713 <\/td><\/tr>
500 <\/td>\u2713 <\/td>\u2713 <\/td>\u2713 <\/td>Verified <\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Run this against your next model review. If the team\u00a0can’t\u00a0answer those four questions, the LOD number\u00a0has no value.\u00a0<\/p>\n\n\n\n

Practical Framework: How to Actually Manage LOD on a Project<\/strong>\u00a0<\/h2>\n\n\n\n

Specify what “mechanical at LOD 300 by DD” means \u2014 mains versus branches, equipment to footprint versus connection point, primary framing versus embedments. If it isn’t written down at that level, everyone will interpret it differently and nobody will be wrong. <\/p>\n\n\n\n

Align on definitions before the first federated model review. LOD 300 means something different to the architect, the structural engineer, and the GC. Get one agreed definition per element type, on this project, in writing, at kickoff.  <\/p>\n\n\n\n

And watch for teams modeling beyond their declared LOD. It looks like initiative. It’s actually undeclared assumption \u2014 and assumption embedded in geometry is the hardest risk to catch before it costs someone. <\/p>\n\n\n\n

Work With a Team That Knows the Difference<\/strong><\/h2>\n\n\n\n

The teams that get this right are agreeing on definitions before the first model review, auditing against those definitions at every milestone, and pushing back when a stamp doesn’t match what’s actually in the model. <\/p>\n\n\n\n

That discipline is harder than it sounds \u2014 and it compounds. A project that manages LOD seriously from 100 through 500 spends less time in RFIs, less time in variation disputes, and less time explaining on site why the model said one thing and reality said another. <\/p>\n\n\n\n

Srinsoft delivers LOD 300\u2013500 across architectural, structural, and MEPF \u2014 coordination, shop drawings, and as-builts. If\u00a0you’re\u00a0working on a project where that\u00a0rigour\u00a0matters,\u00a0talk to the team<\/a><\/p>\n\n\n\n

FAQs<\/strong>\u00a0<\/h2>\n\n\n\n

1. What does LOD actually tell me\u00a0on\u00a0a project?<\/strong>\u00a0<\/h3>
\n

It tells you what decisions you can safely make from the model. Not how detailed it looks.<\/p>\n<\/div><\/div>\n\n\n\n

2. Can I use the model for procurement at LOD 300?<\/strong>\u00a0<\/h3>
\n

Only if quantities\u00a0don\u2019t\u00a0need manual correction. If they do,\u00a0you\u2019re\u00a0still carrying\u00a0risk.\u00a0<\/p>\n<\/div><\/div>\n\n\n\n

3. Why do teams still get coordination issues even after clash detection?<\/strong><\/h3>
\n

Because clash detection checks geometry, not constructability. Missing\u00a0supports, access zones, and tolerances\u00a0cause\u00a0the real\u00a0problems.\u00a0<\/p>\n<\/div><\/div>\n\n\n\n

4. When is coordination truly \u201ccomplete\u201d?<\/strong><\/strong><\/h3>
\n

Not at LOD 300 sign-off. Only when interfaces, connections, and installation constraints are modeled and\u00a0validated.<\/p>\n<\/div><\/div>\n\n\n\n

5. Why does LOD fail even when\u00a0it\u2019s\u00a0clearly defined in the BEP?<\/strong><\/strong><\/strong><\/h3>
\n

Because no one audits it. The label stays. The model drifts. Decisions get made on unchecked assumptions.<\/p>\n<\/div><\/div>\n\n\n\n

<\/p>\n","protected":false},"excerpt":{"rendered":"

BIM LOD is like image resolution.  Low levels (100) show rough shapes. They are typically used in early conceptual design stages to convey massing […]<\/p>\n","protected":false},"author":13,"featured_media":1197,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1187","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.srinsoft.engineering\/blogs\/wp-json\/wp\/v2\/posts\/1187","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.srinsoft.engineering\/blogs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.srinsoft.engineering\/blogs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.srinsoft.engineering\/blogs\/wp-json\/wp\/v2\/users\/13"}],"replies":[{"embeddable":true,"href":"https:\/\/www.srinsoft.engineering\/blogs\/wp-json\/wp\/v2\/comments?post=1187"}],"version-history":[{"count":4,"href":"https:\/\/www.srinsoft.engineering\/blogs\/wp-json\/wp\/v2\/posts\/1187\/revisions"}],"predecessor-version":[{"id":1198,"href":"https:\/\/www.srinsoft.engineering\/blogs\/wp-json\/wp\/v2\/posts\/1187\/revisions\/1198"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.srinsoft.engineering\/blogs\/wp-json\/wp\/v2\/media\/1197"}],"wp:attachment":[{"href":"https:\/\/www.srinsoft.engineering\/blogs\/wp-json\/wp\/v2\/media?parent=1187"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.srinsoft.engineering\/blogs\/wp-json\/wp\/v2\/categories?post=1187"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.srinsoft.engineering\/blogs\/wp-json\/wp\/v2\/tags?post=1187"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}

Structural steel connections<\/a> modeled in detail by the design team. The fabricator picks them up and immediately starts revising \u2014 shop constraints, equipment limitations, standard connection preferences. The model and the shop drawings quietly diverge. Site follows the shop drawings. The model becomes decoration. <\/p>\n\n\n\n