Remote NDT Data Review: Scope, Access and Evidence

Define the review question before transferring files

Remote review can mean checking a report for completeness, interpreting a defined dataset, providing a second technical opinion or reviewing whether a submitted package meets stated project requirements. These are different services. Write the requested question in a form that the reviewer can answer without guessing the buyer's intention. Identify the decision that will use the answer and the person responsible for that decision.

Do not describe the task merely as approve these files. Approval may have a specific meaning under a contract, procedure or qualification system. Confirm whether the reviewer has the necessary role and authority for that action. If the intended result is advisory, say so in the engagement and the final record rather than allowing recipients to infer a broader authorization.

Map responsibilities across the review chain

Identify who acquired the data, who performed the original interpretation, who is conducting the remote review and who releases the final report. One person may hold more than one role, but the responsibilities should still be distinguishable. Record which organization controls the technical instructions and who can resolve questions about their application.

A remote reviewer cannot reconstruct every field condition from a data file. The acquisition team remains an essential source of context about identification, coverage and limitations. Agree how the reviewer can contact that team and how answers become part of the controlled review record. A verbal explanation that materially changes the interpretation should not disappear when the call ends.

Establish the dataset boundary

List the examination events and locations included in the review. Link each to the relevant asset or component identity, acquisition date and file set. A folder name alone may be ambiguous if it contains exports from several jobs or revisions. Use a manifest that makes included, superseded and excluded files distinguishable.

Freeze the review input at an identifiable version. If the acquisition team adds files while review is underway, record the addition and ask the reviewer to confirm whether it changes the agreed scope or completion timing. A moving dataset makes it difficult to demonstrate what the reviewer actually examined when issuing an opinion.

Ask for context as well as images

The useful review package may include controlled instructions, drawings, examination location references, acquisition settings and relevant checking records. The exact requirements depend on the method and the assigned task, so the qualified reviewer should define them. This guide provides no universal technical checklist or acceptance threshold.

Explain the known limitations of the acquisition. Missing coverage, uncertain identification or an unresolved field question should be visible before the reviewer begins. Do not hide these details in a general comments file that is separate from the dataset. Place a clear reference in the package index so that the reviewer can decide whether the available evidence supports the requested work.

Preserve the original data separately

Keep the original delivered files unchanged and use controlled working copies for review activities. Record any conversion, annotation or processing applied to those copies. The purpose is to preserve the ability to distinguish acquired evidence from later analysis and presentation. A revised filename should not be the only indication that a file has been altered.

If the software saves changes automatically, understand that behavior before opening the only available copy. Ask the data owner or system administrator to establish an appropriate working arrangement. The reviewer needs enough freedom to perform the authorized analysis without making the historical input ambiguous. Any derived output should retain a clear relationship to its source files.

Test interoperability with a representative package

The public scope of ASTM E2339 describes DICONDE as supporting interoperability of NDE imaging and acquisition equipment. That stated purpose does not prove that a particular export and viewer combination will preserve every feature needed for a specific review. [2]

Test a representative authorized package before scheduling the full review. Confirm that identifiers, relevant data and expected functions are available in the receiving environment. Have the technical reviewer assess usability rather than treating a successful file open as sufficient. Record software versions and any conversion steps so that later changes can be evaluated against a known working arrangement.

Check the viewer against the assigned task

A presentation viewer may display a result while lacking the tools required for the requested analysis. Ask the reviewer what functions are necessary and verify that the available software provides them. Do not assume that a vendor's free viewer, a PDF export and the acquisition workstation are interchangeable.

Clarify licensing, access duration and support before the review starts. A temporary license expiring during a technical query can interrupt the service even when the files remain available. If the reviewer will use a different version from the acquiring team, include that difference in the compatibility trial. The goal is to establish a usable review environment, not to recommend a particular product.

Use approved access arrangements

NIST's remote access guidance discusses securing the components used for remote work and establishing appropriate security policies. It is general information security guidance, not an NDT qualification standard. [1] Apply it through the organization's authorized IT and data-sharing arrangements rather than improvising a connection during a deadline crisis.

Define who may access the package, what they may download or change and when access ends. Use individual identities where the approved system supports them, and avoid sharing a colleague's account to bypass an access delay. The technical review plan should acknowledge security constraints early enough that they do not become a reason to use an uncontrolled transfer route later.

Distinguish file review from live screen sharing

A live screen-sharing session can help participants explain the dataset, point to a location or discuss a question. It does not automatically provide the same evidence or independence as direct access to the relevant files. Image quality, navigation control and the ability to revisit information may differ.

Agree what role the session serves. It might be an orientation call, a collaborative technical discussion or part of a defined review process. Record important decisions separately from the meeting invitation. If the reviewer cannot inspect information needed for the assigned conclusion, identify the limitation and request an appropriate route to the evidence instead of treating attendance on the call as completion.

Worked example: a screenshot package is insufficient

In a fictional assignment, an asset owner asks a remote specialist to review selected screenshots from a prior examination. The specialist can understand the reported locations but cannot assess the full question using those images alone. The request originally described the task as independent verification, which implies more than the available package can support.

