
How to Specify BIM Deliverables Without Gaps
A BIM model can look complete on screen and still fail the project. A missing ceiling void, an assumed roof junction or an unmodelled structural offset may not become a problem until design coordination, planning or construction. Knowing how to specify BIM deliverables is therefore less about requesting a Revit file and more about defining the information your team must be able to trust.
For existing buildings, this distinction is particularly important. The model is often being used to replace unreliable record drawings, support an extension, coordinate services or understand an irregular listed structure. The brief needs to establish what is known, what will be captured, and where reasonable assumptions are not acceptable.
Start with the decisions the model must support
The strongest BIM specifications begin with use, not software. Ask what the model will allow the design team to do during the next project stage. A model for early massing and area studies has different requirements from one intended to coordinate new MEP routes through a constrained refurbishment.
Set out the primary uses in plain language. These may include measured design development, existing-condition coordination, heritage recording, planning drawings, landlord approval, clash review or construction detailing. This prevents a common mismatch: commissioning a low-definition model, then expecting it to answer detailed questions about soffits, risers, roof geometry or concealed structure.
It also helps to separate the existing building model from proposed design information. A survey-based BIM deliverable should represent observed conditions at the agreed date of survey. It is not a design model, a structural certification exercise or a guarantee that every hidden element has been identified. Clear boundaries protect both programme and decision-making.
How to specify BIM deliverables by scope, not labels
Terms such as LOD 200 or LOD 300 are useful shorthand, but they are not a complete scope. Different practices and clients interpret them differently, particularly when an existing building is involved. A requirement for LOD 300 does not, by itself, explain whether skirtings, radiators, exposed steelwork, window reveals, ceiling features or rooflights should be modelled.
Specify the deliverable in three connected parts: required geometry, required non-graphical information, and acceptable accuracy. This turns an ambiguous model request into a structured instruction.
Define geometry element by element
Describe the building elements that need representation and the level of detail expected. For example, walls may need their measured faces and principal thicknesses; doors and windows may need accurate openings, frames and sill levels; stairs may need individual flights, landings and headroom-critical geometry.
Where complex geometry matters, call it out directly. Curved facades, warped roofs, vaulted ceilings, historic timber frames, non-orthogonal rooms and irregular floor level changes should never be left to an assumed standard. State whether the model must follow the captured condition closely, provide a simplified but dimensionally dependable representation, or show a combination of both.
For renovation work, include elements that affect coordination even if they are not visually prominent. Service risers, bulkheads, structural downstands, plant, drainage runs where visible, and accessible ceiling voids can be far more valuable than decorative detail.
Specify information only where it has a use
A model does not become more useful simply because every object carries extensive parameters. Request the data needed for the planned workflow: room names and numbers, floor levels, element classifications, fire compartment references, asset identifiers or survey confidence notes, where appropriate.
If the model will support design rather than asset operation, avoid burdening the appointment with facilities-management fields that will not be maintained. Excess data increases production time and creates more opportunities for inconsistent entries. A concise, agreed parameter schedule is generally more dependable than an exhaustive one.
State accuracy and tolerances clearly
Accuracy is not the same as model detail. A highly detailed generic family placed from incomplete information is less useful than a simpler element positioned to a known tolerance.
Your specification should state the required dimensional tolerance, the survey control approach and the intended reliance on the information. Tolerances may vary by element and purpose. Existing structural grids and primary floor levels might need tighter control than decorative cornices, for instance. If the project depends on exact geometry around a stair, roof intersection or retained facade, identify that area as a priority rather than applying an unrealistic blanket tolerance to the whole building.
Make the capture method part of the brief
The quality of an existing-condition BIM model is set before modelling starts. If the model is to be based on terrestrial laser scanning, measured survey, photographs or existing drawings, say so. These inputs determine what can be verified and how confidently.
For complex, inaccessible or heritage buildings, agree access requirements and survey limitations early. Locked rooms, occupied flats, high-level roof areas, dense storage, ceiling voids and restricted plant spaces all affect coverage. A dependable scope records how inaccessible areas will be treated: omitted, modelled from available evidence, or returned for a follow-up visit.
Point cloud delivery should also be considered. Some teams need a registered point cloud for verification and ongoing design work; others require only the coordinated Revit model and drawing set. If a point cloud is required, specify the preferred format, coordinate system, clipping requirements and whether it should be issued as a combined file or divided by floor or scan zone.
Set coordinates, levels and model conventions early
A model that is geometrically accurate but incorrectly located can create costly coordination issues. Confirm the coordinate strategy before site capture and before files are exchanged. This may mean an agreed project origin, a survey grid, known control points, or alignment with an existing federated model.
Define the level datum and naming convention as well. Floor names, level names, grid references, worksets and linked-file conventions should support the receiving team’s workflow. For multi-storey buildings, make clear whether each level is to be modelled independently, whether split levels require separate datums, and how basements, roof zones and external areas are to be organised.
When a client template is available, provide it at appointment stage. If it is not, request a clean, logically structured model with naming that can be understood by another consultant without repeated clarification. A usable deliverable is not merely accurate geometry - it is geometry that can be navigated, queried and developed efficiently.
Agree formats, drawings and handover requirements
A Revit model may be the primary output, but it is rarely the only one. Confirm the required native version, exchange formats and drawing outputs before work begins. The receiving practice may need RVT, IFC, DWG, PDF sheets, point cloud files or a combination of these.
Be specific about drawings. State which plans, elevations, sections and roof plans are required, their scales, annotation expectations and whether they are intended as survey records or presentation-ready sheets. If section locations are critical, identify them in advance. Standard sections may not reveal the geometry that matters in an irregular building.
Version compatibility deserves particular care. A model cannot be saved backwards into an earlier Revit version without conversion or loss of native functionality. Confirm the authoring version at the outset rather than discovering the issue at handover.
Include exclusions and assumptions without weakening the brief
A clear exclusions schedule does not make a BIM deliverable less valuable. It makes it safer to use. Existing buildings contain hidden conditions, and no survey method can see through finishes, fixed furniture or closed-up construction.
Record foreseeable exclusions such as concealed structure, services above inaccessible ceilings, internal construction build-ups, underground drainage, loose furniture or areas not available during the survey. Then define how uncertainty should be shown. Depending on the project, this could be through model notes, a survey report, element parameters or marked-up drawings.
The objective is honest information management. Your design team should be able to distinguish measured geometry from informed interpretation, and informed interpretation from an item requiring further investigation.
Build quality checks into acceptance criteria
Do not leave quality to a general expectation of “coordination”. Set measurable checks for the delivered model. These may include alignment to the point cloud, agreed dimensional spot checks, absence of duplicate elements, correct level assignment, naming compliance, clean views and removal of unnecessary imported content.
For a model intended to support coordination, require a review of obvious intersections and modelling anomalies. This is not the same as a full design clash detection exercise, but it confirms that the existing-condition model is coherent before it enters the wider project environment.
Agree a review period and a practical route for queries. A responsive documentation partner should be able to explain decisions, identify survey constraints and correct genuine scope issues promptly. At Space Captures, that clarity is part of producing a model that design teams can use with confidence rather than spend days validating.
A useful brief gives the model a job
The best BIM deliverable specification is specific enough to remove guesswork, but proportionate to the decisions ahead. It identifies the geometry that matters, the accuracy required, the information that will be used and the limitations the team must manage. Give the model a defined job at the start, and it becomes a dependable base for better design decisions rather than another file to interrogate.





Comments