01 March 2013

What is this thing called LOD

There still seems to be some confusion about what LOD levels mean, and how they should be used. I must say I have difficulty relating what I do and what I need whenever confronted with filling in an LOD table. If they are this difficult why are we using them? Are they really useful, or just a waste of our time?


From what I can gather LOD was developed by Vicosoftware, a software company that produces construction costing software. They saw the advantages of costing straight from a BIM model, but had a problem. How do you tell how accurate, or how definitive, the model elements you are connecting to in the model are? Traditional methods of costing have a human between what was being measured and the way it was being measured. But automatic take off from the BIM model doesn't.
So they developed the concept they call "Level of Detail". A measure of how definitive an element is in terms of costing it. So LOD 100 meant not very definitive, an area or volume rate is accurate enough, LOD 200 you can assume the number of items in the model is correct, but use an estimate for each, LOD 300 items are identified and actual cost can be used, LOD 400 is a measure what has actually been supplied so can be used to assess payments.
Sounds very sensible, very precise. But then the AIA (American Institute of Architects) decided that this system would be a good one to apply to all uses of a BIM model, from energy analysis to 5D programming. They sensibly renamed it "Level of Development" because "Level of Detail" could get confused with the amount of information, rather than the decisiveness of the information. Although both still have an acronym of LOD so the two continue get confused (more on that later).
Others have taken up the concept, and today it has become one of few common BIM concepts that is kind of understood by all  (more on that later).


LOD, as in "Level of Development", is a measure of how seriously you take the information represented by a BIM element. It is not necessarily a measure of the amount of information, although obviously there must be enough information to satisfy the LOD level it is at. It is also not a measure of the amount or accuracy of graphical information. The appearance of a BIM element is only one piece of information about that object, and usually the least important. A contractor doesn't need to know what a desk looks like to order it, nor to place it in the building. But they do need to know what the manufacturer and model number is. Others may need to know its dimensions to coordinate with things around it, but they too do not necessarily need to know what it exactly looks like.

Therefore LOD levels for a chair might go:
LOD 100 = there is a chair
LOD 200 = there is a chair that has nominal space requirement of 500x500
LOD 300 = there is a chair with arm rests and wheels
LOD 400 = manufacturer and model number.
LOD 500 = manufacturer and model number, supplier, date purchased

or in general terms:
LOD 100 = there is a thing
LOD 200 = there is a thing about this size
LOD 300 = there is a thing with these functions and options
LOD 400 = it is this particular thing.
LOD 500 = this particular thing provided by this person on this date.

The purpose of an LOD table is that it tells others what information they CAN USE. To put it another way, it is a measure of the certainty, or confidence, of that information. So even if a chair in the model contains information that would satisfy LOD 400, only the portion of that information that satisfies LOD 100 can be  relied upon with any certainty. This means a chair family from a manufacturer could be used at LOD 100, but everyone knows (by referring to the LOD table) that this particular chair is not necessarily the one that will be actually used.

LOD is also a measure of progress. At LOD 100 there is obviously more work to do to reach LOD 300. In that sense it is like the traditional percentage complete of drawings. Assuming LOD 500 is 100%, then LOD 100 = 20%, LOD 200 = 40%, LOD 300 = 60% etc.
Except LOD contains more information. It tells you how decisive each element is, not just how complete its representation is on a drawing. It is more useful to know that on a plan the floor is 60% complete (LOD 300), the walls are 50% complete (LOD 250) and the service ducts are 40% complete (LOD 200), rather than the whole drawing is 50% complete (the average of all elements).


Level of Detail is a measure of the amount of information provided. Because it is only a measure of quantity, the underlying assumption is that all provided information is relevant to the project and so can be relied upon with certainty.

Because of the confusion between the two LODs, most BIM guides and plans use other terminology for Level of Detail.

Some examples:

CIC (Penn state)
"Information Level of Detail" - AKA "Info"
A - Accurate size & location, including material and object parameters
B - General size & location, including parameter data
C - Schematic size & location

A - 3D + facility data
B - 2D + facility data
C - 2D, part of an assembly or text description

AEC (UK) BIM Protocol
"Graded Component Creation"
G0 - Schematic
G1 - Concept
G2 - Defined
G3 - Rendered

