NDT Data File Manifest: Make an Inspection Handover Traceable

Define the handover question

A useful manifest allows the recipient to answer three questions: what was delivered, what each file represents and whether the package is usable for its agreed purpose. Those questions are narrower than technical acceptance of the examination. Keeping the distinction clear prevents a successful file transfer from being described as approval of the underlying inspection results.

Start by identifying the intended recipient and use. A document-control team may need the released report and attachment list, while a qualified analyst may also need native acquisition data and the relevant setup information. An asset owner planning future comparison may require stable component references and information about how positions were recorded. The manifest should support those actual needs rather than collect every field a spreadsheet can hold.

The National Archives describes technical manifests containing file identifiers, names, formats and other metadata [1]. The workflow here adapts that general record-management idea to an inspection handover; it does not make archival transfer rules mandatory for private NDT projects.

Establish the package boundary

Assign the handover package an identifier, issue date, revision and responsible sender. Describe the examination scope covered by the delivery and any exclusions. A package might concern one component, a defined production lot or a stated examination period. The recipient should not have to infer the boundary from the number of files in a folder.

Record the deliverable requirement that the package is intended to satisfy. If the contract asks for reports and native data, identify both categories. If a category is not included, explain whether it is outside scope, pending or unavailable. A blank folder named raw data can otherwise be mistaken for evidence that no such data existed.

Keep staged deliveries distinguishable. A preliminary package, a corrected report package and a final closeout package may contain some of the same files. Give each delivery its own revision or transaction reference and describe its relationship to earlier deliveries. Reusing one folder name without a delivery record makes it difficult to establish what the recipient actually received.

Give every file a stable identity

Record a file identifier and its exact delivered filename or relative path. The identifier should remain useful if the package is moved to a different storage location. Avoid using a temporary download link as the only identity, because the link may expire or depend on an individual account that later closes.

Add a plain-language role for the file: released report, acquisition dataset, setup file, location map, supporting image or another defined category. A filename extension alone rarely explains that role. Two files with the same extension can contain very different information, while a single compressed archive may contain several categories requiring separate review.

Preserve the original source filename where renaming is necessary. Record the delivered name and its relationship to the source rather than silently replacing it. This is particularly important when acquisition software creates internal references between files. A tidy naming convention is not an improvement if it breaks the software's ability to open the dataset.

Connect files to components and examination records

For each item, identify the component, weld, grid area or examination segment it represents. Use the same controlled identifiers as the examination map and report. If one file covers several components, record the mapping explicitly or reference a separate relationship table. Do not force a many-component dataset into a misleading single-component field.

Include the relevant report, technique and examination-date references where they help establish context. Distinguish the date of examination, the date a file was exported and the date it was delivered. These events may be different, especially when analysis and reporting occur after acquisition. A generic date column can hide that difference and confuse later reconstruction.

NIST's research on linking design, manufacturing and inspection information illustrates that lifecycle connections require deliberate integration work [2]. In a practical handover, stable identifiers and explicit relationships are the starting point. A large quantity of files does not establish a usable information chain if their component references cannot be reconciled.

Record format and access dependencies

Identify the file format and, where material to use, the software or version needed to read it. Distinguish a native acquisition file from an exported image or summary. A screenshot may help explain an interpretation but may not preserve the information needed for independent analysis. Agree on the intended deliverables rather than assuming these formats are interchangeable.

Record any access dependency that the recipient must arrange, such as a compatible viewer, a documented import process or an authorized account. Do not place passwords or license keys in the manifest. Identify the responsible contact and approved access process instead. The recipient needs enough information to plan access without receiving unnecessary secrets in a broadly shared index.

Test a representative file in the recipient's intended environment before a large final delivery when practical. Document the outcome and any limitation. Being able to open a file on the sender's workstation does not demonstrate that the receiving team can read it after transfer or after the original project personnel leave.

Check transfer integrity separately from technical validity

Record file size and, where the handover process uses one, a checksum generated through an agreed method. Preserve the source value and the recipient's comparison result. These checks can help identify missing, changed or incomplete transfers. They do not establish that the original examination, calibration or interpretation was technically valid.

Use a defined exception process for mismatches. Identify the affected file, retain the observed result and request a replacement or explanation. Avoid overwriting the only received copy while investigating; it may be needed to understand what happened. Mark the package as incomplete until the relevant discrepancy is resolved through the agreed handover review.

Also check the file count and expected relationships. Every expected file can arrive intact while a required component is absent from the package. Conversely, an extra file may be a legitimate supporting record rather than an error. The manifest review must reconcile content against the stated delivery scope, not just compare byte counts.

Preserve versions and supersession

Record each file's revision or issue status where one exists. Distinguish draft, issued, corrected and superseded records using the project's controlled terminology. If a source file has no internal revision field, do not invent one that appears to come from the acquisition system. Use a package-level version or a documented local identifier instead.

When a corrected report replaces an earlier issue, identify the superseded file and the reason for the change. Keep the supporting data relationship clear. A report correction may leave acquisition data unchanged, or it may follow reanalysis that introduces new supporting files. The manifest should show which situation applies rather than treating every correction as a complete new examination.

