In the past few months, I’ve been involved in several conversations on projects that want to move forward with model based delivery, but are having a hard time understanding the legal implications. What does LOD mean to us? Does everything have to be in the model? What if is wrong? Mostly, people are consistently nervous about having an external definition to their instruments of service.
The reality is that the LOD system is not meant to be a prescription, but instead a framework. Unfortunately, it is also very vague, and has failed to guide people in its implementation. This has led to general confusion and even dilution of the effort as some have even come up with their own interpretations, many of them just plain wrong.
I recently came across James Vandezande’s most recent post on this and found his explanation to be most in line with the realities of those who are implementing this stuff on non-IPD projects. Probably the most useful aspect of the post is that he swiftly debunks the incorrect definition of LOD in the E202 context as being ‘Level of Detail’ (to be fair it does mean that if you’re thinking of the computer graphics term, which only adds to the confusion). What I like is that he provides a clear explanation as to why it is incorrect and even misleading. He states:
DETAIL = INPUT
DEVELOPMENT = RELIABILITY
This is probably the clearest distinction I’ve seen out there on the issue of LOD. What is most compelling about it, is the fact that it brings the conversation back into the realm of actual project delivery. We are not talking about abstract modeling concepts anymore. We are talking about the documents, or artifacts, that are used to actually design and build. This is very important because it places the focus back on the intent behind the model and elevates the status of the model from somewhere above a physical model (usually only a visual aid), to somewhere just below the actual drawings. It grounds a model back within the realm of process.
An update to the E202 with E203
Coincidentally, at the end of last week the AIA also published their updated Digital Practice Documents E203 – 2012, G2012 – 2012 and G202 – 2012 for public review. In it, there are a lot of improvements, but off the bat, one caught my eye. Section 1.4 of the E203 document lists the definitions and there are many more this time around that in the E202. There are some that were there before too, but have now been updated. One of these is LOD.
The new version, the E203 (2012) defines LOD as:
The Level of Development (LOD) describes the minimum dimensional, spatial, quantitaive, qualitative, and other data included in a Model Element to support the Authorized Uses associated with such LOD”.
Versus the old version, the E202 (2008) which defines LOD as:
The Level(s) of Development (LOD) describes the level of completeness to which a Model Element is developed.”
The new version refers to two other terms, Model Element and Authorized Uses, whereas the old version only refers to Model Element. Authorized Uses was actually not part of the E202 document at all. Authorized Uses is defined as:
The term “Authorized Uses” refers to the permitted uses of Digital Data authorized in the Digital Data and / or Building Information Modeling protocols established pursuant to the terms of this Exhibit”
The new version more clearly defines LOD as the minimum information needed to support the authorized uses. This new definition clearly speaks to James’ definition and I’m glad it’s made its way into the new documents. The prior definition was definitely misleading in that it seems to imply a geometric completeness over its intended use. It is a very clear directive to tell someone not only that they can use a model for a particular purpose, but that they may rely on it for that purpose.
We’ll see how people take to it…