9 Design Risks of Inaccurate Scan-Based As-Builts

# 9 Design Risks of Inaccurate Scan-Based As-Builts

TL;DR

• The risk in scan-based as-builts is rarely that the scan itself was inaccurate — it is that nobody stated what accuracy meant before design started, so nobody could check for it.
• USIBD Level of Accuracy (LOA) Specification C120/Guide C220 separates Measured Accuracy (how close the model is to the field) from Represented Accuracy (how the modeler simplified it) — most of these nine risks live in the gap between the two.
• Each risk below has a detection method and a numeric threshold, not just a warning: grid disagreement, drift, occluded MEP, wall-face ambiguity, slab levelness, column plumbness, represented-accuracy drift, coordinate mismatch, and stale data.
• A short pre-design verification checklist — run once, before the first line is drawn against a received as-built — catches most of these before they reach coordination.
• On a documented 220,000 sq ft plant retrofit, an as-built found 143 pipe runs routed differently than record drawings showed; that gap is the mechanism behind several of the risks below, not an exception to them.

Most conversations about bad as-builts jump straight to the drawing itself: it was wrong, someone measured badly, the scanner missed something. That framing misses where the failure actually starts. A registered point cloud can meet a stated ±5 mm accuracy and the model built from it can still send a design team into a wall, because nobody wrote down what "accurate" needed to mean for that specific project — which surfaces, which tolerance, which datum, checked against what.

Design teams that receive an as-built rarely ask how it was verified before they start designing against it. The nine risks below are not scanner failures. They are the specific, recurring points where an unverified assumption about the as-built gets built into a design decision, and the mismatch does not surface until coordination, fabrication, or the field. Each one follows the same structure: the risk, the mechanism that produces it, how to detect it before design starts, and the threshold or mitigation that closes it.

What are the 9 design risks of inaccurate scan-based as-builts?

The nine risks span three sources of error: how the building was measured, how the point cloud was modeled, and how the model gets linked into the design file. Each is detectable before design starts if someone checks for it deliberately.

1. Grid disagreement between as-measured and record drawings

The risk: the column grid in the new scan does not match the grid in the record drawings the design team already has open, and both get used interchangeably. The mechanism: buildings move during construction, get modified during additions, and record drawings are drafted intent, not as-built condition — a grid can drift 1–3 inches over a long building without anyone documenting it. How to detect it before design starts: overlay the as-measured grid on the record drawing grid and check offset at every column, not just at the corners. The threshold or mitigation: flag any grid intersection where as-measured and record drawings disagree by more than the project's stated design tolerance, and design against the as-measured grid, not the record set, for anything load-bearing or fit-critical.

2. Cumulative network drift across long floor plates

The risk: local dimensions look right, but the far end of a long corridor or floor plate is off by an amount that only shows up at handoff between design disciplines. The mechanism: a registration built station-to-station without control accumulates error with every join; a 20-station chain without a surveyed control network can drift well past the stated per-station accuracy by the far end, even though each individual station passed its own check. How to detect it before design starts: ask whether the point cloud was constrained to surveyed control or registered cloud-to-cloud only, and request the residual report. The threshold or mitigation: for any floor plate over roughly 150 linear feet, require a control-tied registration with reported residuals; do not accept cloud-to-cloud registration alone as the basis for grid-critical design.

3. Occluded MEP modeled from assumption

The risk: ductwork, piping, and conduit above ceilings or behind chases get modeled from what a similar bay looks like, not from what is actually there, because the scanner could not see through the finish. The mechanism: a laser scanner captures visible surfaces only; anything above a hard ceiling, inside a wall cavity, or behind equipment is invisible to the scan and gets filled in by inference during modeling. How to detect it before design starts: request the coverage map or exclusion list that shows which areas were scanned with ceiling tiles removed versus left in place. The threshold or mitigation: treat any above-ceiling MEP not confirmed by direct scan coverage as LOD 200 assumption, not LOD 300 measured geometry, and schedule a supplemental scan or field verification before routing new work through that zone.

4. Wall thickness and finish-face vs. core ambiguity

