AquaSentinel

• 

  Overview

• 

  Water Network-Stream Reaches

• 

  Water Network-Catchment Map

• 

  Evidence

• 

  Incidents

• 

  Operations

• 

  Resilience

• 

  Interoperability

• 

  System Health

Inspiration and problem

AquaSentinel began while I was researching and building Agrinance, my fintech platform for farmers. As I worked through papers on agricultural distress, environmental risk, information asymmetries, I kept encountering the same underlying problem: a signal is not the same thing as a meaningful event. A single observation can be noisy, incomplete, or misleading. That idea stayed with me when I began exploring water-quality research. I started digging into literature on environmental monitoring, remote sensing, citizen science, and anomaly detection. I read a 2024 review of citizen-science applications in water-quality monitoring, which explicitly examines the potential of citizen science to compensate for gaps in in-situ measurements and discusses its intersection with remote sensing.

That paper’s findings made me ask: If a monitoring system detects a small anomaly in a water body, how do we determine whether that anomaly represents a genuinely significant environmental threat rather than noise or an isolated observation? And once we determine that it is significant, can that conclusion actually trigger a real-world response and then feed the outcome of that response back into the system?

I saw how a satellite-derived anomaly is not, by itself, proof of contamination. A citizen report is not ground truth. A weather event can produce an apparent water-quality anomaly without there being a persistent contamination event. The interesting engineering problem was therefore not simply detecting anomalies, but establishing significance through evidence convergence . Then I found the IEEE OneAquaHealth Global Hackathon’s Track 7: Digital Health Standards which framed the problem around interoperability across fragmented systems, specifically identifying FHIR models, AI agents, and integration frameworks, a perfect fit.

We could use the Citizen Science ecosystem as one source of environmental evidence, combine it with satellite observations, weather and in-situ measurements, establish whether a seemingly small anomaly was actually significant through explicit spatial, temporal, corroborative, and contradictory evidence, and then solve the second half of the problem: what happens after significance is established?

We began designing not a system that simply raises an alert, but one that could carry evidence through an operational lifecycle: observation → evidence fusion → significance assessment → incident classification → supervised response → field verification → reassessment → interoperable record.

*That became AquaSentinel's central question: Can we build a system that determines when fragmented environmental signals become a significant water-health event—and then closes the loop from that determination to human-approved real-world action and verified outcome?Which is what we built on top of. *

What it does

AquaSentinel basically turns heterogeneous environmental observations into an operational response loop. It ingests evidence from Sentinel-2 optical observations, weather telemetry, citizen reports, in-situ probes, historical reach baselines, and field inspections. Each observation is spatially associated with a monitored reach, quality-checked, deduplicated using SHA-256 provenance, persisted, and emitted onto an event bus.*8 ObservationReceived triggers evidence fusion; EvidenceUpdated then drives incident assessment and response generation. **The fusion engine uses this point based system: In-situ evidence contributes up to 20 base points, field inspection up to 25, satellite anomalies 16, citizen observations 8, and weather 4, with source-specific caps. Repeated observations have diminishing returns, while independent corroboration adds +15 points for two source groups and +25 for three or more. Contradictory evidence can subtract 20–40 points, and factors such as cloud cover, spatial mismatch, and conflicting normal readings are actually explicitly penalized. The resulting 0–100 assessment is then gone on and mapped into NORMAL, VERIFY, INVESTIGATE, or PRIORITIZE, while preserving the evidence breakdown and an explainable rationale answering four questions: what changed, what corroborates it, what weakens it, and what is missing?

That evidence state drives deterministic incident classification. The system is also coded to distinguish patterns such as possible cyanobloom, eutrophication, sewage contamination, industrial discharge, and stormwater events rather than treating every anomaly as the same threat. For example, elevated NDCI combined with low dissolved oxygen or bloom-related citizen observations can support a cyanobloom classification, while heavy rainfall and healthy dissolved oxygen can actively suppress a false alarm. AquaSentinel then evaluates response measures through four hard safety gates and seven suitability dimensions before producing recommendations. A human supervisor reviews the recommendation, selects the responder and priority, and explicitly approves the action. Approval creates a real operational task and publishes a corresponding FHIR R4 Task. The loop does not end there. Field operators progress tasks through REQUESTED → ACCEPTED → IN_PROGRESS → COMPLETED → VERIFIED. Field verification captures geofenced location, water appearance, odour, foam, dead fish, probe measurements, photographs, and sample identifiers. Those observations are ingested back into the evidence engine as FIELD_INSPECTION evidence, triggering reassessment and an outcome evaluation that can produce CONFIRMED, NOT_CONFIRMED, or ADDITIONAL_VERIFICATION_REQUIRED.

So basically to bottle it all down, AquaSentinel is designed around a complete detect → understand → decide → act → verify loop.

How we built it## How we built it

We built AquaSentinel incrementally from a main product requirements document and 9 phase-specific PRDs.

