Process Safety Reporting for Generation and LPG operations

§01 — Engagement

At a glance

Client	One of Australia's largest energy suppliers
Sector	Power generation and LPG operations
Engagement period	2022 to 2026
Funding model	Capital investment, delivered through successive statements of work
Role	Solution architect and development manager
Team	Succinct delivery team of five
Core technology	React front end, containerised .NET back end, Power BI integration
Deployment	Inside the client's environment, operated by the client's IT function
Status	Final component deployed August 2026

Fig. 1 — engagement record

§02 — The problem

The indicators existed. Seeing them together did not.

Power generation and LPG handling are high-hazard operations. The organisations that run them are judged, internally and externally, on how well they understand whether their risk controls are actually working. That understanding comes from process safety indicators: the leading measures that show a control degrading before it fails, and the lagging measures that record what happened when one did.

The client had the indicators. The difficulty was assembly. The data sat across separate systems, each with its own structure and refresh cycle. Producing a consolidated view meant exporting, reconciling and reformatting by hand, then rebuilding the same pack the following month. The work was repetitive, the output was static, and the definitions behind each number depended on whoever had assembled it.

The cost of that is easy to see: senior technical people spending days a month on data handling. The lag is the part that does real damage. A leading indicator that surfaces six weeks after the fact has quietly become a lagging one.

The brief was a single application, owned internally, that produced the same view every time, from the source data, with nobody in the middle.

§03 — How the work ran

Embedded in the client's team, funded in increments

Succinct was engaged as a delivery partner inside the client's own team rather than as a vendor working to a specification handed over at the start. That distinction shaped everything that followed.

The platform was funded as a capital investment and delivered through successive statements of work, each scoping a defined increment. That gave both sides something worth having. The client could fund a piece of work, see it land, and decide what came next having actually used the previous release. Succinct could build against real feedback rather than against a document written before anyone had touched the product.

The work ran in six phases:

1. 01Functional review of the existing dashboard
2. 02Requirements gathering with operations and process safety specialists
3. 03Design and build-out, using coding templates on a common architecture pattern, with a database uplift underneath
4. 04Implementation into the client's environment
5. 05Testing, with dedicated QA across every release
6. 06Support, including hypercare after go-live

Build-out, implementation and testing repeated across successive releases rather than running once.

Two roles sat with one person for the whole four years: solution architect, owning the technical design and the decisions that came with it, and development manager, running the people who built it.

Around that sat a small, stable delivery team. Keeping it small was deliberate. On a platform where the domain knowledge is the hard part, every handover costs more than it looks like it will. The same group carried the work from the first release through to the final component.

Fig. 2 — delivery team

§04 — What was built

A web application over a scheduled integration layer

The front end is built in React. Its central feature is a set of asset and hazard dashboards giving a consolidated view of safety-relevant indicators against specific assets: what is being measured, how it is tracking, and where attention is needed. Users move between an enterprise view and an individual site without changing tools or exporting anything.

Behind that sit the KPI definitions, and this is the part of the work that is easiest to underestimate. A process safety indicator is only as good as the rule that calculates it, and those rules are specific to the operator: what counts as an exceedance, how a partial period is treated, which events fall in scope. Encoding the client's definitions, and holding them consistent as scope widened, took a larger share of the effort than the interface did.

Scope grew in stages. The platform started with generation assets and later extended into LPG operations, which needed its own KPI set built on the same indicator framework. Governance dashboards were added to give oversight of the reporting process itself. Power BI integration was built so the data could feed the wider reporting estate instead of terminating in a tool of its own.

Fig. 3 — platform components

React · .NET · Docker · Power BI · Scheduled integration · Agile delivery

§06 — Outcomes

What four years of capital funding bought

The platform was backed across successive capital cycles, extended into new asset classes and wired into the wider reporting estate. At completion in August 2026:

• —Manual assembly of process safety reporting replaced by a single application drawing directly from source systems.
• —Indicator definitions held in one place and applied consistently, so the same question returns the same answer regardless of who asks it.
• —Coverage spanning generation and LPG operations under a common indicator framework.
• —Platform data feeding broader reporting through Power BI rather than sitting in isolation.
• —Running inside the client's environment, deployed and operated by the client's own IT function.
• —Left AI-ready: built on a common architecture pattern with coding templates, and documented so AI coding assistants can extend it the same way.
• —Build completed on schedule, with the final component delivered in August 2026.

The client holds the underlying operational figures. This page does not publish numbers that are not ours to publish.