The parties revise the scope. They either provide the necessary authorized dataset and context or limit the engagement to a clearly described review of the submitted presentation material. The resulting record names the limitation. The example illustrates a scope decision, not a technical conclusion about any real component or a rule that all remote work requires the same file format.

Give information gaps a controlled status

Maintain a short register of missing or contradictory information. Each entry should identify the affected part of the review, the question, the responsible contact and the response needed. Distinguish a minor administrative clarification from an issue that prevents the reviewer from completing the requested technical assessment.

Do not force every open item into a generic pending category. The buyer needs to know whether work can continue on unaffected areas, whether the final conclusion must remain limited or whether new acquisition may be required. Those judgments belong to the responsible technical parties. Record their decision and the evidence supporting closure of the question.

Plan communication across time zones

Remote services can create a misleading impression of continuous availability. Agree working windows, expected acknowledgement arrangements and the person who covers urgent questions. Use explicit time zones for review meetings and delivery milestones. A deadline stated only as end of day can create an avoidable disagreement.

Prepare questions in a form that the acquisition team can answer efficiently. Include the file identifier, location reference and a concise description of the issue. Avoid sending a long sequence of disconnected screenshots through several channels. Consolidating related questions reduces the chance that an answer is applied to the wrong dataset or lost outside the final review record.

Handle differing interpretations openly

If the original interpreter and remote reviewer disagree, preserve both positions with their stated basis and the affected records. Follow the project's defined technical escalation route. Do not ask a third person simply to choose the more convenient answer or treat a majority vote as a substitute for the applicable requirements.

The resolution may require additional context, further review or additional examination. Record who has authority to decide the next step and how the final disposition is communicated. A disagreement is not automatically evidence of poor performance. The important question is whether the process can expose uncertainty and resolve it through qualified, documented review.

Define the remote review deliverable

Specify whether the output is a review memorandum, marked comments, a revised report or another controlled record. Require it to identify the input package, review purpose, responsible reviewer, date and stated limitations. The precise technical contents should be agreed with the qualified parties and applicable project requirements.

Separate observations from decisions. A reviewer may identify a discrepancy without having authority to approve the corrective action. Likewise, a report amendment may require release by the original issuing organization. The deliverable should make these boundaries clear enough that a later recipient does not assume that every comment is a final disposition.

Preserve review traceability without excessive copying

Keep references to the files and versions examined, the significant questions raised and the decisions made. Avoid creating multiple uncontrolled copies of sensitive datasets merely to demonstrate that a review occurred. Use the approved repository and retention arrangements, with the review record pointing to the controlled evidence.

Where annotations are exported, label them as derived review material and preserve their source relationship. If a recipient prints or downloads a review memorandum, its identifiers should still allow the organization to find the corresponding dataset. Traceability depends on stable relationships between records, not on putting every possible attachment into every email.

Confirm what happens when access ends

At completion, review outstanding questions before removing access. Confirm which working files may be retained, which must be returned or deleted under the agreement and who can provide future clarification. Coordinate the end of access with IT and the data owner rather than leaving a temporary account active indefinitely.

Do not promise that every copy has been destroyed unless the organization has evidence for that claim. Follow the actual retention and contractual requirements. If the final report may need later correction, preserve an authorized route to the necessary source evidence. Closing a review session should not make the underlying technical record impossible to reconstruct.

Use the worksheet for a readiness meeting

Complete the worksheet jointly with the buyer, reviewer and data owner. Begin with the review question and authority rows, then test the dataset and viewer readiness. Assign an owner to each unresolved field. A blank software or access row is a planning gap even if the reviewer has excellent technical credentials.

Use a small sample package during the meeting if sharing is authorized. Ask the reviewer to locate a specified item and explain which records support the assigned task. This exercise tests the arrangement rather than the actual component. Keep the outcome with the engagement records and revise the plan before transferring the full dataset.

Test recovery from an interrupted review

Discuss what happens if the connection fails, the viewer becomes unavailable or the source package must be replaced. The reviewer should be able to identify the last completed portion and the input version used. An interrupted session should not require guessing which files were already considered or treating an unfinished screen recording as the review record.

Agree a pause and restart convention appropriate to the engagement. Record whether annotations have been saved, whether new files arrived during the interruption and whether the reviewer needs to repeat any work after a software or dataset change. This is particularly useful when the review spans several short working windows.

If the interruption prevents the agreed delivery date, communicate that fact through the engagement coordinator. A technical reviewer should not have to choose between silently missing a deadline and issuing a conclusion before the assigned work is complete. The owner can then decide how the delay affects its own planning.

Judge completion by the agreed review scope

A remote review is complete when the agreed work and deliverable are finished, or when the parties formally record why the requested conclusion cannot be supported. File transfer, meeting attendance and software access are milestones toward that result. None alone establishes that the technical question has been answered.

NDT Connect can help with provider discovery and service enquiries, but this guide does not describe a built-in native-data archive or remote review workstation. Establish the review environment and engagement directly with the selected provider. The useful outcome is a traceable, appropriately limited technical record that the authorized decision maker can understand and use.