Firstly, we designed and implemented an event-driven backend around an in-memory EventBus. We built a REST observation endpoint (POST /api/v1/observations) that validates incoming observations, associates them with monitored reaches, generates SHA-256 deduplication hashes, attaches cryptographic provenance, persists them to PostgreSQL, and publishes ObservationReceived events. We then wired domain subscribers so those events automatically trigger evidence fusion, incident assessment, recommendation generation, and live frontend updates instead of relying on polling.

After this we, implemented dedicated ingestion pathways for satellite, weather, citizen-science, and batch observations, while also building deterministic adapters so the system could reproduce realistic environmental conditions without depending on fragile external services during demonstrations.

We also designed the PostgreSQL persistence layer to store observations, provenance, evidence assessments, incidents, recommendations, tasks, verifications, outcomes, forecasts, early warnings, interoperability events, and audit records. Alongside that persistence layer, we also wrote domain services that derive spatial associations, temporal correlations, evidence scores, incident classifications, recommendation suitability, geofence status, and outcome evaluations rather than hardcoding those states into the frontend.

To make it rigorous, we built the evidence-fusion engine from explicit mathematical rules. We assigned base evidence weights—20 points for in-situ probes, 25 for field inspection, 16 for satellite anomalies, 8 for citizen reports, and 4 for weather—then implemented source-group caps, diminishing returns, spatial and temporal relevance, baseline deviation, corroboration bonuses of +15 or +25 for independent source groups, and contradiction penalties of up to 40 points. We bounded the resulting confidence score from 0–100 and implemented explainable output covering what changed, what corroborates it, what weakens it, and what evidence is missing.

To seperate out different events we also coded deterministic incident-classification logic capable of distinguishing possible cyanoblooms, eutrophication, sewage contamination, industrial discharge, stormwater events, and unknown anomalies. We specifically implemented contradiction handling so that evidence such as heavy rainfall and healthy dissolved oxygen can actively suppress a misleading contamination signal rather than allowing every anomaly to escalate.

To ensure rigour across the recommendations we built the recommendation engine around four hard safety gates and seven suitability dimensions, which were Evidence Compatibility, Incident Compatibility, Site Compatibility, Temporal Compatibility, Verification Readiness, Operational Feasibility, and Contraindication Penalty. We then implemented a human-review workflow in which recommendations remain pending until a supervisor explicitly approves them, assigns a responder and priority, and records execution notes.

We also then built the operational task state machine and connected approval directly to task creation. Once approved, the system creates a PostgreSQL task, publishes a corresponding FHIR R4 Task, records an audit entry, and emits a TaskCreated event.

To ensure FHIR integration we, integrated a real HAPI FHIR R4 server and implemented FHIR resource mapping for Observation, Task, Flag, and DiagnosticReport. We also built a transactional interoperability outbox, downstream acknowledgement system, retry and deduplication logic, HMAC-SHA256 verification, and a standalone external consumer service, allowing us to test interoperability as an actual delivery pipeline rather than simply displaying FHIR objects in the UI.

We implemented the field-operations lifecycle as REQUESTED → ACCEPTED → IN_PROGRESS → COMPLETED → VERIFIED. We then built mobile verification intake with GPS geofencing and structured field evidence covering water colour, foam, dead fish, odour, dissolved oxygen, turbidity, pH, temperature, photographs, and sample barcodes.

Most importantly, we closed the feedback loop. Field verification creates a new FIELD_INSPECTION observation, feeds it back into evidence fusion, triggers reassessment, and runs the outcome engine to determine whether the incident is CONFIRMED, NOT_CONFIRMED, or requires additional verification.

We wrote integration tests covering the full lifecycle, from raw environmental input through evidence fusion, incident classification, human approval, FHIR task creation, field verification, outcome assessment, and downstream interoperability.

The result is not a collection of independently coded pages so we engineered a connected event-driven system in which an observation can propagate through evidence, decision-making, human approval, field action, verification, and interoperability as one operational lifecycle.

Challenges we ran into

The hardest problem was making heterogeneous, imperfect evidence behave like evidence. A satellite anomaly cannot be treated as ground truth. A citizen report can be valuable but noisy. Weather can explain an apparent contamination signal rather than corroborate it. A missing laboratory assay should reduce confidence rather than silently disappear from the model. We therefore had to encode corroboration, contradiction, temporal alignment, spatial relevance, missing evidence, and source-specific uncertainty directly into the evidence model. We also had to prevent the system from becoming an automated actuator. A high score should not automatically mean “issue a public warning” or “deploy containment.” We introduced safety gates and a human approval layer so that consequential recommendations remain supervised. Another challenge was interoperability. It is easy to claim that an application is “FHIR compatible”; but it is actually like considerably harder to maintain a coherent lifecycle where a domain action creates an actual FHIR resource, records its identifier, places downstream events into an outbox, delivers them reliably, handles acknowledgement and retries, and preserves an audit trail.

Accomplishments that we're proud of

