API 580 and 581: a defensible RBI program

Risk-based inspection is easy to buy and hard to defend. The promise is that inspection effort moves to where risk is, intervals stretch where risk is low, and the program spends less to find more. The failure mode is that a risk number with no visible pedigree becomes the justification for skipping an inspection, and when the auditor or the incident investigator asks what stood behind it, the answer is a software output nobody can reproduce. API 580 exists to prevent that. API 581 exists to make it quantitative. This paper describes what a defensible program does with both, and what the record must carry so the risk number is evidence rather than an opinion.

What is the difference between API 580 and API 581?

API 580 is the recommended practice on the process of risk-based inspection. It defines the elements a program must contain: data collection and quality, damage mechanism identification, probability of failure assessment, consequence of failure assessment, risk determination, risk management through inspection planning, other risk mitigation, reassessment, roles and training, and documentation. It permits qualitative, semi-quantitative and quantitative approaches, and it is deliberately method-neutral.

API 581 is the methodology. It gives the generic failure frequencies, the damage factor equations, the management systems evaluation, the consequence models, the risk matrix layout, the inspection effectiveness tables and the inspection planning logic. A program can follow API 580 without using API 581 numbers, but a program that uses API 581 numbers is expected to satisfy API 580 process requirements.

The distinction matters for the record. API 580 compliance is demonstrated by documents: the team, the data sources, the assumptions, the risk target, the plan, the reassessment schedule. API 581 compliance is demonstrated by calculations whose inputs can be traced. A program needs both kinds of evidence, and a review that finds one without the other is a finding.

How is probability of failure built up?

In API 581, probability of failure for a component is the product of three terms.

• Generic failure frequency (GFF). A base leak frequency for the component type (vessel, pipe, tank, exchanger), distributed across four representative hole sizes from a small leak to rupture. These are industry values, not site values.
• Damage factor (Df). The site-specific multiplier. Separate damage factors are computed for thinning, stress corrosion cracking, external damage including corrosion under insulation, high-temperature hydrogen attack, brittle fracture, mechanical fatigue for piping, and lining failure, then combined. The thinning damage factor rises with the fraction of required wall consumed by the corrosion rate over the component's age, and it is adjusted by the number and effectiveness of past inspections.
• Management systems factor (FMS). Derived from a structured evaluation of the site's mechanical integrity management system: leadership, process safety information, procedures, training, inspection program, MOC, incident investigation and so on. A weaker system raises probability across the whole plant.

The damage factor is where inspection data enters. If the corrosion rate is well established by repeated, well-graded inspections, the uncertainty is low and the damage factor is modest. If the rate is assumed from a table because no readings exist, API 581 treats the uncertainty as high and the damage factor climbs. The practical effect is that a program with poor thickness data will compute high probability and short intervals until it does the inspections that establish the rate. Software that lets a user override the damage factor without recording why has removed the discipline that makes the method work.

How is consequence of failure assessed?

API 581 assesses consequence for each hole size and combines them. The Level 1 consequence analysis uses a set of representative fluids with tabulated properties; Level 2 uses the actual fluid.

• Release rate and type. From hole size, pressure and fluid phase, and whether the release is instantaneous (a large inventory lost quickly) or continuous.
• Detection and isolation. Credit for instrumentation that detects a leak and systems that isolate it, which reduce the released mass.
• Flammable consequence. Consequence areas for equipment damage and personnel injury, from pool fire, jet fire, flash fire and vapor cloud explosion outcomes with event tree probabilities.
• Toxic consequence. Areas for toxic exposure for fluids such as hydrogen sulfide, hydrogen fluoride, ammonia and chlorine.
• Non-flammable, non-toxic consequence. Steam, acids and caustics, based on physical effects of the release.
• Financial consequence. Equipment damage, production loss from outage, personnel injury cost and environmental cleanup, so that risk can be expressed in currency per year where a site prefers that to area.

Consequence inputs are where programs quietly go wrong. The inventory available for release depends on how the inventory group was defined. The population density assumption drives personnel consequence. The isolation credit depends on whether the isolation valve actually works. Each of these is a recorded assumption with a source, or it is a guess wearing a decimal point.

How does inspection effectiveness change the risk?

API 581 grades every past inspection for each damage mechanism into an effectiveness category.

• A, highly effective. The method and coverage will correctly identify the damage state in nearly all cases. For general thinning, this looks like extensive thickness measurement or scanning over the susceptible area.
• B, usually effective. Correct identification most of the time.
• C, fairly effective. Correct identification about half the time.
• D, poorly effective. Correct identification infrequently; for example spot readings where local thinning is the mechanism.
• E, ineffective. The method cannot detect the mechanism, or no inspection was performed.

