Inspiration

The Punjab floods were a stark wake-up call. We saw firsthand how generic weather apps, designed for casual rain, completely fail when a real crisis hits. People were getting conflicting information, or worse, delayed warnings. When every minute is the difference between safe evacuation and disaster, unreliable data is deadly. We knew the solution wasn't just another weather app—it needed to be a dedicated, dual-layered flood AIsystem that gives people rock-solid, hyper-local risk scores when they need them most. That's why we built AquaSentry.

What it does

AquaSentry provides the most reliable flood forecasting available by using a Hybrid Dual-Model AI Architecture. We built two separate logic systems to provide the right information for the right context, as a single model is insufficient for both awareness and action. Risk Visualization Model (Awareness): Our main dashboard (SafetyTipsActivity) uses a Max-Ensemble Logic (Math.max). It analyzes both the river discharge and rainfall forecasts and displays the highest potential risk (from 0-5ft) on a custom, animated FloodLevelView diagram. This is crucial for assessing property danger. Evacuation Trigger Model (Action): Our EvacuationRouteActivity uses a more rigorous logic. It runs a Dual-Check Threshold System that only triggers a "DANGER" alert if two conditions are met: the absolute flood level is high AND the rate of increase is dangerously fast. This Dual-Model architecture ensures users get a nuanced risk level for awareness, but a high-confidence, binary alert for evacuation. The app also includes a fully Offline Safety Hub (for emergency contacts) and a one-touch Google Maps Evacuation Router (using native Android Intents) to find the nearest shelter, making it a complete, life-saving tool.

How we built it

We built a native Android application in Java, prioritizing stability and resilience. The core architecture is a Dual-Model AI system that runs two logic engines in parallel. Model 1 (Max-Ensemble): We integrated the OpenMeteo River (GloFAS) and Weather (Precipitation) API. The combineAndAnimateFloodData function parses both JSON results and uses a Math.max() call to identify the single worst-case scenario, which is then passed to our custom FloodLevelView for animation. Model 2 (Dual-Check): We built a separate isFloodRiskHigh function that performs a high-confidence check. It validates both the absolute danger level (MINIMUM_DANGER_LEVEL) and the rate of change (DANGER_INCREASE_PERCENT) before triggering an evacuation state. We used Java's ExecutorService for concurrent, non-blocking API calls and Handler to post results to the UI thread. The evacuation route uses an Implicit Intent to Google Maps, ensuring it works reliably on any device without draining the battery. We also implemented a custom Tls12SocketFactory to ensure network compatibility and security on older Android devices that do not enable TLSv1.2 by default. Challenges we ran into The biggest challenge was designing the core AI Logic. We quickly realized a single model was insufficient for two different user needs (Awareness vs. Evacuation). A simple Math.max() is great for awareness but too sensitive for an evacuation trigger. A simple average ((a+b)/2) was too dangerous, as it could hide a 100% risk from one source. Our solution was to engineer two separate, specialized logic systems (the Max-Ensemble for the dashboard and the Dual-Check Threshold for evacuation) to provide the right information for the right context. We also overcame a critical networking bug on older Android devices (API 19-21) where our HttpsURLConnection calls were failing due to outdated security protocols. We engineered a custom Tls12SocketFactory to successfully force all API calls to use the modern TLSv1.2 protocol, ensuring our app is both secure and functional across a wider range of devices. Accomplishments that we're proud of We are incredibly proud of building a fully functional, native Android app that is architecturally resilient. By separating the logic, we created a system that provides nuanced awareness while preventing "alert fatigue." We are also proud of the custom-built FloodLevelView animation and the low-level Tls12SocketFactory, which shows our commitment to solving deep engineering problems. Most importantly, we've created a system that we genuinely believe can save lives by providing reliable, timely evacuation guidance.

What we learned

We learned that in a life-critical system, the architecture must account for different user needs. The logic for "Should I be worried?" is different from "Should I run?" We also learned the immense value of designing for disaster—the UI UX decisions (like using native Intents and an Offline Safety Hub) were not about aesthetics; they were about minimizing cognitive load and prioritizing reliability when time is running out.

What's next for AquaSentry

Our immediate focus is on expanding our geographical coverage. We plan to integrate community-reported data safely validated by our AI to further refine our hyperlocal risk maps. We will also integrate the MapRoutesActivity's hard-coded flood zones with the live data from our OpenMeteo APIs to create a fully dynamic, real-time routing engine.

Technical Deep Dive: The Dual-AI Logic

AquaSentry's reliability is powered by its unique Hybrid Dual-Model AI Architecture. It runs two distinct logic engines side by side to serve two different purposes: long-term flood awareness and real-time emergency action.

Model 1: Risk Visualization Model (Awareness)

This model tackles a simple but crucial question: "What is my potential property risk?" It focuses on showing the worst-case scenario to help users understand possible dangers early.

Let ( R_{river} ) represent the predicted flood risk (in feet) from river discharge data obtained through the GloFAS API.
Let ( R_{rain} ) represent the predicted flood risk (in feet) from precipitation data fetched via the OpenMeteo API.

The final displayed risk, ( R_{visual} ), is derived from our Max-Ensemble Logic:

$$ R_{visual} = max(R_{river}, R_{rain}) $$

By taking the maximum of both values, the system always presents the highest possible risk level — ensuring users never experience a "false safe" situation where one data source misses a developing threat.

Model 2: Evacuation Trigger Model (Action)

This model focuses on the urgent question: "Do I need to evacuate right now?" It is built for precision and avoids triggering unnecessary panic through overly frequent alerts.

Let ( F_{level} ) represent the absolute predicted flood level from combined data sources.
Let ( F_{rate} ) represent the percentage rate of increase of that flood level over time.
Let ( T_{level} ) be our predefined Minimum Danger Level threshold.
Let ( T_{rate} ) be our Danger Increase Rate threshold.

An evacuation alert is triggered only if both conditions are satisfied, according to our Dual-Check Threshold logic:

$$ EvacuationAlert = (F_{level} ge T_{level}) land (F_{rate} ge T_{rate}) $$

Here, ( land ) denotes the logical "AND" operator. This ensures that any evacuation alert AquaSentry sends is not just a warning, but a confident life-saving directive — issued only when both the danger level and its growth rate are critical.