Sentinel AI - Disaster Risk Intelligence & Response

Sentinel AI predicts when floods start, peak and ease, AI-verifies citizen reports, blocks fakes and duplicates, and dispatches volunteers in seconds - even offline, in 6 languages.

Comment

Inspiration

India lost $79.5B (~₹6.6L Cr) to climate disasters between 1998 and 2017 (UNDRR), and more than 100 crore people live in disaster-prone zones. While working on urban flood risk in Hyderabad, we kept running into the same gap. Forecasts exist (CWC river levels). Public alerts exist (NDMA SACHET). But the part in between is still handled over phone calls: confirming what is actually happening on the ground, deciding who goes where, and proving the job got done.

Field reports take hours to verify and arrive duplicated. Alerts miss people who don't read English. Departments work without a shared picture. And when the mobile network goes down, reporting stops completely.

The disaster isn't the problem. The blind spot before it is.

We designed Sentinel AI flood-first, so it can be extended to cyclones, storm surge and fire. Every one of these hazards fails the same way: nobody sees it coming.

What it does

Sentinel AI covers the whole disaster lifecycle (before, during and after) on one shared H3 risk grid.

🟢 Before: Digital Twin + Prediction Agent

  • A real-time city Digital Twin combines live rainfall, radar, river gauges, satellite imagery and government hazard layers, and rescans every zone every 5 minutes.
  • Each H3 cell is scored as Risk = Hazard × Vulnerability, before a single report comes in.
  • A Prediction Agent turns forecasts into per-cell hazard windows that say when danger starts, peaks and eases, not just how bad it is.
  • When forecast data runs out, the cell stays "still elevated" instead of quietly showing an all-clear.
  • The Digital Twin is live in 2 cities (Hyderabad, Bengaluru), and 26+ regions are under forecast monitoring.

🟣 During: Detect, Verify, Dispatch

Citizens can report in 3 ways, in 6 languages (English, Hindi, Telugu, Tamil, Malayalam, Kannada):

  1. Online reporting (PWA): an auto-geotagged photo or video, saved offline and synced when the connection comes back
  2. Voice SOS: hold for 2–3 seconds to send a geotagged alert to nearby volunteers
  3. AI Calling Agent: dial a number from any phone and report by voice, no mobile data needed

Every report gets a 4-signal verification score, with the four signals weighted equally:

$$S = 0.25\,\left(S_{\text{image}} + S_{\text{heatmap}} + S_{\text{user}} + S_{\text{climate}}\right)$$

Score Action
≥ 85% Priority dispatch, top of the queue
50–84% Standard official review
< 50% Held, needs corroboration
  • Corroboration: nearby reports (~5.5 km / 24 h) raise confidence, and duplicates are matched automatically so a second team is never sent to the same spot.
  • Evidence integrity: screen-recapture detection keeps re-photographed screens out of auto-approval.
  • Dispatch: verified alerts go out to geo-fenced areas only, so the whole city isn't panicked. The nearest volunteer is notified on WhatsApp with AI-routed navigation, ≤ 3 seconds from verification to notification (tested).
  • Proof of closure: an incident can't be closed until GPS + photo proof is submitted.

🔴 After: LifeLine P2P Recovery

  • Survivors post their needs, donors post supplies, and LifeLine matches and dispatches them automatically. This reaches the gap that institutional aid can't cover quickly.
  • A Community Hub lists relief events, cleanups and blood drives, with points, badges, leaderboards and certificates for volunteers.

Six portals, one system

Citizen · Volunteer · Supervisor · Analyst · Municipal Commissioner · Community. Every approval, rejection, resource movement and resolution is timestamped and CSV-mirrored for audit.

