Practical checklist
What this article covers
A deliverable review matrix tied to agreed requirements, not promises of universal accuracy or survey certification.
Accept a scan-to-BIM deliverable against an agreed use and a recorded set of checks, not its visual completeness. A model that opens is not automatically suitable for every renovation decision.
This proposed acceptance worksheet helps an architecture team identify what was delivered, what supports it and what remains unresolved. Project professionals must define the relevant verification methods and acceptance limits; this article supplies no default tolerances or certification.
Start with the intended use
Name the package, model revision, source datasets, required outputs and decision owner. Describe the task the recipient needs to perform. A room-planning reference and a model intended for a different technical use may need different information.
Autodesk describes point clouds as reference information for modeling existing conditions. Keep the source dataset distinct from the authored model and its agreed verification record.
Review evidence by category
| Acceptance question | Evidence to request | Action if unresolved |
|---|---|---|
| Is this the agreed package? | Model, dataset and output revision list | Clarify the baseline |
| Is required information supported? | Defined checks, results and source references | Refer the unsupported item to its owner |
| Are needed locations covered? | Coverage observations and access limitations | Record affected use |
| Are omissions deliberate? | Agreed scope and exclusion decisions | Separate missing work from agreed exclusions |
| Are assumptions visible? | Assumption IDs and affected objects or drawings | Request explanation or further evidence |
| Can the recipient use the package? | Receiving-environment check and review record | Identify the specific obstacle |
A provider's scan-to-BIM workflow describes sample-zone review and an exclusions log. That is an attributed example, not a universal standard or evidence that another provider has performed those checks.
Hypothetical example: a required room identifier is missing
In this fictional assignment, the brief requests room identifiers in the model and the room schedule. The delivered schedule leaves one identifier blank even though the agreed reference list provides it.
Record the missing field, its reference and the affected schedule. Ask the assigned production owner to respond. After a correction, the reviewer checks the identified model and schedule locations in the returned revision.
This demonstrates information acceptance only. It does not establish geometric accuracy, concealed conditions or suitability for construction.
Route unresolved items to the right record
Use the point-cloud coverage checklist for missing observation support and the modeling exclusions schedule for agreed scope boundaries. Keep assumptions in the existing-conditions register, not only in private notes.
When records disagree, use the drawing discrepancy log. Logging an uncertainty does not resolve it or authorize reliance on unsupported information.
State the outcome and its limits
Record accepted for the specified use, returned for correction, or awaiting a decision, with the review scope and unresolved exceptions. A restricted acceptance must state what is not covered and who authorized it.
For a subsequent drawing package, carry those limits into the remote-team drawing issue checklist. Nest's scan-to-BIM briefing guide and scan-to-BIM service page provide context for defining the production assignment before work begins.
Related guides and services
Keep the production handoff connected to the wider workflow:
Need help with current production work?
Tell us which drawings, models, visualizations, or review packages need attention. We can review the assignment, confirm availability, and explain whether a project package or dedicated monthly support fits.
Book a project callSend a project brief