Settlement as Its Own Assignment: How It Now Returns Into the Same Tank Project

NDT Integrity API inspection software for connected tank, vessel, piping, and settlement workflows

Settlement work has always required careful field execution, controlled measurements, and clear engineering review. The problem has often been the workflow around it.

A settlement survey may be performed by a different technician, on a different schedule, using a different device than the main API 653 tank inspection. When that survey returns as a separate spreadsheet, PDF, or email attachment, someone still has to connect it back to the correct tank, inspection project, report revision, and final condition summary.

That manual connection is where duplicate entry, missing evidence, and calculation rework begin.

API/NDE 2.0 changes that structure. Settlement can now participate as its own inspection assignment while remaining connected to the same Tank project as the rest of the inspection work.

The result is a controlled workflow for separate field execution and one authoritative tank record.

Settlement is a separate scope, not a separate tank

A tank inspection may include several distinct scopes:

  • General API 653 inspection
  • Shell and openings
  • Roof and appurtenances
  • Floor or bottom inspection
  • NDE and thickness measurements
  • Settlement assessment
  • Engineering review and disposition

These scopes do not always belong to the same technician or crew. Separating them at the assignment level reflects how the work is actually performed.

In API/NDE 2.0, the settlement survey can be assigned independently. The technician receives the settlement scope, completes the required field work, records the readings, adds supporting photos or sketches, and returns the assignment for review.

The settlement assignment still carries the identity of the tank and the parent project. It is not created as an unrelated report that must later be reconciled by hand.

That distinction matters. A separate assignment gives the field team a clear scope. The shared project keeps the asset identity, inspection history, and final reporting connected.

The workflow from assignment to approved project data

The settlement workflow follows the same controlled path as other API/NDE 2.0 assignments:

Tank project → Settlement assignment → Field data collection → Review → Approval → Same Tank project → Final report

A project manager can create the tank project and define the inspection scopes. Settlement is then issued as its own assignment to the appropriate technician or engineering resource.

The assigned technician works from the settlement scope rather than searching through a general project folder or trying to determine which parts of a large inspection package apply to the task.

When the work is returned, it is staged for review. The returned data does not blindly overwrite the master project. Reviewers can see what was submitted, confirm the readings and supporting documentation, and approve the contribution before it becomes part of the authoritative project record.

This creates a visible chain between the field assignment and the final tank report.

You can identify:

  • Which tank the settlement work belongs to
  • Which technician completed the assignment
  • What measurements and observations were returned
  • What photos, drawings, or notes support the work
  • What was reviewed and approved
  • Which project record received the approved results

That information should not have to be reconstructed from filenames, email threads, and separate spreadsheets.

Field data stays connected to the tank

Settlement data is only useful when the measured points can be understood in relation to the tank.

With NDT Integrity’s field workflow, technicians can work from a tablet using checklists, inspection objects, sketches, and project-specific documentation. SketchMapp supports inspector-level drawings for CMLs, tank features, NDT callouts, and field annotations without requiring a heavy CAD process.

For a settlement assignment, the drawing and supporting documentation can remain connected to the tank project rather than becoming a standalone attachment with no relationship to the inspection model.

That same tank context can also include other API 653 calculation workflows. For example, the project may contain bottom remaining thickness data with floor plate, critical zone, annular plate, corrosion-rate, retirement-thickness, interval, and status fields tied to the same tank record. That MRT workflow is supporting tank calculation context inside the project. It is not the settlement assessment itself.

That distinction matters because settlement remains its own assignment, with its own field execution, review path, and approved return into the same Tank project.

That continuity reduces a common source of confusion: one drawing in the office, another version in the field, and a third version attached to the final report.

The field workflow follows the same principle used across NDT Integrity:

Create the project object once. Use the same object through assignment, field collection, review, approval, and reporting.

The tank identity remains stable while the assignment status changes.

Verified readings and automated calculations

Settlement evaluation depends on measured field data and the engineering rules applied to that data. It should not depend on someone manually copying values between documents and deciding which version is current.

