SeepWatch

Inspiration

In the Central Valley, farms and rural towns depend on reliable water delivery. But sometimes water “goes missing” inside irrigation canals—through seepage, breaks, unmetered diversions, or operational problems. Operators often only notice after crops start to suffer. SeepWatch is inspired by that real-world delay: the need to spot unusual water loss earlier, using the only thing many systems consistently have—paired water readings upstream and downstream.

What it does

SeepWatch is a forecasting and alert dashboard that:

Detects unusual water loss patterns across a canal corridor using upstream vs. downstream gauge balances. Forecasts the next 1–7 days of that unusual loss signal. Estimates downstream shortfall impact (how much less water may arrive at key delivery points). Shows where to look first with a simple, judge-friendly interactive map and an evidence panel. Keeps values honest with clear labels for what is measured vs. modeled vs. schematic. It’s designed as a hackathon-ready demo: it turns technical water balances into a clear “priority watchlist” for field crews and decision makers.

How we built it

We built it as a full pipeline + interactive web app:

Data ingestion & QC: pull time-series water readings from public CDEC gauges, clean/aggregate them into daily signals, and track flood/operation edge cases. Reach-balance labeling: compute “unexplained loss” as a reach-level difference using transit lag logic between paired points. Features & leak-safe framing: engineer lag-aware features and seasonality cues so the model targets the right effect. Forecasting models & baselines: Persistence and simple benchmarks. A quantile-style LightGBM approach for robust forecast ranges. A “normal expected” band for interpreting excess loss. Anomaly + shortfall propagation: Flag sustained excess-loss signals. Run downstream propagation with uncertainty to estimate shortfall ranges. FastAPI + bundled UI: A single bundle.json powers the API. Frontend renders the map, cards, and evidence drawer. Mobile-first responsive layout. The result is an app you can run locally and demo in minutes.

Challenges we ran into

Data realism vs. public availability: many irrigation canals don’t have paired public flow gauges, so the most reliable proof-of-concept corridor is a system where reach balances and gauge pairing are well documented. Not overstating “leaks”: a reach balance difference can’t prove seepage in isolation—so we needed UI wording that says “unusual loss signal”, not “leak detected.” Model honesty and uncertainty: forecasts need both a median expectation and uncertainty ranges; otherwise judges won’t trust the numbers. UI clarity under time pressure: technical dashboards can easily become jargon-heavy. We had to compress the story into simple, scroll-friendly, map-first visuals with minimal language. Map usability: color alone wasn’t enough—labels had to be readable, uncluttered, and mapped to real place names.

Accomplishments that we're proud of

A clean, judge-friendly story: big numbers first, then “how it works,” then evidence. Honest framing: measured vs. modeled vs. schematic values are clearly separated. Interactive explainability: Clickable map routes and checkpoints A drawer that summarizes “what to do first” An evidence panel aligned to pre-registered evaluation rules End-to-end deliverable: data → modeling → propagation → bundled demo UI that runs locally.

What we learned

You can’t win trust with accuracy alone—you earn trust with wording and structure. In water analytics, “loss” is real, but the cause is often not uniquely identifiable from gauge balances. So: The best products prioritize checks, not overclaim diagnosis. A great demo isn’t “more features,” it’s fewer, clearer steps: Find the signal Locate the route Understand downstream risk Verify with evidence Visual hierarchy (big numbers, color meaning, uncluttered map labels) is often the difference between “cool project” and “judge understands it.”

What's next for SeepWatch

Expand beyond a single corridor by adding: More paired gauge datasets (where available) Better operational context filters (routing, bypass handling) Improve the demo experience: More scenario toggles (still labeled as modeled/synthetic) Even clearer “priority checklist” output for field crews Prepare for deployment: Faster pipeline refresh Hardening reliability around missing data and gauge gaps Validate on additional regions/district configurations where paired gauge comparisons can be established. If you want, tell me whether your hackathon submission requires a short version (e.g., 6–8 bullet points total) or a long version (full narrative like above), and I’ll compress/format it to match.

Built With

• css
• java
• python