Thickness Data You Can Trust: UT and CML Integrity Across Round Trips
A thickness reading is only useful when you know exactly where it belongs, what it should be compared against, and whether it changed during the inspection.
That sounds straightforward. In practice, UT and CML data often passes through several stages before it reaches the final report:
Office setup → assignment → Android capture → return to the office → import → QC → project reopening → reporting
Every handoff creates a risk. A baseline can be overwritten. A current reading can be mistaken for an old value. An unchanged field can be marked as edited. A CML can lose its identity and attach to the wrong location.
These are not cosmetic data problems. They can affect thickness trending, corrosion calculations, inspection history, and the confidence your client places in the report.
As part of the API/NDE 2.0 release series, NDT Integrity has strengthened how UT and CML information survives these round trips. The focus is practical: preserve the data that matters, identify what actually changed, and keep every reading connected to the correct inspection location.
The problem is not collecting one reading
Most inspectors know how to take and record a UT reading. The harder problem is maintaining that reading’s meaning as the project moves between people, devices, files, and revisions.
A typical inspection may involve:
- A CML created during office preparation
- A technician receiving that CML through an assignment
- An inspector capturing the current thickness on an Android tablet
- A return package being imported into the main project
- A reviewer checking the result
- A report being reopened or regenerated later
- Historical values being compared against the new inspection
If the system does not preserve the relationship between the CML, the baseline, and the current reading at every stage, the project can become difficult to trust.
This is where manual work creates avoidable uncertainty. Someone may compare the latest thickness against the wrong previous value. An unchanged baseline may appear to have been modified. A returned assignment may create a duplicate CML instead of updating the existing one.
NDT Integrity’s goal is to remove that uncertainty from the workflow. The platform supplies only what the data says and preserves the inspection structure that gives each reading context.
Baseline and current thickness remain distinct
Baseline thickness and current thickness are not interchangeable.
The baseline establishes the reference point for the inspection history. The current thickness represents the latest measured condition. If those values are blended, overwritten, or shifted during a project round trip, the resulting trend can be misleading even when the latest UT number is correct.
The updated UT and CML handling gives the system a stronger separation between these values. Baseline information remains available as baseline information, while current inspection data is preserved as the current reading.
That distinction supports the practical work inspectors perform every day:
- Reviewing previous and current thickness side by side
- Tracking historical changes at a specific CML
- Performing corrosion-rate and remaining-life calculations from the correct inputs
- Identifying whether a value is an established historical reference or a new field observation
- Reopening a project without losing the relationship between the reading and its history
The point is not to add more fields for the sake of adding fields. It is to prevent one value from silently taking the place of another.
When a calculation depends on the difference between two measurements, the software must preserve both measurements first. That is how you eliminate guesswork before the calculation begins.
Improved dirty-state logic shows what actually changed
Field teams work with real project data, not perfectly clean test records. A project may contain existing thickness values, imported history, assigned scopes, and inspection fields that are carried from one stage to the next.
That creates a common problem: systems sometimes treat values as “dirty” or edited simply because they passed through an assignment, an import, or a save operation.
When unchanged values are incorrectly marked as field edits, the review process becomes noisy. Supervisors have to spend time checking changes that did not happen. Returned assignments may appear to contain more modifications than they really do. A reviewer can lose sight of the fields that genuinely require attention.
The improved dirty-state logic is designed to distinguish between:
- A value that was carried through unchanged
- A value that was intentionally updated in the field
- A value that was changed during review or import
- A new value that requires validation
That distinction produces a more accurate review workflow.
If the technician did not change the baseline, it should not be presented as a changed field. If the current thickness was updated, that update should remain visible. If a value simply traveled through the workflow unchanged, the project should not create unnecessary review work around it.
This matters particularly when multiple inspectors contribute to one project. Reviewers need a clear view of what each assignment actually returned: not a list inflated by technical saves, data transfers, or unchanged values.
CML identity must survive the complete workflow
A CML is more than a number on a table. It represents a specific inspection location on a specific component.
Its identity may be connected to:
- The equipment or piping component
- The drawing location
- The CML label
- The inspection scope
- The historical thickness record
- The current assignment
- The field device that captured the reading
If any of those connections break, the reading can become difficult to interpret. In the worst case, a valid reading may attach to the wrong CML.
That risk increases in complex projects where multiple inspectors work on different scopes, assignments are returned at different times, and project data is imported or reopened more than once.
NDT Integrity has strengthened CML identity and persistence across the full round trip:
Assignment → Android capture → return → import → project reopening
The objective is simple: the CML created in the project should remain the same CML used in the field and reviewed in the final project.
This is also where the two provided visuals matter together. The CML grid shows the record-level controls that preserve previous and current readings, comments, history, and import behavior. The tank shell drawing shows those same inspection points anchored to real shell locations with findings attached to the right places. One view protects the table record. The other protects the physical location. Together, they show how readings stay attached to the correct component instead of drifting during assignment returns, imports, or project reopening.
This supports the broader SketchMapp workflow, where CMLs, findings, NDE callouts, and inspection objects can be connected to the equipment drawing rather than managed as disconnected notes.
When the CML retains its identity, the drawing and the thickness history support one another. The inspector can work from the correct location, the office can review the correct reading, and the report can use the approved data tied to that location.
Android capture without losing project context
Field mobility only helps when the data captured on the tablet returns to the project with its meaning intact.
NDT Integrity’s Android workflows are designed around structured field collection. Inspectors can work from assigned project data, use tablet checklists, capture inspection information in the field, and connect readings to the relevant inspection objects.
The provided CML table screenshot also highlights the Android side of that process. It shows CML table building on the tablet alongside the same identity-critical data points inspectors and reviewers care about: current and previous readings, nominal thickness, comments, history, and import paths. That matters because the reading is not being collected as a loose number. It is being captured against a defined CML that already has context.
The UT and CML improvements reinforce that workflow by protecting the relationships established before the technician leaves the office.
The field process becomes more controlled:
- The project contains the defined CML and its existing history.
- The appropriate scope is assigned to the inspector.
- The inspector captures the current field information on Android.
- The returned data is evaluated against the existing project structure.
- Only actual changes are treated as field edits.
- The reading remains associated with the intended CML when the project is updated.
Direct Bluetooth UT gauge readings and structured tablet workflows can reduce transcription work, but the data still needs a reliable destination. The improvement is not only about getting a number into the device. It is about keeping that number connected to the right CML when it comes back.
Safer imports and project reopening
Inspection projects do not always move in a straight line. A project may be reopened after a review, imported from another stage of the workflow, or updated after additional field work.
Each reopening is another opportunity for identity drift or unnecessary duplication if the system treats returned data as a new record instead of part of the existing project.
Stronger persistence helps protect against common round-trip failures:
- Current readings becoming detached from their original CML
- Baseline values being replaced by current values
- Unchanged values being flagged as new edits
- Returned assignments creating duplicate inspection locations
- Historical thickness information becoming separated from the equipment drawing
- Reopened projects displaying a different data relationship than the one originally captured
The result is a project that is easier to review because the system preserves continuity instead of forcing the team to reconstruct it manually.
That continuity also supports the reporting workflow in NDT Integrity’s API inspection platform, which brings CML management, UT imports, automated calculations, digital drawings, and report generation into one connected inspection record.
What this means for inspectors and reviewers
For inspectors, the practical benefit is less time spent explaining whether a value changed, where it came from, or which CML it belongs to.
For reviewers, it means the returned assignment shows the changes that require attention instead of treating every transferred value as an edit.
For project managers, it means fewer duplicate records and less manual reconciliation when several inspectors contribute to one project.
For clients, it means the final report is built from thickness data that has retained its baseline, current value, identity, and project history through the workflow.
The software does not replace technical judgment where professional review is required. It removes avoidable uncertainty before that review takes place. It eliminates guesswork about whether a value changed and reduces the risk of a reading being attached to the wrong inspection location.
One reading, one CML, one continuous history
Trustworthy UT data depends on more than the accuracy of the instrument. It depends on preserving the full chain around the measurement.
The reading must retain:
- Its baseline and current context
- Its CML identity
- Its assignment and project relationship
- Its field-capture history
- Its change state
- Its place in the final inspection record
The latest API/NDE 2.0 improvements strengthen that chain across assignments, Android capture, imports, and project reopening.
That is the standard NDT Integrity is building toward: perform the inspection once, preserve what the data says, and use that same verified information through QC, calculation, and reporting.
When the project comes back from the field, the right reading should still be attached to the right CML. When nothing changed, the system should say so. And when a thickness value did change, that change should be clear, traceable, and ready for review.