Building Information Modeling replaces stacks of separate drawings with a single digital model assembled from objects that carry data: a wall in the model knows it is a wall, what it is made of, what it costs and what it touches. Because the model is a database, one source produces the plans, the quantities, the schedule simulation and the clash report. And because every discipline builds from the same description, the expensive discovery that two designs collide happens on a screen, months before it would have happened in the field.
The problem
Buildings are designed by separate disciplines producing separate documents, and for most of the industry’s history the place where those documents were finally reconciled was the jobsite, at the cost of rework, idle crews and claims. Modelling inverts that: the disciplines’ models are combined into one federated model, and the conflicts surface digitally, while they still cost hours instead of weeks. The technology is mature, dominant at the top of the market, and required on major GSA and Army Corps of Engineers work.
What is not settled is everything around the model. Whether it is a contract document or the drawings govern; who owns it and who may rely on it; how developed each element must be at each milestone; how its objects are classified so a quantity means the same thing to the estimator, the specifier and the auditor; and what part of it the owner actually receives at handover. The authoring software has stabilised; the rulebook around it is still being rewritten, and the gap between the two is where projects get hurt.
What governs this area
- Autodesk RevitParametric authoring: models assembled from objects that carry data.
- NavisworksModel federation, interference detection and 4D sequencing.
- MasterFormatSpecifications organised by work results; the master list of North American practice.
- UniFormatBuilding elements by function, for schematic-phase cost estimates.
- OmniClassFifteen faceted tables classifying the full built environment.
- IFCThe vendor-neutral exchange format between modelling platforms.
- AIA E201/E202/G203-2022The current BIM exhibits and execution plan of the AIA family.
The decisions it comes down to
- Is the model a contract document, or do the drawings govern when they conflict?
- Who models what, to what level of development, at which milestone?
- Who owns the model, and who may rely on it, for what purpose?
- Which classification system files each object, so quantities and costs mean the same thing to everyone who touches them?
- Who runs the federated model, on what coordination cycle, and who must answer for the clashes it finds?
- What part of the model survives handover, in what format, and for whom?
The governance question
Whose Model Is It, and What May You Rely On?
1. From drawing to database
A drawing is a picture that a person interprets. A model is a database that software can query. That is the entire revolution, and everything else on this page follows from it. In a building information model, a wall is not a pair of parallel lines; it is an object that knows its type, its material, its fire rating, its cost code and what it touches, and the drawings, schedules and quantities are extracted from it as views. The discipline’s reference text, the BIM Handbook (Sacks, Eastman, Lee & Teicholz, 3rd edition, Wiley, 2018), runs to more than six hundred pages because the subject is not a piece of software: it is a technology and a set of processes that change who produces information, when it exists, and what can be done with it.
The practical consequence is discipline. Because every output is a view of one source, a change made in the model propagates to every plan, section and schedule that depends on it; the version-control chaos of issued-and-superseded drawings becomes a database problem with a database answer. The cost of that discipline is also real: modelling asks for decisions earlier, from people trained to make them, on software that must be bought and learned. Which is why the economics of modelling are argued project by project, and why the chapters of this practice keep returning to one question: who pays for the information, and who collects its value.
2. The coordination instrument
The highest-value use of the model during design is the one shown at the top of this page: coordination. Each discipline models its own scope; the models are combined into a federated model; and interference detection finds, in minutes, the places where the structure passes through a duct or a beam blocks a pipe run. This practice has run that workflow directly, on federated architectural and structural models of a university library and tower, and the lesson it teaches is economic before it is technical. A clash found on screen is an email and a model revision. The same clash found in the field is rework, idle crews and schedule, plus the argument about who pays. The federated model moves the discovery to where it is cheap, which is the same preconstruction logic this practice’s Risk Allocation chapter builds into contract structure.
Coordination is also where the governance questions start, because the federated model is a shared instrument produced by parties with separate contracts. Someone must run it, on a cycle; someone must classify which clashes matter; and someone must be answerable for what the coordination missed. None of that is decided by the software. All of it is decided, or left dangerously undecided, in the documents this chapter’s checklist points at.
3. Three letters, then four, then five
The industry counts the model’s uses in dimensions. 3D is geometry coordinated in space. 4D binds the model’s objects to the construction schedule, so the sequence can be simulated and watched before it is lived: a month of logistics argued over a screen instead of a month of surprises argued in the trailer. 5D binds objects to quantities and cost, so the takeoff is extracted rather than measured by hand, and an estimate can move at the speed of a design option. Each added dimension is the same idea again: attach one more kind of decision to the single description of the work, and the decision gets faster, earlier and more checkable.
The research frontier keeps extending the logic. Published work has proposed coupling 5D models to blockchain-executed payment terms, so that verified progress against the model triggers the release of funds (Yoon & Pishdad-Bozorgi, 2022, in the proceedings of the 39th International Symposium on Automation and Robotics in Construction). The mechanical half of that idea is plausible engineering; the institutional half, deciding who verifies that the work behind a pay application is real, is exactly the limit this practice’s Construction 4.0 chapter draws for automated agreement generally. The model can carry the payment logic. It cannot certify the work.
4. Filing the building: classification
A model object is only useful to anyone else if it is filed where they expect to find it. That unglamorous fact is why three classification systems matter to this chapter, and why the peer-reviewed comparison of them puts it plainly: “it is critical to use classification systems when dealing with specifications, structuring of documents and cost estimation” (Afsari & Eastman, 2016, Associated Schools of Construction proceedings).
MasterFormat, published jointly by the Construction Specifications Institute and Construction Specifications Canada, is the master list that organises specifications and project manuals by work results: what gets built and how. It is the filing system of North American commercial construction, and its 2004 edition expanded it from sixteen divisions to fifty to make room for what buildings had become. UniFormat classifies the same building the other way, by functional elements (substructure, shell, interiors, services) regardless of material or method, which is what an estimator needs at schematic design, when there is a wall to price but no specification to file it under; a related ASTM standard, ASTM E1557, carries the same elemental logic. OmniClass is the umbrella built on the framework of ISO 12006-2: fifteen faceted tables classifying the full built environment, with UniFormat as the basis of its elements table and MasterFormat as the basis of its work-results table, and it serves as a reference standard within the United States National BIM Standard.
The governance point is the same one this practice makes about every information structure: a 5D estimate, a specification and a pay application can only be checked against each other if their objects are filed the same way. Classification is what makes a quantity auditable. Choosing the system, and holding every model author to it, is a decision the project’s information plan has to make once, early, in writing.
5. The open format
Classification decides where an object is filed; the exchange format decides whether the object survives the trip between platforms. The industry’s answer is IFC, the Industry Foundation Classes: a vendor-neutral description of the built environment that lets a model authored in one platform be read, checked and archived in another, published today as an international standard (ISO 16739-1:2024) and maintained by buildingSMART International, the industry consortium formerly known as the International Alliance for Interoperability. The standard’s own history is the best evidence of how hard interoperability is. The scholarly review of its development (Laakso & Kiviniemi, 2012, open access) traces an effort running since 1994, through repeated changes of architecture, organisation and strategy, and observes that “were it not for the growing demand for the standard provided by public actors, momentum and enthusiasm for the effort might have petered out.” Public actors carried the standard through its lean years, and the reason is not hard to see: they hold assets for decades, and a decades-long record cannot be hostage to any vendor’s file format.
The governance reading follows directly. An owner who accepts the handover only in a proprietary format has tied the asset’s memory to a software licence; the model that must outlive its software has to be demanded in an open format, in the information requirements, at the start. One sentence in the right document, written early, is where that protection begins.
6. The model meets the contract
The clearest evidence that the model’s legal status is still being worked out is that the standard contract documents keep changing underneath it. The American Institute of Architects’ current digital practice family dates from 2022: E201-2022 and E202-2022 are BIM exhibits whose entire difference is whether model versions may be enumerated as contract documents, G203-2022 is the BIM Execution Plan, and G204/G205 allocate, element by element, who models what to what level of development. Their 2013 predecessors were permanently retired on July 31, 2024. Read that timeline against the software’s: the authoring platforms stabilised years ago, while the contract layer was redesigned as recently as 2022 and the old forms only left service in 2024. The technology is not what is moving. The rulebook is.
The execution plan is where the abstractions become assignments: which parties model, in what software, coordinated on what cycle, exchanged in what formats, to what level of development at each milestone, with what uses authorised and what reliance permitted. Every item on that list is a sentence someone must write before the modelling starts. The projects that skip the writing do not skip the questions; they answer them later, in a dispute, at dispute prices. The information-management architecture that holds all of this together across a project is the subject of the Information Governance chapter.
7. The public owner decided first
None of this is a vendor fashion, and the proof is procurement policy two decades old. The U.S. General Services Administration, the federal government’s civilian landlord, established its National 3D-4D-BIM Program in 2003, and its BIM Guide stated the requirement plainly: “for all projects receiving design funding in Fiscal Year 2007 and beyond, a spatial program BIM will be the minimum requirement” for major projects seeking final concept approval. The Army Corps of Engineers’ binding digital-delivery requirements, treated in the federal delivery case, carry the same logic into military construction. When an owner of that scale has required the model for this long, the question facing everyone who builds for it is not whether to model. It is whether the governance around the model, ownership, reliance, classification, handover, is written well enough to survive an audit. That is a question of craft, and it is this practice’s subject.
8. Built to be inherited
The model’s last test is whether it survives its own project. The peer-reviewed treatment of facility-management-enabled BIM (Pishdad-Bozorgi, Gao, Eastman & Self, 2018, in Automation in Construction) reaches the conclusion this practice builds on: a model that operations can actually use is planned from the start, with the operator’s data needs specified while there is still a design team under contract to meet them. Retrofitting operational usefulness onto a construction model after handover is the expensive way. What the operator should receive, in what structure, and what becomes of it across decades of operation is where this chapter hands off to Digital Twins & Asset Operations: the model is the seed of the twin, but only if it was grown for it.
Basis
Federated architectural and structural models of a university library and tower, assembled and coordinated in Autodesk Revit and Autodesk Navisworks Manage: interference detection across disciplines, sections and elevations extracted from the model rather than drawn, and construction-sequence simulation. Team project work, and the origin of the coordination positions this chapter takes.