Inspiration

I spoke with Rusty Shawver, Distribution Supervisor at the State College Borough Water Authority, about how his crews find leaks. They already use acoustic loggers and correlators to locate them. What stuck with me was something earlier in the process. He wanted crews to get alerted sooner and get out faster. That gave me the idea for Ripple. I wanted to see whether pressure and flow data could help flag suspicious changes earlier, then bring the evidence together so an operator could investigate.

What it does

Ripple helps water network operators investigate unusual sensor readings. You can replay historical measurements, explore the pipe network, and inspect the sensors behind an experimental warning. Pressure charts, water supply, pump transfer, and tank levels stay synchronized as you move through time.

Once you find something worth reviewing, you can save the investigation, share a link that restores the same view, and create a printable brief with the measurements and your notes. There is also a separate benchmark view where you can check an example against the official leak record. It shows the actual benchmark location without presenting it as a location Ripple predicted.

How we built it

I built Ripple solo using React, TypeScript, Cytoscape, and ECharts for the frontend. The backend uses FastAPI, Python, and WNTR for hydraulic modeling. Tiger Data stores over 330,000 sensor readings, nearly 9,000 detector scores, more than 41,000 contributing sensor records, and saved investigations. Detailed readings support closer inspection, while continuous aggregates provide longer historical context. I benchmarked raw queries against equivalent aggregate queries and checked that their results matched. One daily history workload went from approximately 441 ms to 143 ms, about a 3× improvement in database execution time. The app runs on Vultr using Docker, Caddy, and HTTPS at followtheripple.us. Cursor was my main coding agent for the backend, frontend, migrations, tests, and research experiments. Grok Bot helped me compare approaches, review architecture and code, draft my outreach to the water authority, and organize routines to stay on track.

Challenges we ran into

The hardest part was separating possible leak signals from normal network behavior. Pressure changes throughout the day because of demand, pumps, and tank operation. Several detector approaches looked promising at first but did not hold up across more examples. Some produced too many warnings. Others stayed active for so long that they could not flag a new event. I also found a calibration bug that inflated estimated demand.

Fixing it actually made some pressure fit numbers slightly worse, which was a good reminder that a better-looking metric does not always mean the implementation is more correct. The current detector caught 2 of 8 abrupt events excluding a development example in the 2019 diagnostic evaluation. It missed the 10 gradual events and produced six unmatched notifications. The evaluation was not a blind holdout, and pipe localization is still unresolved. That is why the app lets operators inspect the evidence behind a warning instead of treating it as a confirmed leak.

Accomplishments that we're proud of

I’m proud that a conversation with someone doing this work led to an application I could actually demonstrate. You can open a warning, inspect its sensor readings, compare operating conditions, and create something another person can review. Tiger Data supports that entire process. I also spent a lot of time getting the smaller details right. Moving backward in the replay removes future warnings. Selecting another sensor keeps the same timestamp. Saved links reopen the investigation, and the printable brief uses the evidence currently on screen.

What we learned

I learned that noticing a change is much easier than figuring out what caused it. I also learned how misleading an early result can be. A method might work on a familiar example or a clean simulation and still struggle on the rest of the data. Talking with Rusty helped me focus on what the application should do for someone using it. A warning needs enough context for an operator to understand what happened and share the findings.

What's next for Ripple

I want to improve detection across different operating conditions, especially for gradual leaks. I also want feedback from operators on the investigation workflow and brief. I need to find out whether they contain the information someone would actually want before a field inspection. Eventually, I’d like Ripple to narrow an investigation to a useful area of the network. For now, I’m focused on making the warnings more reliable and the evidence easier to review.