API 571 is the reference document for damage mechanisms in fixed equipment: what each mechanism is, what drives it, what it looks like, where it occurs, and how to find it. It is organized as a library, and that is exactly how programs misuse it. A library on the shelf answers no audit questions. The working question is always the same: for this equipment, in this service, which mechanisms are credible, and what does the inspection plan do about each one?
From library to susceptibility call
Each mechanism entry follows a pattern that maps directly onto program decisions:
- Description and affected materials tell you whether the mechanism is even possible for the metallurgy in question.
- Critical factors tell you whether the service conditions can drive it: temperature ranges, contaminant levels, water presence, stress state.
- Appearance and morphology tell you what the damage looks like when found, which is how findings get attributed to the right cause.
- Prevention and monitoring tell you which inspection technique can actually detect it, which is where many plans quietly fail.
A susceptibility review takes each equipment item or corrosion loop through this pattern and records the outcome both ways: mechanisms ruled in, with the driving conditions noted, and mechanisms ruled out, with the reason. The ruled-out list matters more than most programs think. When an auditor or an incident investigation asks why wet H2S cracking was never inspected for, "we assessed it and here is why it is not credible" is a defense. Silence is not.
Matching technique to mechanism
The most common gap between a mechanism list and an inspection plan is technique mismatch. General thinning is found by straight-beam thickness readings at CMLs. Localized corrosion under deposits can walk between CMLs, which pushes toward scanning coverage. Cracking mechanisms are invisible to a thickness gauge entirely and need surface or volumetric methods chosen for the crack orientation and location. High temperature hydrogen attack, embrittlement mechanisms, and creep each carry their own detection problem.
The plan therefore has to record not just what will be inspected and when, but with what technique and why that technique answers the mechanism in question. A plan that inspects a cracking-susceptible circuit with thickness readings on schedule is compliant-looking and blind.
Conditions change, and the review must follow
Susceptibility is a function of service conditions, and service conditions drift: feed composition shifts, temperatures creep, injection chemistry changes, units run outside original design envelopes. Integrity operating windows exist to catch these drifts, and each excursion is a prompt to ask whether the mechanism review still holds. A review dated before a major process change is evidence of the wrong thing.
This is why the mechanism review belongs in the equipment record with a date and a revision trail, not in a study binder. The questions that reach it years later are always specific: what did you believe about this exchanger, when, and based on what conditions?
The record that makes it real
A working API 571 practice leaves this trail per item: the credible mechanism list with driving factors, the exclusions with reasons, the technique assignments, the review date and participants, and the linkage from any inspection finding back to the mechanism it confirmed or contradicted. Findings that contradict the review are the most valuable records in the file, because they are the trigger for updating it.
intelliSPEC ties findings, techniques, and equipment history into one record, so the mechanism review has current evidence to stand on. Bring a corrosion loop to a demo and see how the trail holds together.
