Of all the arithmetic in an inspection program, remaining life is the calculation auditors check first, because everything hangs from it. The formula is short: current thickness minus minimum required thickness, divided by corrosion rate. The next inspection interval then follows from the half-life rule: half the remaining life, capped by the code maximum for the equipment class. Three inputs, one division, one halving. Every term has its own way of being wrong, and audits are essentially a tour of those ways.
Input one: current thickness
The numerator starts with the latest reading at the governing location. The failure modes are familiar: a reading paired to the wrong CML, a stale value carried forward because the latest survey never made it out of a field file, or an average used where a minimum was required. For remaining life, the question is always the worst credible location, and the record has to show which reading, from which date, at which CML, was taken as current.
Input two: minimum required thickness
This is the quietly dangerous input. Minimum required thickness is a design calculation: pressure, temperature, allowable stress, joint efficiency, and geometry produce the thickness the component needs to do its job, plus any structural minimum that governs instead. Two failure modes dominate:
- The inherited number. A t-min copied from an old report, whose basis nobody can produce. When the auditor asks how it was derived, the file has no answer, and every remaining-life figure built on it is unsupported.
- The unrevised number. The equipment was rerated, the operating conditions changed, or the service was re-specified, and the minimum thickness was never recalculated. Remaining life is then measured against the wrong floor.
A defensible file carries the t-min per component with its calculation basis and revision history, not a bare value.
Input three: the corrosion rate
The rate comes from the thickness history, evaluated both long-term and short-term, with the more conservative result governing. The audit interest here is which rate was used and why. A program that always uses the long-term rate has, in effect, a policy of ignoring recent acceleration, and that pattern is visible across a file in minutes.
The halving, and why it exists
The interval is set at half the remaining life, subject to the code's maximum. The halving is the code's margin philosophy in one move: if the rate estimate is wrong by a factor approaching two, the next inspection still arrives before the metal reaches minimum. Programs that find the halving painful usually have a rate problem, not an interval problem. The cure is better data, tighter CML identity, and honest recalculation, not creative rounding.
Two consequences follow. First, remaining life is not computed once. Every survey refreshes the rate, which refreshes the life, which can shorten or lengthen the interval. A plan whose intervals never move while its readings keep arriving is a plan nobody is recomputing. Second, when remaining life gets short, the halving compresses intervals quickly, and that compression is the code working as intended: the program is being pushed toward a repair, rerate, or fitness-for-service decision, on the record.
The reconstruction test
The audit standard is reconstruction: from the file alone, recover the current reading and its CML, the t-min and its basis, both rates and the one that governed, the division, the halving, the cap check, and the sign-off. Any link supplied from memory is a finding waiting to be written.
intelliSPEC runs this chain from stored history, so the number in the plan and the evidence behind it are the same record. Bring one vessel file to a demo and reconstruct it live.
