How an inspection contractor delivers twin-ready NDT data without rebuilding the workflow

Why the request arrived, and what it usually means

Asset owners investing in digital twins reach a predictable moment roughly a year in. The model exists, the handover data is loaded, and then the first live inspection campaign produces a PDF report and a spreadsheet that nobody can load into it. The response is a new clause in the next inspection scope of work, and that clause is where most contractors first encounter the words twin-ready. It is frequently written by someone who has not run a field campaign, which is why it is often vague.

In practice the requirement decomposes into three concrete questions, and it is worth extracting them before pricing anything. Which identifier scheme must every result carry, and who issues it. Which file format does the receiving system ingest, and can you see a working example. What location reference does the client expect, in what coordinate convention and against what datum. Answers to those three define the whole obligation, and they are usually answerable in one call with the client's integrity engineer.

Everything else in a typical twin-ready clause is work you already perform. Procedure references, technician certification records, calibration status and campaign dating are standard elements of a defensible inspection record under any quality system. The novelty is not the metadata, it is that the metadata must arrive in a structured field rather than in a sentence on page four of a PDF. That distinction is worth explaining to clients who assume the request is larger than it is.

The payload: what a twin-ready result contains

Start from the deliverable rather than from the software. A twin-ready result is a row of data with a defined set of fields, however it is transported. It carries the client's asset tag so the system knows which equipment it belongs to. It carries the client's location identifier — condition monitoring location, weld number, component identifier — so the result can be compared to previous results at the same place. It carries a location reference so the result can be positioned in space rather than only associated with an asset.

It carries the measured value with an explicit unit, because unit ambiguity between metric and imperial is a silent and dangerous failure in remaining-life calculations. It carries the method, the procedure number and the revision in force at the time of examination, which is what makes the result defensible in a fitness-for-service or jurisdictional review years later. It carries the technician's identity, method, level and certification validity at the time of the examination.

And it carries the campaign identifier and the examination timestamp, which is what allows a system to distinguish this year's readings from last year's rather than collapsing them into an undated set. Eight fields, most of which your existing report already contains somewhere in prose. The engineering task is making them structured and consistent, not inventing new information. That reframing is usually what unlocks the internal conversation at a service provider, because it converts an intimidating request into a data entry design problem.

Asset identity: use the client's register, never your job number

This is the single most common failure and it is worth being blunt about. Contractors number things for their own operational purposes — job number, scan sequence, report section, drawing sheet. Those numbers are internally coherent and completely meaningless to the client's integrity system. A deliverable identified by contractor scan numbers requires someone at the client end to map each row to their register by hand, and that manual mapping is where errors enter and where the same physical location acquires two identities across two campaigns.

The correct approach is to obtain the client's register before mobilisation and carry their identifiers as the primary key throughout, keeping your own numbering as a secondary reference. Both can coexist in the deliverable and both are useful — yours for your traceability and theirs for their system. What cannot happen is yours being the only identifier present, because that shifts the reconciliation burden onto the party least able to do it accurately.

Where new locations are being established, the numbering convention still has to be agreed with the client rather than invented. Under API 570 and API 653 practice, condition monitoring locations are the client's integrity record, and prior editions' independent thickness measurement location designation has been folded into the CML concept in current code. Issuing new identifiers back to the client for incorporation into their register is part of the deliverable, and a contractor who does this reliably becomes materially harder to replace.

Location referencing: four methods and when each survives the field

The first and most robust method is the identifier itself, where the client's register already ties each condition monitoring location to a known position on the model. Here the contractor's job is simply to use the identifier faithfully, and no coordinate work is needed. This covers most recurring thickness monitoring on registered equipment and it is the method to prefer whenever it is available, because it makes the contractor's obligation trivial and the client's ingestion automatic.

The second is a component-relative convention: station along a line from a named origin, plus clock position around the circumference, plus elevation where relevant. This is how field crews already describe locations verbally, it survives insulation and access constraints, and it requires no instrumentation. Its weakness is that the origin and the direction convention must be agreed and recorded, because station 4.2 metres means nothing without knowing which end is zero and which way is positive.

The third is grid referencing on a mapped surface — corrosion mapping on a tank floor or shell course, where a grid is established, marked and photographed. The fourth is direct coordinate capture using survey equipment or a scanner's own registration, which is the most precise and the least practical for routine campaigns because of equipment, time and access cost. Most real programmes use the first two, reserve the third for mapping work, and use the fourth only where a scan is already being performed for other reasons. Deciding which applies per work type, in advance, prevents crews improvising.

Datums and conventions: the quiet source of unusable data

Location data fails more often through convention mismatch than through measurement error. A crew records clock positions viewing the line from the north end; the model was built with the convention that clock positions are viewed in the direction of flow. Every position is now mirrored, and the error is undetectable in the data itself because the numbers look entirely reasonable. It surfaces months later when a corrosion pattern appears on the wrong side of a line and somebody investigates.

The preventable version of this is a short written convention statement agreed before mobilisation and reproduced on the deliverable itself. It should name the origin for station measurements on each line or vessel, state the direction of increasing station, define how clock position is referenced and from which viewpoint, state the elevation datum, and state the units. Half a page, agreed once per client per asset type, and it eliminates an entire class of silent error.

Reproducing the convention statement inside the deliverable matters as much as agreeing it. Data outlives the people who created it, and a file arriving at an integrity engineer's desk three years later with positions but no stated convention is guesswork. Contractors who embed the convention in every submission are protecting themselves as much as the client, because the party asked to explain an anomalous reading years later is usually the one who took it.

