The Invisible Work That Makes Team Inspection Possible: Data-Integrity Protections in API/NDE 2.0
When inspection software is working properly, you rarely notice the protections underneath it.
You notice that a technician can open the correct assignment on an Android device. You notice that a CML is still connected to the right component. You notice that a returned inspection updates the correct project instead of creating another disconnected copy.
What you do not see is the data-integrity work making those outcomes possible.
That invisible work is a major part of the API/NDE 2.0 release. Several of the most important changes are not new buttons or redesigned screens. They are protections around serialization, project identity, revisions, hashes, persistence, cloud synchronization, and merging.
Those protections matter because inspection teams do not work in a single-user environment. One project may involve several inspectors, multiple inspection scopes, different Android devices, office review, engineering assessments, NDE results, and a final report that must accurately represent the approved work.
A professional inspection platform has to keep all of those contributions connected.
The problem is not collecting more data. It is keeping the right data connected.
Most inspection teams already have plenty of information.
They have historical thickness readings, current UT measurements, equipment drawings, photographs, NDE results, engineering calculations, checklists, certifications, and report templates. The difficult part is maintaining the relationship between those records as the project moves through the workflow.
A reading without its component identity is incomplete.
A finding without its location is difficult to use.
A field update without its project and revision context can be dangerous.
A report assembled from mismatched files may look professional while containing the wrong revision of a drawing, an outdated calculation, or a result from another inspection scope.
This is where traditional workflows create risk. Data is exported, copied, renamed, emailed, imported, and manually reconciled. Every handoff creates an opportunity for duplication or loss of context.
API/NDE 2.0 addresses that problem at the platform level. The objective is not simply to store inspection information. It is to preserve the identity, history, and relationships of that information throughout the complete workflow.
Serialization: preserving the inspection object during transfer
Serialization is one of those technical terms that rarely appears in a field report, but it has a direct effect on field reliability.
When project data moves between the desktop platform, cloud services, and an Android device, the inspection objects have to be converted into a format that can be transferred and reconstructed. Those objects may include equipment, components, CMLs, inspection findings, photos, assignments, NDE locations, and engineering results.
The important requirement is that the object remains the same object after that transfer.
A CML created in the project should not become an unrelated point when it reaches the tablet. A field update should not lose its component reference when it returns to the office. An assignment should remain connected to the equipment and scope it was created for.
The API/NDE 2.0 architecture includes protections around this serialization process so that data can move between environments without losing its structure or identity.
The Dashboard screenshot supports the workflow context around that claim. It shows a visible project authority with organized assignments, statuses, and cloud-connected controls in one place. In practice, that kind of structure matters because transferred work has to come back to the same project authority it left from. The screenshot does not by itself prove internal serialization logic, but it does accurately illustrate the type of centralized project context that those protections are designed to preserve.
For inspectors, the result is practical: you work with the assigned inspection data instead of rebuilding the asset from notes. For supervisors, it means returned work can be evaluated as a contribution to the project rather than treated as an unconnected file.
Project identity prevents the wrong project from receiving the right work
A project is more than a folder name.
Two assets may have similar equipment numbers. Two facilities may use similar component codes. Two inspections may involve the same vessel but different inspection dates, scopes, or revisions.
If a returned field package is identified only by a filename or a human-readable description, the system has too much room for ambiguity.
API/NDE 2.0 strengthens the project identity used throughout the workflow. Assignments, field data, revisions, and returned contributions remain tied to the project they belong to.
That control is essential when multiple inspectors are working at the same time. Each technician needs to receive the correct scope, and the platform needs to recognize where that work belongs when it comes back.
This also supports continuity with existing inspection programs. NDT Integrity uses the same component codes across workflows, which helps preserve historical relationships when legacy data is imported or exported. You do not have to create a second naming system simply because the project moved into a new digital workflow.
The result is less manual matching between old records and current inspection data. The component identity remains part of the project structure.
The CML table screenshot is useful here because it shows visible CML identity inside a structured table, with each record presented as part of a larger equipment context rather than as an isolated reading. That visible organization does not by itself demonstrate how internal identifiers are serialized or validated, but it does show the user-facing structure that depends on those protections. If a CML is going to trend correctly, merge correctly, and remain tied to the right component over time, its identity has to persist across revisions and synchronization events.
Revisions make change visible instead of destructive
Inspection work changes as it progresses.
A technician may return a completed scope. A QC reviewer may identify a missing reading. An engineer may update an assessment after reviewing the verified data. A project manager may approve one contribution while another remains open.
A weak workflow handles these changes by overwriting files. That creates uncertainty about what changed, who changed it, and which version should be used.
API/NDE 2.0 treats revisions as part of the project history. Work can move through assignment, return, review, approval, and repository stages without silently replacing the authoritative project.
This creates a controlled distinction between work in progress and approved project data.
That distinction matters in the field. A returned package should be available for review before it becomes part of the final project record. At the same time, the original project should remain protected while additional inspection work continues.
Instead of asking which spreadsheet is current or which attachment contains the latest drawing, the team can work from a structured revision history connected to the inspection project.
This does not eliminate the need for professional review. It makes that review more reliable by showing the work that is being reviewed and preserving the outcome.
Hashes provide a technical check on data changes
Hashes are another example of invisible infrastructure with a practical purpose.
A hash is a calculated representation of data. When the underlying data changes, the resulting hash changes. Comparing hashes gives the system a way to identify whether a project package or serialized object is still the same as the version that was created or transferred.
In an inspection workflow, this supports validation during movement between devices, services, and project repositories.
The purpose is not to make the inspector interpret technical values. The purpose is to give the platform a way to detect changes that should not be treated as unchanged data.
That is important when project content is synchronized through the cloud or merged after independent field work. The platform needs more than a filename and a timestamp to determine whether two records are compatible. It needs a reliable way to validate the data being handled.
These checks support the larger principle behind API/NDE 2.0: the system should supply what the verified data says and should not rely on human guesswork to decide whether two project packages are interchangeable.
The Registry screenshot reinforces the practical side of identity and synchronization. It shows a structured equipment registry and visible cloud-oriented controls that fit the way authoritative project records are managed across teams. The screenshot itself does not prove hash validation or sync-state logic, but it does show the organized registry and control surface that those protections support. In a team workflow, registry discipline matters because persistence and synchronization only stay reliable when equipment identity, project context, and returned work remain attached to the same underlying record structure.
Persistence keeps project state available after the screen changes
Field applications need to do more than display information temporarily.
An inspector may work through a checklist, place CMLs in SketchMapp, add NDE callouts, capture readings, attach photos, and return to the project later. The platform has to preserve those updates as project data rather than treating them as temporary screen activity.
Persistence protections help maintain the state of the project as users move through assignments and devices.
This is particularly important for Android field work. A technician should not have to recreate inspection progress because a session ended, a connection changed, or the project was reopened. The data must remain associated with the correct equipment, scope, and revision.
The same principle applies to office review. When a returned assignment is opened for QC, the reviewer needs to see the field contribution as it was submitted, including its data relationships and associated evidence.
Persistence is what allows the workflow to continue without forcing the team to reconstruct what already happened.
Cloud synchronization supports parallel inspection without duplicate projects
Multiple inspectors working on one asset need a controlled way to exchange project data.
That requires synchronization that understands the project structure. It is not enough to copy a large file from one device to another and hope the latest version contains everything.
API/NDE 2.0 is designed around cloud synchronization of project work, allowing assigned inspection scopes to move between the central project and Android field devices while preserving project context.
One inspector can work on the API inspection and photographs. Another can complete shell and openings. Another can handle roof and NDE work. A separate technician can perform a settlement assessment.
These scopes can be completed independently because the platform keeps each contribution tied to its assignment and project identity.
That architecture reduces the need to split one asset into separate unofficial projects just to divide the work. It also removes the need to manually combine unrelated files at the end of the inspection.
The Sphere screenshot helps illustrate the structured drawing side of synchronization and merging. It shows that the drawing environment is organized as project data, not just as disconnected markup. That matters because model-based sketches, CML layouts, and NDT callouts need to persist with the asset record and remain mergeable with the rest of the inspection package. The screenshot alone does not establish the internal merge rules or conflict handling, but it does accurately support the claim that structured drawing data is part of the same controlled workflow.
Merging is controlled assembly, not blind replacement
The final step is bringing approved contributions back into the authoritative project.
This is where data-integrity protection becomes visible to the project team. Returned work can be staged for review rather than immediately overwriting the master project. The system can maintain the distinction between an individual contribution and the approved project record.
That matters when several inspectors have worked on different portions of the same asset.
The platform must preserve each contribution, identify where it belongs, detect conflicts or incompatible project states, and merge approved work without losing the rest of the inspection. The goal is not to flatten every update into one undifferentiated file. The goal is to assemble a complete project from controlled, traceable contributions.
This approach supports the workflow already familiar to experienced inspection teams:
- Set up the project and equipment structure.
- Assign defined inspection scopes.
- Complete the work on Android devices.
- Return the field data for review.
- Validate and approve the contribution.
- Merge approved work into the authoritative project.
- Generate the report from the approved inspection data.
The report then becomes the projection of the project record rather than a separate reconstruction assembled from emails, spreadsheets, and revised drawings.
The architecture behind one source of truth
The visible features of API/NDE 2.0: Android field workflows, SketchMapp, inspection assignments, dashboards, engineering assessments, NDE results, and reporting: depend on this less visible foundation.
Serialization protects the structure of transferred data.
Project identity keeps work attached to the correct asset and scope.
Revisions preserve what changed and when.
Hashes support verification of data state.
Persistence keeps project information available throughout the workflow.
Cloud synchronization connects office and field work.
Controlled merging brings approved contributions together without turning collaboration into a file-reconciliation exercise.
Together, these protections help eliminate guesswork from team inspection. They give the platform a way to distinguish verified project data from incomplete, outdated, or unrelated information.
That is the architectural step that makes the larger API/NDE 2.0 workflow possible.
Multiple inspectors can now inspect different portions of the same asset independently on Android and have all of that work safely merged back into one authoritative project.