FMC and TFM Data Retention: What Buyers Must Specify
A TFM image on an instrument screen does not establish that the underlying elementary signals will be retained for later reconstruction. Define the required data object and future review task before treating FMC or TFM capability as a complete deliverable.
For: U.S. NDT equipment coordinators, quality staff and inspection business owners
Start with the later task that makes retention worthwhile
Identify what the organization expects to do after acquisition. It may need to review the issued image, revisit an approved analysis, reconstruct an image from retained elementary signals or develop a new analysis approach in a research setting. These are different uses with different data and software dependencies. The technical authority should decide which use is required, while purchasing and data staff determine what must be supplied and maintained to support it.
Avoid requesting all raw data without a definition. Different people may use raw to mean a native acquisition file, elementary signals, an unannotated image or a vendor-specific project. Write the intended object and the required function in plain language. For example, a hypothetical research requirement might call for access to the retained elementary signals needed by an approved reconstruction exercise. A routine reporting requirement might instead need a reviewed native dataset and the issued report.
Record who will perform the future task and in what environment. A customer with an existing supported analysis application has different needs from a research group building its own reader. A promise of later flexibility is weak if nobody owns the software, expertise and evidence needed to use it. The purchase decision should include those responsibilities rather than treating file retention as an isolated storage purchase.
Distinguish acquisition, reconstruction and presentation
FMC is an acquisition approach involving signals from transmit and receive element combinations, while TFM is an image reconstruction approach. A historical ISO committee explanation describes that distinction. The source is background published in 2019, not a statement of current standard requirements. Use the distinction to ask precise questions about what the system acquires, processes and actually saves.
A rendered screenshot, a retained reconstructed dataset and retained elementary signals are different objects. They may all have a place in an inspection package, but they do not provide identical later functions. A screenshot preserves a selected presentation. A native file's capabilities depend on its contents and supported application. Elementary signals may enable additional processing when the required metadata and software are available, but their presence alone does not validate a new reconstruction.
Do not infer retention from a technique label. A system can display a TFM result while the purchased configuration or chosen workflow saves a different set of objects than the buyer expects. Ask the supplier to identify the retained data explicitly and demonstrate the required later task from a saved file. The answer should be tied to the actual model, options, software version and acquisition configuration being evaluated.
Ask for configuration-specific evidence of raw data access
Manufacturer examples show why the complete configuration matters. Eddyfi's Emerald page distinguishes acquisition features, real-time processing and raw FMC saving. Evident's March 2025 acquisition article describes raw FMC access for a specified OmniScan X4 configuration with additional application and development requirements. These examples support asking about dependencies; they do not justify assuming every instrument in either family has the same capability.
Ask the supplier for a written configuration statement that identifies the exact retained object, required options and supported access method. Include any external computer, application, interface or development work needed to obtain it. If the capability is described as available through an API, clarify whether the supplier provides a supported end-user workflow or whether the buyer must develop and maintain software. Those are materially different ownership commitments.
Keep future or custom capabilities separate from demonstrated delivery. A vendor may be willing to support a development project, which can be valuable, but it should not be represented as a ready-to-use feature without evidence. Record the remaining development tasks, acceptance responsibility and support boundary. The buyer can then decide whether it is purchasing an operational package, a research platform or a combination with clearly defined limits.
Define a retained-data schedule before the demonstration
Create a schedule with one row for each required object: acquisition file, elementary data where required, reconstruction settings, relevant configuration metadata, analysis project, issued images and report. The technical owner determines what belongs in the list. The coordinator records who creates each object, how it is identified and which later task depends on it. This prevents an impressive display from masking a missing dependency in the deliverable.
For each object, state whether it is generated automatically, saved through a supported user action, exported through another application or produced by custom development. Ask the supplier to confirm which workflow is included in the quotation. A data access capability that requires additional software is not equivalent to a standard saved output. The schedule should make that difference visible before the organization promises a deliverable to its customer.
Include the relationship among the objects. A reconstruction record should identify its source data, and an issued image should be traceable to the reviewed analysis that produced it. The exact metadata depends on the approved application and software. Avoid inventing a universal list of acquisition settings here; instead, have the responsible technical personnel identify the information required to reproduce or explain the agreed review task.
Demonstrate the future task from saved evidence
Ask for a controlled, authorized sample generated using the proposed configuration. After saving the required data, close the acquisition session and perform the intended later task in the receiving environment. The technical reviewer should define the acceptance criteria. The buyer's role is to verify that the task is possible with the retained package and purchased dependencies, rather than relying on a live demonstration that may still use information held only in memory.
Record exactly what was reopened and which application performed the task. If the demonstration uses an additional supplier workstation, license or unpublished tool, identify that dependency. A successful vendor demonstration can establish feasibility while leaving a gap in the buyer's delivered workflow. The gap should become a clear action or accepted limitation, not an assumption that the same function will appear automatically on the organization's own computer.
Keep the demonstration source unchanged and retain the resulting evidence separately. If the supplier supplies a replacement dataset after a problem, record why it changed and which acceptance cases were repeated. This preserves the meaning of the test. A later reviewer should be able to distinguish a corrected software workflow from a different sample that no longer exercises the original requirement.
Distinguish supported review from custom reconstruction development
A supported analysis application provides a defined set of functions within its documented scope. Custom reconstruction work adds responsibilities for implementation, interpretation and verification. The organization should decide which category its intended use falls into before purchasing on the basis of raw data access. The presence of readable arrays does not establish a validated analysis application or authorize a new inspection conclusion.
For custom development, identify the owner of the data model, relevant units, coordinate relationships and processing assumptions. Have qualified technical personnel define the evidence needed to establish correct interpretation. The open file portability guide explains why opening a container and understanding its inspection meaning are separate achievements. This article adds a further distinction: even correctly read elementary data require an appropriately evaluated reconstruction workflow.
Do not promote an experimental result directly into an issued inspection report because it looks plausible. Keep research or development outputs labeled according to their status and subject them to the organization's applicable validation and authorization process. Purchasing can support that process by obtaining the required data access and documentation, but it cannot replace the technical work needed to establish a new analytical capability.
Plan storage from representative retained objects
Measure a representative demonstration package rather than estimating storage from the final report size. The objects retained for reconstruction may be substantially different from a selected image or summary table. Record the observed package size, the configuration represented and the assumptions used in planning. Do not extrapolate one sample into a universal data volume for every probe, acquisition arrangement or inspection job.
Include working copies, reviewed outputs and recovery copies in the storage plan where the organization's policy requires them. Identify which objects are authoritative and which can be recreated. This helps avoid retaining many indistinguishable copies while accidentally omitting a small metadata file essential to interpretation. The data owner should review the plan with the technical owner so storage convenience does not silently determine the inspection evidence retained.
Ask about transfer and recovery as well as capacity. A dataset that fits on a drive may still be difficult to deliver within the agreed workflow or reopen after a workstation failure. Use an approved test copy to demonstrate retrieval in the intended environment. Record any dependency on a network location, application configuration or license service. The purpose is a realistic ownership plan, not an unsupported promise of unlimited storage or access.
Preserve processing choices without overwriting the source
A later reconstruction or analysis may produce a useful derivative, but it should remain connected to the source and its processing context. Define how the organization names and stores the derivative so it does not replace the original merely because it is newer or more visually useful. The technical reviewer determines what processing information must be retained to understand the result and whether it is suitable for the intended decision.
If several reconstructions are compared, identify each one clearly. A comparison should not rely on a sequence of screenshots whose settings and source relationships are undocumented. The reader needs to know which outputs belong to the approved analysis and which are exploratory. This distinction is especially important when a research team and an operational inspection team share the same data but have different authority to issue conclusions.
Treat an amended result as a controlled record change under the organization's process. Retaining elementary data does not eliminate the need to preserve the issued report and its revision history. The source may support a new review, but the organization still needs to explain what changed, who approved it and which customer-facing record is current. Data richness and document control solve different problems.
Clarify customer rights and software responsibilities
Agree what the customer is entitled to receive and what function the delivery must support. A contract may require source data, a native project, an issued report or several objects together. Define those terms before acquisition. If a customer expects independent reconstruction, confirm that the proposed package includes the necessary data and an understood access arrangement rather than assuming that delivery of a large native file satisfies the expectation.
Discuss the receiving software honestly. The customer may need a licensed application, a supported viewer or specialist development work. Record who supplies and maintains it and what limitations apply. Do not promise that an open or documented format eliminates every dependency. The buyer should be able to distinguish access to the stored information from access to the supplier's full analysis functionality.
Keep confidentiality and permission requirements connected to the chosen transfer method. Use the organization's approved sharing arrangements for real inspection data and a sanitized sample for purchasing demonstrations. This is a practical information ownership issue, not a reason to collect unnecessary customer material. The acceptance exercise needs enough representative structure to test the workflow without exposing unrelated project records.
Compare two hypothetical retention proposals
A fictional engineering group requests the ability to conduct a defined later reconstruction study. Proposal A includes saved reconstructed data and report images. Proposal B includes a documented elementary data export plus the required interface support. The group records these as different deliverables even though both proposals advertise TFM capability. It asks the technical owner which proposal meets the study requirement and what additional development or validation remains necessary.
During the hypothetical demonstration, Proposal B's sample can be read, but a coordinate relationship required by the study is not yet documented. The team records the access test as successful and the interpretation test as unresolved. It does not approve the complete requirement simply because the arrays are visible. This example illustrates an evidence distinction, not a defect or performance claim about a named manufacturer.
The final purchase decision may select either proposal depending on the actual need. If the organization only requires a supported review of the approved reconstruction, Proposal A may be sufficient after appropriate evaluation. If the defined research task requires elementary signals, a narrower retained object may be insufficient. The important point is that the decision explains the chosen capability and dependencies without treating all advanced UT files as interchangeable.
Keep the accepted capability tied to the instrument record
Record the exact hardware configuration, software version, relevant options and accepted retention workflow in the equipment history. Link to the demonstration package and the owner of future compatibility reviews. When software or hardware changes, determine which acceptance cases need to be repeated. The software change record provides a place to organize that administrative review without claiming that every update automatically invalidates prior evidence.
NDT Connect can hold the instrument's identity, due date, status and a note referring to the accepted configuration record. It does not store FMC datasets, reconstruct TFM images or validate software. Keep the source data and technical acceptance evidence in the organization's selected controlled systems. The equipment register helps staff locate the decision; it does not perform the decision or enforce its conditions automatically.
Before describing the package to a customer, use the precise retained-data language from the acceptance record. State whether the deliverable is a rendered image, supported native dataset, elementary signal package or another defined object. That wording makes the promise reviewable and avoids discovering at handover that the customer and supplier meant different things by raw data. The purchasing work is complete when the promised later task is supported by evidence and an owned maintenance plan.
Frequently Asked Questions
Does a TFM image prove raw FMC data were saved?
No. Confirm the actual retained objects and demonstrate the required later task from saved evidence in the purchased configuration.
Does raw FMC access provide a validated custom analysis system?
No. Reading elementary signals and developing a suitable reconstruction workflow are separate responsibilities requiring appropriate technical evaluation.
Should every inspection retain elementary FMC signals?
The responsible technical and contractual requirements determine the needed evidence. Define the intended future use and evaluate the required data and dependencies rather than imposing a universal rule.
References & Standards Cited
- ISO committee site: historical 2019 explanation of FMC acquisition and TFM reconstruction View source ↗
- Evident: computer-controlled acquisition and raw FMC access, March 2025 View source ↗
- Eddyfi: Emerald acquisition, TFM processing and raw FMC data saving capabilities 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.