How we built it

  • Backend: Python + Flask, PostgreSQL + PostGIS (production), SQLite (dev), REST API layer, APScheduler for background jobs, Docker, deployed on Render with ngrok for webhooks
  • AI / LLM: OpenAI GPT handles verification, with NVIDIA Nemotron as an automatic fallback so scoring never fails. LangGraph orchestrates the Prediction Agent's hazard windows. Qwen3, TextBlob + NLTK handle text and sentiment, and an OSINT framework does source checks.
  • Communication: Twilio runs the AI calling agent, WhatsApp dispatch and SMS fallback
  • Geospatial: Uber H3 grid for risk scoring, Leaflet.js + MapLibre GL, Esri World Imagery, CARTO Voyager, Google Maps Static API
  • Data (20+ sources): Open-Meteo, RainViewer, CWC, TGDPS, Windy, NASA GIBS, OpenStreetMap, plus Mapillary and KartaView street-level imagery as ground truth for the Digital Twin
  • Frontend: HTML5, CSS3, JavaScript, Bootstrap 5, a PWA (Service Worker + Web App Manifest) for offline-first reporting, Chart.js
  • Imaging & analytics: Pillow, NumPy, Matplotlib
def triage(report):
    s = 0.25 * (image_score(report)      # recapture + content check
              + heatmap_score(report)    # nearby reports, ~5.5 km / 24 h
              + user_score(report)       # reporter reliability
              + climate_score(report))   # live weather / hazard alignment
    if s >= 0.85: return "PRIORITY_DISPATCH"
    if s >= 0.50: return "OFFICIAL_REVIEW"
    return "HELD_NEEDS_CORROBORATION"

Challenges we ran into

  • The organizational problem was harder than the algorithmic one. Mapping how five different government bodies actually coordinate during a flood shaped the design of all six portals.
  • Scoring can't go down during a disaster. We built a primary/fallback LLM chain (OpenAI → Nemotron), so a provider outage never stops verification.
  • Fake and recycled evidence. People re-photograph old disaster images off a screen. Recapture detection has to catch these before a reviewer ever sees them.
  • Unreliable data feeds. External APIs lag or drop out. We used multiple sources with fallbacks, and the rule that an expired forecast means "still elevated", never "all clear".
  • Networks fail exactly when they're needed. That's why the system has voice-call reporting with no data, an SMS fallback and offline PWA sync.
  • Responder safety. Volunteers shouldn't be routed into the hazard itself, so dispatch is geo-fenced with hazard-aware routing.
  • Privacy. Citizen photos and voice currently pass through a third-party AI provider. Before we scale, we're moving to DPDP Act 2023-compliant self-hosted processing with India-region data residency.

Accomplishments that we're proud of

  • 3 report channels, 4 verification signals, ≤ 3 s verification-to-dispatch (tested)
  • 6 languages live, 26+ regions monitored, Digital Twin live in 2 cities
  • A working end-to-end loop: predict → report → verify → dedup → dispatch → prove closure → recover

What we learned

  • Forecasting alone doesn't save time. Closing the loop does: verification, deduplication, dispatch and proof.
  • Showing an all-clear is a decision, so it should never be the system's default when data runs out.
  • A response system is only as inclusive as its lowest-bandwidth channel. A voice call on any phone reaches people a smartphone app can't.

What's next for Sentinel AI

Next: PostGIS spatial indexing for city-scale radius queries · WebSocket push alerts in place of polling · scaled APScheduler fan-out for WhatsApp + SMS · scheduled hazard-window recomputation

Later: live IoT river-gauge and drainage-sensor ingestion · native apps with background geofencing · satellite SAR inundation mapping for post-event damage assessment · self-hosted, India-resident processing · integration with NDMA / SDMA / SACHET incident-exchange standards and EOCs

Pilot path (12 months): Hyderabad urban flooding (GHMC) → Bengaluru → a coastal district (cyclone/surge) → district-wide scale-up, at about ₹8,000–10,000 per city per month in pilot operating cost.

Team TECH MAX · Maximum Intelligence. Maximum Safety.

Built With

Share this project:

Updates

Submission history