An RBI model can be technically sophisticated and still produce a weak inspection plan if the facility data behind it is inconsistent, outdated or poorly controlled. Before full modelling begins, an aging process facility needs a traceable basis that connects the correct assets, current operating conditions, credible degradation evidence, inspection history and consequence assumptions.
Data readiness is not the same as collecting every possible field. It means the available information is sufficient for the intended decision, known gaps are visible, and each material uncertainty has an owner and a treatment plan. The practical outcome is one of four choices: proceed, proceed with controlled limitations, run a pilot first, or remediate the data before modelling.
Key Takeaways
- A completed RBI spreadsheet does not prove that the underlying asset identity, service history or inspection evidence is reliable.
- Data requirements describe the inputs a method may need; data readiness asks whether those inputs are current, consistent, traceable and owned.
- Aging facilities need extra attention because tag drift, undocumented modifications, changed service and fragmented inspection history can alter the risk basis.
- Gaps should be classified by their effect on the decision—not by the number of empty fields.
- The readiness review should end with a controlled decision to proceed, pilot, qualify limitations or complete targeted remediation.
Why RBI Projects Fail Before the Model Starts
Risk-Based Inspection depends on a controlled data basis, not only on software or a completed input template. If the wrong equipment boundary, stale process condition or untraceable inspection result enters the model, the calculation may appear complete while the inspection priority is built on the wrong context.
API RP 580 provides programme-level guidance for developing, implementing and maintaining RBI, while API RP 581 provides a quantitative methodology for evaluating Probability of Failure and Consequence of Failure. Both depend on the quality and governance of the information supplied. The applicable project edition and specification must be confirmed before detailed implementation.
For the detailed technical input families used in an RBI study, see NWE’s RBI data requirements guide. This article addresses the earlier question: are those inputs controlled well enough to use?
Common pre-model failure patterns include:
- P&IDs, the CMMS/EAM register and inspection files use different tags or equipment boundaries.
- The design file describes the original service, but the unit has changed feed, temperature, pressure or duty.
- Inspection reports contain values, but the readings cannot be linked to a consistent asset, location, method or date.
- Consequence assumptions are copied from an earlier study without a current owner or review date.
- Data gaps are hidden in defaults, or the project stops because every missing field is treated as equally critical.
- A software configuration is ready, but no process exists to update the data after modifications, incidents or new inspection findings.
What RBI Data Readiness Actually Means
Data is ready when asset identity, operating context, evidence confidence and ownership are sufficient for the decision the RBI programme must support. Readiness is therefore decision-specific. A dataset may be adequate for a limited pilot but not for a full facility rollout.
The goal is not perfect data. It is a controlled, traceable basis that makes uncertainty visible before it changes risk ranking, inspection scope or management decisions. A practical readiness review should be able to reach one of four outcomes:
| Outcome | Meaning | Control needed |
| Proceed | Critical data families are reconciled and material gaps are closed | Approve the controlled dataset and modelling scope |
| Proceed with limitations | The model can run, but one or more uncertainties may influence interpretation | Record the limitation, decision impact, owner and closure action |
| Pilot first | The facility is too complex or uncertain for immediate full rollout | Test a representative unit, challenge the outputs and refine the basis |
| Remediate before modelling | A gap can materially change identity, damage mechanisms, POF/COF or inspection scope | Close the gap through records recovery, field verification or targeted inspection |
NWE’s Risk-Based Inspection services provide the commercial service path. The readiness review described here helps define whether the immediate need is modelling, a pilot or data remediation.
RBI Data Readiness Matrix
Seven dimensions should be challenged before full modelling. This matrix is a practical editorial tool for project planning; it is not an API scoring system and does not create a universal pass mark.
| Dimension | Ready | Conditionally ready | Remediation required |
| Asset identity & hierarchy | Tags, boundaries and circuits reconcile across systems | Minor naming differences are controlled by an approved mapping | Duplicate/missing tags or wrong boundaries could change model scope |
| Design & materials | Design basis, material and key geometry are traceable | Selected values are estimated with a documented basis | Unknown values could change damage selection, POF or inspection scope |
| Operating context | Current service, actual envelope and relevant changes are validated | Limited history exists, but current conditions are confirmed | Stale service data or undocumented process changes remain |
| Damage mechanisms | A credible mechanism basis links service, materials and history | Some uncertainty exists with a planned validation action | Screening is unsupported, contradictory or copied without facility context |
| Inspection history | Results map to equipment, location, method and date; confidence is understood | Usable history exists with explicit limitations | Readings are untraceable, mixed between tags or coverage is unknown |
| Consequence context | Safety, environment and production assumptions have owners and dates | Some business inputs remain provisional | Missing or obsolete assumptions could change ranking |
| Governance | Source of truth, data owner, change log and update triggers are defined | Temporary ownership is accepted for a pilot | No owner, uncontrolled spreadsheets or no update process |
Asset Register and Hierarchy Readiness
RBI cannot be controlled if the facility’s systems do not describe the same assets. A P&ID may show one equipment boundary, the CMMS may use another tag structure, and inspection files may group circuits differently. The first readiness task is to reconcile those identities before any risk result is attached to them.
A controlled asset basis should define the unit and equipment scope, parent-child hierarchy, piping or corrosion circuits where applicable, service boundaries and the mapping between source systems. It should also show which source is authoritative when records disagree.
Practical checks include:
- Do P&ID tags, CMMS/EAM IDs and inspection-report identifiers resolve to the same physical equipment?
- Are retired, replaced or bypassed items still present in one system?
- Have modifications changed circuit boundaries, isolation logic or service grouping?
- Can each model item be traced back to a current drawing and a field-verifiable location?
- Is there a controlled mapping for legacy names rather than silent manual interpretation?
When drawings, tags or equipment boundaries cannot be reconciled, as-built preparation and validation may be required before the RBI dataset is treated as controlled.
Design, Materials and Equipment Data
A legacy gap matters when it can change the damage-mechanism basis, Probability of Failure or inspection scope. Not every missing document is decision-critical, but an unknown material, wall basis, geometry or design condition may prevent the team from selecting or challenging the correct model assumptions.
| Gap | Readiness question | Typical treatment |
| Material grade or specification uncertain | Could the uncertainty change susceptibility, allowable basis or degradation model? | Recover records, verify material where justified, or use a technically reviewed treatment |
| Design condition differs across files | Which condition belongs to the current equipment and modification state? | Reconcile revision history and identify the approved basis |
| Geometry or component details missing | Does the model or inspection plan depend on that feature? | Field verify or recover controlled drawings |
| Repair / replacement history incomplete | Has the physical asset changed while the register retained the old basis? | Reconstruct the change and update asset identity |
Avoid filling decision-critical gaps by habit or convenience. A conservative value may be acceptable in some project contexts, but only when the technical team has reviewed how it affects ranking, scope and downstream decisions.
Operating History and Integrity Operating Context
Original design data cannot replace evidence of actual service. Aging facilities often accumulate changes in feed composition, temperature, pressure, throughput, water content, contaminants, operating mode and shutdown frequency. These changes can alter both the credible damage mechanisms and the rate at which they progress.
The readiness review should establish the current operating envelope, identify material historical periods, and connect excursions or abnormal events to the affected equipment. It should also distinguish a verified current condition from an assumed or outdated value copied from the design file.
A practical operating-history review asks:
- What service does the equipment perform now, and when did it change?
- Which normal and abnormal conditions are relevant to degradation?
- Are laboratory, process historian and operations records aligned with the period covered by inspection data?
- Have excursions, trips, contamination events or long idle periods been captured?
- Who owns the operating basis and confirms that it remains current?
For the broader relationship between operating limits, RBI, FFS and aging assets, see sustainable operation planning for aged oil and gas facilities.
Damage Mechanisms and Degradation Rates
An RBI model needs a credible explanation of what can degrade the equipment and why. A copied list of damage mechanisms is not enough. The basis should connect materials, service conditions, contaminants, temperature history, equipment geometry, inspection findings and known failure experience.
At readiness stage, the question is not whether every mechanism has been calculated in detail. It is whether the screening basis is current, traceable and technically coherent. Contradictions should be resolved before a risk ranking is treated as reliable.
Challenge the basis where:
- The listed mechanism does not match the current service or material.
- A historical corrosion rate is reused after a process or inspection-method change.
- Different reports assign different mechanisms to the same equipment without reconciliation.
- An apparent “no damage” conclusion is based on inspection that did not target the expected morphology.
- A degradation rate is precise, but its source period, locations or confidence cannot be reconstructed.
Inspection History, Coverage and Confidence
Inspection history is useful only when results map to the correct asset, location, method and date. A long archive may still have low decision value if the readings cannot be compared, the inspected area is unclear or the technique was not suited to the expected damage.
For RBI readiness, inspection evidence should be reviewed at programme level: coverage, repeatability, method relevance, result traceability, confidence and the relationship between findings and the current damage basis. Detailed NDT acceptance or thickness-data controls belong in the relevant inspection procedure and engineering workflow.
| Indicator | Ready question |
| Asset and location | Can the result be tied to the correct equipment, component and repeatable location? |
| Method and coverage | Was the technique and inspected area suitable for the expected degradation? |
| Date and service period | Does the inspection represent the operating conditions being modelled? |
| Result traceability | Can the summary be checked against the underlying report or data? |
| Comparability | Are changes between campaigns technical, or could they result from different locations or methods? |
| Open findings | Are anomalies, repairs, no-reads and follow-up actions closed or visible? |
Where data gaps require new field evidence, NWE’s in-service inspection service is a separate route from RBI engineering. The inspection scope should be defined by the uncertainty that affects the decision.
Consequence and Business-Impact Data
Consequence data is not just a set of numbers. Safety, environmental, production and business assumptions need a current facility context, a traceable source, an owner and a review date. Otherwise, risk ranking may reflect an old production configuration or an unverified estimate.
| Data family | Readiness control |
| Safety / personnel exposure | Confirm occupied areas, escalation context, isolation and credible release assumptions with the responsible discipline |
| Environmental impact | Identify the current receiving environment, containment and response basis |
| Production dependency | Confirm whether the equipment is still a bottleneck, has redundancy, or can be isolated without the assumed loss |
| Inventory / process state | Use current operating and isolation context rather than design-only values |
| Business values | Record owner, date, source and whether values are approved, provisional or scenario-based |
The readiness review does not need to reproduce the quantitative consequence method. Its purpose is to expose stale, ownerless or contradictory assumptions before they influence the ranking.
How to Classify and Close Evidence Gaps
Classify gaps by decision impact, not by document count. One missing material value may matter more than hundreds of incomplete administrative fields. Conversely, a missing source reference may not change today’s ranking but can undermine future auditability and model updates.
| Gap class | Definition | Recommended action | Example |
| Decision-critical | Could materially change asset identity, damage basis, POF/COF or inspection scope | Close before full modelling, or use a formally reviewed treatment when technically valid | Unknown material, wrong circuit boundary, missing service change |
| Confidence-limiting | The model may run, but interpretation or priority remains uncertain | Document limitation, review sensitivity and assign a closure action | Partial inspection history, provisional production impact |
| Governance / audit | May not change the immediate result but weakens traceability or updateability | Assign owner/date and close through a controlled backlog | Missing source metadata, inconsistent naming |
| Non-applicable | Not required for the selected scope or method | Document the rationale; do not collect data by habit | Field outside the selected equipment or methodology scope |
A useful gap register records the affected asset or data family, the source conflict, decision impact, selected treatment, responsible owner, due date and any temporary limitation. It should remain visible through modelling and approval—not disappear when the spreadsheet is populated.
If tags, operating history or inspection records do not reconcile, define the gap-closure scope before loading the full RBI model. The correct next step may be document recovery, field verification, targeted inspection, as-built validation or a limited pilot—not automatically a full new data-collection campaign.
Governance, Ownership and Update Triggers
RBI data becomes stale unless ownership and change triggers are explicit. A successful first model is not the end of data readiness; the facility needs a process for keeping the basis aligned with modifications, operating changes, new inspections and incidents.
Each critical data family should have a defined source of truth and an accountable owner. Where several systems must remain in use, the project should define which system controls identity, which stores evidence and how changes are reconciled.
Common update triggers include:
- Management of Change affecting service, materials, equipment configuration or isolation.
- New inspection findings, repairs, replacements or changes in degradation rate.
- Process excursions, incidents, leaks, trips or abnormal operating periods.
- Changes in production dependency, occupancy, inventory or consequence assumptions.
- New or revised project requirements, applicable standards or corporate risk criteria.
- Discovery of a material data error or an unresolved mismatch between source systems.
There is no universal review interval that fits every facility. The cadence should reflect risk, change frequency, regulatory or corporate requirements and the stability of the underlying data. Event-driven triggers should remain visible even when a periodic review is also used.
A Practical RBI Data-Readiness Review
A controlled review moves from the decision and facility scope to a verified dataset, visible gaps and an approved modelling route. The sequence below prevents teams from collecting everything before deciding what the model actually needs.
| Step | Decision question | Output |
| 1. Define decision and scope | Which units, equipment and management decision must the RBI study support? | Scope statement and boundaries |
| 2. Reconcile asset hierarchy | Do P&ID, CMMS/EAM and inspection IDs describe the same assets? | Controlled asset list and mapping |
| 3. Validate data sources | What are the source, date, owner and version of each data family? | Source register and confidence notes |
| 4. Classify evidence gaps | Which gaps can change the decision? | Gap register with impact class |
| 5. Close or control critical gaps | Is field verification, records recovery or a reviewed assumption required? | Remediation actions and limitations |
| 6. Run a pilot and challenge outputs | Does the ranking agree with plant knowledge and visible risk drivers? | Pilot review and challenge log |
| 7. Approve rollout and governance | Who updates the data and what triggers revalidation? | Rollout decision, owners and triggers |
The pilot step is especially useful in aging facilities with inconsistent records. A representative unit can expose hierarchy problems, repeated assumptions and workflow bottlenecks before they are scaled across the site. The pilot should be challenged by people who understand operations, inspection, corrosion, process safety and maintenance—not accepted only because the software produced a ranking.
Define the Next Step Before Full Modelling
The readiness decision should be explicit: proceed, proceed with controlled limitations, run a pilot first, or remediate before modelling. It should state which assets and data families were reviewed, which gaps remain, who owns them and how they affect the planned RBI scope.
Before committing to full modelling, prepare a concise package with the facility scope, current asset register, major source systems, known mismatches, recent process changes, available inspection history and the decision the RBI programme must support. That package makes the first technical discussion more useful and helps separate immediate model inputs from remediation work.
To define the appropriate next step, share the facility scope, current asset register and known data gaps through NWE’s Risk-Based Inspection service page. The discussion should determine whether the immediate need is data reconciliation, targeted evidence, a pilot or full RBI modelling.
Frequently Asked Questions
What is RBI data readiness?
RBI data readiness is the condition in which asset identity, operating context, degradation evidence, inspection history, consequence assumptions and ownership are sufficiently controlled for the intended RBI decision. It does not mean every possible field is complete.
How is RBI data readiness different from RBI data requirements?
Data requirements identify the information categories used by the selected RBI method. Data readiness checks whether those inputs are current, consistent, traceable, correctly assigned to assets and governed well enough to use.
Can an RBI study start with incomplete data?
Sometimes. The answer depends on the impact of the missing information. A confidence-limiting gap may be managed with an explicit limitation and closure action, while a decision-critical gap should normally be closed before full modelling or handled through a technically reviewed treatment.
Which data gaps should be closed before modelling?
Prioritize gaps that can change asset identity, damage-mechanism selection, Probability of Failure, Consequence of Failure or inspection scope. Examples include wrong circuit boundaries, unknown material, undocumented service changes and untraceable inspection history.
Why do aging process facilities need a separate readiness review?
Older facilities often contain legacy tags, undocumented modifications, obsolete drawings, changed operating service and inspection records created under different systems. A readiness review reconciles those changes before they are converted into a risk ranking.
Who should own RBI data?
Ownership is usually cross-functional. Equipment identity may sit with engineering or asset data, operating conditions with operations or process engineering, inspection evidence with inspection, and consequence assumptions with process safety and business owners. The programme still needs a clear owner for the controlled RBI dataset.
When should RBI data readiness be reviewed again?
Review it when changes may affect the basis: modifications, service changes, excursions, incidents, repairs, new inspection findings or revised consequence assumptions. Periodic review may also be required, but no single universal interval applies to every facility.
What should an RBI data-readiness review deliver?
A useful deliverable includes the defined scope, reconciled asset hierarchy, source register, readiness matrix, gap register, owners and actions, limitations, pilot recommendation where needed, and a clear proceed, pilot or remediate decision.