The damage factor is reduced according to the number of inspections at each grade. Two B inspections do more than one, and one A inspection may do more than several C inspections. This is the mechanism by which RBI rewards good inspection and penalizes weak inspection, and it is the reason a program cannot claim credit for an inspection it cannot describe. To grade an inspection A for CUI, the record must show the insulation removal extent and the NDE performed. If the record says only "external visual, no findings," the honest grade is D or E.

This is the strongest argument for keeping inspection records and RBI in one place. Grading an inspection from a PDF three years later is guesswork. Grading it from the structured record of method, extent and locations is a query.

What makes an RBI program defensible to an auditor?

A program that would survive a regulator, an insurer or an incident board has these properties.

• Data pedigree. Every design, process and inspection input has a source and a date. Where a value is assumed, the assumption is marked as such and its conservatism is stated.
• Named mechanisms. Damage mechanisms are assigned per component from a documented review, not inferred by the software from fluid type alone.
• Written risk target. The acceptable risk, whether area or financial, is written down and approved, and the inspection plan shows the date at which each component's risk reaches the target.
• Traceable intervals. The plan states the interval, the inspection effectiveness required, and how that inspection brings risk back under target. The API 510 and API 570 interval rules still apply unless the RBI assessment is documented and approved to override them.
• Reassessment that runs. Triggers are defined: new inspection data, process or feed change, repairs, MOC, incident, and the maximum cycle the codes set. The record shows when each reassessment happened and what changed.
• Approvals and segregation. The person who built the assessment is not the only person who approved it. Engineering and inspection both sign.
• Reproducibility. The calculation can be rerun from stored inputs and produce the same output. A risk number that depends on a spreadsheet version nobody kept is not evidence.

The common thread is that a defensible program stores decisions, not just results. The result is the interval. The decision is everything that produced it.

What are the common failure modes of RBI programs?

Programs rarely fail at the math. They fail at the edges.

• Default inputs left in place. Conservative defaults that were meant to be replaced with site data stay for years, and the program computes either inflated risk that wastes effort or, worse, credit for inspections that were never done.
• Consequence drift. Inventory groups, populations and isolation credits set at implementation are never revisited as the plant changes.
• Interval extension without effectiveness. The interval is stretched on the strength of a low risk number, but the inspection that would justify the low damage factor is graded generously.
• No reassessment after change. A feed change introduces a new mechanism, and the RBI model does not know because the MOC process does not talk to it.
• Orphaned assessments. The engineer who built the model leaves, the tool license lapses, and the assessment survives only as a printed risk matrix.
• Software as authority. The output is treated as the decision rather than as input to one. API 580 places the decision with the owner-user team.

Each of these is a record-keeping failure before it is an engineering failure, which is why the structure of the record is the first thing to fix.

How intelliSPEC handles it

intelliSPEC carries RBI in intelliINTEGRITY as a semi-quantitative API 580 and 581 scoring: probability multiplied by consequence, each ranked one to five, against the component record. Damage mechanisms are first-class records, not text fields, so thinning and cracking mechanisms assigned in a review attach to the component and travel with it into the risk calculation and the inspection plan. The API 510 and API 570 interval remains capped at half the remaining life, and the corrosion summary that feeds it produces short-term, long-term and governing rates from the CML history held in intelliNDT.

The controls that make an assessment defensible are in the platform rather than in a procedure. Every create, update and approval carries actor, tenant, request id, IP address and user agent and is linked into a SHA-256 hash chain per tenant that a verify routine recomputes for auditors. Calculators are individually permissioned among 991 permission entries, and a segregation-of-duties rule prevents a calculator author from approving their own work. Workflow transitions including submit, approve, reject, hold and owner sign-off record who moved an assessment and when. Completed records pin the form configuration, locale and reference options they were executed with, so an assessment approved in a prior cycle renders exactly as it was signed. Results that depend on engineering judgment, such as ASME B31G remaining strength, are held as provisional until an engineer verifies them and are never applied to derate a component automatically.

The inspection records that RBI grades live in the same asset graph as the assessment, with method, extent, locations and photos structured at capture, so effectiveness grading reads from the record rather than from memory. Chemical and petrochemical sites, where consequence modeling carries toxic as well as flammable outcomes, are described on the chemical page, and the terms used here are defined in the glossary.

RBI is a way of deciding where to look. The program is defensible when the deciding is on the record.