Case study · European bulk-liquid operator

Eleven years of records, one governed timeline

The operator had every record an auditor could ask for. They were in four systems that had never been introduced to each other, and answering one crossing question took days of spreadsheet archaeology.

27,338
Maintenance work orders ingested and validated, 2015-2026
236
HSSE incident, near-miss and deviation records
75
Commercial contracts structured with exposure in one view
Daily
Automated tank-report ingestion, straight from operator email

The situation

In short

A European bulk-liquid terminal operator ran a multi-site business on four systems that each held part of the truth: a CMMS for maintenance, gauging for tank data, spreadsheets and shift logs for HSSE, and a drawer of commercial contracts. Nothing was missing. Nothing was connected. Any question that crossed two systems became a research project measured in days.

This is not a story about bad operators or neglected records. The maintenance history was meticulous: eleven years of it, including 2,442 distinct recurring orders. The HSSE register went back roughly a decade. The contracts were signed, filed and current.

The problem was structural, and it is the same at nearly every terminal we have looked at since. Each system answers questions inside its own boundary very well. It is the questions that cross a boundary that have no owner:

Every one of those was answerable. Each one cost days.

What was built

The operator's systems were left exactly where they were. Nothing was replaced, nothing was migrated, and no one on the operations team changed how they work.

  1. Read what the systems already produce. Native CMMS exports, tank reports, HSSE records and contract workbooks. No vendor API, no integration project, no change request to a system nobody wants touched.
  2. Validate on the way in, not after. Eleven years of real operational history is not clean. Records were parsed, checked and reconciled against the source before entering the record, so a number in a report can be traced back to the row it came from.
  3. Join on the operational entity, not the document. Tank, site, counterparty, asset. This is the step that makes crossing questions answerable, and it is the step a document store or a search tool skips.
  4. Keep the daily feed running. The operator's own scheduled tank report arrives by email and lands in the structured record automatically. The historical archive is the foundation; the daily feed is what keeps it a live operational record rather than a one-off analysis.
  5. Make every state change attributable. An append-only audit trail, timestamped and tied to an actor. Evidence is only evidence if you can say who changed what and when.

What the joined record showed

The point of joining the records is not the dashboard. It is the class of question that becomes cheap.

Evidence on demand

An audit or insurance question that previously meant assembling a case from four systems becomes a filter and an export, with the underlying records attached.

Revenue at risk, early

Contract expiries and counterparty concentration surfaced against the tanks and volumes they actually depend on, while there is still time to act, rather than at renewal.

Deferred work, in context

Recurring maintenance patterns read against capacity and commitment, so the cost of deferring a job is visible as throughput, not just as an open ticket.

Incidents with their surroundings

An HSSE event reconstructed alongside the maintenance state and tank activity around it, instead of as an isolated entry in a register.

The honest framing. Joining records does not create information the operator did not have. Every one of these answers was already latent in their own systems. What changed is the cost of asking: from days of assembly to seconds of query, with the evidence trail attached. That is the entire proposition, and it is worth stating plainly rather than dressing up as insight generation.

What this engagement was, and what it was not

Being precise about this matters more than the numbers above, and it is where most vendor case studies quietly overstate.

DimensionWhat is true
The dataReal. Live operational records from a working multi-site terminal business: maintenance, HSSE, tank and contract data, not a demo set or a simulation.
The engagementA paid pilot and MVP. The platform was developed and validated against real terminal workflows rather than assumptions.
The buildDelivered. Commercial intelligence and portfolio analysis were built and handed over, along with the operational and evidence layers.
The relationshipConcluded. The commercial collaboration did not continue past the pilot. The platform is now licensed independently, and no client is named here or anywhere else.
The claim we do not makeWe do not describe this as a multi-year production rollout, and we do not name the operator. Discretion is the arrangement; overstating the deployment would be the easier story and the wrong one.

The reason to publish it at all is that the alternative, a platform with no demonstrable history, asks a terminal operator to take considerably more on faith.

Why the numbers stay anonymous

Terminal operators do not publish their operational patterns, and neither do we. Volumes, incident rates and contract structures describe how a business runs and where it is exposed. That is not marketing material, and treating it as such would tell every future client exactly what to expect from us.

So the counts are here, the operator is not, and the platform itself is shown in private walkthroughs on representative data. How the data is handled →

Common questions

How long does ingesting a decade of maintenance history take?

Ingestion is measured in days, not months, because the layer reads the exports the CMMS already produces rather than requiring an integration project. The longer part is validation: deciding what a malformed eleven-year-old record should become, and confirming the totals reconcile against the source.

Do we have to replace our maintenance or gauging system?

No, and you should be sceptical of anyone who suggests it. Your existing systems remain the systems of record throughout. The operational layer reads from them. If it were removed tomorrow, every source system would still be running exactly as it is.

What if our exports are messy or inconsistent?

They will be, and that is the normal starting condition. Eleven years of real operational data contains format changes, retired conventions and records entered by people who have since left. Handling that is part of the work rather than a precondition for starting it.

Can we test this against our own data before committing?

That is what the Shadow Pilot exists for: thirty days, historical exports only, nothing touching production, and you keep the findings whether or not you proceed. How the Shadow Pilot works →

Bring one question your records struggle to answer

Not a demo of our features: a walkthrough of how your own kind of question looks when the operation can testify for itself.