We built a working closed-loop environmental response system rather than stopping at detection.

AquaSentinel can proudly do all of taking heterogeneous observations, preserving provenance, associating them spatially and temporally, fusing them into an explainable confidence state, classifying an incident, evaluating response measures, requiring human approval, generating an operational task, mirroring that task into FHIR R4, executing a field workflow, ingesting field verification, reassessesing the evidence, determining an outcome, and propagating the resulting event through an interoperable outbox.

We are particularly proud of the fact that the system can reason about contradictory evidence, not merely accumulate positive signals. Our deterministic scenarios include weak signals, corroborated events, stormwater contradictions, high-confidence incidents, and situations where critical evidence is missing. We also built a real field-response lifecycle with geofencing and structured ground-truth evidence, meaning the system can distinguish between an incident that was merely suspected and one that was subsequently confirmed or rejected in the field. On the interoperability side, we have a real HAPI FHIR R4 boundary, an event-driven outbox, downstream acknowledgement, retry/deduplication infrastructure, and an external consumer service. GEOSSIP was actually deliberately excluded because it was an unstable external integration and wasn't production-ready.Most importantly, we built the architecture so that a demonstration can be reset to a clean baseline in roughly tens of milliseconds, allowing the entire operational lifecycle to be reproduced!

What we learned

Frankly, this was our first time working at the level of a genuinely distributed, event-driven environmental application rather than a conventional CRUD project. We learned how PostgreSQL persistence, domain events, REST APIs, SSE transport, background workers, FHIR resources, transactional outboxes, external consumers, retries, idempotency, provenance, and state machines have to fit together if a system is going to behave coherently under real operational conditions. Building the evidence engine forced us to think about spatial correlation, temporal windows, baselines, source reliability, diminishing returns, corroboration, contradiction, missing observations, and ground truth. We learned that environmental data is also inherently contextual I saw at first hand that the same optical anomaly can mean something very different when accompanied by rainfall, healthy dissolved oxygen, citizen observations, or an in-situ measurement. That changed how we think about AI and environmental monitoring. A sophisticated system is not necessarily one with the most complicated model, infact it is one that can expose the chain of reasoning from evidence to decision, recognize when evidence conflicts, know what it does not know, and keep a human accountable for consequential action. That is super important in water safety, where a false negative can have public-health consequences, but a false positive can also trigger unnecessary interventions, resource expenditure, and public alarm.

What's next for AquaSentinel

Our next step is to go into a controlled pilot environment and eventually move toward real geographic deployment. In terms of technical advancements as we do more detections we will build a big database and incorporate z-score and statistical methods to replace the current mathematical system which cannot be replaced for now due to a lack of data points. We want to adapt AquaSentinel to the water systems of additional cities, beginning with local deployment where we can work with real streams. The goal is to calibrate the evidence and response layers to each watershed. From there, we want to expand the platform across cities and eventually across countries, building a geographically extensible network of water-safety monitoring systems while preserving our beloved same core architecture: multimodal evidence fusion, explainable risk assessment, supervised intervention, field verification, and interoperable One Health records. Long term, AquaSentinel should definitely become more than software that tells a municipality that its water may be changing. It should become infrastructure that allows environmental evidence to move continuously from the water itself, to the people and systems monitoring it, to the decisions made about it, and back again through verified ground truth.

Our Target Users

Our Primary users are municipal environmental-health departments, watershed/catchment managers, and emergency environmental response teams responsible for deciding when an anomalous water-quality signal warrants investigation or intervention. Our secondary users are field inspectors, laboratories, public-health authorities, and interoperable health/environmental information systems that consume the resulting records. The important distinction is that AquaSentinel is designed for the people who must make and execute decisions about a water event, not simply the people who want to visualize environmental data.

Impact on human life

AquaSentinel’s highest-value impact is potentially reducing the gap between an uncertain environmental signal and a defensible intervention. This matters because environmental signals can be substantially wrong: one validated HAB study found satellite-based indicators with 12–80% false-positive rates and up to 38% false negatives, depending on algorithm. EPA’s Cincinnati warning-system evaluation likewise found that only 0.38% of alerts were ultimately valid, illustrating the operational burden of distinguishing actionable incidents from noise. If AquaSentinel can improve that triage and accelerate verification, responders could concentrate scarce field capacity on credible threats, contain localized incidents sooner, and reassess conditions before unnecessary restrictions persist. At scale, the plausible impact is therefore not simply more monitoring, but fewer missed threats, fewer wasted interventions, and shorter exposure windows with contaminated water ecosystems for people.

Built With

• citizenscience
• copernicusdataspace
• datafusion
• digitalhealth
• docker
• environmentalmonitoring
• event-drivenarchitecture
• express.js
• fhirr4
• geospatialdata
• hapifhir
• hmac-sha256
• node.js
• onehealth
• open-meteo
• postgresql
• react
• remotesensing
• restapi
• sentinel-2
• server-sentevents
• typescript