NDT Integrity’s engineering assessment workflow is designed to keep settlement evaluation tied to the submitted readings and the project record. Built-in assessments support settlement, localized depression, and plumbness workflows so the results can be handled as part of the inspection process rather than recreated in a separate calculation package.

The platform supplies the readings that were entered or imported. It applies the configured calculation logic. It records the resulting assessment for review.

That removes guesswork from the data path.

It does not replace the qualified inspector or engineer responsible for reviewing the results. It does remove unnecessary speculation caused by disconnected files, unclear revisions, and handwritten calculations. The system supplies only what the data says and preserves the basis for the conclusion.

If a result requires additional engineering evaluation, repair planning, or follow-up, that disposition can remain associated with the same tank project. The condition is not lost in a separate settlement report.

Industrial pressure vessel and process piping representing connected inspection scopes and asset records

Separate field work without duplicate project setup

A separate assignment should not require a second project setup.

The tank project can hold the documents, inspection history, equipment identity, drawings, assignments, photos, and report components in one organized location. Teams can use a folder-based project setup to place project documents in the correct folder, upload them, and build a report that is already substantially complete.

That same structure supports settlement work.

Instead of creating a new tank record for the survey, a coordinator adds settlement as a defined assignment under the existing project. The survey returns to that project with its own review status and supporting evidence.

This avoids common administrative failures:

  • Creating duplicate tank records
  • Entering the same asset information twice
  • Rebuilding tank drawings for a separate settlement package
  • Copying settlement results into the main report by hand
  • Losing track of which report revision contains the approved result

The settlement scope remains independent where it needs to be independent, while the project record remains unified where it needs to be unified.

One report, not a stack of disconnected deliverables

The final deliverable should show the tank as one inspected asset.

It should not force the client to interpret a general inspection report, a separate settlement spreadsheet, an unrelated sketch package, and a collection of emailed photographs.

When the settlement assignment is approved, its results can return into the same Tank project alongside the other inspection scopes. The final report can then include the settlement assessment with the rest of the tank’s inspection data, drawings, photos, NDE results, and conclusions.

Report content is generated from approved project data instead of being reconstructed at the end.

NDT Integrity supports professional report generation with custom branding, cover sheets, inspection drawings, photos, checklists, calculations, and supporting documentation. Users can control report colors and branding without sending every minor cover-sheet change back through a development queue.

That gives the final report the correct company identity while keeping the technical content connected to the inspection record.

Historical data remains part of the conversation

Settlement is not only a current inspection result. It can also be part of the tank’s longer-term integrity history.

When the current settlement assessment returns to the same tank project, it remains associated with the same asset identity used for prior inspections. That supports a more practical review of historical records and future inspection planning.

NDT Integrity also supports legacy system integration through the continued use of familiar component codes. That makes historical imports and exports easier to manage and helps preserve the connection between older inspection records and new project data.

The benefit is straightforward: changing software does not have to mean abandoning the tank’s history or creating a new naming system for every inspection component.

Built around how tank inspections actually happen

Tank inspections are rarely completed by one person performing every task on one device from start to finish.

One technician may collect general inspection data. Another may perform NDE. A specialist may complete the settlement survey. A reviewer may verify the results. A project manager may assemble the final report and deliver it to the client.

API/NDE 2.0 is built around that reality.

Settlement can now be treated as its own accountable assignment with its own field execution and review path. Once approved, it returns to the same Tank project instead of becoming a disconnected side report.

That gives you:

  • One project identity for the tank
  • Separate assignments for separate inspection scopes
  • Controlled field-to-office data transfer
  • Review before changes enter the master record
  • Settlement results connected to the final report
  • Historical continuity through consistent asset and component records
  • Fewer opportunities for duplicate entry and revision confusion

The core idea is simple:

Perform the settlement assessment as its own assignment. Keep the result with the same tank.

That is how API/NDE 2.0 turns a separate field responsibility into one connected inspection record.

Explore NDT Integrity’s API inspection workflow to see how API 510, API 570, and API 653 inspection data, calculations, drawings, and reporting fit into one platform.

Digital inspection data represented as a connected point-cloud and reporting environment

Connected Android field workflow for inspection drawings, assignments, and approved project data