Pukaar: Building a Human-Centered Flood Early-Warning System for Himalayan Villages on AWS
Combining deterministic risk assessment, generative AI, IoT telemetry, and offline-first design to explore how flood warnings can reach mountain communities more effectively.
Introduction: A Warning Is Only Useful If It Reaches People
In the Himalayan region, heavy rainfall can rapidly change river conditions, damage roads, and threaten communities living near riverbanks and mountain streams. Forecasts and dashboards are valuable, but information must also reach the people who need to act on it.
A warning system faces several challenges beyond predicting dangerous conditions:
- How can regional weather information be translated into meaningful village-level risk assessments?
- How can local observations complement incomplete or delayed forecasts?
- How can warnings be communicated in languages people understand?
- How can the system remain useful when internet connectivity becomes unreliable?
- How can authorities verify that an alert was reviewed and delivered?
These questions inspired Pukaar (पुकार), a flood early-warning prototype focused on the needs of Himalayan communities.
The guiding idea is simple:
The call that reaches the village before the river does.
Pukaar explores how cloud services, deterministic risk rules, generative AI, community reporting, and IoT telemetry can work together to support a more accountable warning workflow.
1. Understanding the Last-Mile Problem
A flood warning can exist in a dashboard without reaching the people who need it.
A technical forecast may be difficult to interpret quickly. A message may not use a familiar language. Cellular connectivity may be unavailable in a remote valley. A local landslide or overflowing culvert may go unnoticed by a regional forecasting model.
There is also an important distinction between sending a notification and confirming that somebody received and understood it.
Pukaar approaches these challenges through five design principles:
Forecast to local context: Translate weather and river information into understandable risk indicators associated with configured villages.
Automation with accountability: Use programmed rules to evaluate conditions while retaining an explicit review and approval process where configured.
Text to speech: Explore spoken Hindi warnings using Amazon Polly, making alerts more accessible to people who may have difficulty reading technical messages.
Delivery to acknowledgement: Record available delivery and acknowledgement events rather than treating dispatch as proof of receipt.
Centralized data to community intelligence: Allow local observations to complement forecast and sensor data.
The goal is not to replace official disaster-management systems. It is to explore how software can help connect environmental evidence, local observations, and actionable communication.
2. Architecture: Code Decides, the Model Words
One of the most important engineering decisions is separating risk assessment from generative AI.
Large language models can help draft messages, summarize reports, and organize unstructured observations. However, they should not independently determine whether a village is in danger or decide who receives an emergency alert.
Pukaar follows this principle:
Code decides. The model words.
The intended architecture has several stages:
- Collect available weather forecasts, river-discharge estimates, sensor readings, and community reports.
- Validate incoming data and identify missing, stale, or suspicious measurements.
- Evaluate the available evidence using explicit, configurable risk rules.
- Generate an explainable decision record showing which conditions contributed to the result.
- Prepare a human-readable warning, using AI-assisted drafting where available.
- Route the proposed warning through the configured approval workflow.
- Deliver the approved message through the available communication channel.
- Record delivery events, acknowledgements, and relevant actions for later review.
AWS services can support different parts of this workflow. AWS Lambda can run event-driven processing, Amazon DynamoDB can store application records, and AWS Step Functions can coordinate multi-step workflows and approval tasks.
Amazon Bedrock can support constrained text generation, while Amazon Polly can convert supported Hindi text into speech.
The architecture is intended to keep risk calculations explicit and reviewable. The exact operational behavior depends on the deployed configuration and tested implementation.
3. From Forecasts to Explainable Risk
A warning system needs to explain why it considers a situation dangerous.
Pukaar's risk-assessment approach brings together several potential evidence sources:
- Rainfall forecasts: Indicate whether significant precipitation is expected.
- River-discharge estimates: Provide information about forecast river flow.
- Physical gauge telemetry: Can provide direct measurements when a sensor is installed and transmitting valid readings.
- Community reports: Can surface local observations such as rising water, debris flows, or blocked culverts.
- Independent evidence: Multiple consistent sources can increase confidence in an assessment when the underlying rules support that interpretation.
The project uses a transparent risk-state concept:
- Normal
- Watch
- Warning
- Critical
These states are intended to help users understand changing conditions without relying on an unexplained AI-generated score.
Why source resolution matters
Not all environmental data has the same spatial or temporal resolution.
For example, Open-Meteo's Flood API provides GloFAS-based river-discharge information at approximately 5 km resolution with daily forecast values. Such information can be useful for regional context, but it should not be treated as a precise measurement of a small Himalayan stream or a minute-by-minute prediction of flood arrival.
Likewise, a software process that checks forecast data every 15 minutes does not mean the underlying forecast is refreshed every 15 minutes.
Before using these sources for operational decisions, the coordinates, river coverage, update frequency, and suitability for each location must be validated.
Rainfall classifications should also be tied to the relevant measurement period. For India's standard 24-hour rainfall categories, the India Meteorological Department classifies heavy rainfall as 64.5–115.5 mm, very heavy rainfall as 115.6–204.4 mm, and extremely heavy rainfall as 204.5 mm or above. These categories describe rainfall intensity; they are not, by themselves, validated flood thresholds for an individual village.
Reducing alert fatigue
Risk measurements can fluctuate around a threshold. Without appropriate state management, a system might repeatedly switch between Warning and Normal.
A technique called hysteresis helps reduce these unnecessary transitions. For example, a system can escalate risk when an upward threshold is crossed but require several consecutive lower-risk evaluations before downgrading an existing state.
The actual thresholds and transition rules must be calibrated against relevant historical and local observations. A configured rule is not automatically a validated safety threshold.
4. Human Approval with AWS Step Functions
A risk assessment and an emergency communication are different decisions.
A system may detect a potentially dangerous situation, but an operational workflow also needs to define who reviews the evidence, how the decision is recorded, and what happens if the responsible person is unavailable.
AWS Step Functions supports workflows that pause while waiting for an external response. Its callback task-token pattern can be used to coordinate human approval.
A possible Pukaar workflow is:
- A configured risk rule identifies a potentially dangerous condition.
- The system prepares a decision record and a proposed warning.
- An authorized officer receives the relevant information.
- The officer reviews the evidence and the proposed message.
- The workflow continues according to the recorded decision.
- Timeouts and escalation paths handle cases where a response is not received.
A review interface should present the village, evidence, risk state, warning text, and available actions without unnecessary complexity.
The design also raises an important safety question: what happens if nobody responds during a critical event?
That behavior must be explicitly designed, approved by the responsible authorities, and tested. A fallback that automatically sends a warning is not inherently safe simply because it avoids a timeout. Its authority, message content, recipients, and conditions must be carefully defined.
5. Responsible AI with Amazon Bedrock
Generative AI can make technical information easier to communicate, but it can also introduce unsupported statements.
In a flood-warning context, an invented water level, evacuation time, village name, or shelter location could create serious risks.
Pukaar's design therefore treats AI as a constrained assistant rather than the authority for life-safety decisions.
A responsible implementation should follow three principles.
Ground the model in structured evidence. Provide the model with approved facts, such as the village name, validated measurements, risk state, and verified safety instructions.
Validate generated text. Check names, measurements, locations, and other critical claims against the source data. Reject unsupported details and use a reviewed fallback message when necessary.
Keep safety instructions controlled. Critical instructions should come from approved templates and authoritative local guidance, rather than unrestricted model generation.
For example, a model may help turn a technical decision record into clear Hindi. It should not invent a shelter or estimate how many minutes remain before floodwaters arrive unless such information is supported by a separately validated source.
AI-generated messages should also be reviewed by fluent Hindi speakers and, where relevant, people familiar with local terminology and dialects.
6. Spoken Warnings with Amazon Polly
Text is not always the most accessible format during an emergency.
A spoken message can help people who have difficulty reading a screen or who need to hear an instruction while away from home.
Amazon Polly supports Hindi speech synthesis, including the Kajal neural voice. Pukaar explores how a validated warning can be converted into audio and distributed alongside written instructions.
A potential delivery workflow is:
- Finalize the approved warning text.
- Generate speech from the supported Hindi text.
- Associate the audio with the relevant alert identifier.
- Deliver the written and spoken warning through a configured channel.
- Record available delivery and acknowledgement events.
The delivery channel matters. Telegram can support message and audio delivery to users who have access to the service, but it does not reach every resident by default.
SMS, voice calls, public-address systems, and local responders are possible complementary channels. Each requires separate implementation, testing, and operational arrangements.
An acknowledgement button can record that a user interacted with a message. It cannot prove that the person fully understood the warning or that everyone in the household received it.
7. Community Reporting and Offline-First Design
Sensors and forecast models cannot observe every local event.
A resident may notice an overflowing culvert, a damaged footbridge, a sudden change in river conditions, or a landslide blocking a road before that information appears in a regional data source.
Pukaar's community-reporting concept allows people to submit local observations using a lightweight interface, including voice notes and photographs where supported.
An offline-first approach can help when connectivity becomes unreliable. A browser can temporarily queue selected report data for later upload, subject to available storage, permissions, and device limitations.
A reliable implementation must consider:
- Whether a report was saved successfully on the device.
- Whether it has been uploaded or is still queued.
- Whether the upload failed and can be retried safely.
- Whether the report contains duplicate or misleading information.
- Whether its location and timestamp are available and trustworthy.
- Whether sensitive information is protected.
Reports should be labelled by verification status. A submitted report is evidence to assess, not automatically a confirmed event.
When a report is verified by an authorized person or corroborated by independent evidence, the system can use that information according to its configured rules.
This bidirectional approach is important because local observations may reveal conditions that broader forecasting products miss.
8. IoT River Gauges: Connecting Software to Physical Measurements
Forecasts provide information about what might happen. A correctly installed and calibrated river gauge can provide information about conditions at a particular physical location.
Pukaar explores an IoT design using an ESP32 microcontroller and a waterproof ultrasonic distance sensor, such as the JSN-SR04T.
The basic concept is straightforward:
- Mount a sensor at a suitable, stable location above the water.
- Measure the distance from the sensor to the water surface.
- Use a surveyed reference point and installation geometry to derive a meaningful water-level measurement.
- Transmit the reading through a configured communication link.
- Validate the reading before using it in the risk-assessment process.
The sensor does not automatically know the absolute river stage. Its measurements need a reliable reference datum, appropriate mounting, calibration, and checks for obstructions, turbulence, sensor faults, and changing installation geometry.
AWS IoT Core and telemetry
AWS IoT Core can provide authenticated device connectivity and MQTT-based message ingestion. A practical deployment can assign device credentials, validate incoming readings, and route accepted messages into the application backend.
Each measurement should carry useful metadata, such as:
- Device and location identifiers.
- Measurement timestamp.
- Water-level value and units.
- Data-quality or sensor-health indicators.
- Whether the reading is simulated or physically measured.
Missing, stale, or implausible readings should not be silently treated as current and valid.
Prototype limitation: The project's documented IoT approach includes simulated gauge readings. A simulated reading demonstrates software behavior, not the accuracy of a physical gauge. Hardware installation, calibration, weatherproofing, power reliability, communications, and field performance must be validated separately.
9. Roles, Access Control, and Auditability
Flood response involves different responsibilities.
District-level officers may need to review regional conditions and coordinate alerts. Village representatives may need to verify local observations and maintain information about shelters. Members of the public need a straightforward way to access relevant information and submit reports.
Role-based access control helps ensure that each user can perform only authorized actions.
AWS Cognito can support user authentication, while application-level authorization policies can restrict access to particular operations or locations. Every sensitive action should be recorded with relevant details, including the actor, action, timestamp, and result.
Audit records can help answer questions such as:
- Who approved or rejected a warning?
- Which evidence supported the decision?
- Was a report verified or rejected?
- Which communication attempts succeeded or failed?
- Were any actions performed without the expected authorization?
An audit trail is useful only when its access controls, retention, integrity, and failure behavior are designed appropriately. It should not be described as immutable unless the storage architecture actually enforces that property.
10. Testing Beyond the Happy Path
A system can work correctly during a normal demonstration and still fail under real conditions.
Flood-warning software needs tests for unusual inputs, interrupted connections, stale measurements, service failures, and ambiguous decisions.
Pukaar's testing strategy should distinguish between several kinds of evidence:
Unit tests: Check individual risk rules, data validation, state transitions, and message validation.
Integration tests: Verify that data moves correctly between the backend, storage, workflow, and delivery components.
Failure tests: Simulate missing sensor readings, network outages, service errors, duplicate events, and officer timeouts.
Replay tests: Run historical or synthetic scenarios through the same risk logic to examine when the system would have raised or lowered a risk state.
Field validation: Compare measurements with trusted reference observations and assess how people interpret and respond to messages.
Replay testing is useful, but it is not proof of predictive accuracy. A meaningful historical evaluation needs suitable data, documented assumptions, and metrics such as missed events, false alarms, detection timing, and data availability.
A replay should also be clearly separated from live operation. Test alerts must never accidentally reach real emergency recipients.
Before claiming successful back-testing against a specific historical flood, the underlying dataset, event timeline, expected outcomes, and measured results should be documented.
11. AWS Services and Their Roles
The following services are relevant to Pukaar's architecture. The exact services used in a deployed environment should be confirmed against the implementation.
AWS service | Potential role |
|---|---|
AWS Lambda | Event-driven processing and backend tasks |
Amazon DynamoDB | Village metadata, readings, report records, and audit events |
AWS Step Functions | Multi-step workflows, approvals, retries, and timeouts |
Amazon Bedrock | Constrained text drafting and structured report assistance |
Amazon Polly | Hindi text-to-speech generation |
Amazon Transcribe | Speech transcription, where supported and configured |
AWS IoT Core | Authenticated device connectivity and telemetry ingestion |
Amazon S3 | Storage for media and generated artifacts |
Amazon Cognito | User authentication |
Amazon EventBridge | Scheduled or event-driven execution |
AWS Systems Manager Parameter Store | Storage and retrieval of configuration and secrets, with appropriate access controls |
AWS Serverless Application Model (AWS SAM) can help define supported infrastructure as code, making deployment configuration more repeatable and reviewable.
Using managed services does not remove the need for security, cost management, regional service-availability checks, operational monitoring, and disaster-recovery planning.
12. What We Learned
Deterministic rules and generative AI have different responsibilities
AI can help explain evidence, but risk classification and alert authorization require explicit rules and accountable operational decisions.
Local observations are important
Regional forecasts cannot be assumed to capture every localized event. Community reports and physical measurements can provide additional evidence, provided they are validated appropriately.
Connectivity must be treated as a design constraint
A system intended for remote mountain communities needs clear behavior when the network is unavailable, data is delayed, or a device goes offline.
An alert being sent is not the same as an alert being understood
Delivery logs and acknowledgement controls can improve visibility, but real reach and comprehension require additional evaluation.
Honest limitations improve engineering quality
Clearly identifying simulated data, untested hardware, incomplete integrations, and deployment gaps makes a prototype easier to evaluate and improve.
13. What Comes Next?
Pukaar's next steps should focus on validating the complete warning workflow rather than adding technology for its own sake.
Priorities include:
- Verify deployment status and test the configured AWS resources.
- Validate the geographic mapping between sensor locations, river segments, and downstream villages.
- Test the risk engine against representative historical and synthetic scenarios.
- Build and calibrate a physical gauge prototype before relying on its readings.
- Evaluate warning language with native Hindi speakers and people familiar with local communities.
- Test the complete approval, delivery, acknowledgement, and failure-handling paths.
- Explore additional communication channels and reliable offline behavior.
- Work with relevant local authorities to validate thresholds, safety instructions, shelters, and escalation procedures.
Any real-world deployment would require field testing, appropriate authorization, reliable communications, and coordination with official disaster-management authorities. Pukaar should be treated as a prototype and engineering effort, not as a replacement for official warnings.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article