Multiple Inspectors. One Authoritative Project.
When a large inspection has several scopes, dividing the work is practical. Dividing the project is not.
A tank inspection may require one inspector to complete the API 653 scope, another to document shell courses, nozzles, and manways, another to inspect the roof, and another to perform settlement work. Each person has a defined responsibility, a different part of the equipment, and a different set of field observations to record.
The traditional problem begins when those assignments become separate project files.
Now the team has multiple copies of the same tank, multiple drawing revisions, repeated equipment information, and several sets of field data that must be reconciled before a report can be issued. Someone in the office has to determine which version is current. Someone else has to copy findings into the master report. The original contributor may then need to review the result and explain what changed.
That workflow creates avoidable rework.
API/NDE 2.0 changes the project architecture: multiple inspectors can work independently on one asset using Android inspection packages, then return their completed work to one master Windows project. The contributor identity remains attached to the work, while the approved information becomes part of one authoritative inspection record.
The difference between splitting work and splitting the project
Most inspection teams already divide responsibilities in the field. The issue is how the software represents that division.
In a file-based workflow, each inspector may receive a copy of a report, spreadsheet, drawing, or project folder. Those copies quickly become independent documents. Even when the work is accurate, the team still has to merge it manually.
That is where endless revisions begin:
- Equipment descriptions are entered more than once.
- Shell course or component references do not match.
- One inspector works from an older drawing.
- Findings are copied from field notes into a report by someone who was not on the asset.
- Photos and comments become detached from the inspection location.
- The project manager has to compare several files to determine what has been completed.
API/NDE 2.0 is designed around a different model. There is one project for the equipment, and that project can distribute controlled assignments to multiple Android devices.
The team is not creating several unrelated inspections. It is completing different portions of the same inspection.
That distinction preserves project identity from assignment through review, approval, and reporting.
One asset, multiple field assignments
Consider an API 653 tank inspection.
The master Windows project contains the equipment identity, existing project information, inspection scope, drawings, and the structure required for the final deliverable. From that project, the inspection team can assign separate portions of the work.
For example:
- Inspector 1: API 653 inspection scope and general tank documentation
- Inspector 2: Shell courses, nozzles, and manways
- Inspector 3: Roof condition and related findings
- Inspector 4: Settlement readings and settlement assessment
The point is not to create four versions of the same tank. It is to send four controlled assignments from one project, let each inspector complete a defined portion of the same equipment, and return that work to one master record.
Each inspector receives the portion of the project needed to complete the assigned work on an Android device. The assignment is tied to the same asset and the same project structure. The inspector can record observations, measurements, photos, comments, sketches, and other required information without rebuilding the equipment from the beginning.
This matters in the field because the inspector can focus on the component in front of them instead of managing the limitations of a shared file.
The shell inspector does not need to wait for the roof inspector to finish. The settlement inspector does not need to use a separate spreadsheet that will later be retyped into the report. The work can proceed in parallel while remaining connected to the master project.
The result is a coordinated team inspection rather than a collection of disconnected field packages.
The Dashboard visual below supports that operating model by showing the project overview, assignment flow, active projects, and contributor workflow in one place. Instead of losing visibility once work is split up, you can see how separate field packages still belong to the same project structure and return path.
Independent work without losing accountability
Parallel work is only useful when the project can show who did what.
API/NDE 2.0 retains contributor identity as inspection packages return to the master Windows project. The merged project does not flatten every contribution into an anonymous set of values. It preserves the relationship between the returned work, the assignment, and the inspector who completed it.
That provides practical traceability for review:
- Which inspector completed the shell inspection?
- Who documented the roof condition?
- Who entered the settlement readings?
- Which package contained the nozzle and manway findings?
- What information was returned for review?
- What was accepted into the authoritative project?
The answers remain connected to the project record.
This is important for inspection companies managing multiple technicians, subcontractors, or specialty personnel. Supervisors can distribute work without losing visibility into the source of the information. Reviewers can evaluate the returned package in context instead of trying to reconstruct ownership from filenames, email threads, or handwritten initials.
Contributor identity is not a cosmetic feature. It is part of maintaining a defensible inspection history.
The return path: Android package to master Windows project
The core workflow is straightforward:
- The inspection team establishes the master project on Windows.
- The equipment and inspection scope are organized into assignments.
- Different portions of the asset are sent to the appropriate Android users.
- Inspectors complete their assigned work in the field.
- Each inspection package returns to the master project.
- The returned contributions are reviewed and merged into the authoritative project.
- The approved project data supports the final report.
The important step is the controlled return and merge.
The software is not simply allowing several users to overwrite the same file. Each assignment comes back as identifiable project work that can be reviewed before it becomes part of the final record. That gives the project owner a clear boundary between field contribution and accepted project data.
That is where the Registry and assignment controls matter. They show the equipment registry that anchors the project, the assignment controls that send the right scope to the right contributor, and the single-project operating model that brings completed work back to one authoritative record.
It also avoids a common failure in multi-user workflows: the last person to save a file unintentionally replacing information entered by someone else.
The authoritative project remains the central record. The Android packages are controlled work contributions connected to it.
Built for the way inspectors divide real work
Inspection teams do not divide work randomly. Assignments usually follow equipment geometry, inspection scope, access requirements, or individual capability.
One inspector may be responsible for the roof because that person is already completing the roof access and visual examination. Another may focus on shell thickness and openings. A third may have the survey equipment and experience required for settlement work.
API/NDE 2.0 supports that field-built organization without forcing the team to create a separate project for every responsibility.
The same principle applies beyond storage tanks. A vessel project can be divided by shell, heads, nozzles, and NDE scope. A piping project can be divided by circuits or equipment areas. A larger turnaround can be organized by asset and inspection package while preserving the connection to the overall project.
The software follows the inspection structure instead of making inspectors adapt the inspection to a single-user file workflow.
Less reconstruction after the fieldwork
The value of team merging becomes most visible when the fieldwork is complete.
Without a connected project architecture, the office may spend hours or days reconstructing the inspection:
- Importing readings from several spreadsheets
- Comparing drawings from different inspectors
- Renaming component references
- Sorting photos into the correct equipment sections
- Re-entering observations into a report template
- Asking inspectors to clarify which version is correct
- Repeating calculations after data is moved
That is exactly what this workflow is built to eliminate. Multiple inspectors can complete different portions of the same equipment, return those assignments to one master project, and keep the project manager out of the business of stitching together disconnected files.
Every manual handoff introduces another opportunity for transcription error or lost context.
With NDT Integrity’s project-centered workflow, the field contribution returns to the project it belongs to. The equipment identity, assignment, contributor, and inspection data stay connected. That eliminates duplicate project setup and reduces the need to rebuild the inspection from separate documents.
It also keeps the final report closer to the original field evidence.
The objective is not to remove professional review. Review remains necessary. The objective is to remove the administrative reconstruction that adds no inspection value.
The same data continues into the report
After the team’s packages are returned and approved, the master project becomes the source for the final deliverable.
That can include the assigned inspection findings, equipment drawings, CML information, photos, comments, NDE callouts, and engineering assessment results. With SketchMapp, inspectors can work with equipment-level drawings and inspection markers rather than relying on separate CAD revisions or disconnected images.
The report is then built from the controlled project data.
That connection matters because a professional report should represent the work completed in the field: not a second version of the inspection recreated later by an office team.
NDT Integrity’s API inspection workflow is built around that same principle: capture the information once, retain its connection to the asset, and carry it through the review and reporting process.
One project does not mean one person does everything
A single authoritative project does not require a single inspector to perform every task.
It means the team can work independently while the software preserves the relationship between each contribution and the asset being inspected.
That is the architectural change in API/NDE 2.0:
- Multiple inspectors can work at the same time.
- Each inspector can receive a defined portion of the equipment.
- Android packages can return to one master Windows project.
- Contributor identity remains attached to the submitted work.
- Returned work can be reviewed before it becomes part of the authoritative record.
- The final report is built from one controlled project instead of several disconnected files.
For inspection companies, this creates a practical way to scale team assignments without multiplying project confusion.
For inspectors, it means spending more time documenting the equipment and less time explaining which file contains the right information.
For project managers and reviewers, it means one project to control, one inspection history to follow, and one authoritative record to carry forward.
Multiple inspectors. One asset. One controlled merge. One authoritative project.
That is the foundation of team inspection merging in API/NDE 2.0.