When the Finding Was Written by Somebody Else's Inspector

The finding arrives as somebody else's PDF

Most terminals do not employ the people who find their problems. Shell thickness comes from a UT crawler contractor, bottoms come from an MFL crew, the formal evaluation comes from an API 653 inspector who may work for a third firm, and seal gaps come from whoever holds the environmental compliance scope. Each of them delivers a document, and each document is written to satisfy that firm's internal review, not to be loaded into your system.

This inverts the usual assumption behind deficiency tracking software. The register is not primarily a place where your staff raise findings; it is an ingestion point for other people's judgement, arriving in inconsistent form, at unpredictable intervals, sometimes months after the fieldwork. By the time the report lands, the crew has demobilized and the person who can explain an ambiguous entry is on another job in another state.

The design consequence is that ingestion quality matters more than workflow elegance. A tracking module for a terminal is judged on how faithfully it captures a third party's output, how well it preserves the identity of the report and its revision, and how quickly a reviewer can reconcile an entry against the source document without opening the PDF and scrolling.

Severity schemes do not survive a change of contractor

Open two API 653 reports from two firms on two adjacent tanks and you will find two different priority vocabularies. One uses Priority 1 through 3 keyed to time frames. One uses Immediate, Short Term and Long Term with no defined durations. One embeds severity in the recommendation text and offers no label at all. A fourth reports everything as an observation and leaves prioritization entirely to the owner.

Terminals that load these labels straight into a shared backlog get a work queue sorted by procurement history. The tank inspected by the more conservative firm dominates the top of the list, not because it is in worse condition but because that firm writes stronger language. Budget follows the list, and the tank that actually needed attention sits three screens down under a mild adjective.

The workable pattern is two fields, not one. Keep the contractor's label verbatim as evidence of what you were told, and add an owner tier assigned by your own engineering, using your own criteria, applied uniformly across every tank regardless of who inspected it. Only the owner tier drives scheduling. The contractor's label stays alongside it, because if a deferral is ever questioned, the question will be what you were told and what you decided, in that order.

MFL percentages and the basis problem

Magnetic flux leakage is the standard first pass on a tank bottom, and it is fast, broad and appropriately cautious. It is also, in the strict sense, not a thickness measurement. It reports an indication and estimates metal loss as a percentage, and the percentage is meaningless until you know what it was taken against.

Most reports take it against nominal plate thickness. A bottom plate specified at a quarter inch will not be a quarter inch. Mill tolerance takes some, the previous twenty years of service took more, and the underside of a bottom plate is precisely where you have no history. Forty percent loss against nominal and forty percent against measured actual are two different remaining thicknesses, and API 653's minimum bottom thickness criteria do not care which one you meant. A register that stores the percentage and drops the basis has stored a number that cannot be used.

The corollary is that an MFL indication is a candidate, not yet a deficiency. It earns that status after prove-up ultrasonic measurement establishes an absolute remaining thickness at the location. Terminals that promote every MFL indication straight to a finding create a backlog inflated with indications that prove up acceptable, and the inflation is not harmless: it drags the apparent corrosion picture down and can pull an interval shorter than the physical evidence justifies.

An indication is not a deficiency until it is proved up

The prove-up step is where third-party data quality is won or lost, and it is usually the least documented part of the campaign. A technician walks the flagged locations with a UT gauge, records readings, and the readings appear in the report as a table. What frequently does not appear is which MFL indication each reading verifies, what calibration block and couplant were used, and whether the reading was taken on the flagged spot or on the nearest accessible clean surface.

That last point matters more than it sounds. Bottom plates in service are rarely clean; scale, product residue and coating all interfere. A prove-up reading taken two inches from the indication because the indication itself would not couple is a different measurement, and if the register records it as verification, the file now contains a confident number that describes a location nobody measured.

A register that handles third-party data well makes the link explicit: every prove-up reading points at the indication it verifies, and an indication with no linked prove-up remains visibly unresolved rather than quietly closing. The count of unresolved indications after a campaign is one of the few honest data-quality metrics a terminal can hold a contractor to, and it is available for free once the link is a field.

