TL;DR: As-built documentation records what exists. As-built verification goes a step further: it aligns a scan of the constructed work to the design model and reports where the two disagree. The output is a deviation report, usually a colour-mapped comparison plus annotated sections, showing which elements sit outside the project's agreed limits. It is most useful at rough-in, before finishes close everything in, and it answers a narrow question well rather than every question loosely.
Most reality capture work on a construction project is documentation: capture the space, produce drawings or a model, hand it over. Verification is a different job. It starts from the assumption that a design model already exists, and asks a single question about the building in front of you: does the built work match it, and where does it not?
That question comes up more often than teams expect, and usually at an awkward moment.
Documentation and Verification Are Not the Same Deliverable
It is worth separating these clearly, because they are quoted, scoped, and used differently.
As-built documentation produces a record of existing conditions where no reliable record exists. The output is measured as-built drawings or a Scan to BIM model. Nobody is comparing it to anything; it becomes the reference.
As-built verification produces a comparison. It requires a design model or drawing set to compare against, and the value is in the difference between the two, not in the scan itself. The scan is the measuring instrument. The report is the deliverable.
A project can need both. Documentation of an existing building before design work starts, then verification of the new construction against that design later. They are separate engagements with separate scopes.
How the Workflow Actually Runs
The sequence is consistent across most verification projects, whatever the building type.
1. Confirm what the comparison is against. This is the step most likely to derail the engagement if it is skipped. Verification needs an agreed reference: a specific model file, a specific drawing revision, at a stated coordinate system. Comparing a scan to an out of date model produces a report full of deviations that are not deviations at all, just design changes nobody recorded.
2. Capture the constructed work. 3D laser scanning records the built condition as it stands on the day. Coverage planning matters here in a way it does not for general documentation, because a deviation you did not scan is a deviation you cannot report. Areas of known risk, structural interfaces, and congested service zones usually get denser coverage.
3. Register and align. The individual scans are registered into a single point cloud, then aligned to the design model's coordinate system. Alignment is where verification projects most often go wrong: if the scan and the model are not sitting in the same space correctly, every subsequent measurement is off by the same error, and the report becomes noise.
4. Compare and classify. With both datasets aligned, elements are compared and the differences are classified. Not every difference matters. Part of the work is separating deviations that affect the project from those that do not, which requires knowing what the project cares about.
5. Report. The deliverable is issued for the team to act on. Format depends on who reads it, which is covered below.
What the Deliverable Looks Like
Verification outputs tend to combine a visual and a written component, because the two audiences want different things.
| Output | What it shows | Who uses it |
|---|---|---|
| Colour-mapped comparison | Deviation magnitude across a surface or element, rendered as a gradient | Coordinators and designers scanning for problem areas quickly |
| Annotated sections | Cut views through specific locations with measured differences called out | Trades and site teams working on a fix |
| Written deviation schedule | Element by element list of where the built work differs from the model | Project managers, contract administrators, owners |
| Registered point cloud | The underlying capture, delivered alongside | Anyone who needs to check something the report did not cover |
The point cloud is worth requesting even when the report answers the immediate question. Verification reports are scoped to a question asked at a particular moment. The cloud holds everything that was visible on the day, which is what teams come back to when a different question surfaces three months later.
When Verification Is Worth Doing
Timing changes the value of this work more than any other factor.
At rough-in, before finishes. This is the window most teams ask about, and for good reason. Structure is up, services are installed, and nothing is hidden yet. A deviation found here is a coordination conversation. The same deviation found after drywall is a demolition conversation.
Before a critical interface. Where a new element has to meet existing construction, prefabricated assemblies, curtain wall, elevator shafts, verification of the receiving conditions can help before the fabricated piece arrives on site rather than after.
During a dispute or change order. When two parties disagree about what was built, a scan taken at a known date is a measurable record rather than a recollection. It does not resolve the commercial question, but it removes the factual one.
At handover. Owners increasingly ask for a verified record rather than a marked up drawing set, particularly on facilities where future work will depend on knowing what is actually behind the walls.
The Limits, Stated Plainly
Verification answers a narrow question, and it is worth being direct about where it stops.
It only sees what was visible. A scanner records surfaces in line of sight. Anything already concealed behind finishes, inside wall cavities, buried, or otherwise inaccessible is out of scope unless it was captured before it was covered. This is the single biggest reason timing matters.
It compares to a model, not to intent. If the design model itself contains an error, verification will faithfully report the built work as deviating from a model that was wrong. The comparison is only as sound as the reference.
It reports differences; it does not judge them. Deciding whether a given deviation is acceptable is an engineering or design decision belonging to the responsible professional. On-Site Measurements produces the measured comparison. We do not provide engineering sign off, code assessment, or architectural stamping, and a deviation report is not an approval.
Accuracy depends on the setup. The scanner, the registration method, the coverage plan, and site conditions all affect what a comparison can resolve. We do not publish a single tolerance figure because the honest answer varies by project. What we can do is agree the approach before the work starts, so the report's limits are understood when it is read rather than discovered afterwards.
Scoping a Verification Project
The information that makes a verification quote meaningful is different from a documentation quote. Useful to have ready:
- The design model or drawing set that will serve as the reference, including its revision
- The coordinate system the project works in
- Which elements or systems are in scope: structure, MEP, envelope, or a defined subset
- The construction stage at the time of scanning
- Site access constraints, since verification often happens on an active site around trades
- Who reads the report and what decision it feeds
The last point shapes the deliverable more than people expect. A report written for a coordination meeting looks different from one written for a contract dispute.
Related Work
A worked example of construction stage capture is covered in our construction verification scanning case study. For projects still at the documentation stage rather than the verification stage, Scan to BIM and as-built drawings are the relevant starting points. Verification work in the GTA is scoped through our Scan to BIM in Toronto page.
Frequently Asked Questions
What is as-built verification in BIM?
It is the comparison of a laser scan of constructed work against the project's design model, reported as a set of deviations. The scan provides the measured built condition; the model provides the intended condition; the deliverable is the difference between them.
How is deviation analysis different from clash detection?
Clash detection runs inside the model and finds conflicts between designed elements before anything is built. Deviation analysis runs against reality and finds differences between what was designed and what was actually constructed. One is predictive, the other is a check after the fact.
What model do I need to provide?
A design model in a format that can be aligned to scan data, most commonly Revit or IFC, along with the coordinate system and the revision it represents. Where no model exists, a dimensioned drawing set can sometimes serve as the reference, though the comparison is necessarily more limited.
Can verification be done after the building is finished?
Only for what remains visible. Once services are behind drywall and ceilings are closed, they cannot be scanned. Verification of concealed work has to happen before it is concealed, which is why rough-in is the window teams are usually advised to plan around.
Does the report say whether a deviation is acceptable?
No. The report states what the difference is and where. Whether that difference matters is a decision for the design or engineering professional responsible for the element. We provide the measurement, not the judgement.
Do I get the point cloud as well as the report?
Yes, when it is included in scope, and we generally recommend it. The report answers the question that was asked; the point cloud retains everything that was visible, which is what teams return to when a different question comes up later.
If you have a project where the built work needs checking against the design, send the model revision, the elements in scope, and the construction stage. We will come back with a verification approach and what the comparison can and cannot resolve. Request a quote or browse more field notes.