Defining When a BIM Model Is Complete

Complete for which decision

A building information modelling (BIM) model is complete when it meets the agreed requirements for a defined purpose and review stage. Visual detail alone cannot establish that status. A model for coordinating services, a manufacturing deliverable and an asset information submission may represent the same equipment but need different evidence.

Before reporting completion, state what the receiving team needs to do next: review a service corridor, produce installation drawings or prepare maintenance records. Write the acceptance criteria around that task. A project label such as level of development (LOD) should be explained and accompanied by specific geometry, data and review requirements.

Define a manageable acceptance unit

Divide the submission into units that can be checked meaningfully: a zone, a system or an agreed package. For each unit, record its scope, reference revisions, required attributes and acceptance owner. A whole building marked nearly complete tells a receiving team little about which areas are ready for use.

Separate production progress from accepted delivery. Objects may be created but not checked, or checks may pass while a decision involving another discipline remains outstanding. If a required condition is unmet, do not report full acceptance. The authorised recipient may allow a limited use with documented exceptions only where the agreed procedure permits it. Record restrictions, responsible parties and follow-up dates.

Check information and engineering separately

buildingSMART's Information Delivery Specification (IDS) expresses requirements for information in Industry Foundation Classes (IFC), a building information exchange standard. IDS can check properties and classifications but does not cover geometry [1]. A passing report therefore does not prove constructibility, engineering correctness or the truth of a value entered without supporting evidence.

Our suggested review has separate gates for geometry, required data and interfaces. Check required locations and dimensions against the approved design basis; verify the agreed fields and units; then examine interfaces such as openings, access zones and other disciplines' dependencies. Record the responsible reviewer for each gate. Detailed design decisions still need the appropriate engineering authority.

Handle incomplete inputs without hiding them

An illustrative example is an equipment location modelled before a supplier's final service clearances are available. The location may be useful for preliminary coordination, but it should not imply that the final access arrangement has been accepted. Record the assumed envelope, its source, the pending supplier information and the decision that will trigger a recheck.

This makes the deliverable usable without overstating certainty. Some preliminary packages legitimately contain assumptions. The problem is not their existence, but the loss of their meaning when the model is passed to the next team.

A practical acceptance record

• Purpose and package boundary are stated.
• Design and reference revisions are identifiable.
• Required geometry and data checks have recorded results.
• Cross discipline interfaces have an owner and review outcome.
• Open matters are listed with their effect on permitted use.
• An authorized recipient accepts the identified revision.

After acceptance, control changes to the package. A revised object, supplier selection or design reference may invalidate an earlier check. Identify the affected checks and repeat them before relying on the earlier acceptance for the changed information.

For modelling and coordination support, SmartBuild Tech can help define these package boundaries and review records. The acceptance standard should remain part of the project's agreed delivery requirements, not an informal expectation introduced at the final submission.