The open structure also means that the software and its resulting records can be used with modern artificial-intelligence tools. The HTML or JavaScript source code can be read and analysed by an AI coding assistant, while completed assessment records stored as XML and reports produced as PDF files can also be reviewed, searched, compared and summarised by suitable AI systems. This creates opportunities for plant-wide analysis that extend beyond the assessment of an individual item of equipment. Subject to the capability, configuration and security controls of the selected AI system, multiple XML assessment files may be examined to identify missing information, inconsistent assumptions, common damage mechanisms, high-risk equipment, overdue activities and trends across a facility. The PDF report remains a readable engineering record for people, while the XML file provides structured data that can be processed by software and AI. Retaining both formats allows the company to preserve a formal report while also maintaining information in a form suitable for future analysis, migration and system development. The software, XML records and PDF reports may be stored within the company’s existing Microsoft 365 environment, including approved SharePoint or OneDrive locations. This allows the company to apply its own document controls, permissions, retention policies, version history and access arrangements rather than placing its RBI information in a separate vendor-controlled database.
Where the company’s Microsoft 365 environment and AI tools are configured within its approved security architecture, the information can remain under company control and behind the company’s security perimeter. The actual level of protection will depend on the company’s Microsoft 365 configuration, identity controls, network architecture, firewall arrangements, endpoint security and the AI system selected for use. OpenRBI does not require the assessment data to be held in a remote proprietary RBI database. The company can retain possession of the application, its source code, its XML files and its completed reports. Access to the company’s RBI records therefore does not need to depend on maintaining a subscription with the original software provider. This is an important distinction from a closed software-as-a-service system. In a proprietary system, the calculation logic may be inaccessible, the data structure may be controlled by the vendor and continued access may depend on ongoing licence payments. OpenRBI instead allows the company to retain a working copy of the software and the records it has created.
The open structure also supports long-term maintainability. Future engineers are not restricted to using the software exactly as it was originally issued. They may inspect the source code, understand its logic and update it as company requirements, government obligations, industry practices and international standards change. AI-assisted software-development tools may help future engineers understand the code, locate affected calculations, prepare proposed amendments, improve reports and add new functions. This could make maintenance of the application more practical than maintaining a closed program whose source code is unavailable. AI assistance does not remove the need for competent technical review. Any amendment affecting RBI calculations, engineering assumptions, risk criteria, inspection intervals, statutory obligations or standards-based requirements should be tested and verified before being adopted for operational use. Changes in legislation and standards must also be identified deliberately. An AI system should not be assumed to know automatically that a government requirement or international standard has changed. The relevant legislation, standard, amendment or company requirement must be obtained, reviewed and translated into controlled software changes by competent personnel.
A suitable update process would include identifying the changed requirement, recording the source of the change, assessing which parts of the application are affected, modifying the code, testing the revised calculations against known cases, independently reviewing the results and issuing the updated version through the company’s document-control process. Because OpenRBI is not locked, the company is not necessarily dependent on the original developer to perform every future modification. A competent future engineer or software developer may maintain the application, provided that the engineering methodology is understood and appropriate verification is completed. This supports continuity across generations of engineers. The application can remain part of the company’s engineering knowledge base rather than becoming unusable when an individual consultant retires, a supplier changes direction or a commercial software subscription ends.
The open model also makes the basis of previous assessments easier to preserve. A future engineer can retain the version of the software used for an assessment, examine the associated XML record and review the resulting PDF report. This provides a clearer technical trail than a result generated by an inaccessible system that may later be changed by the vendor. Version control will remain important. The company should identify which software version produced each assessment, what methodology or standard edition was used, who reviewed the assessment and whether later changes require the assessment to be reconsidered. Open software enables this traceability, but the company must still establish the process that manages it. The professional expertise required to implement OpenRBI as a reliable company RBI program remains a separate paid service. Implementation may include data preparation, equipment-register development, damage-mechanism review, company-specific configuration, calculation verification, report development, training, plant-wide analysis and integration with the company’s integrity-management procedures.
Review and verification by an RPEQ may also be required where the work constitutes a professional engineering service in or for Queensland and is not performed under an applicable exclusion or under the direct supervision of an appropriately registered engineer. The need for RPEQ involvement depends on the nature, location and intended use of the engineering work. The software therefore remains open, portable and available to the company, while the professional responsibility associated with applying it is addressed separately. The customer is not paying merely for permission to open the software they have that. The customer is paying for the engineering knowledge, implementation effort, verification, interpretation and professional accountability required to turn the software into a reliable company RBI program. OpenRBI can therefore be viewed as a transparent and maintainable engineering platform rather than a disposable software product. Its source code can be retained and reviewed, its structured XML data can support future digital and AI-assisted analysis, its PDF reports can preserve readable engineering records, and all of these may be managed within the company’s approved Microsoft 365 environment.
The principal message here, is that your company retains control. It can retain the software, retain its assessment data, retain its reports and maintain the platform as requirements change. Professional implementation, verification, customisation, training and RPEQ engineering support, where required, remain a paid services.