The risk: a wall dimension gets used for a clearance calculation without knowing whether it was measured to the finish face, the substrate, or an assumed core thickness. The mechanism: a point cloud captures the visible finish surface; the modeler then has to decide how much to add or subtract to represent the wall's structural core, and that decision is rarely documented on the deliverable itself. How to detect it before design starts: ask the provider whether wall thicknesses in the model represent finish-to-finish, face-to-face, or core dimensions, and request that this be stated per assembly type, not once for the whole model. The threshold or mitigation: for any clearance calculation within roughly half an inch of a code minimum, verify the wall assembly with a field measurement rather than relying on the modeled thickness.

5. Slab levelness and deck height errors propagating into ceiling and clearance design

The risk: a uniform floor-to-deck height gets assumed for an entire floor plate, and a ceiling grid or duct main designed to that assumed height does not fit where the slab actually sags or the deck actually steps. The mechanism: slabs are rarely perfectly level, and deck heights vary across additions and renovations; a single spot check gets extrapolated across a space that was never verified at more than one or two points. How to detect it before design starts: request a levelness or deck-height heat map derived from the point cloud, not a single stated dimension, especially in older buildings or at addition tie-in lines. The threshold or mitigation: where deck height variance across a space exceeds roughly ±10 mm — the same band used for LOD 300 model-to-cloud accuracy — design the ceiling or duct main to the lowest measured point, not the average.

6. Column plumbness ignored, so vertical alignment fails at fit-out

The risk: a column assumed perfectly vertical gets used as the reference line for curtain wall, partition layout, or millwork, and the misalignment only appears when the fit-out element is delivered square into a column that is not. The mechanism: older structures settle and lean; a scan captures the actual lean, but if the model simplifies the column to a single vertical extrusion for drafting convenience, the plumbness data gets discarded before design ever sees it. How to detect it before design starts: request plumbness deviation per column, top to bottom, not just a centerline location at floor level. The threshold or mitigation: for any column with plumbness deviation beyond the project's stated fit-out tolerance, design the abutting element with a scribe or shim allowance rather than assuming a square condition.

7. Represented-accuracy drift — the modeler's simplification, not the scanner's error

The risk: the registered point cloud is well within its stated accuracy, and the resulting model is still off by a meaningful margin, because the gap is in how the modeler simplified curved, irregular, or cluttered geometry into drafted lines. The mechanism: USIBD's Measured Accuracy and Represented Accuracy are two different numbers — the cloud can hold ±5 mm to the surveyed control while a modeler's decision to straighten a wavy wall or average an irregular opening introduces drift that has nothing to do with scanner performance. How to detect it before design starts: ask which USIBD Level of Accuracy band was targeted for representation, not just what accuracy the raw registration achieved. The threshold or mitigation: for scan-to-BIM deliverables, hold model faces to ±10 mm against the registered cloud at LOD 300, and require the provider to report where any geometry exceeds that band rather than silently smoothing it.

8. Coordinate system and units mismatch on link-in

The risk: the linked model lands in the wrong location, at the wrong scale, or rotated relative to the design file, and the error is not visually obvious until dimensions are checked. The mechanism: a point cloud or Revit link can be delivered in a local site coordinate system, a different unit convention, or an unshared basepoint, and if the design team links it in without confirming the shared coordinate system, everything drawn against it inherits the offset. How to detect it before design starts: confirm the coordinate system, units, and shared basepoint or survey control point in writing before linking, and check at least two known reference points after linking. The threshold or mitigation: treat any post-link offset greater than the stated field accuracy as a coordinate error, not a modeling error, and resolve it at the link step — never by nudging geometry inside the design file.

9. Stale data — the building changed between scan and design; no re-scan trigger defined

The risk: design proceeds against an as-built that was accurate on the day it was captured, but the building has since been modified — a wall added, equipment relocated, a tenant fit-out completed — and nobody defined when the data needed refreshing. The mechanism: an as-built is a record of one moment; without a stated shelf-life or a defined trigger for re-verification, teams keep designing against it long after the physical building has diverged. How to detect it before design starts: ask when the scan was captured relative to the design start date, and whether any work has occurred in the space since. The threshold or mitigation: set a re-scan or spot-verification trigger tied to elapsed time and known building activity — for actively occupied or under-renovation buildings, treat an as-built older than roughly 90 days as requiring a targeted verification pass before it drives new design.

