Risk-based inspection conversations tend to blur two documents that do different jobs. API 580 is the recommended practice that defines what a credible RBI program must contain: its elements, its data requirements, its documentation, its limits. API 581 is one methodology that satisfies it: a specific, quantitative procedure for computing probability of failure, consequence of failure, and the risk that drives an inspection plan. You can run a program under API 580 without using API 581. You cannot sensibly use API 581 outside the discipline API 580 describes.
What API 580 governs
API 580 is about program integrity, not arithmetic. It answers the question: what has to be true for a risk-based interval to be defensible?
- Scope and boundaries. Which equipment is in the program, which is out, and why. RBI applied to half a unit with the other half on time-based intervals is fine, if the split is documented.
- Data quality. Risk output is only as good as thickness history, process conditions, and damage mechanism identification going in. The practice expects the program to know where its data is weak and to treat those results with appropriate conservatism.
- Team and competence. RBI is a multi-discipline exercise: inspection, process, materials, operations. The practice expects the roster and their qualifications to be part of the record.
- Documentation and reassessment. Every risk ranking must be traceable to its inputs, and the assessment must be revisited on a schedule and after significant changes: process shifts, incidents, inspection findings that contradict the model.
Qualitative, semi-quantitative, and fully quantitative approaches are all admissible under API 580, provided the approach is documented and consistently applied.
What API 581 governs
API 581 is the quantitative engine. It computes probability of failure by starting from a generic failure frequency for the equipment type and modifying it with damage factors: how much damage is expected from each active mechanism, and how much confidence the inspection history provides about the equipment's actual state. More effective inspection reduces uncertainty, which reduces the damage factor, which reduces computed probability.
Consequence is computed separately: release size, fluid behavior, affected area or financial impact. Risk is the product, tracked against a target, and the inspection plan is the set of activities that keeps risk below that target through the plan period.
Two practical implications follow:
- Inspection effectiveness is graded, and the grade matters. A poorly documented inspection may not earn credit in the model, which means the record quality of past work directly changes future intervals.
- The model has an appetite for data. Process conditions, fluid composition, thickness history per component. Thin data forces conservative assumptions, which forces shorter intervals. The economics of RBI are mostly the economics of data quality.
What an auditor checks in each
Against API 580, the auditor checks the program: scope decisions, team qualifications, data quality controls, reassessment triggers, and whether documented procedure matches actual practice. Against API 581, the auditor checks traceability: pick an equipment item and walk from its risk ranking back through damage factors, inspection effectiveness grades, and consequence inputs to source records. Rankings that cannot be walked back are opinions with decimal points.
The common thread is that both documents make the inspection record load-bearing. The interval extension RBI promises is purchased with evidence, and the evidence has to be findable years later.
intelliSPEC keeps the inspection history, effectiveness evidence, and thickness data that RBI consumes in one traceable record. If your RBI program is fighting its own data, bring an example to a demo.
