Inspiration
Freshwater concerns do not arrive as a clean, complete dataset. A resident may report unusual cloudiness, another may notice an odor, and a reassuring observation may arrive later. Meanwhile, forecasts change. For people coordinating environmental follow-up, a useful question is not only “What do we know now?” but also “What did we know when this decision was made, and does it still apply?”
We built AquaSentinel to make that question visible and actionable for water ecologists, public-health officers, and parks staff.
What it does
AquaSentinel is a working evidence-review prototype for urban freshwater monitoring. It separates real historical sensor measurements from synthetic citizen reports and lets users replay the information available at a selected time.
The demonstration follows a complete workflow: a rainfall Watch, corroborating reports that recommend human review, a late conflicting report, and a revised forecast. Previously recorded dry-run alerts show when they no longer apply. A human review is linked to the exact evidence reviewed; new evidence preserves that review in history while marking it as stale.
Printable One Health briefs organize evidence and follow-up for ecological, public-health, and animal-health/parks audiences. Environmental FHIR R4 exports make observations and review provenance inspectable by other systems.
How we built it
The application uses Python, SQLite, and a JavaScript interface with Leaflet. Real USGS daily discharge and river geometry validate the data pipeline at Arroyo Seco near Pasadena. Open-Meteo forecast captures are stored as separate versions with fetch and import timestamps. Replay selects only captures available to the application by the selected time. Fetch time is not presented as provider publication time.
Triage uses explicit, inspectable rules rather than a trained machine-learning model. Docker and Kubernetes manifests support deployment; the prototype also provides a read-only mode and isolated public-demo sessions.
Challenges we ran into
The central challenge was time: an observation can happen before it becomes available, and a forecast can be revised after a decision. We separated observation, receipt, capture, and import semantics instead of treating all timestamps as interchangeable.
Another challenge was preserving meaning across data types. Daily discharge is environmental background, not a citizen report or proof of contamination. Our interface and exports retain those distinctions.
Accomplishments that we're proud of
We implemented the full Watch-to-review-to-retraction demonstration, preserved review history when evidence changes, connected real environmental captures, and added printable briefs and FHIR exports. On September 27, all 39 automated tests passed, including time-scoped replay, alert retraction, HTTP behavior, and visitor-session isolation. These tests validate software behavior, not environmental effectiveness.
What we learned
A trustworthy monitoring tool must communicate uncertainty and revisions as clearly as it communicates a concern. Keeping old decisions attached to their original evidence helps users understand why follow-up was suggested and when reassessment is needed.
What's next for AquaSentinel
Next steps are prospective forecast collection, evaluation with independently specified event windows, usability testing with intended users, authenticated reviewer roles, and integration with an official citizen-science export when one becomes available. Scaling beyond the current single-process prototype will require additional engineering and validation.
One Health impact and limitations
The intended benefit is clearer coordination around freshwater ecosystems, wildlife, and community exposure concerns. No measured health benefit or field efficacy is claimed.
Arroyo Seco is a pipeline-validation location, not a OneAquaHealth pilot. Citizen reports and the recorded alert scenario are synthetic; alerts are dry-run only. USGS discharge peaks are a runoff proxy, not water-quality labels or validation of unusual citizen reports. Historical reanalysis does not establish as-issued forecast skill. FHIR checking covers base-R4 structure, not clinical validation or OneAquaHealth profile certification. Official Citizen App integration is not implemented.
Development transparency
The September 15 runnable baseline is preserved under the tag pre-hackathon-baseline. It already included ingestion, replay, rule triage, review binding, a local interface, and tests. Real-data adapters, forecast versioning, dry-run alerts, geographic intake, One Health briefs, and FHIR exports were added afterwards. The repository preserves this development history. Organizer clarification on the published date discrepancy was requested; no eligibility ruling is assumed.
Log in or sign up for Devpost to join the conversation.