Measured Data, Capture Process, Maintained Model: Three Different Purchases

Three words, three different purchases

A quote headed digital twin and a quote headed reality capture can describe work that differs by an order of magnitude in effort. The three terms are not synonyms and they do not sit on one spectrum. One names a data product, one names a field activity, one names an ongoing service with an owner. Buyers who conflate them sign for the cheapest of the three, then discover eighteen months later that nothing about the asset has been updated since handover and the only deliverable is a file nobody can open.

Point cloud is the data product. It is a set of measured coordinates, each carrying an intensity or colour value, produced by a laser scanner or a photogrammetric solve. It holds no notion of a vessel, a line number or a nozzle. Software renders it, sections it and measures between any two points in it, and that is the complete list of what it does unaided. It carries no attributes, no history and no relationship to your equipment register.

A 3D scan is the field process that produces the cloud. It is priced in setups, site days, permit hours and registration effort. A digital twin is neither of those: it is a maintained representation of named assets with live data bound to them and a defined refresh cadence. The breakdown at /digital-twin-vs-idms takes the next step and separates a twin from the inspection data management system it sits beside, because those two also get sold as one thing.

A point cloud is a measurement, and it carries an error budget

Every point cloud has a stated accuracy or an undeclared one. The U.S. Institute of Building Documentation publishes the framework the American market uses for this. Document C120 defines five Levels of Accuracy, LOA10 through LOA50, deliberately numbered in tens to avoid collision with the BIM Forum LOD hundreds series. LOA10 runs down to 5 cm with a user-defined upper bound, LOA20 spans 5 cm to 15 mm, LOA30 spans 15 mm to 5 mm, LOA40 spans 5 mm to 1 mm, and LOA50 runs from 1 mm to zero.

Every one of those bands is stated at the 95 percent confidence level, and that matters more than the headline number. A tolerance and a standard deviation are different objects. C120 draws the distinction its DIN 18710 lineage draws: a tolerance permits no excursion, a standard deviation describes a distribution. The guide's own rule of thumb puts the required standard deviation at roughly one fifth of the overall tolerance you are trying to hold, which is why a scanner quoted at 5 mm does not deliver a 5 mm tolerance.

Registration compounds all of this. Individual setups each carry error, and solving them into a single coordinate system adds residuals of its own. A congested process unit captured from ninety positions behaves differently to an open tank farm captured from twelve. Ask for the registration report and the residuals rather than a brochure figure, and put the reported registration accuracy into the acceptance criteria alongside the LOA level.

Measured Accuracy and Represented Accuracy are two different numbers

This is the most useful distinction in the whole specification and the one vendors quietly skip. C120 splits accuracy into Measured Accuracy, the standard deviation range achieved by the final measurements regardless of how they were taken, and Represented Accuracy, the standard deviation range achieved once those measurements are processed into line work or a model. They are specified separately because they are achieved separately, by different people, at different stages of the job.

The guide states the governing relationship plainly: Represented Accuracy can only equal or fall below Measured Accuracy. Modelling never adds precision. A cloud captured at LOA30 and modelled by an operator snapping to nominal pipe diameters yields a model that looks crisp and represents nothing better than LOA20. The scan was accurate; the deliverable is not. Nobody discovers this until a fabricated spool arrives on site three quarters of an inch short.

A scope naming one accuracy number is therefore a scope you cannot audit. Name Measured Accuracy for the capture, name Represented Accuracy for the model, and name both per element class rather than site-wide. Steel and civil work sit at a looser band than nozzle positions and tie-in faces without any loss of value, and specifying that difference is where the budget conversation becomes useful instead of adversarial.

The scan is not where the money goes

Field capture is the fastest part of the job and the part buyers fixate on. Modern instruments are not the constraint. Leica publishes the RTC360 at up to two million points per second, completing a scan including high dynamic range imagery in under two minutes. Nobody waits on the scanner. They wait on the hot work permit, the confined space entry, the escort, the operating unit that will not release the area, and the scaffold that must go up before anything above head height gets a clean line of sight.

Occlusion drives setup count, and setup count drives everything downstream. A process unit dense with piping needs positions a warehouse does not, and every additional position adds registration work and quality control. A scan quote priced per square foot tells you almost nothing useful about a refinery and a great deal about how many refineries the vendor has actually captured.

The largest single cost sits after the field crew leaves. Turning measured points into named objects - this exchanger, that line number, this nozzle at this elevation - is manual authoring work, and it routinely exceeds the cost of capture. That step produces the thing an engineer can actually use, and it is the step most often quietly descoped to make a number fit a budget.

What makes a twin a twin is the feed, not the geometry