The interval is a consequence of the finding, not a field

API 653 sets inspection frequency from the condition of the tank, not from a calendar preference. Shell and bottom corrosion rates, computed from successive thickness measurements against the calculated minimum, determine how much remaining life exists and therefore how soon the next examination has to happen, subject to the standard's maximum intervals. The number is derived. It is not a policy choice.

In practice, most terminals hold next-inspection dates as typed fields in a schedule, updated by a person after an inspection closes. That works until a single reading changes the picture — a new low on a course that was previously stable, or a corrected basis on an old reading that steepens a rate. The derived date should have moved and the typed field did not, and nobody discovers the gap until the following campaign, by which time the tank has been operating outside its interval on paper.

This is the strongest argument for keeping thickness data and deficiency data in one system rather than two. When a finding carries its readings, the recomputation is automatic and the alert is generated by arithmetic rather than by someone remembering. It also makes deferral honest: if engineering elects to defer a recommendation, the register can show what that deferral did to the computed remaining life, which is a far better basis for the conversation than a priority label.

What the compliance file expects to see

A terminal's deficiency register is not only an engineering artifact. The SPCC rule requires integrity testing of aboveground containers on a schedule and after material repairs, combining visual inspection with another technique in accordance with industry standards, and the plan is certified by a Professional Engineer. Many states layer additional programs on top, and air districts add their own requirements around floating roof seals and emissions control.

What an agency inspector or an insurer's engineer asks for is rarely exotic: the plan, the schedule, the records for the tanks in scope, and evidence that what the inspection found was acted on. The last item is where files come apart. Reports are filed diligently; closure evidence is not, because closure often happens through a maintenance system that does not talk to the inspection folder.

Keeping the loop inside one register removes that seam. The recommendation, the decision, the work order, the repair evidence and the re-examination live on one record with one number, and the compliance extract is a report rather than an archaeology project. It also protects the engineer who certified the plan, because the certification rests on a program that can be shown to function, not merely to exist.

Roof seals, drains and findings on a different cadence

Not every terminal finding comes from a formal inspection campaign. Floating roof seal gap measurements, roof drain checks, water draw-off observations, gauge and overfill protection verification under API 2350, and routine operator rounds all generate findings, on cadences ranging from daily to annual, from people with entirely different reporting habits and tools.

These items are easy to under-model because individually they are small. Collectively they are the ones that produce a regulatory citation or a product release. A seal gap out of tolerance is a compliance finding with a clock attached; a plugged roof drain is a sinking-roof scenario. Neither fits the shape of an API 653 recommendation, and neither belongs in a separate spreadsheet where it will age unwatched.

A single register with different intake forms is better than several registers with one form each. The operator entering a seal gap on a tablet during rounds should not be navigating an inspection module built for a formal campaign, but the finding they raise should land in the same backlog, carry the same tank identity, and compete for attention against everything else on that tank. Terminals that split these streams routinely discover that the small findings never appeared in any prioritization at all.

Evaluating a system that has to live on third-party data

Test ingestion, not workflow. Take the last two API 653 reports you received from different contractors and ask the vendor to bring both into the system in front of you. Watch what happens to the priority labels, the recommendation wording, the report revision number and the thickness tables. Anything that gets paraphrased on the way in is evidence you will not have later.

Then test the three-field discipline. Ask where the contractor's observation lives, where the contractor's recommendation lives, and where your engineering decision lives, and confirm they are separate and separately reportable. Ask what happens when a report is revised after a decision has already been made against revision 1. Ask whether an MFL indication with no prove-up can be closed, and by whom.

Finally, test the interval. Enter a thickness reading that steepens a corrosion rate and see whether the next inspection date moves on its own. If it does not, you are buying a document library with a task list attached, which is not the same thing. Atlantis builds this as a module of an Odoo-based NDT ERP, with report validation available as a separate service where you want a second Level III opinion on what a contractor delivered. To review your own reports against the model, contact info@atlantisndt.com.

Request a consultation