Making third-party thickness data arrive in a form you can actually trust

Contractor data is not wrong, it is inconsistent — which is worse

A fabrication shop rarely owns all of its own examination work. Radiography goes to an outside house, ultrasonics may arrive with the client's third-party inspector, hardness surveys and material verification may be a third party again, and on a busy job three subcontractors will be on the floor in the same week. Each returns competent work in its own format, to its own conventions, with its own idea of what a report should contain.

That is precisely the problem. Wrong data announces itself; inconsistent data does not. One house numbers points clockwise from the north seam, another uses SP-1 through SP-4 with the datum recorded in a photograph, a third reports only the minimum reading for the whole spool. All three are defensible field practice. Merged into one register they produce a dataset in which no point can be revisited and no comparison between visits is valid.

The instinct is to fix this at review, with someone senior reading the sheets and reconciling them by hand. That works until volume rises, and it consumes exactly the person whose time is scarcest on a busy shop floor. The alternative is to move the requirement upstream and make the register refuse a file that does not carry what a later reader will need.

The shop writes the owner's day-one baseline whether it means to or not

A fabrication shop thinks in terms of acceptance: does this weld pass, is this wall within tolerance, can the spool ship this week. The owner thinks in terms of the next thirty years. The measurements taken in the shop are the first entry in an inspection history that will be trended under API 570 or API 510 long after the fabricator has left the job and the contract has closed.

Whatever leaves the shop becomes the reference for that trend. If the turnover package quotes nominal wall, the owner's mechanical integrity program will trend against nominal. If it gives a minimum reading with no location, the owner cannot re-find the point, will establish their own, and will discard the baseline entirely. If it gives measured thickness at identified, re-findable locations, the owner's first campaign produces a real corrosion rate rather than an artifact of the paperwork.

There is commercial weight in this that fabricators consistently underestimate. Owners with mature integrity programs notice which vendors hand over structured, importable baseline data and which hand over four hundred scanned pages in a binder. It is one of the few genuinely differentiating things a shop can offer that a competitor cannot neutralise simply by cutting the bid.

Mill undertolerance, bend thinning and formed heads

Nominal is not a measurement. Seamless pipe to ASTM A106 may be supplied up to 12.5 percent under the specified wall, so 0.375 inch nominal is legitimately acceptable at 0.328 inch as delivered. Plate carries its own tolerance rules under the general requirements specifications. None of this is a defect and none of it is a supplier failing; it is the ordering basis, and the design accounted for it from the start.

Fabrication then removes more material. Induction and hot bends thin at the extrados, commonly by 10 to 15 percent depending on radius and process, which is why the piping codes require the finished bend to satisfy minimum wall rather than nominal. Head forming under the pressure vessel rules thins the knuckle. Weld repair excavations and arc-strike removal take local material away permanently. Each creates a point where real thickness diverges from the number on the drawing and stays diverged.

Those are exactly the points that should become monitoring locations, because they are where design margin is smallest on day one. Recording measured thickness at the extrados of every hot bend, at the knuckle of every formed head, and at every repair excavation is not additional work — the readings are usually taken anyway for acceptance. What is missing is somewhere to put them that the owner can inherit as data.

Reject on import, not on review

The reliable way to obtain consistent contractor data is to make inconsistent data fail at the door. A register that accepts any file and defers the problem to a reviewer has simply relocated the mess and added a delay. A register that validates on import, names the missing field and returns the file has changed the subcontractor's behaviour by the second job, because rework is more expensive to them than filling in a column.

The minimum set is short and non-negotiable. A point identifier that resolves to a registered spool, weld or component. A declared unit and instrument resolution. The measured value and any reference thickness held as separate fields. The procedure number and its revision. The examiner's certificate number, method, level, scheme and expiry. The instrument serial with its calibration block or step wedge and verification times. Every one of these will be demanded by somebody later, and every one is trivially available at the moment of measurement.

