More Pipeline Data, Same Reactive Decisions

More than 70 percent of water utility pipeline assets are buried. Until recently, that meant asset managers were maintaining what they couldn't see — relying on break history, age estimates, and the institutional memory of whoever had been on-site a decade ago.

That is changing. Smart meters, remote pressure sensors, acoustic leak detection, and inline inspection tools are now generating real-time condition signals across distribution networks. GIS platforms are adding sensor overlays. SCADA systems flag transients in near-real-time. For the first time, water network managers can see what is happening inside buried infrastructure while it is happening.

And yet, across most utilities, maintenance decisions remain reactive. A main breaks; crews are dispatched. A pressure transient is logged; it joins a queue of alerts nobody has time to triage properly. Sensor investment has not translated into a corresponding improvement in planning, prioritization, or downtime reduction.

The data is there. The decisions still are not.

Why more data doesn't automatically mean better decisions

The gap is structural, not informational. Water utilities typically run three separate systems: a GIS for network topology, a SCADA or AMI platform for real-time telemetry, and a CMMS or EAM for work orders and maintenance records. Each system does its job. None of them communicates with the others in a way that allows integrated reasoning.

A pressure anomaly flagged in SCADA sits in a SCADA dashboard. It does not automatically become a maintenance priority in the work order system. Getting from "anomaly detected" to "work order assigned, crew dispatched, compliance flag raised" requires a human to switch between three systems, look up the asset in GIS to understand its network context, check its maintenance history in the CMMS, and manually decide whether to act.

At scale — for a regional water authority managing thousands of kilometres of pipe — that human-in-the-middle workflow is the bottleneck. The data is arriving faster than anyone can act on it. The result is alert fatigue: everything is flagged, so nothing is prioritised.

The reasoning gap that GIS and SCADA can't fill

The problem isn't just workflow friction. It's that the reasoning required to turn a pressure reading into a maintenance decision is genuinely network-level reasoning — and most EAM platforms were not built for it.

A pressure anomaly at a network node is not interpretable in isolation. Its significance depends on where the node sits in the network topology, what condition data looks like on adjacent segments, which downstream infrastructure is exposed if this segment degrades, and what the historical failure pattern looks like for similar network positions.

Network-aware reasoning for linear assets requires the platform to hold topology and asset condition data in a single model, and to traverse the graph when evaluating any individual signal. That is a GIS-native architecture combined with a maintenance reasoning engine — not a GIS bolted next to a CMMS via a nightly export.

Without that unified model, sensor data stays siloed in whichever system collected it. GIS knows the topology but not the telemetry. SCADA knows the telemetry but not the maintenance history. The EAM knows the work orders but not the network context. No individual system can answer the question that matters: does this signal require action, and if so, what, where, and when?

The treatment plant problem

The same operator who manages the distribution network also manages treatment plants, pump stations, and reservoirs.

Those assets are discrete, not linear. A treatment plant contains systems, equipment, and components arranged in a functional hierarchy. Maintenance is measured against ISO 14224 classifications and OEE-grade performance data. Failure modes follow parent-child relationships within the hierarchy.

Managing discrete assets well requires hierarchy-aware reasoning — a different computational model than the graph traversal needed for a pipe network. Most utilities end up with one system for their facilities and a GIS tool for their network, and neither understands the assets in the other.

When a pump station at a critical network node is due for maintenance, the decision cannot be made by the facilities team alone. The network implications — which pressure zones are exposed during the outage window, what balancing operations are needed upstream, which customers need notification — require the linear asset model. Conversely, when a pipeline segment shows deterioration near a pump station, the operational status of that pump station is directly relevant to remediation options.

UniEAM's agentic platform works across both asset types in a single model. When the reliability agent identifies a high-priority segment for inspection, it factors in the operational status of the adjacent treatment facilities and proposes a combined intervention window that minimises total network exposure. Every recommendation carries a full decision log: which data points were consulted, what the model's confidence level was, and what alternatives were evaluated.

That matters now more than ever. CISA's OT asset inventory mandate and updated EPA resilience guidance are increasingly asking water utilities to demonstrate not just that they acted, but that they acted on evidence — and that the evidence is traceable.

What it looks like when the pieces are unified

The fundamentals of managing a linear water network have not changed: condition assessment, integrity verification, risk-based prioritisation. What has changed is the expectation that these processes run in a unified platform with a reasoning layer connecting network topology, sensor telemetry, and maintenance history — and that feeds AI agents able to act on that reasoning without requiring three human handoffs per anomaly.

Water utilities that achieve this do not experience a step-change in data collection. They experience a step-change in how much of the data they already have actually reaches a decision.

Curious how UniEAM handles both? Request a demo.