Why I Developed OpenRBI: A Practical, File-Based Approach to Risk-Based Inspection. John Fletcher MSc DIC RPEng RPEQ

As a Principal Engineer involved in Risk-Based Inspection since 1996 in Aberdeen, I have learned one important lesson: final accountability for asset integrity rests with competent people, not automated code.  I started on a IBM db2 database using the new windows 95 wow heady days.  I found there was a few rules to the RBI as I went along and that was ...it is was and always will be an engineering tool, and it should be treated like one. It can help improve inspection planning, identify higher-risk equipment, and focus limited resources where they are most needed. However, it is not a golden bullet. It does not remove the need for inspections. It does not automatically justify extending inspection intervals for 10 or 20 years. It does not replace engineering judgement, plant knowledge, or professional accountability.  

And that inspection does not repair things it just removes uncertainty.  

The Reality of RBI in the Real World

I know how difficult it can be to get management support for RBI in the first place. Then, once you finally obtain that support, you may face the opposite problem: convincing people that RBI is not simply a way to cut costs, reduce inspections, or defer work indefinitely.  Its a different prespective on a complex issues.

I know what it is like when a new manager arrives wanting to make a name for themselves by pressuring you to cut costs, extend inspection intervals, or increase production without understanding the technical basis.

I know the reality of working with older facilities and smaller operators. Assets may have passed through several previous owners with little or no formal handover documentation. Original design calculations may be missing. Piping and instrumentation diagrams may be incomplete, outdated, or unavailable. Drawings may not reflect the plant that is actually operating.

Inspection reports may be scattered across old filing cabinets, spreadsheets, SharePoint sites, personal drives, and contractors’ archives. Thickness readings may exist without a clear inspection history. Equipment may have been modified without an effective Management of Change process. Operating conditions may have changed gradually over the years without being properly documented.

Production targets may have taken priority over record keeping. Process engineers may be rewarded for achieving extra throughput but have little time to help resolve asset integrity questions. When something goes wrong, however, everyone suddenly becomes interested in the inspection history, the assumptions, and the person who approved the decision.

I know what it is like when nobody wants to take responsibility for incomplete records, undocumented changes, or inherited problems. I also know how easily an engineer can be pressured to sign off a consultant’s report using assumptions they did not select, calculations they cannot properly interrogate, and outputs they do not fully control.

That is not how RBI should operate.

RBI Must Remain Under Engineering Control

RBI should remain transparent, practical, and under the control of the people responsible for the equipment. The source data should be visible. The assumptions should be recorded. The calculations should be understandable. Data gaps, limitations, and uncertainties should be identified clearly.

The engineer should be able to challenge the result, reject an unsupported conclusion, and require further inspection where the available evidence is not good enough. RBI should support the engineer. It should not replace the engineer.

Why a Simpler Approach to a More Quantitative and In-Depth Study Is Needed

Many companies do not have the budget for a major database project, expensive consultants, ongoing software subscriptions, or recurring per-seat licence fees. A smaller operator may need to assess only a limited number of vessels, filters, tanks, heat exchangers, or piping systems. They should not be forced into a large enterprise software platform before they can begin applying sound RBI principles.

At the same time, smaller operators still need the ability to move beyond a basic qualitative review. They may need to examine measured thickness data, corrosion rates, remaining life, damage mechanisms, inspection effectiveness, consequence categories, and the assumptions behind each risk ranking.

A more quantitative and in-depth study does not necessarily require a complex cloud-hosted database. It requires a disciplined engineering method, clear source data, visible calculations, traceable assumptions, and a practical way to review the results.

Modern cloud-hosted SaaS platforms may require sensitive asset data to be stored on external servers. That data can include equipment registers, thickness measurements, inspection findings, operating conditions, damage mechanism profiles, and risk assessments.

For many companies, particularly smaller operators, this can introduce additional cost, complexity, cybersecurity review requirements, and data-governance concerns. There is also a practical question: why should confidential plant information be moved into a remote database on the other side of the globe when a simpler file-based approach may be sufficient?

Hence OpenRBI

That is why I developed OpenRBI. OpenRBI is a free, file-based RBI analysis system designed for practical use. It does not require a dedicated cloud database, a major IT project, or recurring per-seat licence fees. It is designed as a lightweight browser-based utility hosted on Netlify and its Sharepoint IT manager friendly and so are the files. Selected engineering files are processed locally within the user’s browser memory rather than intentionally uploaded into a remote OpenRBI application database. The approach is deliberately simple. Your raw XML files can remain within your existing Microsoft 365, SharePoint, or OneDrive environment, subject to your organisation’s own document-control arrangements.

When you need to review, update, or format the data, you open the HTML interface, select the relevant files, and allow the local client-side script to perform the repetitive work. The browser processes the information temporarily in memory and generates a new file for download. You can then review the output and save it back into your controlled folder structure. This is not intended to replace your existing document-control system. It is intended to work with it.

A Data Clerk, Not an Engineer

OpenRBI is built using AI assistance in coding html and Javascript, it does not make engineering decisions. It does not approve inspection deferrals. It does not eliminate inspections. It does not assume liability for asset integrity decisions. The local script acts as an efficient data clerk. It helps sort, structure, calculate, and present information so that the user can review the inputs and outputs directly.

The person responsible for the assessment retains oversight. Every data point, assumption, calculation, and conclusion must still be reviewed against the available plant records, inspection history, operating context, and engineering judgement. Where the evidence is incomplete, the uncertainty should be recorded. Where the result is not credible, the engineer should challenge it. Where the data is insufficient, further inspection or investigation should be required.

A Practical Workflow

The workflow is straightforward. Start with the records you have. Identify what is missing. Record the uncertainty. Review the equipment history. Check the damage mechanisms. Confirm the operating conditions. Apply the appropriate engineering method. Inspect where the available evidence is not good enough. Then retain a clear, file-based record under your control.

A Necessary Verification Step

Any browser-based engineering tool should still be reviewed before use. The deployed source code, hosting configuration, analytics settings, third-party scripts, and external dependencies should be checked to confirm that selected engineering files are not transmitted outside the browser. No web-hosted tool should be accepted for safety-critical work merely because it is described as local or serverless.

The Point of OpenRBI

OpenRBI is not intended to replace competent engineers, inspectors, owner-user representatives, or statutory decision-makers. It is intended to provide a practical and transparent workspace with no unnecessary database, no recurring per-seat cost, no remote black box, and no consultant asking you to sign off a report you cannot properly interrogate.

RBI should help engineers manage real equipment in the real world. It should not create another layer of cost, complexity, or loss of control.