Rolling Up Thickness Data When Every Client Numbers CMLs Differently

The registry you do not own

Almost every article written about condition monitoring locations assumes the reader owns the asset. It talks about placing CMLs to API 574 guidance, rationalising grids, setting inspection intervals under API 570 and defending them in a management-of-change review. All of that presumes authority over the scheme. A service provider has none of it. The numbering arrived with the contract, it is embedded in the client's inspection data management system, it is referenced in their integrity operating windows, and it is not open for discussion.

What the service provider does own is execution and evidence: the technician who took the reading, the instrument that produced it, the technique used, whether the point could be reached, why a reading was excluded, and whether the deliverable arrived in the specified form within the specified period. That is a genuinely different data model. The client's model is about the asset. The contractor's model is about the work performed on someone else's asset, indexed by locations someone else defined.

Software that fails to make that distinction pushes contractors into one of two bad shapes. Either it forces them to become a shadow owner, maintaining a parallel asset hierarchy that drifts out of step with the client's, or it degrades into a job-tracking tool with the readings as attachments, which is exactly the situation the multi-site roll-up problem describes.

Why four branches produce four incompatible datasets

The divergence is rarely carelessness. It is local optimisation. The branch serving a large refinery got client logins to their inspection data management system, so the technicians key readings straight in and the branch has no local dataset at all. The branch serving a cluster of midstream operators receives a spreadsheet template per campaign and returns it, so its data exists as several hundred workbooks in a shared folder. A third branch, serving smaller fabricators with no system of their own, built a database and produces a nicely formatted report. Each solved its own problem correctly.

Then head office asks a reasonable question — how many thickness readings did the company take last quarter, and what did they cost per reading — and there is no answer. The first branch's data is inside client systems it cannot query in bulk. The second's is in workbooks whose column layouts changed three times. The third's is queryable but uses its own location identifiers, so a client who also appears in branch one is double-counted or missed entirely.

The second-order damage is worse than the missing number. Because the branches never compare, practice drifts. One reports the minimum of a four-point grid, another reports each point and lets the client take the minimum, and a third records a single reading per location because that is what its clients ask for. Aggregate those and you produce a statistic that looks precise and means nothing, which is more dangerous than admitting you do not know.

A canonical identity with an alias map, never a renumbering

The workable architecture is one layer of indirection. Internally, every physical monitoring point gets a canonical identity the contractor generates and never changes. Externally, that identity carries one or more aliases: the client's CML number, the site it belongs to, the scheme version, and the dates over which the alias is valid. Deliverables always render the alias. Analytics always count the canonical. Neither side ever sees the other's vocabulary.

This solves a set of problems that look unrelated until you have the alias table. A client renumbers during a system migration, so you add a new alias with an effective date and the internal history survives. Two clients use the same CML number on different assets, which is common and harmless once identifiers are namespaced by client. A plant changes hands and arrives at a different branch under a new owner's numbering, and the contractor can still show it has fifteen years of continuity on those points, which is a genuine competitive argument at retender.

It also disciplines what "standardising" means politically. Branch managers resist standardisation when it reads as "stop doing what your client asked and do what head office prefers", and they are right to. The alias model asks them to change nothing client-facing. What gets standardised is the internal vocabulary — the exclusion reason codes, the technique fields, the grid definitions, the instrument register — which nobody outside the company ever sees and nobody has a reason to defend.

One written practice, or an audit finding waiting to happen

ASNT SNT-TC-1A is a recommended practice, not a standard that applies itself. It works through the employer's written practice, the document that says how this specific company trains, examines, qualifies and certifies its personnel in each method and level, with ANSI/ASNT CP-189 setting minimum requirements where a client invokes it and ISO 9712 governing where third-party certification is required. Every serious client audit asks for that document and then samples technicians against it.

Multi-branch contractors, particularly those built by acquisition, frequently carry more than one. The acquired company's written practice stayed in force because rewriting it meant requalifying people, so the group now has two definitions of an acceptable Level II in ultrasonic thickness measurement, two sets of training hours, and possibly two Level IIIs signing off with different interpretations. Nobody notices until an auditor asks the same question at two sites and receives two answers, at which point the finding is not about a technician — it is about the quality system, and it lands at group level.

