NDT Native Data Handover: What Buyers Should Specify and Test
Receiving a folder of inspection files does not establish that your team can use the underlying data. Agree the purpose, viewing environment and evidence of a successful handover before the examination package is delivered.
For: Asset owners, inspection buyers and technical reviewers receiving native NDT datasets
Define why the buyer needs native data
Start with the future activity the data must support. The owner may need an independent technical review, comparison with later examinations, investigation of a reported location or retention of the acquisition evidence. These purposes can require different files and supporting context. Asking for all raw data without explaining the use can produce a large delivery that still omits what the recipient needs.
Have the responsible technical reviewer identify the information necessary for that use. A procurement coordinator can organize the deliverables but should not decide which data are sufficient for a technical reassessment. Record the intended use in the RFQ and confirm that the provider understands it before agreeing the package.
Separate a present review need from a possible future ambition. If the owner hopes to compare data over many years, discuss the identity, location and access dependencies that make comparison possible. A current readable export may meet today's reporting need without supporting every future analysis the buyer imagines.
Distinguish native files, exports and issued reports
Define the terms used in the agreement. Native acquisition or analysis files may preserve information and functions associated with a particular application. An exported image or table presents a selected representation. An issued report communicates reviewed results within its stated scope. These objects can complement one another without being interchangeable.
Ask the provider to explain what each proposed deliverable contains and what it leaves out. A PDF can be useful for routine review while lacking the information needed to revisit an acquisition. Conversely, a native dataset without a clear report relationship may be difficult for an owner to interpret even when the file itself opens.
Keep the contractual description specific enough to avoid substitution by convenience. If the agreed scope includes a native package, a collection of screenshots should not silently replace it. If only a report is required, do not assume native data are included merely because the provider retains them internally.
Specify the complete package and its dependencies
Identify the files, setup information, component maps and other supporting records needed to open and understand the delivery. Native data may rely on companion directories or configuration files. The responsible application user should explain those relationships so the buyer does not receive only the most visible file from a larger working package.
Ask how the package will be assembled from the controlled source and whether its original folder structure must be preserved. Document any permitted renaming or packaging step. A delivery process that changes internal references can make the files unusable even though every expected filename appears in a manifest.
Include the relevant issue or revision references for the supporting documents. An old component map paired with current data can create an identity problem that a file-integrity check will not detect. The package needs a coherent relationship among its parts, not simply a complete list of unrelated attachments.
Establish the format basis without assuming universal compatibility
Ask which format will be supplied and what evidence describes its compatibility with the receiving environment. ASTM's public scope for E2339 describes DICONDE as an approach to interoperability and preservation of NDE image or signal information with relevant parameters [1]. That context supports asking about structured exchange, not assuming every file labeled DICONDE will behave identically in every application.
Where a standard exchange format is specified, have knowledgeable parties identify the applicable requirements and conformance information. This guide does not reproduce the standard or determine compliance. The buyer should obtain the appropriate technical review rather than treating a filename extension or marketing statement as sufficient evidence.
If the delivery remains proprietary, make that dependency explicit. A proprietary format may be appropriate to the agreed use, but the owner needs to understand the application, version and access arrangements required. The decision should be informed before the final handover, when replacing the deliverable may be difficult.
Confirm the receiving environment early
Identify who will open the data and what software or viewing capability they have. Ask whether the intended environment can access representative files with the needed functions. A supplier's successful demonstration on its own workstation does not establish that the owner's team can perform the agreed review after delivery.
Clarify any licensing, account, installation or support dependency through the authorized commercial and IT contacts. Do not assume the owner receives indefinite access because a viewer was available during the project. Record the terms and responsibilities that affect future use without inventing a guarantee about software availability.
Where the owner cannot currently open the native format, resolve the plan before relying on the deliverable. Options may include an agreed viewing arrangement or an additional export suitable for a defined purpose. The responsible technical reviewer should confirm which limitations remain and whether the arrangement meets the intended need.
Preserve component and location identity
Require a clear route from each delivered dataset to the physical component and examination record it represents. Include the relevant identifiers, location references and relationships to the report. Data that cannot be placed reliably on the asset may have limited value for comparison or follow-up, regardless of the sophistication of the acquisition system.
Check how the package represents repeated examinations, multiple scan segments or several datasets associated with one component. Avoid forcing complex relationships into a single ambiguous filename. A manifest and component map can preserve the relationships while allowing each file to retain its necessary native structure.
NIST's work on integrating design, manufacturing and inspection information illustrates the importance and difficulty of maintaining information connections [2]. For this handover, the original editorial recommendation is to test those connections directly. Do not infer that a shared project name establishes a reliable relationship between every file and the correct asset.
Explain processing and export history
Ask the provider to distinguish acquired data from processed or selected outputs relevant to the delivery. Record the information needed to understand how the displayed or exported result relates to the source. The appropriate detail depends on the method and intended use, and should be established by qualified technical personnel.
If files are converted for exchange, identify the conversion and any known limitations. A receiving team should know whether it is looking at the original native object, a converted representation or an image of a selected view. These distinctions affect what later reviewers can reasonably conclude from the package.
Preserve the source-to-export relationship without requiring unnecessary duplication of private working material. The goal is enough provenance to understand the delivered record, not an indiscriminate copy of every temporary file on the provider's workstation. Agree the relevant boundary and document any excluded material that affects the intended use.
Agree access and permitted use
Identify the owner of the delivered records and the parties permitted to access them under the agreement. Clarify whether an independent reviewer, future service provider or internal analytics team may receive the data for the intended purpose. Do not assume that possession of a file resolves every contractual or intellectual-property question associated with its use.
Use the authorized commercial process to establish those terms and obtain suitable advice where needed. A technical handover checklist should record the agreed arrangement, not invent legal rights. Keep confidential project information within the approved distribution and storage environment while allowing the legitimate review workflow to function.
Ask what happens when the project ends or the supplier relationship changes. The owner needs a usable route to the agreed records and enough context to interpret them. An undocumented dependency on a former project contact can make a nominally complete delivery difficult to use when a later question arises.
Test a representative package before final delivery
Select a small package that represents the actual data types and relationships expected in the final handover. Have the provider assemble it through the planned process and the recipient open it in the intended environment. This tests the handover workflow rather than only the supplier's ability to display its own working files.
Ask the recipient to locate a component, find its associated report entry and identify the relevant dataset. Include a case with more than one file or an exception in the mapping. Record where additional explanation is needed and update the package instructions or requirements before the full delivery is prepared.
Keep the trial's limitations visible. A successful example does not establish that every later file is complete or technically valid. It provides evidence that the proposed packaging and access arrangements can support the defined use, subject to the final package checks and qualified technical review.
Reconcile delivery against the agreed manifest
At final receipt, compare the delivered package with the manifest and scope. Confirm identities, expected files and relevant revisions. Record missing, unexpected or inaccessible items separately so the sender can address a specific issue rather than respond to a general statement that the data do not work.
Use the agreed integrity checks where applicable, while keeping their meaning precise. Matching a reference checksum can support confidence that a file transferred unchanged. It does not show that the correct component was acquired, that the examination met its requirements or that the selected file is the technically approved one.
Document receipt, usability review and technical review as separate stages. Different people may be responsible for them, and each stage may produce its own exceptions. A delivery acknowledgment should not become an unintended statement that the examination results or every contractual obligation have been accepted.
Work through a fictional viewer mismatch
Consider a fictional asset owner receiving native ultrasonic data and a PDF report. The supplier demonstrates the files successfully in its analysis application. During the agreed recipient test, the owner's viewer opens the files but does not expose the location relationship needed to connect the data to the component map.
The parties record the limitation and ask the technical reviewer what additional information or viewing capability is required for the intended future review. The supplier provides an agreed mapping export and clarifies the remaining native-software dependency. The buyer then assesses the revised package against the original purpose instead of treating the initial file-opening success as complete handover.
This example is fictional and does not describe a particular product's capabilities. Its lesson is that opening a file is only one part of usability. The recipient must be able to perform the agreed task with the information and functions actually available in the receiving environment.
Use the worksheet to assign unresolved handover actions
For each exception, record the affected file or relationship, the intended use that is blocked and the responsible owner. Distinguish a missing delivery item from a recipient-environment issue or a technical interpretation question. This classification helps route the action without assuming that every problem belongs to the provider or every problem belongs to IT.
Set the closure evidence before marking the item resolved. A missing map may require a revised package and a successful trace, while an application issue may require the authorized recipient to demonstrate access. A message saying fixed is less useful than a record showing the behavior that now works.
Carry any accepted limitation into the final handover summary. If the owner agrees to receive a package that supports only a narrower use, state that scope explicitly. The limitation should remain visible to future users who were not part of the discussion and might otherwise assume the data support a broader analysis.
Preserve the received package during later review
When a qualified reviewer later works with the data, distinguish the received package from any working copy or new analysis output. The original delivery should remain identifiable so another person can understand what the supplier supplied and what the later reviewer changed or added. Follow the organization's approved controls for creating and retaining those versions.
If the later review identifies a discrepancy, record its relationship to the original report and route it through the responsible technical and document-control process. Do not silently edit the historical package to reflect a new interpretation. A subsequent conclusion may be important, but its author, evidence and date need to remain distinguishable from the earlier issued result.
The handover agreement should make this future workflow possible without implying that every recipient is authorized to reinterpret the examination. Access to data and authority to make a technical decision are separate matters.
Maintain access beyond the handover meeting
Assign an owner for storage, access and periodic usability review according to the organization's record requirements. Preserve the manifest, viewing instructions and relevant software context with the package. A folder of data separated from its interpretation guide may become difficult to use even if the underlying files remain intact.
Consider changes that should trigger another access check, such as a new workstation environment, application update or migration to another archive. Coordinate those checks with the responsible IT and technical teams. The purpose is to identify loss of usability before a time-sensitive review depends on the historical package.
NDT Connect does not host native inspection data or provide a long-term viewing guarantee through its service marketplace. Agree these arrangements directly with the provider and record owner. A successful handover leaves the recipient with identifiable, usable evidence for a defined purpose, clear responsibility for remaining limitations and a practical plan for retaining the information needed to use it later.
Frequently Asked Questions
Is a screenshot equivalent to native inspection data?
No. A screenshot records a particular display. It may omit data, metadata or interactions needed for later review. Specify the deliverable appropriate to the intended use.
Does a standard format guarantee every receiving system can use the file?
No. Confirm the applicable format and conformance information, then test representative delivery files in the intended receiving environment.
Does successful data handover approve the examination result?
No. Transfer, usability and technical review are separate activities with different evidence and responsible personnel.
References & Standards Cited
- ASTM International, E2339 Standard Practice for Digital Imaging and Communication in Nondestructive Evaluation: public scope. Accessed October 31, 2026. View source ↗
- NIST, Defining the Requirements for Integrating Information between Design, Manufacturing, and Inspection. Accessed October 31, 2026. View source ↗
Related on NDT Connect
Join NDT Connect — free
The free marketplace for the NDT industry — connect inspectors and the companies that need them.
Free to join · Compare provider qualifications and confirm availability directly · Browse providers
By NDT Connect Editorial · Updated
Source-based editorial guidance. Read our editorial policy and disclosures.