A model becomes a twin when data keeps arriving and the model keeps agreeing with the plant. That means asset tags reconciled to the equipment register, condition monitoring locations bound to geometry, thickness readings with dates, calculated corrosion rates, next examination due dates, open work orders and management-of-change status. Four of those are inspection outputs, which is why a twin built without the inspection department is a viewer with a good demo attached to it.

Cadence is the second half of the definition. A twin has a stated refresh interval, a named owner and a reconciliation routine that catches drift between model and field. Without those three the deliverable degrades into a dated as-built the moment the first tie-in goes in. The platform overview at /digital-twins describes how the inspection feed is bound to the model rather than pasted beside it in a document library.

This is also the honest limit of the product. A twin presents the record; it does not certify it. The signed thickness reading, the corrosion rate and the interval calculation live in the inspection system and they stay there. A twin that quietly becomes the authoritative record is a compliance problem waiting for the next client audit to find it.

Effort profiles after handover, which is where buyers get hurt

A point cloud has zero maintenance cost and a short useful life. It is a dated snapshot, accurate on the day, decaying locally with every physical change. Treated as a turnaround-cycle purchase it is excellent value; treated as a permanent asset record it is a slow disappointment. Plants that re-capture on the same cycle as their inspection intervals get compounding value, because each capture is directly comparable to the last one.

An as-built model decays faster than the cloud it came from, because it is expected to be authoritative. Every management-of-change item that moves steel or pipe puts the model out of date, and the rework is manual. Budget model maintenance the way you budget drawing revision control, because it is the same problem carried in a heavier file format and with fewer people trained to do it.

A twin carries the highest ongoing effort and the only genuinely increasing return. Each inspection cycle adds readings, each turnaround adds as-built corrections, and after two cycles the twin holds a history no drawing set ever held. The failure mode is not technical. It is that nobody was made the owner, so nothing was refreshed. Name the owner in the contract, on the first page.

What the buyer asking for a digital twin usually needs

Three intents hide behind the same request. The first is access and clash: I need to know what is physically there before I fabricate, scaffold or lift. That buyer needs a scan and a registered cloud at a stated LOA and nothing more. Buying a twin to satisfy that requirement is expensive theatre, and it delays the answer by several months.

The second is engineering: I need named geometry I can attach documents to and hand to a design contractor. That buyer needs an as-built model with a defined Represented Accuracy and a tag reconciliation against the equipment register. The third is integrity: I need to see condition, history and risk in spatial context and keep seeing it. Only the third is a digital twin, and it is the one most often requested by name and least often actually bought.

The diagnostic question is short. Ask what changes on the deliverable after the first inspection campaign. If the answer is nothing, you are buying a scan or a model and you should pay scan or model effort for it. If the answer names specific fields that update on a stated cadence, and names who updates them, you are buying a twin.

Writing a scope that gets you what you meant

Four clauses do most of the work. State Measured Accuracy and Represented Accuracy separately, each as a USIBD level, broken out by element class. State the registration deliverable: control network, residuals and a registration report, not only the cloud. State the attribute schema - which tags, from which source system, reconciled how - because a model carrying tags that do not match the equipment register is worse than a model carrying none at all.

State the refresh cadence and the acceptance test. The acceptance test is the clause buyers omit and later regret. A good one is concrete: select twenty elements at random, field-measure them, and check them against the delivered model at the specified Represented Accuracy. That single paragraph converts an argument about quality into an arithmetic check that either passes or fails in an afternoon.

Then write down who owns the deliverable after handover, on what interval, funded from which budget line. If that sentence cannot be written, the organisation is buying a scan and calling it a twin, and it is cheaper to say so at the start. Atlantis scopes this work backwards from that sentence, and issues a quote on request through /contact.

The NDT acceptance test: can it answer a thickness question?

One test separates all three deliverables for an integrity engineer. Point at a location on the deliverable and ask: what is the last recorded wall thickness here, when was it taken, what is the corrosion rate, and when is the next examination due? A point cloud answers no part of it. An as-built model answers none of it either, though it shows you precisely where you are pointing, which is worth something.

A twin answers all four because the condition monitoring locations are bound to the geometry and the readings flow from the inspection record. Building that binding is unglamorous work. CML identifiers have to be stable, positions have to be surveyed once and reused, and the reporting system has to emit readings keyed to those identifiers rather than to a job number. The note at /blog/building-a-cml-register-that-survives-ten-years covers the identifier discipline that makes it possible.

That is why the reporting layer matters more than the rendering layer. If field data arrives as flat PDFs, no twin will ever answer the question, whatever the geometry cost. The capture-tool comparison at /ndt-inspection-software and the reporting shortlist at /best-ndt-reporting-software-2026 both work from the same requirement: structured readings, keyed to an asset, produced in the field, retrievable a decade later.

Request a consultation