The registry is where this becomes visible or stays hidden. If personnel qualification records live in branch HR folders, no one can run the query that reveals the divergence. If certification, method, level, examination dates, vision test dates and the governing written practice revision all sit against the technician record, and every reading references that technician, then the company can check its own conformity before a client does. Where operations span jurisdictions with different certification regimes, the record has to hold which scheme applies to which technician rather than flattening them into one field.

A rejected deliverable is an invoicing problem, not a data problem

Contracts for inspection services normally tie payment to accepted deliverables in a specified format within a stated number of days from completion. That single clause converts a data-formatting issue into a cash-flow issue. When a client's system rejects an import — wrong column count, an unknown location identifier, a date format the validator will not parse, a reading outside a plausibility band — the deliverable is not delivered, and the period keeps running while a technician who has already mobilised to the next job works out why.

The visibility problem is what makes this expensive. Rejections arrive as an email to one person. There is no ticket, no status, and no aggregate. Finance discovers the pattern only when a client queries an invoice, typically several weeks later, and by then the evidence trail is a mail thread. A company can be losing a meaningful share of its receivable ageing to import rejections without a single report showing it.

The fix is pre-submission validation against a stored format profile for each client: expected columns and order, identifier namespace, permitted units and precision, date format, mandatory fields, and plausibility rules such as a reading exceeding the recorded nominal or falling below the last known minimum by an implausible margin. Validate before the file leaves the building, log every rejection that still occurs against the client and the branch, and first-time acceptance rate becomes a number you can manage rather than an anecdote.

Instruments, techniques and the traceability a client audit follows

When a client audits a service provider, the trace runs backwards from a number in their system. Which technician produced it, what were they certified in and to what written practice on that date, which instrument was used, what was its verification status, what probe and technique, what surface condition and couplant, what temperature correction if any was applied on a hot line. Every one of those hops is a place the chain can break, and in a multi-branch organisation the most common break is the instrument.

Gauges travel. A branch with a shutdown coming borrows two units from a neighbouring region, and the verification log stays in the lending branch's cabinet. Six months later a reading from that period is questioned and nobody can produce the record for that serial number on that date. An instrument register keyed to serial number, holding verification events, reference block details, repairs and current custody, is the only structure that survives an asset moving between cost centres.

Technique is the quieter risk. Ultrasonic thickness measurement carries known traps that a bare number hides: reading through a coating without the correct mode, doubling on thin wall, back-wall loss on heavily pitted internal surfaces, uncompensated readings on elevated-temperature lines, and the difference between reading a single point and reading a grid. Where the client's own specification names the technique, the contractor's record should show the technique actually used, so any deviation is discoverable by the contractor before it is discovered by the client.

What to test before you commit to a system

Run the alias test first, because everything else depends on it. Load two clients whose CML numbering collides, then a third whose scheme changed at a system migration, and ask the system to produce both a company-wide count of distinct locations and a client-format export for each. If the alias map only allows one identifier per location, or if the export can only render the internal identity, the architecture will not carry a multi-client business regardless of the rest of its features.

Second, test the field-to-accepted path with the network turned off. Crews work in areas without coverage, in gloves, under time pressure, and often on someone else's site under someone else's device policy. Capture offline, sync without conflict, validate against the client's format profile, and produce the deliverable — then measure how many manual steps sit between the technician finishing and the client's system accepting the file. Every one of those steps is where a branch will invent its own workaround, and the workaround is how divergence starts again.

Third, look at governance of the vocabulary itself. Who can add an exclusion reason code, and can a branch add one locally? If yes, the code list fragments within a year and the rework metric dies with it. If no, the list has to be maintained centrally and quickly enough that branches do not resort to free text. That balance — a governed central vocabulary with a fast path for legitimate additions — is the difference between standardisation that holds and standardisation that gets quietly worked around. Atlantis NDT builds this registry around the client schemes and deliverable formats a contractor already has to satisfy; scoping conversations and demonstrations are available on request at info@atlantisndt.com.

Request a consultation