Ask why a vessel's next internal inspection is due in March 2028 and you learn a lot about a site. The good answer cites a basis: a code interval, a half-life calculation from measured corrosion rates, or a risk assessment with a date and an approver. The common answer is that the date is in the spreadsheet, and the spreadsheet inherited it from the previous spreadsheet.
A due date without a recoverable basis is not a schedule. It is a superstition with a reminder attached.
What a due date is made of
Every defensible date is a conclusion from inputs, and the inputs should be inspectable.
- The governing rule. Which code clause, jurisdiction requirement, or internal standard sets the maximum interval for this equipment class. Recorded on the schedule item, not assumed.
- The condition inputs. Last inspection date and result, measured corrosion rates, remaining life at the limiting CML. When the interval is half of remaining life, the date is only as good as the thickness data underneath it, which is why gauge-to-record integrity matters upstream.
- The risk position, if you run RBI. A risk-based interval carries its assessment: the damage mechanisms considered, the consequence ranking, the analysis date, and the approver. An RBI-extended interval whose assessment cannot be produced is worse than a code interval, because it looks deliberate.
- The deferral history. If the date moved, the record shows the original date, the justification, the risk review, and the signature. A date that was quietly retyped has no history, and retyped dates are what audit findings are made of.
Why spreadsheets fail at this
The spreadsheet failure is not sloppiness, it is architecture. A cell holds a value, not a derivation. When a new thickness survey shortens remaining life, nothing recalculates. When the corrosion engineer updates a rate, the due dates that depend on it do not know. The linkage lives in someone's head, and heads rotate.
The failure compounds at handover. The new inspection lead inherits four thousand dates and no way to tell which were calculated, which were deferred, and which were typos. The rational response is to trust none of them, and rebuilding trust takes a year the program does not have.
Scheduling as a living calculation
The alternative is a schedule where dates are outputs.
- Each schedule item declares its basis: fixed interval, remaining-life fraction, or RBI, with the parameters attached.
- New data triggers recalculation. A survey that doubles the corrosion rate at the limiting CML pulls the date in, and the change is visible, attributed, and dated.
- Deferrals are workflow, not edits. A move past the basis date requires documented justification and a named approver, and the original date stays in the record.
- The lookahead is a query. What comes due in the next 12 months, by unit and access requirement, feeds turnaround scoping directly instead of being reassembled by hand each planning cycle.
The self-defending test
Pick five due dates at random and ask each one why. A defensible program answers all five in minutes, from the record: rule, inputs, calculation, approvals, deferral history. That same production is what a regulator asks for after an incident, except then the answer is graded.
If your dates live in cells, start with the ten most consequential vessels and rebuild their basis. The exercise usually finds at least one date nobody can explain, and that discovery is worth the afternoon.
intelliINTEGRITY holds the interval basis, recalculates from incoming thickness and RBI data, and keeps deferral history on the record, so the schedule assembles its own defense as work happens. Bring five of your dates to a demo and ask them why.
