TL;DR
Accuracy at a single point tells you almost nothing. What breaks coordination is how error accumulates across a network — a per-station residual on a long corridor can turn into inches of drift at the far end, even when every individual measurement looked fine. Local accuracy and global network accuracy are different measurements, and a provider can be right at every station and wrong across the building. USIBD's measured-vs-represented-accuracy distinction explains how a ±5 mm cloud can still produce a model that's 15 mm off. Control-tied registration and independent verification are what prevent this from reaching a shop drawing or a field crew.
# How As-Built Accuracy Affects Design Coordination
Author: ZEALOT Reality Capture Editorial Team
Published: 2026-08-19
Last updated: 2026-08-19
TL;DR
- Accuracy at a single point tells you almost nothing. What breaks coordination is how error accumulates across a network — a station-by-station residual on a 400 ft corridor can turn into inches of drift at the far end, even when every individual measurement looked fine.
- Local accuracy (this wall, this dimension) and global network accuracy (does the far end of the building sit where the model says) are different measurements, and a provider can be correct on one and wrong on the other.
- USIBD separates measured accuracy (how close the point cloud is to physical reality) from represented accuracy (how close the finished model is to the point cloud) — a cloud can be ±5 mm and the model still 15 mm off because of a modeling decision, not a scanning error.
- On a documented hospital wing project, control-tied registration and 36 independent QC checks avoided 23 RFIs and $147,000 in change-order risk; the mechanism was network accuracy, not a single impressive number.
Accuracy, precision, and network accuracy
Accuracy, precision, and network accuracy answer three different questions, and conflating them is the single most common reason a design team trusts an as-built that later fails in coordination. Accuracy measures how close a single measurement is to the true physical location. Precision measures how repeatable that measurement is. Network accuracy measures whether every point across an entire building or corridor holds its correct position *relative to every other point*, not just relative to the scanner that captured it.
A provider can report excellent numbers at every individual scan station and still deliver a model that is wrong across the building. This happens because terrestrial and mobile laser scanning both build a model out of many overlapping setups or a continuously moving trajectory, and each setup or trajectory segment carries its own small registration residual. A single station can close to a fraction of a millimeter against its neighbors and still be part of a network that has drifted, because the error isn't in any one measurement — it's in how the measurements are stitched together.
This is why local accuracy figures, quoted in isolation, are close to meaningless for a floor plate over a few hundred feet or a building with more than a handful of scan setups. A scanner's own point-to-point performance — the kind of figure verified using a method like ASTM E3125-17 — describes what the instrument can do under test conditions. It says nothing about whether the registration chain built from dozens or hundreds of those measurements holds together across a real building.
The bound on global accuracy is the control network: a set of surveyed points, established independently of the scan data, that the registration is tied to and periodically checked against. Without control, a registration can be internally consistent — every scan agrees with its neighbors — while the whole assembly has walked away from true position. With control, every scan is checked against a fixed external reference, and residuals at the far end of a building reveal themselves instead of hiding inside an internally consistent but globally wrong model. ZEALOT's method constrains scans to surveyed control, verifies loop closures, and reports residuals rather than suppressing them, which is what makes a ±5 mm survey-grade registered accuracy figure meaningful at building scale rather than only at a single station.
How error accumulates
Error accumulation is arithmetic, not opinion, and it explains why a project that looks fine at every checkpoint can still produce a grid line that is meaningfully off by the far end of a long run. Consider a 400 ft corridor registered as a chain of 20 scan stations, each contributing a small residual relative to the one before it. If registration is done cloud-to-cloud only — each scan tied only to its immediate neighbor, with no independent check against fixed control — the residuals do not cancel out on average; they tend to accumulate in a roughly random-walk fashion along the chain.
A commonly used way to estimate that accumulation is the root-sum-square (RSS) of the per-station residuals along the chain, rather than a simple sum. If each of the 20 station-to-station registrations carries a small residual on the order of a few millimeters, the RSS combination across the chain grows with the square root of the number of stations rather than linearly — but it still grows, and it grows in an uncontrolled direction because nothing is anchoring the chain back to a known reference. By the time that chain reaches station 20, the cumulative positional uncertainty at the far end can be several times the single-station residual, and there is no way to know from the cloud-to-cloud data alone which direction the drift has gone.
Contrast that with a control-tied network. Surveyed control points placed along the same corridor give the registration external, fixed references at intervals — for example, at every third or fourth station. Instead of one long unbroken chain of relative residuals, the registration is broken into shorter segments, each independently checked against a known point. Drift within a segment is bounded by the distance to the nearest control point, not by the length of the entire corridor, and any segment that doesn't close within tolerance is flagged and re-registered before it ever reaches a deliverable.
The practical consequence at the far end of a 400 ft run: a control-tied network keeps the far-end positional uncertainty within the same order of magnitude as the near end, while a cloud-to-cloud-only chain lets it grow with distance and station count. A grid line that a structural engineer needs to hold to a specific column line, or a curtain wall mullion layout that needs to land on a specific slab edge, is exactly where that difference becomes visible — not on the first sheet reviewed, but on the one at the far end of the building.
Where the error surfaces in coordination
Uncontrolled network error does not announce itself. It shows up as a clash, a field conflict, or a change order weeks or months after the as-built was accepted, and it shows up in specific, predictable places.
| Error type | Design activity affected | What fails | When it's found |
|---|---|---|---|
| Cumulative drift along a corridor or floor plate | Curtain wall layout to slab edge | Mullion spacing doesn't land on the structural grid at the far end of the run | During curtain wall shop drawing review or field layout |
| Global position offset in a multi-story registration | MEP mains routed through structure | Sleeve or opening location in the model doesn't match the as-built structural penetration | During MEP rough-in, after openings are already core-drilled |
| Local model tolerance stacking with global drift | Ceiling heights and clearance | Modeled clearance below a beam or duct is tighter in the field than in the model | During ceiling grid installation or above-ceiling MEP coordination |
| Unverified network accuracy across a corridor | Door and corridor widths against code | Clear width falls short of the code minimum once as-built dimensions are field-verified | During accessibility or life-safety review, sometimes after permitting |
| Independent registration of structural vs. architectural scans | Structural grid vs. architectural grid | The two disciplines' models disagree on where a column line actually sits | During federated model clash detection |
| Drift between an existing-conditions scan and a new construction control network | Tie-ins to new construction | New structure doesn't align with the as-built connection point | During foundation or structural tie-in layout, on site |
The common thread across every row is that the failure is discovered downstream of where the error was introduced — during shop drawing review, rough-in, or field layout — which is exactly what makes network accuracy expensive to get wrong and cheap to verify up front. This is the same causal chain examined in detail, at the level of specific cloud defects, in how poor point clouds disrupt BIM coordination; this page focuses on the registration and network-accuracy mechanism, while that page catalogs the resulting modeling errors.
Measured accuracy vs represented accuracy
USIBD's Level of Accuracy framework draws a distinction that almost never appears in provider marketing: measured accuracy and represented accuracy are not the same number, and both matter to a design team using the model for coordination.
Measured accuracy describes how closely the registered point cloud matches physical reality — the figure verified by independent check measurements against the built condition, such as ZEALOT's ±5 mm survey-grade registered accuracy or the ±6 mm registered accuracy tied to plant control used on industrial projects. This is a property of the scan data itself.
Represented accuracy describes how closely the finished model — the walls, ducts, and structural elements a modeler draws — matches that registered point cloud. This is a property of a human decision, not the scanner. At LOD 300, ZEALOT's published standard holds model faces to ±10 mm of the registered cloud, but that figure is a modeling tolerance, applied after the scan is already registered.
The gap between the two explains a scenario that confuses design teams every time it happens: the point cloud can be verified at ±5 mm, and the resulting model can still be 15 mm or more off from as-built reality, because a modeler made a judgment call — snapping a wall to a nominal thickness, simplifying an irregular surface to a planar face, or centering a duct within a noisy cluster of points — that is reasonable, documented, and still introduces error beyond the scan's own accuracy. This is not a defect to be hidden; it's a decision that should be stated as part of the model's LOD and LOA documentation, so a design team coordinating against that model knows which tolerance actually applies to which element. What does ±5 mm accuracy mean explains the measured-accuracy side of this in more depth; this section is about where the number changes on the way into the model.
What it costs when it goes wrong
The cost of unmanaged network error and undocumented representation decisions shows up as rework, RFIs, and schedule slip — not as a line item labeled "registration error." On a 38,400 sq ft occupied hospital wing renovation, captured across two overnight shifts at ±6 mm registered accuracy (4.2 mm mean error verified across 36 independent QC checks), the control-tied, verified registration avoided 23 RFIs and $147,000 in change-order risk, and accelerated the project schedule by 10 days. On a 220,000 sq ft live process plant, scanned in five days with zero downtime, the as-built documentation found 143 pipe runs routed differently than the existing PDFs showed — each one a coordination failure waiting to happen if the outdated drawings had been trusted instead. On a 200,000 sq ft data center project delivered to an LOD 350 MEP model, the same discipline eliminated more than 40 field conflicts and finished three weeks ahead of schedule.
These are project-specific, verified outcomes, not industry averages. The broader interoperability problem they sit inside of is documented at the national scale in NIST GCR 04-867, the federal study that quantified inadequate interoperability among AEC software systems — including the kind of coordination breakdown that starts with an inaccurate as-built — at $15.8 billion per year across the U.S. capital facilities industry. That figure is cited here by report name, not as an unattributed "industry study," because the distinction matters: a number with a source can be checked, and a number without one cannot. For the cost mechanics of design rework specifically — RFIs, change orders, schedule impact traced back to bad as-built documentation — see how inaccurate as-builts cause design rework and the true cost of bad as-builts in AEC; this page has focused on the accuracy and error-propagation mechanism that produces those costs, not the cost accounting itself.
How to specify accuracy so this doesn't happen
The fix is specified up front, not discovered in the field. A scope of work should state the required measured accuracy (for example, ±5 mm registered to surveyed control), the required represented accuracy at each LOD tier (for example, ±10 mm at LOD 300), the control network method that will bound global accuracy across the building or corridor, and the independent verification method — check measurements against physical reality, not just internal loop closure — that will confirm both numbers before the deliverable is accepted. The complete guide to 3D scanning scope of work provides a copy-pasteable template covering exactly these fields, including where to name the control network requirement so it isn't left implicit. Coordinating on a model with these terms stated and verified — rather than assumed — is what keeps the failure modes in the table above from reaching a shop drawing or a field crew. ZEALOT Reality Capture's as-built documentation service is built around this method: control-tied registration, published residuals, and independent check measurements on every project, from a single floor plate to a multi-building campus. Projects that need this level of accuracy stated in a signed scope can request a free scope review.