Compostable Software in OpenRBI

1. https://fault-tree-analysis.netlify.app/     a top-down, deductive method to find the root causes of an undesired system event. It uses a visual diagram with logic gates like AND and OR to map out failure pathways. 

2. https://monte-carlo-analysis.netlify.app/     a mathematical technique that forecasts a range of possible outcomes by repeatedly running a model with random variable samples. 

3. https://cof-581type-level2-analysis.netlify.app/      provides a highly precise calculation of the Consequence of Failure (CoF) by using thermodynamic equations of state to model custom chemical compositions and complex, multi-component fluid dynamics. 

4. https://markov-analysis.netlify.app/     Markov analysis is a mathematical method used to predict future outcomes based entirely on a system's current state. 

5. https://art-rbi-analysis.netlify.app/     Art​ means the component wall-loss fraction since the starting thickness was established—usually the last measured thickness or, when no inspection thickness exists, the original furnished thickness. 

6. https://physical-effects-calculator.netlify.app/  A training calculator for loss-of-containment (Yellow book approach)  physical effects: liquid/gas release, flash, pool evaporation, vapour dispersion, VCE, fire radiation, and vessel burst. Each module explains the scientific principle, then runs a simple SI screening calculation and can chain results into the next step. 

Software Designed to Be Replaced

Technology changes quickly. New AI models, databases, calculation tools and reporting systems continually become available. OpenRBI is therefore designed around a simple principle: individual software tools should be replaceable without losing the engineering information on which the RBI assessment depends.

This approach is called compostable software architecture.

Compostability does not mean that software is unreliable or disposable. It means that replaceable tools are kept separate from authoritative engineering data, validated calculations, inspection evidence and approved decisions. When a tool becomes obsolete, it can be removed while the important engineering records remain available.

Composable and Compostable Software

Composable software is built from separate components that can be connected and rearranged. Compostable software takes this idea further by considering how each component will eventually be removed or replaced. A component is genuinely compostable when its function is clearly defined, its interfaces are documented, its data can be exported and another component can perform the same function without reconstructing the complete system.  For example, OpenRBI may use an AI model to help locate information in an inspection report. If a better model becomes available, the AI component should be replaceable without changing the equipment register, inspection history or approved RBI assessment.

The Stable Engineering Core

Not every part of OpenRBI should be temporary. Some information must remain controlled, traceable and available for engineering review. The stable core includes equipment identification, design conditions, materials of construction, process information, inspection results, corrosion rates, damage-mechanism assessments, minimum-wall calculations, consequence results, risk evaluations, recommendations, approvals and supporting evidence. These records represent the engineering basis of the assessment. They should not depend on one AI model, software supplier or proprietary database. OpenRBI treats calculation tools, user interfaces, report generators, AI assistants and document-search systems as supporting components around this stable core. These tools can change while the engineering record remains intact.

A Simple Example

Consider an AI assistant used to screen inspection reports for wall-thickness readings. The original inspection report remains the authoritative evidence. The AI assistant may help find measurements and transfer them into a review table, but its extracted values must be checked before they become accepted engineering inputs. If the AI assistant is replaced next year, the original report, verified measurements, reviewer’s name and approval record remain available. Only the supporting AI tool changes. This separation is important because an AI-generated answer is not the engineering record. The controlled source document and the verified assessment remain the engineering record.

Avoiding Vendor Lock-In

Vendor lock-in occurs when an organisation cannot change a software product without losing data, rebuilding workflows or paying a high migration cost. OpenRBI reduces this dependence by favouring accessible files, documented data structures and clearly separated modules. Engineering information should be exportable in usable formats and should not exist only inside a proprietary platform. This does not remove every dependency. File formats, operating systems and software libraries still create technical relationships. The objective is to make those relationships visible and manageable so that one replaceable product does not control the complete RBI process.

The Role of Interfaces

Separate modules must communicate through defined interfaces. An interface specifies what information a component receives and what it must return. For example, a consequence module might receive fluid properties, operating conditions and release-hole size. It would return calculated release and consequence results in a documented format. A replacement module could use a different internal calculation method, but it would have to receive and return the required information in the agreed structure. The replacement must then be tested. A new component should not be accepted merely because it connects successfully. Its calculations, units, limits, error handling, security and outputs must be checked against defined acceptance criteria.

Compostability and Technical Debt

Technical debt develops when temporary solutions become permanent dependencies. An old tool may remain in use because nobody knows what data it contains, which systems depend on it or how its functions could be replaced. A compostable approach addresses this problem at the beginning of the component’s lifecycle. Its purpose, owner, inputs, outputs, dependencies and removal procedure are documented when it is introduced. This does not automatically eliminate technical debt. Poor documentation, uncontrolled interfaces and duplicated data can still make a modular system difficult to maintain. Compostability must be supported by disciplined configuration management and engineering governance.

Data Must Be Managed, Not Simply Deleted

The composting metaphor does not mean that old engineering information should be destroyed. Temporary AI conversations, caches and intermediate working files may be suitable for deletion after an approved retention period. Inspection reports, calculations, equipment histories, engineering decisions and approval records may need to be retained for legal, operational or safety reasons. Each type of information therefore requires a defined lifecycle. It may remain active, be superseded, move to an archive or be securely deleted when retention is no longer required. The decision must be based on the status and value of the information rather than merely its age.

A database can store a corrosion rate, but the database is not the evidence for that rate. The evidence may be a series of verified thickness measurements and inspection reports. An AI assistant can suggest a damage mechanism, but the suggestion is not an approved damage-mechanism assessment. A calculator can produce a result, but the result is not reliable until the inputs, method, units and limitations have been checked.

Software tools will change throughout your career. The need for traceable evidence, sound calculations and accountable engineering judgement will remain.

The OpenRBI Principle

OpenRBI separates enduring engineering knowledge from replaceable technology.  The equipment data, evidence, assumptions, calculations and approvals form the controlled engineering record. Software modules help engineers collect, analyse and present that information, but no replaceable module should become the only place where the engineering basis exists. The practical test is straightforward:

If this software component disappeared tomorrow, could we recover the engineering data, understand the decisions already made and replace the component without rebuilding the complete RBI assessment?

If the answer is yes, the component is reasonably compostable. If the answer is no, the system has created a dependency that must be recognised and managed.