Enforcement has to be even-handed to survive commercially. Publish the import template and the validation rules with the purchase order, and apply them to your own in-house crews first. That turns the requirement from an arbitrary dispute into a specification the subcontractor priced for. Contractors object to unpredictable rework, not to a stated requirement they can plan around.

Repair excavations are permanent record, not a rework note

When a weld is rejected, ground out and re-examined, three things exist. There is the original examination with its rejection, the excavation with its depth and remaining thickness, and the re-examination with its acceptance. In many shops only the third survives into the turnover package, because the accepted report is the one the traveler needs to close and nobody has anywhere obvious to file the other two.

That is a traceability failure with a long tail. The excavation removed material at a specific location, and the remaining wall there may be the governing thickness for the component. An owner inspecting that spool ten years later has no way to know a repair occurred, and will compare a locally thinned area against nominal — producing either a false corrosion signal or, worse, a genuine finding attributed to entirely the wrong mechanism.

The registry model is a parent-child relationship. The rejection is the parent, the excavation and re-examination are children under the same point identity, and the accepted result cannot be created without that chain existing. The traveler still shows an acceptance. The record behind it shows how the acceptance was reached, which is what a client audit and a future inspector both need and neither can reconstruct from a single PDF.

Weld numbers, heat numbers and the traceability spine

Thickness points do not exist in isolation in a fabrication shop. Each sits on a component with a heat number tied to a material test report, on a spool with a drawing revision, adjacent to welds that carry their own identifiers, procedure specifications and welder qualifications. The register is only as useful as its attachment to that spine, and a register keyed on its own private numbering is a second silo rather than a solution.

Material verification adds a further layer. Where a verification program requires positive material identification, the alloy result belongs on the same component record as the thickness reading, because both answer the same question about what is physically installed as opposed to what was ordered. Sour service work adds hardness acceptance to that record too, since the limit applies to the specific weld in front of you rather than to the procedure in the abstract.

When these live in one structure, useful queries become possible: every component from a single heat, every weld examined under a procedure revision later found deficient, every spool that received a repair. When they live in separate spreadsheets keyed on different identifiers, each of those questions becomes a manual reconciliation carried out under time pressure, usually after something has already gone wrong.

The third-party inspector and the integrity engineer want different things

A client's third-party inspection agency works to the inspection and test plan. It cares about hold and witness points, whether notification was given in time, whether examination was performed to the stated procedure revision, and whether results are properly signed. Its output is a release note, and its interest in your data effectively ends at shipment.

The owner's integrity engineer arrives much later and cares about almost none of that. They want to know where the metal is thin, where it was repaired, what the actual as-built thickness is at defined and re-findable locations, and whether the dataset can be loaded into their own inspection data management system without anybody retyping it. The two audiences want the same underlying facts arranged in completely different ways.

A shop that maintains one structured register can serve both from it: release evidence against the inspection and test plan during the job, and a clean baseline export at handover. A shop that maintains a folder tree per project ends up producing the second deliverable by hand in the final two weeks, while everyone is trying to close the contract. That is why it almost always ships as PDFs.

Evaluating a registry when the data comes from other people's systems

The feature that matters most here is the one least often demonstrated: import behaviour. Ask to import a real subcontractor file — not the vendor's own template — containing a missing certificate expiry and a duplicated point identifier. A system that accepts it and puts a warning somewhere will not change contractor behaviour. A system that rejects it with a specific, quotable reason will, because that reason can be forwarded verbatim.

Then test identity handling. Import the same spool's readings twice under two different naming conventions and see whether duplicates are detected or silently doubled. Record a repair against an already-accepted point and see whether the chain is enforced or bypassed. Change a stored as-built value and ask what the field history shows afterwards. Each of these takes two minutes and predicts several years of data quality.

Last, test what leaves. Ask for a handover extract in a structured format including measured as-built, point location and datum, examination provenance and repair history, and then try to load it into something else. If the export turns out to be a report rather than data, the owner will retype it or ignore it, and the baseline you spent an entire project assembling will not survive the handover it was built for.

Request a consultation