Leak detection fails when it stops at detection

Leaks persist because utilities still run them as separate jobs

A recent estimate from the U.S. Environmental Protection Agency puts treated drinking water loss at 19.5 percent, or about 6.75 billion gallons a day, with more than $6.4 billion in annual uncaptured utility revenue. That loss is the cost of treating leakage as a detection problem instead of one operating process for finding, ranking, repairing, and checking repairs.

The hardest part is making the next decision faster and better: which district deserves attention, what the likely cause is, which crew should go, what parts they need, and whether the repair actually changed the flow. Most utilities still split those steps across SCADA, AMI, GIS, hydraulic models, work orders, and call centers, so the evidence never arrives in one place when action is needed.

A useful leak program is a closed loop. It connects measurement, anomaly detection, hydraulic diagnosis, work prioritization, field dispatch, and verified repair in one workflow, with people still approving excavation, valve operations, and customer notifications. Anything less produces alerts, not recovered water.

The cost sits mostly in real losses, not billing noise

The EPA estimate says about 87 percent of total U.S. water loss is real loss, meaning leaks and pipe bursts rather than meter error or billing problems. That narrows the operational target. If most loss is physical, the answer is a faster way to identify buried failures before they become visible breaks or long-running background leakage.

This also explains why small and very small utilities carry a heavier burden, averaging more than 20 percent water loss according to the EPA estimate. Fewer staff, fewer sensors, and less analytical capacity make it harder to see a leak early, and harder still to turn a detection into a confirmed repair. The problem persists because the work is split across teams that do not share the same identifiers, timestamps, or definitions of success.

A Northern Italian case study showed that pressure sensors across a network serving about 300 users could detect hydraulic and mechanical anomalies, including significant leakage events and simultaneous anomalies in multiple areas. That is useful evidence, but it is not a claim that pressure alone solves the problem. It shows something more modest and more important: anomaly detection works when the network is instrumented enough to distinguish normal variation from a real change in behavior.

Detection is only useful when it feeds the dispatch queue

The central failure mode is easy to see in practice. A sensor flags a district, but the field crew still needs a likely location, access constraints, critical customers nearby, expected severity, and the correct materials. If the work order system does not carry that context, the crew spends time reconciling maps, calling operations, and driving back for parts. Leakage remains open while the organization debates which system is right.

A better reference design starts with a shared asset and location model. SCADA, district-metered-area flow, pressure, AMI, GIS, maintenance history, customer contacts, and work orders all point to the same pipe, valve, zone, or service connection. From there, minimum-night-flow analysis can mark excess use in a district, pressure and flow analytics can identify the change point, hydraulic diagnosis can narrow the candidate zone, and the dispatch queue can rank the job by risk, access, traffic, and expected water savings.

The point is not perfect prediction. The point is fewer wasted visits and faster confirmed repairs. A model that is right often but cannot produce a credible work package is less useful than a simpler system that can assign the right crew with the right evidence and then verify the result after the repair is closed.

For readers who want the broader operating pattern, our free paper on how operators get production value from AI is the better starting point than another vendor demo. The issue is the same across industries: data only matters when it reaches a decision queue with ownership and auditability.

Where the technology helps, and where it does not

Pressure and flow anomaly detection can be built with rules, change-point methods, clustering, or unsupervised machine learning. Hydraulic-model and sensor-fusion diagnosis can then compare observed telemetry with expected behavior to estimate a likely leak location or pressure-zone change. Acoustic tools and transient-based localization can narrow the search further once the district has already been identified.

That stack is credible because each layer does a different job. Rules catch obvious excess night flow. Statistical methods detect a change from normal operation. Hydraulic diagnosis reduces the search area. Acoustic confirmation helps decide where to dig. None of those layers should be treated as proof on its own.

There is a hard limit here. Sparse or noisy sensing, outdated GIS connectivity, valve-status uncertainty, and weak repair records will produce false alarms and bad priors no matter how good the model looks in a notebook. Automated control is also risky if it can threaten fire flow, minimum pressure, or water quality. For that reason, the safest pattern is recommendation plus human approval, with every action recorded in an audit log and every repair checked against post-repair telemetry.

The work order is where many programs fail. If the system does not record whether the anomaly was confirmed, what asset was actually repaired, whether the repair held, and how much flow changed after the fix, the organization learns almost nothing. That leaves the next leak to be rediscovered from scratch.

The real payoff comes from closing the loop

Utilities do not need another dashboard that says a district looks strange. They need a process that turns an anomalous flow pattern into a ranked crew dispatch, captures the field result, and feeds that result back into the detection and prioritization logic. That is the difference between activity and recovery.

In practical terms, the workflow should be narrow enough to govern and broad enough to matter: retrieve the asset record, summarize the evidence, create a candidate work order, ask for missing information, notify the responsible team, and compare pre- and post-repair telemetry. Humans stay in charge of the decisions that carry hydraulic and public-safety risk, while the system handles the handoffs that usually consume the day.

That is the decision in front of utilities, and it is the same decision facing any operation with expensive, physical losses hidden inside fragmented systems. Treat leak detection as a sensing project and the alerts will pile up. Treat it as a closed operational loop and the work starts to resemble asset management instead of firefighting. QueryNow builds the foundation enterprise AI runs on, and the agents that run on it. Talk to our team about the workflow you want to start with: every engagement starts with one scoped workflow and acceptance criteria agreed in writing before the build starts.