Loss of Containment (LOC) Event Repository Data Consistency

Loss of Containment (LOC) Event Repository Data Consistency

My last blog post titled "How to improve RBI predictions using a consolidated central repository of failure events" received some great comments. The best one came from Haider Javaid, and here is his LinkedIn profile: (4) Haider Javaid | LinkedIn. Haider said, "The repository idea holds up. The part that usually breaks it is that two operators will describe the same damage mechanism three different ways in their incident reports, so the model ends up learning vocabulary instead of failure. Normalizing that against a common taxonomy is unglamorous work, but it decides whether the whole thing produces signal." Haider, thank you for inspiring me to write this blog.

Haider is absolutely correct. Entering event data into the database without validation makes normalization more difficult. Therefore, for a global loss of containment (LOC) event database/repository, the most important principle is:

If the input data is inconsistent, incomplete, or biased, the analytics built on top of it will produce misleading recommendations.

In my humble opinion, the repository should therefore operate more like an aviation accident database than a simple incident log. Every record should be traceable, standardized, and technically validated.

Below are recommended constraints and business rules.

1) Source Validation

Event record source validation is very important. It provides the evidence for confidence scoring. Every record should include:

• Source
• Publication date
• Organization
• Investigator
• Report number
• URL or document reference
• Copyright status

Here is an example:

• Source:
  • CSB Investigation Report
  • Report No. 2019-03-I-TX
  • Published:
  • June 2021
  • Confidence Score: 5

Never allow anonymous technical conclusions.

2. Required Minimum Data

Set a minimum data requirement. Event records shall have the following fields populated:

Event

• Date
• Country
• Facility
• Unit
• Equipment
• Material
• Released fluid
• Release type
• Event description

If any of these are missing, reject the record.

3. Standard Equipment Taxonomy

The event record input template should never allow free-text equipment names. Instead, it shall have controlled cascading lists for:

• Equipment Class – per common API equipment categories

• Equipment Type – per common API equipment types

• Component Type – per common API component types

4. Materials

Materials selected from approved standards only. Below are some examples:

• ASTM
• ASME
• EN
• ISO
• DIN
• JIS

Materials of construction must have a material specification per the appropriate code or the common manufacturer's name. See the examples below:

• SA-106 Grade B
• SA-516 Grade 70
• 316L SS
• Inconel 625
• Duplex 2205
• Monel 400

Never accept unspecified generic names. Here are some examples:

• "Steel"
• "Carbon Steel"
• "SS"

5. Fluid Standardization

Select fluids from a controlled, validated list. Ideally, it should be a composite of the lists from:

• OSHA
• EPA
• ECHA
• HSE
• Health Canada / Environment and Climate Change Canada
• Safe Work Australia
• Japanese Government / NITE
• Chinese Government / MEE
• Government of India / PESO

Examples include:

• Hydrogen
• Wet H2S
• Amine
• Crude Oil
• Natural Gas
• Ethylene
• Steam
• Cooling Water
• HF Acid
• Sulfuric Acid
• Caustic
• Ammonia
• Propane
• LPG
• Methanol
• Ethanol
• Hydrogen Chloride
• Oxygen
• Nitrogen

6. Damage Mechanism Rules

Damage mechanisms should only come from recognized sources. See the list of examples below:

Some examples include:

• HTHA
• CUI
• External Corrosion
  • Atmospheric
  • CUI
• Internal Corrosion
  • General
  • Localized
  • Pitting
• Sulfidation
• Amine SCC
• Chloride SCC
• Fatigue
• Thermal Fatigue
• Hydrogen Blistering
• Hydrogen Embrittlement
• Erosion
• FAC
• MIC
• Galvanic Corrosion
• Temper Embrittlement
• Polythionic Acid SCC
• Graphitization
• Creep
• Stress Rupture

Never allow just a damage mechanism like "corrosion" without qualifiers like:

• External
• Atmospheric
• CUI
• Internal
• General
• Localized
• Pitting

Qualifiers must be specified. If these are missing, reject the record.

7. Failure Cause Hierarchy

To make the most of the event data, create a failure cause hierarchy and taxonomy that moves from the immediate cause to more researched causes. Here are some recommendations below:

Level 1 - Immediate Cause

• Examples:
  • Pipe rupture
  • Valve leak
  • Flange leak
  • Instrument failure
  • Tank crack

Level 2 - Physical Cause

• Examples:
  • General corrosion
  • Localized corrosion
  • Fatigue
  • Overpressure
  • Thermal expansion
  • Hydrogen damage
  • External impact

Level 3 - Underlying Cause

• Examples:
  • Inspection missed
  • Incorrect RBI interval
  • Poor design
  • Wrong material
  • Improper repair
  • Management of Change failure
  • Training deficiency
  • Procedure not followed

Level 4 - Organizational Cause

• Examples:
  • Budget reduction
  • Deferred maintenance
  • Contractor issue
  • Management system failure

8. Failure Conditions

We need to capture general conditions at the time of, or shortly before, failure. Here are some recommendations:

• Operating Pressure
• Operating Temperature
• Flow Velocity – especially for acids
• Stream Composition – in addition to the standard fluid above
• Corrosion rate – used to predict remaining life
• Age – time in service
• Inspection history summarized – including inputs to the condition forecast
• Previous repair/replacement history summarized

9. Confidence Score

Every event record should have a confidence score, such as:

Verified by Impartial investigation - 5

Verified by metallurgical examination - 4

Company Official investigation - 3

Engineering judgment - 2

Witness statement - 1

Media report - 0

This ensures that any target AI can weigh information accordingly.

10. Duplicate Detection

The database should check for duplicate records. It should periodically and  automatically check the following for each record:

• Date
• Location
• Equipment
• Source
• Description similarity

If it finds duplicate records, it should flag them for review. This avoids skewed results from duplicate events.

11. Mandatory References

Every failure event technical conclusion must have evidence. Here are some examples:

• Laboratory report
• Metallurgical report
• CSB investigation
• Inspection report
• Failure analysis
• Photographs
• API reference

Unsupported conclusions should not be allowed.

12. Image Requirements

If some of the evidence is photographs or images, the recommended minimum metadata should be:

• Equipment
• Orientation
• Damage location
• Damage mechanism
• Scale
• Date

13. AI Readability Rules

Every field for each event record should be machine-readable. That means specific values like:

• Pressure = 835 psig
• Temperature = 725°F

They should never be vague descriptions, such as:

• Pressure = High
• Temperature = Very Hot

15. Standard Units

Units of data fields need to be standardized  and automatically converted, such as:

• psi ↔ MPa
• °F ↔ °C
• ft ↔ m
• gal ↔ L
• lb ↔ kg

Store the original units alongside the conversions.

16. Security and Privacy

Separate technical data from sensitive information.

Store separately:

• Company identity (optional or anonymized)
• Personnel names
• Witness statements
• Legal findings
• Insurance information
• Litigation documents

Provide role-based access controls so contributors can share technical lessons while protecting confidential or legally sensitive information.

A well-governed Global Loss of Containment Event Repository should be more than a collection of incident reports; it should serve as the industry's authoritative technical knowledge base for process safety. By enforcing standardized taxonomies, validated engineering data, traceable evidence, and confidence scoring, it can support consistent failure investigations, improve API 580/581 Risk-Based Inspection (RBI) assessments, identify emerging trends in damage mechanisms, benchmark reliability across industries, and provide high-quality training data for AI systems that predict and help prevent future loss-of-containment events. This transforms historical incidents into actionable engineering intelligence that continuously improves mechanical integrity and process safety worldwide.

Be the first to comment

There are no comments for this article.