Aapda Vaarta: Sikkim Flood Alert Adaptor

Aapda Vaarta turns one official flood alert into life-saving, multilingual emergency messages that reach the right people through the right channel, even on 2G.

Comment

About the Project

Inspiration

Aapda Vaarta was inspired by a real and urgent gap in disaster communication. In flood emergencies, the problem is often not that authorities fail to issue alerts, but that the alert does not reach the right people in the right form at the right time.

The 2023 Sikkim glacial lake outburst flood showed how fragile last-mile communication can be in mountain regions. A warning may exist in English, but people on the ground may need it in Nepali, Hindi, or another language, in a simpler form, through SMS or IVR, and under poor network conditions. That reality pushed us to think beyond a normal translation tool.

We wanted to build something that feels closer to a real district emergency communication system:

  • serious
  • operational
  • multilingual
  • low-bandwidth aware
  • safe for life-critical messaging

That idea became Aapda Vaarta.

What We Built

Aapda Vaarta is a Gemini Flash-powered emergency alert adaptation platform for flood response.

It takes one official alert in English and transforms it into:

  • an SMS version
  • a WhatsApp voice-note script
  • an IVR script
  • an audio playback version
  • multiple language variants
  • multiple literacy adaptations

We also expanded the project beyond adaptation into a more complete emergency operations concept. The system now supports:

  • 14 languages
  • 4 literacy levels
  • 3 network conditions
  • a district-collector-friendly quick broadcast flow
  • voice-input support
  • a dashboard-style emergency control panel
  • database-backed citizen targeting and broadcast logic scaffolding

In simple terms:

\text{One Official Alert} \rightarrow \text{Many Safe, Usable Delivery Formats}

And in the larger system vision:

\text{One Alert} \rightarrow \text{Right Adaptation} \rightarrow \text{Right Audience} \rightarrow \text{Right Channel}

How We Built It

We built the system using:

  • Next.js App Router
  • TypeScript
  • Tailwind CSS
  • Node.js API routes
  • Gemini Flash
  • Prisma + SQLite-based local data scaffolding
  • browser speech APIs for dictation and playback

Core AI pipeline

The project uses a three-step Gemini pipeline:

  1. Intent extraction
    The system first extracts:

    • disaster type
    • location
    • urgency
    • action required

  2. Message generation
    It generates channel-specific outputs across languages and literacy levels.

  3. Meaning validation
    It checks whether the generated output still preserves the life-saving intent of the original alert.

So the core flow looks like:

A \rightarrow I \rightarrow G \rightarrow V

where:

  • (A) = original alert
  • (I) = extracted intent
  • (G) = generated outputs
  • (V) = validation

System design

We built the frontend like a government-style operations console:

  • language-selection entry screen
  • official header and branding
  • navigation bar
  • operator profile area
  • live output cards
  • loading states while typing
  • quick broadcast controls

We also started shaping the backend for future targeting and delivery:

  • citizen/location/language-aware data handling
  • broadcast API scaffolding
  • dashboard API scaffolding
  • delivery and targeting helper modules

This helped move the product from “AI text generator” toward “emergency communication platform.”

What We Learned

This project taught us that disaster communication is not only a language problem, it is a systems problem.

We learned that:

  • preserving meaning matters more than producing fluent text
  • emergency UX must optimize for speed, clarity, and trust
  • the same message must be adapted differently for SMS, IVR, and voice delivery
  • multilingual support alone is not enough if literacy and network conditions are ignored
  • AI in crisis systems needs structure, constraints, and fallback safety checks

We also learned how quickly complexity grows when you combine:

  • (L) languages
  • (R) literacy levels
  • (N) network conditions
  • (C) delivery channels

The adaptation space becomes:

\text{Variant Space} \approx L \times R \times N \times C

Even for an MVP, that means the system must be carefully designed, or it becomes inconsistent very fast.

Challenges We Faced

  1. Preserving life-saving intent

The hardest challenge was making sure the message stayed safe.

In an emergency, “simpler” must never mean “weaker.” If the original instruction says:

  • evacuate immediately
  • avoid bridges
  • avoid riverbanks

then those instructions must remain intact in every adapted version.

That forced us to think carefully about prompt design, output structure, and validation rules.

  1. Designing for real Indian emergency conditions

This project is rooted in an India-specific disaster context. That meant we had to think about:

  • multilingual communication
  • low literacy support
  • 2G and poor-network fallback
  • district-level operational use
  • local place accuracy

We had to avoid making it feel like a generic AI product and instead make it feel grounded in how flood communication may actually work in states like Sikkim, Assam, or Bihar.

  1. Making the UI feel official and usable

Another challenge was product identity.

We wanted the interface to feel like:

  • a control room
  • a command dashboard
  • a district operator tool

not:

  • a chatbot
  • a basic translator
  • a generic form app

So we built branding, navigation, validation states, voice support, and broadcast readiness into the experience.

  1. Balancing hackathon speed with production thinking

Hackathons reward fast execution, but this problem demands serious design thinking. We had to decide where to build real depth and where to keep things as a believable prototype.

For example:

  • we implemented real adaptation logic and validation flow
  • we built the UI and API structure for broadcasting
  • we added database and targeting scaffolding
  • but we did not fully integrate production telecom systems like live WhatsApp Business or IVR vendors

This balance was a major design decision throughout the project.

  1. Technical integration issues

We also faced practical engineering challenges:

  • CSS selector issues during build
  • type-safety gaps with SQLite adapter packages
  • memory pressure during production builds
  • keeping the UI, data model, and Gemini prompts aligned while the scope expanded

These issues were important reminders that production polish is not only about features, but also about stability.

Why This Project Matters

Aapda Vaarta matters because in a disaster, communication failure can become a second disaster.

A warning is only useful if:

  • it reaches the person
  • in time
  • in a language they understand
  • in a format they can act on
  • through a channel that still works

The project is built around the belief that last-mile communication deserves the same seriousness as forecasting and rescue.

Future Scope

Aapda Vaarta can grow into a full targeted emergency broadcasting platform with:

  • district-wise audience targeting
  • citizen preference databases
  • map-based coverage analytics
  • telecom and IVR integrations
  • WhatsApp Business delivery
  • retry and fallback logic
  • operator audit trails
  • vulnerable population prioritization

The long-term system vision is:

\text{Official Alert} \rightarrow \text{Adaptive Intelligence} \rightarrow \text{Targeted Delivery} \rightarrow \text{Reach Analytics}

That would turn the platform from an alert adaptor into a full disaster communications infrastructure layer.

Closing

Aapda Vaarta started as a flood alert adaptation challenge, but it became a broader exploration of how AI can support inclusive, resilient, high-stakes public communication.

At its heart, the project is about one principle:

In an emergency, the right message is not enough. It must reach the right person, in the right way, before it is too late.

Built With

Share this project:

Updates