Do not delete earlier versions merely to make a delivery folder look clean. The responsible record owner should determine retention and supersession handling under the contract and quality system. The manifest can point to the current issue while retaining the historical relationship needed to reconstruct earlier decisions.

Work through a fictional delivery

Consider a fictional inspection package containing a released PDF report, several native scan files, a setup file and a component map. The sender initially lists only filenames. The recipient can open the PDF but cannot determine which scan corresponds to one reported indication, and the setup file appears to belong to a different examination date.

The sender adds stable file identifiers, component-segment references and the relationship between the setup and acquisition files. A discrepancy remains on one dataset, so that item is marked unresolved rather than silently matched to the nearest filename. The recipient records which files opened successfully and which require clarification.

The package becomes reviewable because the relationships and exceptions are visible. This example does not claim a measured reduction in review time or an improvement in technical detection. Its evidence is the completed mapping and the documented exception, both of which another reviewer can inspect without relying on the sender's memory.

Assign sender and recipient responsibilities

The sender should prepare the manifest from the actual delivered package and check that references resolve. The recipient should confirm receipt, access and scope reconciliation according to the agreed review plan. These roles may be performed by different people from those authorized to interpret examination data or approve a final technical disposition.

Give discrepancies a clear owner and response route. A document controller may resolve a missing attachment, while a qualified examiner may need to clarify the relationship between a dataset and its setup. Routing every question to a generic project mailbox can delay resolution and make it unclear who is authorized to answer.

Record the handover status precisely. Received, readable, complete for administrative purposes and technically reviewed are different states. Avoid a single accepted checkbox that conceals which checks were actually performed. A recipient's acknowledgment should not imply approval beyond the scope of that person's responsibility.

Test one record from report to underlying file

Select a representative entry and trace it from the issued report through the component reference to the delivered file. Confirm that the path identifies the intended data rather than merely a folder with a similar name. Ask a recipient who did not prepare the package to perform the same exercise using only the supplied manifest and agreed viewing environment.

Record where the recipient needs additional explanation. A package may be technically complete yet depend on a sender's private naming convention or memory of the acquisition sequence. Add the missing relationship to the manifest or its supporting guide so the next person can follow the same path without a separate conversation.

Repeat the check for an exception, such as a component with several associated files or a file covering multiple locations. These relationships often reveal weaknesses that a simple one-report-to-one-file example misses. The test should confirm that the manifest can describe the actual package structure, including legitimate complexity, rather than force every record into an inaccurate simple pattern.

Use the worksheet to record exceptions explicitly

When a required file is missing, create an exception tied to the relevant manifest entry. State what is absent, who is responsible for obtaining it and how the omission affects the agreed use of the package. Avoid leaving an empty cell that a recipient may interpret as not applicable when the information is actually outstanding.

Distinguish unavailable, intentionally excluded and not required. A raw dataset may be outside the agreed deliverables, while a required component map may be temporarily unavailable. These are different conditions and should not share an unexplained missing label. The receiving authority needs enough context to decide whether the handover can proceed with a documented limitation.

If a later delivery closes an exception, issue a traceable update rather than silently inserting the file into a previously received folder. Identify the added item, its relationship to the earlier package and any manifest revision. This allows the recipient to reconcile the amendment and prevents two users from holding different packages under an identical issue label.

Distinguish package receipt from technical acceptance

A recipient may confirm that files arrived before checking their content or opening native data. Record those stages separately. Delivery confirmation, file-integrity checks, usability review and technical acceptance answer different questions. A single received checkbox can become misleading if it is later cited as evidence that every technical and contractual requirement was satisfied.

Consider a fictional handover containing all listed filenames. The recipient confirms the transfer, then discovers that an exported table lacks the component column needed to relate rows to the report. The manifest helped establish what arrived, but the usability review identifies a missing relationship. The sender must correct or supplement the export through the agreed process.

The final record should show both the successful transfer and the subsequent exception. Do not erase the first event or pretend it established more than it did. A clear sequence supports an accurate handover history and helps the parties identify whether the problem arose in package preparation, transfer or interpretation.

Agree which person can close each review stage and what evidence they need. An administrator may reconcile file counts, while a qualified reviewer determines whether the technical deliverables meet the agreed scope. The manifest can support both activities without conferring technical approval authority on whoever prepared the spreadsheet or clicked the receipt acknowledgment.

Keep the manifest useful after project closeout

Store the manifest with the controlled package and preserve a stable route to the underlying files. Test whether a colleague who did not participate in the project can locate a sample component, open the relevant records and explain the version relationships. That exercise reveals weaknesses that a sender familiar with the folder structure may overlook.

Include the required handover contents in the inspection service request before award. NDT Connect can help communicate the requested work and deliverables, but the portal is not represented here as a native inspection-data repository or a long-term archive. Agree on the actual transfer and storage arrangements with the service provider and record owner.

Review the manifest when storage locations, access controls or viewing software change. A file that was readable at delivery can become difficult to use later if its dependencies are lost. The useful completion point is a package whose identity, relationships, access requirements and unresolved questions remain understandable to the next authorized reviewer.