USACE is probably based on the CIC definitions, but customised to suit the current abilities of BIM software and the consultants they use. I suspect it may change over time. The AEC (UK) grades include 'Rendered' which is purely graphical, which seems to suggest it is a measure of graphical detail only. Their accompanying diagram shows 3D representation, although presumably 2D only would be acceptable.


Typical LOD tables are a 2 dimension matrix, down the left side are Model Elements, across the top the first heading is project stage or Project Milestone - (e.g. Concept; Schematic; Documentation; Construction; As Built), below that is LOD, and any other measurable, like MEA (Model Element Author), Grade (Level of Detail) etc.

Some are others loose and flexible (like AIA E-203):

some are incredible long and complicated, (like Australia's NatSPEC):

The most common other addition is "Model Element Author". This is, as the name suggests, the authoring party of an element. Typically this is the structural engineer for structural elements, mechanical engineer for ductwork etc. It has nothing to do with LOD but is useful information as is sets out who does what. My reading is it sets out who is the creator and responsible party in the BIM model, and not necessarily contract deliverables like drawings and schedules. For example the architect may be the MEA of structural elements because the structural engineer won't model accurately enough for the architect's purposes (see my previous post Should Engineers Model Accurately). But of course the structural engineer is still responsible for structural contract documentation for construction.

Other additions include the Level of Detail (AKA Grade or Information), and really anything else that may be useful. In the past I've included method of delivery which provides a timeline for when information gets put into the BIM model.


Although I am using the term here there is actually no such thing as an LOD table because LOD is used in tables with other things, and for slightly different purposes. Some of the names for tables include:
Vicosoftware              - "Model Progression Specification"
(US)AIA                     - "Model Element Table"
USACE                      - "Minimum Modelling Matrix" or "M3"
Veteran affairs (US)  - "VA Object Element Matrix"
NatSpec                    - "BIM Object Element Matrix"

So really LOD table is a generic term to describe to tables that include LODs. Is any name better than others? Again I think Vicosoftware got it right. LOD tables may describe other things, but LOD fundamentally describes how information in a BIM model will progress. How much information will be usable at each stage or milestone of the project. They use "Model Progression specification", but "Model Progression Table" or "Model Progression Matrix" are just as good.


Level of Development and Level of Detail are closely related. You can't have a certain Level of Development if the Level of Detail doesn't exist.
Only defining the graphical level of detail seems pointless. It doesn't matter how realistic a chair looks, if you don't have the manufacturer and model data no-one can cost or order it. It just looks pretty.

The level of graphical appearance doesn't necessarily progress during a project, it may actually go backwards. The realities of a project usually mean you use the highest Level of Detail at the beginning when there is the lowest Level of Development, as this is when you use rendered images to sell the design to your client and stake-holders.
And to keep the complexity and size of your documentation model low during documentation you want to use a low Level of Detail, even though the Level of Development is quite high.

Of course Level of Detail could explain more than just graphical appearance, but it still doesn't communicate what everyone needs to know - what information can I use with certainty?
And is there any point defining Level of Detail if it is required for Level of Development? Probably not.

To avoid confusion we all should always use the acronym LOD for Level of Development, and use some other term for level of detail. "Grade" is used by a few BIM guides, but it not very descriptive. To keep the metaphor going how about "Depth of Detail" (DOD), where each LOD is a level of certainty passing through the Depth of Detail.

The diagram on the left below shows what is meant when you use Depth of Detail only, the one on the right when you use Level of Development (which by inference includes DOD).


The original restricted use for Level of Development (LOD) developed by Vicosoftware makes sense, but when you apply it to a cover all uses for BIM information it starts to loose clarity. The reality is LOD levels means different things for different uses, so now you need another table - the BIM Uses table - to explain what uses each LOD level can be used for.

LOD makes sense if you link it with model elements (by putting it in a parameter for example) so your costing software can extract LOD data directly from the model. But when it is listed in a separate document where is the advantage? It seems strange (and not BIM like) to keep LOD requirements in a place separate from where those creating the information that satisfies those requirements are working. Shouldn't it be part of the model accessible to all those working and using the model, not in a separate spreadsheet or word processing document?
Indeed is a better use for LOD one where it describes what level of development (or certainty) an element is after the fact? Users nominate the LOD of elements they are working on as they go. As element information becomes more definitive it's LOD increases. Then LOD would be in the model, and extractable as a schedule.

When first explaining LOD to a director (an architect) his initial response was "you mean LOD is the same as a project stage". My first reaction was "well, yes and no". But when I thought about it, yes it is. By separating LODs into different project stages it is just stating the obvious. Of course at concept stage most things will be at LOD 100, at As-Built Stage LOD 400. There will be some things at different LODs, but is it worth filling in a massive table for these few exceptions?

Which leads to me to my other reservation. Are they serious when they say every model element type has to be listed with it's own author and LOD? And use Uniformat or Omniclass or Masterformat? It is not just the massive amount of work to do it, who will ever refer to it? Do they really think the mechanical engineer is going refer to it to find out if he has to model duct work because some-one else might be going to do it?

Going by the current BIM guides and standards an LOD table is both over complicated and yet imprecise. A lot of effort for little practical benefit. If people just followed the BIM guides and standards there is a real danger LOD tables will be a "tick the box" task. Done once and never referred to again.
But an LOD table could impart some useful information. What is that information and what is it the best way to communicate it?


An LOD table is an attempt to record agreed (whether voluntarily or not) responsibilities around a BIM model.  As mentioned above, it only relates to the BIM model, not other deliverables or responsibilities.

For each part of the BIM model and at each stage of the project we need to know:
  • Who is the author and responsible party.
  • What is in and not in the BIM model.
  • How much of the information embedded can be used with certainty.

Obviously the complexity and amount of detail required for each of these will be different for different types and sized projects. The level of sophistication achievable will also depend on the BIM experience of the project team. So to have a one size fits all approach doesn't make sense.


So should we throw LOD tables out and come up with a better alternative? Many have made the same suggestion and even come up with alternatives. I've seen what used to be LOD tables have LOD removed and replaced by percent complete, because everyone understood what percent complete means. Some have replaced LOD with Depth of Detail (like USACE and AEC(UK)), because that is easier for people to visualise.

But I think LOD is a good idea - as a concept. It holds more information then Depth of Detail or percent complete, but is still a simple concept. I don't think it is a good idea as a 'standard', if applied too rigorously LOD tables quickly become irrelevant, and a management burden on projects.
So, a bit like the definition of BIM (see my previous post What does BIM mean to you?), it is best to treat LOD as a broad concept rather than a precise tool. We all need to understand what it generally means, but still appreciate it means different specific things to different people, and on different projects.


The (US)AIA E-203 Document uses LOD and MEA (Model Element author) in its Model Element Table. But it is not highly prescriptive about how that table might be constructed. Although Uniformat is suggested, it is not compulsory  ". . . there is no single best system for classification of the Model content.", and "the user is also free to delete or alter the CSI structure and insert another guideline or a firm specific or project specific model element structure."

The structure of LOD numbering, broad definitions 100 apart, leaves plenty of scope to slot in extra numbers with special meanings for your project. I've used 250 and 350 before to overcome issues around services construction design being done by D & C contractors.

The (US)AIA E-203 is also not strict on LOD use itself, suggesting items not modelled be identified as "NM". This could be expanded to code where the information can be found.
And just to make it really flexible the Model Element Table has a notes column for each stage plus a notes column for each model element.

I believe the (US)AIA approach is the right one. Use the broad structure and concept, but tailor it for your own purposes.


The best way to make LOD useful is to think about how you can make LOD meaningful to your project and the project team, or your office if you are the BIM manager.

If you are required to do an LOD table say you will comply the (US)AIA E203 document, rather than one of the other BIM guides. It gives you pretty much the freedom to create an LOD table any way you like.

Don't be afraid of doing a really simple LOD table, particularly if it is your first one. If the project team is using Revit there is no reason you couldn't list Revit categories as your building elements. If you are comfortable listing trade packages, do that.

Create your own LOD levels. That's why the standard ones are so far apart, it is designed to have other, in between levels. Just make sure you define what those levels mean.

Do multiple LOD tables if it helps. I do a simple short one for sign off by directors, owners and sometimes the contractor, and then a more elaborate one (which aligns with the simple one) for the project team. By taking this approach you could, for example, make the AIA E-203 Model Element Table simple, so that it only sets broad requirements (and therefore flexible, always a good idea when signing a contract), yet still have the opportunity to be more precise when managing the project team via a more detailed table.

And finally think of other uses for LOD. Remember, it is a concept, not a rule. Why not have an LOD parameter for objects in your model to track progress and work as a QA check?
For example:
- LOD 290 = preliminary construction defined;
- LOD 292 = checked for functional requirements;
- LOD 294 = checked for fire requirements;
- LOD 296 = checked for smoke requirements;
- LOD 298 = checked for acoustic requirements;
- LOD 300 = final construction defined;

Let's take ownership of LOD and make it our own.

A discussion on the [US]AIA E203 document LOD defintions can be found in my post
 LOD, are we there yet.

Bored with BIM?
Need a present for that special woman in your life?
The Lost Woman series follows the adventures of Christina as she makes her way through a world of design, fashion and ... men.
Book one of the series, "Awakening the lost woman", is available now on Amazon,  Google Books,  Kobo  and  iBooks.


  1. The images for the LODs in the initial picture are mixed up. The chair representing LOD 300 should be LOD 100.

    1. Justin, read all of the post and all will be revealed.

  2. Amazing article Anthony. Thank you!

  3. Good article Antony. Like many others, I found the Levels of Development to be a confusing concept as it attempts to describe a complex object/transaction with a single number. I don't know if you've seen it but some companies - convinced that they must use LOD as part of the BIM delivery plans - have resorted to splitting LODs into LOD50, LOD150 and even LOD180! As a consultant/researcher, the way I tried to solve this mess is by deconstructing LODs into two separate indices: Level of Information Detail (LID) and Degree of Certainty (DoC). These two indices can then be combined with Time (described as a phase, stage, milestone, or exchange cycle), Object Authorship/Ownership, and Exchange Format (IFC, RVT, XLS, etc). These five 'ingredients' can be used with any object classification system (e.g. OmniClass Table 21) but should not be confused (or combined) with each other. If they are, they make the big mess we are all in.

    1. Bilal, you, along with a few other enlightened people, have tried to find a solution to the certainty problem with BIM.
      My view is that we are trying to solve fundamentally the same problem, and that it would be helpful to everyone if we used the same terminology. As LOD has been effectively endorsed by the (US)AIA it is as good as any to use. It may not be perfect, but at least we will be speaking a common language.

    2. Thanks Antony. I have no problem with terminology, whether it is LOD, BIM, IPD or whatever people agree to use. As my scholarly uncle used to say: a well-used term, even if inaccurate, is much better than an accurate term that nobody uses (loose translation from Arabic). However, as you pointed out in your article, LOD doesn't have the same meaning across industry (or even within one country). So, for all of us to use LOD in a consistent way, it is important to define what we’re trying to communicate when we use it. The way I see it, Level of Development (LOD) tries to paint a complex picture with a single colour (5 shades allowed). It is an excellent way to make all pictures look similar but adding extra colours can make the picture a little bit more expressive.

  4. In the MEP world we have been frustrated by the preconceptions built into LOD as defined by the AIA. The issue is that LOD 300 is defined by the AIA as the appropriate LOD for construction documents yet this is the same LOD that also mandates elements as being accurate in size, position, and orientation. This makes things difficult for MEP, especially electrical, because there are usually alternate products that are acceptable and won't be "locked down" until the products are purchased. These alternative products will probably vary in size and can vary in orientation. Also, especially in electrical, unless the architect is modeling the wall studs, how can MEP accurately position elements on the wall? They can't. If you specify in your contracts that you do LOD 250 as MEP consultants you get glares from the architect or owner because they feel that LOD 250 means they aren't getting a complete model. This can be addressed by education but the real cause of the problem is the artificial limitations in trying to use tables to describe a very complex process.

    1. What is important for us (the General Contractor) is that LOD 300 is achieved from the engineer so that what is designed can actually be built and coordinated during the design phase. You're correct that alternative products may/will be selected but this now falls into the construction side of coordination, independent of the design side of coordination. Our frustration comes from the fact that MEP engineers are laying out systems that are not coordinated in the first place, so not only do we have to coordinate alternative product selections but also residual/inherited design coordination issues. To address this, my company requires the design team to coordinate to LOD 300 with clearances around all model objects to account for LOD 400. What this means is that a simple LOD 300 duct has a Navisworks clearance zone of +/- 2” to account for flanges, insulation, and hangers. This allows the design team to model simple geometry and the construction team to have room for their LOD 400 model objects. Inclusive of routing clearances we need to account for equipment access and code required clearances during design. Without these clearances design coordination is much less successful. In my humble opinion this should not be an added service from the design team but a minimum standard. How can you possible put something into a CD set of drawings that has no way of being built?... I know, happens everyday but it shouldn't

      If the design team can deliver this level of coordination throughout design, then we can review and address wall cavity coordination per your comment above. In my company we do actually create wall stud models (either ourselves or with our subcontractor) to layout electrical, med gas, plumbing, etc. but historically we are too busy addressing the residual/inherited design coordination issues as mentioned before that our level of development on wall cavity coordination is limited.

  5. Great article. Thank you for sharing and help us understand better the LOD.
    Victor Silva

  6. Not sure that LOD does much for the issues of bloated BIM files. Large files slow down the file loading , image regeneration and overall workflow while information placement and detail development tend to be arbitrary and inconsistent. I am focusing on what conceptual improvements we can achieved using an LOD outline to manage the database.

  7. Great read Anthony. Thanks for compiling and sharing!

  8. very interesting article. thanks

  9. Im participating in a big development project in Sweden to integrate a classification system with BIM, and we have decided to call it "level of information" (InformationLevel).
    We use the national classification system (BSAB) as a placeholder for properties connected to each level, and we do that in a PLM database.

    It´s important to understand that "real" BIM, may have objects that is also non-graphical (i call them informationobjets). When working with Informationmodels it is not possible to draw everything with graphics. The classification system is the base for creating such objects. In early stages of a project we can now create a requirement model with objects in a project structure without creating any CAD/BIM model at all. The project is called "Focus I" (= Focus of the letter "I" in BIM).

    Forget about the graphical level of detail, it´s not so important!

  10. hello.
    I apologize if i´m saying something wrong, but I'm new on this subject.

    Level of Development isn't a kind of a blend of Level of Detail and Model Progression Specification (MPS)?

    Because one of the specifications of MPS is the level of detail that different elements of BIM require at the completion of each phase and the responsibles for them right?

    congrats, the article is really good and the chair example is great to show that graphical design of the elements isn´t the most important of all.

    1. Joel, MPS and LOD are two different things. MPS is a type of LOD table and so contains LODs.

  11. Enjoyed reading it, thanks!

  12. Great post I learned a lot


  13. Thanks for this. Very interesting.
    I'd like to make the following suggestion regarding LOD. If LOD is the "certainty"/"development" of information and DOD is the "amount" (or "availability") of information, then to be more clear one would need to identify what is "information" and thus identify the different "pieces" of information that compose the overall "information" being assessed, and provide a LOD and DOD for each one of them.
    Taking your chair example, this could look like a LOD "numbering" structure like "XXXXXX" where each digit "X" corresponds to a piece of information in the table (e.g. Description, or Width, or Height, etc...) and each of these digits would take a value between 0 and 5 (or 0 and 9 if one needs more granularity). The result would be (taking the 0 to 9 scaling):
    - "000000" means 0% information (with 0% certainty).
    - "111111" means 100% information but with low certainty/development.
    - "555000", "000555" or "505050" all mean 50% information with 25% overall certainty, BUT with clear distinction on the pieces of information that are known and to what level.
    - "999999" means 100% information with 100% certainty/development.

    Note, as pointed above, that the average of the digits would give you an overall level integrating both quantitative (amount) and qualitative (certainty/development) information.

    Now, I'm sure that this approach could be defeated with great examples, but I thought that I should put it out there. :)

    1. Frederic, interesting idea, but perhaps redundant.
      A measure of incompleteness (DOD) can be made at any time by anyone by assessing how much information there is.
      But to measure certainty (LOD) you need to know the author's intent, so only the author can provide the measure.
      Which is why the concept of LOD was created.

  14. Amazing article Anthony. Thank you!
    Thanks again for sharing and help us understand better the LOD.

  15. Great post Anthony. Given that LOD's interpretation varies across countries/user groups this is a useful article.

  16. Great post. Personally I think its all backwards. Ultimately the driving factor is the required deliverables. Agree on what they are and provide a specification on each of those deliverables. This will then dictate the level of development and grade for each element without the need to define every single element type. However MEAs are still a necessity and workflow diagrams to deal with the transfer of ownership. Meas also need to be more detailed as different people are in charge of different properties...

  17. Read this:

    Here is a link to the BIMforum website section on LOD:

    Here is a download link for the LOD Specification document
    http://bimforum.org/wp-content/uploads/201 ...
    bimforum.org bimforum.org

  18. I know the article, and it is in many ways very fine, especially for the definition af LOD:

    LOD, as in "Level of Development", is a measure of how seriously you take the information represented by a BIM element. It is not necessarily a measure of the amount of information, although obviously there must be enough information to satisfy the LOD level it is at.

    Important: It is not a measure of the amount or accuracy of graphical information.

    So far so good.

    If you look at my Slide 01, the 3D Building Model could be on a certainly Level of Development, fx. LOD 300, but the 3D Building Model contains at any time both tentative and concrete information, with a rising degree over time, so therefore a design project is containing both preliminary and specific information on different Levels of Information. In my example the objects for the load bearing system is on a higher Level of Information, than the objects for the non bearing system.

    Therefore, a 3D Building Model on a specifik Level of Development contains objects of different Levels of Information.

    In the article they talk about Level of Detail as a measure of the amount of information provided. Because it is only a measure of quantity, the underlying assumption is that all provided information is relevant to the project and so can be relied upon with certainty.

    I'm not sure, that I agree with the statement about the underlying assumption, and for me Level of information is better, because that exact what is about, the word Detail makes unconsciously references to graphic information.

    Allow me to quote from the article:

    Only defining the graphical level of detail ("Information") seems pointless. It doesn't matter how realistic a chair looks, if you don't have the manufacturer and model data no-one can cost or order it. It just looks pretty. The level of graphical appearance doesn't necessarily progress during a project, it may actually go backwards.

    I could not agree more.

    It is essential to remove the excessive focus on graphic as expression for a specified Level of information.

    As written in a report from the Netherlands, Dutch National Levels of Development:

    When showing pictures of BIM and asking people what LOD level of the model, almost none of the responses were the same as the original opinion of the model creator.

    My allegation is that the graphic not necessarily follow developments in Levels of information, but that the designer on each Level of information can choose one of three graphical representations, SOLID, OUTLINE and DETAIL.

    I hope that my Note could have your interest, and maybe could open up for a dialog about the graphic representation in Level of Information.

    Nearly all standards for Level of Information/LOD’s are based on the development in the graphic expression, but it does not mean, that it is the right way to do it.


  19. Good Article! I agree that, LOD should be taken as a language between parties in delivering construction works.

  20. I like the idea of LOD parameters. It is pure bim to add information to elements as the project progresses. Also it forces one to think of things like who is the manufacturer, what are the exact requirements and so on. What concerns me is when LOD hinders one from making a decision because it is not required at this time. Like wall types. The problem is that there is seldom any time and go back through a model from a large project and change all the wall types to what was probably known when generic walls were used. Just the time to go through 35 stories on a fast track program can take days. Every corner every wall cleanup. And one can ask " how have I benifitted by using generic walls?
    When you think about it a generic wall can already have the LOD parameter filled out. Doors where decisions are yet to be made can have this situation flagged up by a LOD 200 and the completed schedule can indictate the completeness of the decision making process.
    Just a few thoughts on the subject.

  21. Millwork – BIM

    We offer Wood Millwork, BIM, and Architectural drafting services.
    Software's : AutoCAD, CabinetVision, Cabinetmaker, Microvellum, SKETCHUP, 3DS MAX

    Wood millwork drafting: the items like Trims, Base, Crown and Moldings, Hand Rails, Wood CAP, Coat closets, Storage Closets, Ceiling Panels, Reception Desks, BAR Counters, Transaction counters, Paneling, Cabinet Case work, Pantry Cabinets, Credenza, Work stations, Vanities, Windows, Doors and Frames, Etc.,

    Visit : www.archmaya.com
    Email : archmayastudio@gmail.com

  22. Thank you sir. Wonderful article