What Accuracy Does Your As-Built Model Actually Need?

Most as-built scopes get this question wrong in one of two directions.

Some ask for everything — maximum accuracy, maximum detail, every component modeled — and then get sticker shock at the quote for a model they'll use to check whether a new skid fits in a room. Others ask for “a scan” with no accuracy requirement at all, get exactly that, and discover three months later that the data won't support the fabrication they were planning to do from it.

Both mistakes come from the same place: treating accuracy as a single quality dial that goes from “cheap” to “good.” It isn't. There are two independent dials, they're routinely confused with each other, and knowing which one you need is the difference between a scope that fits your project and one that wastes money in either direction.

Two dials, not one

Level of Development (LOD) describes how much is in the model. It's the BIMForum framework, and it runs roughly from LOD 100 (a generic placeholder) through LOD 200 (approximate size, shape, and location) and LOD 300 (specific geometry, accurate location) to LOD 400 (fabrication-level detail, including connections and assembly information). LOD is about information richness and geometric specificity — how much a model tells you about a component.

Level of Accuracy (LOA) describes how closely the model matches the real world. The USIBD Level of Accuracy Specification defines five tiers, with tolerance ranges stated at a 95% confidence level:

• LOA10 — user-defined (coarser than 5 cm)
• LOA20 — 5 cm to 15 mm
• LOA30 — 15 mm to 5 mm
• LOA40 — 5 mm to 1 mm
• LOA50 — 1 mm to 0

These are separate dials because they measure different things, and they can move independently. You can have a highly detailed model that's in the wrong place. You can have a very accurate model with almost nothing in it. Neither is a failure of quality — each is just an answer to a question somebody asked.

The USIBD specification also draws a distinction that saves a surprising number of arguments: measured accuracy versus represented accuracy. Measured accuracy is how closely the captured data reflects reality. Represented accuracy is how closely the modeled element reflects it. A scan can be accurate to a few millimeters and the model built from it can still be off by considerably more, because modeling involves interpretation — fitting a cylinder to a lagged pipe, deciding where a corroded edge “is,” idealizing a member that isn't straight anymore. If your spec only addresses the scan, you have specified the easy half.

One more point worth knowing before you write a number into a scope: LOA can be applied per element, not just per project. You do not have to buy your tightest tolerance across an entire facility. The tie-in points can be specified tighter than the building shell they sit in, and usually should be.

The question that actually sets the number

Here's the shortcut. Don't ask “how accurate should this be?” Ask:

What decision is someone going to make from this model, and what does being wrong cost?

Accuracy requirements come from consequences, not from preferences. Work through it by use case. The tier suggestions below are our recommendations for matching use to tier — USIBD defines the tiers, not which one your project needs.

Space planning, familiarization, visual documentation. Someone needs to understand a space, walk it remotely, or hold a record of what was there. Nothing gets fabricated from it. Coarse accuracy is genuinely fine here — LOA10 to LOA20 territory — and paying for more is paying for nothing. This is where 360 capture and photogrammetry legitimately live.

Clash detection, layout, and equipment fit. Will the new unit fit through the door and into the space? Does the new duct run clash with existing steel? These are questions about whether things collide, and collisions are usually decided at centimeter scale, not millimeter. You need reliable geometry and reliable registration; you don't need fabrication tolerance. This is generally the LOA20 band, and a lot of industrial as-built work sits there quite correctly.

Fabrication and routing. Something is going to be built off-site from this model and has to arrive fitting. Now the tolerance has to be tighter than the fit-up you're expecting, because the model error and the fabrication error stack. This is LOA30, sometimes into LOA40.

Connections and tie-ins. The tightest requirement on most projects, and it applies to a small fraction of the total scope. A flange face, a bolt pattern, an anchor location, a hot tap — places where a few millimeters decides whether it lands or doesn't. LOA40 territory, and worth specifying separately for exactly those elements.

Deviation analysis and monitoring. A different problem: you're comparing two states, so what matters most is repeatability of the measurement between captures. The absolute tier matters less than the consistency of method, control, and registration.

Notice the pattern. The tolerance is set by the tightest fit-up someone will attempt from the model, and only over the elements where that fit-up happens.

The three ways this goes wrong

Specifying LOD when you meant accuracy. “We need LOD 400” is a request for fabrication-level detail. It says nothing about whether that detail is in the right place. If what you actually need is a tie-in that lands, you need an accuracy requirement, and you may well need it at a lower LOD than you asked for.

Buying one tolerance for the whole facility. The most common source of a quote that seems irrationally high. If the tightest thing on the project is four tie-in points, specify those four points tight and the rest to what it's actually used for. Per-element specification is how the framework is designed to be used.

Specifying the scan and not the model. If the deliverable is a model, the accuracy requirement has to apply to the model. Otherwise you have a highly accurate point cloud and a model built from it by whatever interpretation choices someone made on a deadline — and no basis to say anything about it.

What a usable accuracy spec contains

You don't need to be an expert to write this well. Six items cover it:

1. What each deliverable will be used for. Say it in plain language: “clash detection against new equipment,” “fabrication of tie-in spools,” “space documentation.” This is the single most useful sentence in the whole scope.
2. Accuracy requirement, stated as a tolerance and a confidence level — and stated separately for the tight elements if the project has any.
3. Whether that requirement applies to the captured data, the model, or both. Both is the right answer when the deliverable is a model.
4. LOD by system, because you rarely want the same detail everywhere. Piping at one level, architectural shell at another.
5. Which elements get the tight treatment, named specifically. Tie-in points, connection interfaces, foundation and anchor locations.
6. How it will be verified. A stated accuracy nobody checks is a marketing claim. Ask what the control and verification approach is and what documentation comes with the deliverable.

Six lines. It costs almost nothing to write and it changes the quote, the method, and the outcome.

Why this is worth ten minutes of your time

Accuracy is one of the few cost drivers in reality capture that buyers control directly. It determines the capture method, the number of setups, the control approach, and the modeling effort — which means it determines the price and the schedule. Under-specify and you buy data you can't build from. Over-specify uniformly and you pay fabrication tolerance for a warehouse wall.

Ten minutes deciding what each deliverable is for is the highest-leverage thing you can do before anyone mobilizes.

Not sure which tier your project needs? Tell us what you'll be building from the model and we'll scope the accuracy to the decisions, not to the whole building. Get a quote →

Related reading: Laser scanning vs. SLAM vs. photogrammetry vs. Matterport · The hidden cost of outdated as-built drawings

Sources: USIBD Level of Accuracy Specification, current release Version 3.1; BIMForum Level of Development Specification.