File formats: what to hand over alongside the report

The PDF report does not go away. It remains the certified, signed, human-readable record and clients still need it for their own quality file. What changes is that it is accompanied by a machine-readable file carrying the same results in structured form. Trying to replace the report with data, or to make the client parse the PDF, both fail — the first for compliance reasons and the second because PDF extraction is unreliable enough to be a liability.

For the structured file, follow the client's receiving system rather than a general preference. A defined CSV or Excel schema with agreed column names is entirely legitimate and is what most working programmes actually use; there is nothing unprofessional about it if the schema is agreed and stable. Where the modality and the client's archive support it, DICONDE per ASTM E2339 and the relevant modality practice is the stronger archival deliverable, particularly for radiographic and computed tomography work. Open instrument formats such as Evident's HDF5-based .nde also satisfy the portability requirement.

Include the native instrument files as well, and say so in the deliverable list. Clients increasingly want the raw acquisition data retained for re-analysis, and supplying it costs the contractor almost nothing while materially strengthening the handover. The format landscape across instrument vendors is uneven enough that it deserves its own treatment — /diconde-ndt-data-standards-digital-twin covers which standards apply per modality and where interoperability actually breaks between conforming systems.

Metadata that keeps a reading defensible three years later

A thickness reading with no procedure reference is a number. A thickness reading with the procedure number, the revision in force, the equipment used, its calibration status, the technician's name and their certification level at the time of examination is evidence. The difference matters at exactly the moment when it is impossible to recover — during a fitness-for-service assessment, a jurisdictional review, or an incident investigation, when the campaign is years past and the crew has moved on.

Capturing this structurally rather than in prose is a modest change to a field workflow and a substantial improvement to the deliverable. Procedure and revision come from your quality system and change rarely. Equipment identity and calibration status come from your asset register. Certification status comes from your personnel records. All three are already maintained; the work is connecting them to the result record automatically rather than transcribing them per report.

There is a commercial dimension worth noticing. Clients running integrity programmes under recognised codes are audited on exactly these records, and a contractor whose deliverables carry them in structured form removes work from the client's audit preparation. That is a differentiator that survives price comparison, because it changes what the client's own team has to do rather than what they pay. Our reporting and ERP work with service providers is built around capturing these fields once and reusing them — /consulting or info@atlantisndt.com if you want the workflow reviewed.

The handover specification: agree it before mobilisation, not after

The document that prevents almost all of the failures on this page is short and should be produced before a crew leaves. It states the identifier scheme and who issues it. It states the location referencing method per work type, with the datum and convention. It lists the deliverable files, their formats and their schemas. It lists the required metadata fields. It states the submission route and the window. It names the person at each end who accepts the deliverable.

Producing it is a contractor advantage rather than an overhead, because the party that drafts the specification defines what compliance means. A contractor who arrives at kick-off with a draft handover specification is demonstrating capability that competitors are not, and is simultaneously ensuring that the obligation is achievable with the workflow they actually have. Clients rarely refuse a well-drafted one, because it removes work from them.

Test it before it matters. Run three or four representative results through the whole chain during mobilisation — capture, export, submission, ingestion at the client end — and confirm they arrive correctly positioned and correctly identified. A one-day test at mobilisation is the difference between discovering a convention mismatch on day one and discovering it after a crew has demobilised, when every fix requires a return visit that somebody has to pay for.

What this costs a contractor, honestly

The cost is front-loaded and it is mostly setup rather than per-reading effort. Obtaining and loading the client's register, agreeing the referencing convention, defining the export schema and running the mobilisation test consume time before the campaign starts. Once that is done, the marginal cost per reading is close to zero if the identifier is selected from a loaded list rather than typed, which is why field data capture that holds the client register pays for itself on the first substantial campaign.

The cost rises sharply in two situations, and both are avoidable. Retrofitting identifiers to data already captured against contractor numbering requires manual matching, which is slow, error-prone and unbillable if the clause was in the original scope. And complying by transcription — technicians reading identifiers off a printed list and typing them onto a sheet — imposes a permanent per-reading overhead and introduces exactly the errors the exercise was meant to prevent.

The realistic planning position is that the first campaign for a given client carries genuine setup effort and the second carries almost none, because the register mapping, the convention and the export schema are reusable. Contractors who price the first campaign as though the overhead recurs every time will lose bids to those who understand it does not. Contractors who price it as though it is free will absorb the setup and resent the client.

Why twin-ready deliverables change what work you win

The commercial logic is straightforward once the technical work is done. Asset owners who have invested in a digital twin have a standing problem: most of their inspection supply chain cannot feed it. A contractor who can, without the client building an ingestion workaround, becomes materially easier to award work to and materially harder to displace at renewal. The switching cost is not the inspection — it is re-establishing the data chain with a new provider.

It also changes the conversation at bid stage. Price comparison between technically identical NDT scopes is brutal and rewards nobody. A bid that includes a draft handover specification, a sample structured deliverable and evidence of a completed ingestion test is not comparable to a bid that does not, and it moves the discussion away from unit rate toward what the client's integrity team will actually have to do afterwards. That is a better conversation to be in.

The requirement is spreading from major operators outward, because the specifications originate with owners running digital twin programmes and propagate through their contractor base. Building the capability once, against one demanding client, produces a reusable asset that qualifies you for the rest. If you want the handover specification and export schema reviewed against your current field workflow before your next bid, /contact or info@atlantisndt.com reaches our team directly.

Request a consultation