What should a design team check on a received as-built before starting design?

A short verification pass, run once before design starts, catches most of the nine risks above without re-scanning the building. Each item has a stated pass criterion so the check is objective, not a judgment call.

• Registration method. Confirm whether the point cloud is tied to surveyed control or registered cloud-to-cloud only. Pass: a stated control network with reported residuals. Fail: no documentation of how stations were joined.
• Stated accuracy with conditions. Confirm the accuracy figure comes with a stated method — control-constrained, verified by independent check measurements — not a bare number. Pass: a figure such as ±5 mm tied to surveyed control and confirmed by independent check. Fail: an unqualified accuracy claim.
• Coverage map. Confirm which areas were captured with finishes removed (above ceiling, behind equipment) versus left in place. Pass: a documented coverage map or exclusion list. Fail: no distinction between measured and assumed areas.
• Wall dimension convention. Confirm whether wall thicknesses represent finish-to-finish, face-to-face, or core, per assembly type. Pass: stated per assembly. Fail: a single unstated convention applied globally.
• Deck height and levelness data. Confirm whether floor-to-deck height is a single stated dimension or a measured range across the space. Pass: a heat map or multi-point dataset. Fail: one number extrapolated across the floor plate.
• Column plumbness. Confirm whether column verticality was measured top-to-bottom or assumed from a single floor-level point. Pass: reported plumbness deviation per column. Fail: no plumbness data provided.
• Level of Accuracy and Level of Development targeted. Confirm the USIBD LOA band and BIMForum LOD used for representation, and that LOD and LOA are not conflated. Pass: both stated explicitly, by edition year for LOD. Fail: only one term used, or the two used interchangeably.
• Coordinate system and basepoint. Confirm the coordinate system, units, and shared basepoint in writing before linking the model. Pass: written confirmation and a post-link check against two known points. Fail: linking without confirming the coordinate system first.
• Capture date and building activity since. Confirm when the scan was captured and whether any work has occurred in the space since. Pass: a stated capture date and a re-verification plan for anything older than roughly 90 days on an active building. Fail: no capture date provided.

What do these design risks cost when they are not caught before design starts?

The cost of these nine risks is not hypothetical — it shows up as RFIs, change orders, and schedule slip once the mismatch surfaces in coordination or the field, and it is cheaper to catch at the verification-checklist stage than after drawings are issued.

On a 220,000 sq ft live process plant scanned over five days with zero downtime, verification against the as-built found 143 pipe runs routed differently than the record PDFs showed — occluded-MEP and stale-data risk, caught before design work proceeded on the wrong routing. On a 38,400 sq ft occupied hospital med-surg wing, an as-built held to ±6 mm registered accuracy with a 4.2 mm mean error across 36 independent QC checks, and the resulting design coordination avoided 23 RFIs and removed roughly $147,000 in change-order risk, while accelerating the schedule by 10 days. On a 200,000 sq ft data center project, an LOD 350 MEP model built to verified accuracy eliminated more than 40 field conflicts before construction, work that traces directly to catching represented-accuracy drift and coordinate-mismatch risk at the modeling stage rather than in the field.

At the industry level, NIST GCR 04-867 puts the annual cost of inadequate interoperability in the U.S. capital facilities industry at $15.8 billion — a figure driven substantially by exactly this category of problem: data generated in one format or convention, at one point in time, that no longer matches the condition or coordinate system another discipline is designing against. Verified reality capture, delivered at $0.05–$0.20 per sq ft, is priced against that exposure, not against the cost of the scan itself.

For the propagation mechanics behind risks like grid disagreement and cumulative drift, see how as-built accuracy affects design coordination. For the dollar cost of design rework caused by inaccurate as-builts generally, see how inaccurate as-builts cause design rework. For the point-cloud-to-model error chain behind risks 3, 4, and 7, see how poor point clouds disrupt BIM coordination. A related, less structured look at existing-conditions risk is available at design risks of inaccurate as-built documentation. Full documentation service scope is covered at as-built documentation services.