Student Innovation-Disaster management includes ideas related to risk mitigation, Planning and management before, after or during a disaster.

SIH 2026 Solution Research & Technical Architecture Dossier

1. Executive Snapshot

Executive Summary

The Smart India Hackathon (SIH) Problem Statement SIH26206 focuses on "Student Innovation in Disaster Management," requiring a comprehensive software solution that addresses risk mitigation, planning, and management across all three critical phases of the disaster lifecycle: before (prevention/preparedness), during (emergency response/rescue), and after (recovery/relief allocation) [PS]. Existing disaster management tools in India—such as NDMA's SACHET early warning portal [RESEARCHED] and ISRO's Bhuvan National Database for Emergency Management (NDEM) [RESEARCHED]—provide essential centralized alerts and macro-level spatial intelligence. However, significant gaps persist at the grass-roots operational level: fragile cellular connectivity during disasters isolates field responders, localized damage assessment takes days to compile, and relief allocation suffers from severe information asymmetry [INFERENCE]. To solve this, we propose "ResilNet" (Aapda-Sathi): an offline-first, edge-intelligent, multi-phase disaster lifecycle management ecosystem [ASSUMPTION]. ResilNet integrates hyper-local AI risk zonation (Pre-Disaster), peer-to-peer Bluetooth Mesh/PouchDB offline emergency communications and AI distress message triaging (During-Disaster), and CV-assisted satellite/drone damage quantification with dynamic resource matching (Post-Disaster) [INFERENCE].

Metadata Table

Fundamental System Objective

To deliver an offline-resilient, end-to-end disaster management platform that empowers citizens, field responders, and district authorities to predict micro-level risks, communicate without cellular networks during active crises, and intelligently coordinate rapid relief distribution [INFERENCE].

2. Problem Deconstruction

The problem statement text states: "Student Innovation-Disaster management includes ideas related to risk mitigation, Planning and management before, after or during a disaster." [PS]

This explicit formulation yields six primary atomic requirements:

Atomic Requirement Deconstruction

1. Req-1: Innovation & Software Focus

   • Source Text: "Student Innovation ... Category: Software" [PS]
   • Interpretation: The solution must be a novel, student-driven software solution or digital system [INFERENCE].
   • Implementation Implication: Hardware dependencies must be minimized or standard off-the-shelf mobile devices/sensors must be leveraged to maintain software portability and hackathon feasibility [ASSUMPTION].
   • Confidence Tag: [PS]

2. Req-2: Multi-Phase Lifecycle Management (End-to-End Coverage)

   • Source Text: "...before, after or during a disaster." [PS]
   • Interpretation: The solution cannot focus solely on a single phase (e.g., just issuing SMS warnings); it must provide cohesive operational capabilities across Pre-Disaster, During-Disaster, and Post-Disaster phases [INFERENCE].
   • Implementation Implication: Software architecture must feature modular pipelines corresponding to the 3 phases: (A) Risk Zonation & Mitigation, (B) Emergency Dispatch & Offline SOS, and (C) Damage Assessment & Relief Mobilization [INFERENCE].
   • Confidence Tag: [PS]

3. Req-3: Risk Mitigation & Planning Before a Disaster (Pre-Disaster)

   • Source Text: "...ideas related to risk mitigation, Planning and management before..." [PS]
   • Interpretation: Proactive identification of hazard-prone areas, vulnerability mapping, resource pre-positioning, and evacuation routing before hazard impact [INFERENCE].
   • Implementation Implication: Integration with spatial hazard data (e.g., IMD weather feeds [RESEARCHED], CWC flood levels [RESEARCHED], ISRO BHUVAN layers [RESEARCHED]) to generate actionable micro-zonation maps and predictive risk scores [INFERENCE].
   • Confidence Tag: [PS]

4. Req-4: Real-Time Management & Response During a Disaster (During-Disaster)

   • Source Text: "...management ... during a disaster." [PS]
   • Interpretation: Continuous situational awareness, distress signaling, triage of incoming SOS alerts, and navigation for rescue personnel while infrastructure is failing [INFERENCE].
   • Implementation Implication: Native mobile app supporting peer-to-peer (P2P) mesh relay over Bluetooth Low Energy (BLE) / Wi-Fi Direct when cellular towers go down, with client-side NLP for automated SOS severity prioritization [INFERENCE].
   • Confidence Tag: [PS]

5. Req-5: Recovery & Management After a Disaster (Post-Disaster)

   • Source Text: "...management ... after a disaster." [PS]
   • Interpretation: Rapid assessment of structural damage, casualty estimation, camp management, and transparent distribution of relief supplies [INFERENCE].
   • Implementation Implication: Computer Vision (CV) model for rapid building damage classification from aerial imagery and an offline-syncable digital ledger for India Disaster Resource Network (IDRN)-compatible inventory tracking [INFERENCE].
   • Confidence Tag: [PS]

6. Req-6: Scalable & Adaptable Multi-Hazard Architecture

   • Source Text: "...Theme: Disaster Management" [PS]
   • Interpretation: The software framework should be adaptable to multiple hazard types prevalent in India (floods, urban waterlogging, cyclones, earthquakes, landslides) [KNOWN].
   • Implementation Implication: Modularity in data ingestion pipelines so that region-specific risk factors (e.g., elevation for floods, slope stability for landslides) can be weighted dynamically [INFERENCE].
   • Confidence Tag: [PS]

3. Stakeholders & User Needs

4. Requirements Traceability

5. Constraints & Environment Realities

1. Cellular Network Failure (Grid Collapse):

   • Reality: Cyclones, earthquakes, and flash floods routinely destroy base transceiver stations (BTS) and power grids, creating zero-connectivity zones for hours or days [KNOWN].
   • Design Response: The application must function offline-first. Local data must persist in IndexedDB / SQLite, and phone-to-phone peer-to-peer mesh networking (BLE/Wi-Fi Direct) must bridge communication to operational cells [INFERENCE].

2. Hardware Constraints of Mass End-Users:

   • Reality: Citizens and Aapda Mitra volunteers in rural India predominantly use low-cost Android smartphones (2GB–4GB RAM, entry-level SoC) [KNOWN].
   • Design Response: Mobile client software must be lightweight (<25MB download size), optimize background battery usage during mesh operations, and run edge ML models using quantized formats (TFLite / ONNX Runtime Mobile) [ASSUMPTION].

3. Linguistic Diversity & Digital Literacy:

   • Reality: Rural communities across Indian states operate in local regional languages and may have limited textual literacy [KNOWN].
   • Design Response: User Interfaces must rely heavily on standardized universal icons (pictograms), audio voice assistance, and support at least 12 major Indian languages (Hindi, Bengali, Tamil, Telugu, Marathi, Gujarati, etc.) in alignment with the NDMA SACHET protocol [RESEARCHED].

4. Power Infrastructure Loss:

   • Reality: Disaster-affected zones experience prolonged electrical grid outages [KNOWN].
   • Design Response: Software UI must support low-power OLED Dark Mode and energy-efficient background polling cycles to extend device battery endurance [ASSUMPTION].

6. Research Questions

1. How can emergency SOS messages be propagated across non-interconnected smartphone nodes without active cellular towers or internet infrastructure? [INFERENCE]
2. What open-source spatial datasets exist in India for building multi-hazard risk zonation models at the village/ward level? [RESEARCHED]
3. How does C-DOT's Common Alerting Protocol (CAP) format structure emergency alert payloads across agencies like IMD, CWC, and INCOIS? [RESEARCHED]
4. How can Computer Vision models rapidly classify building damage levels (minor, moderate, severe/collapsed) from heterogeneous drone or satellite imagery in resource-constrained environments? [INFERENCE]
5. What database synchronization strategy prevents merge conflicts when multiple relief workers update offline inventory stores across separate locations? [INFERENCE]

7. Data Requirements & Sources

Data Categorization Breakdown

• A. Data Explicitly Mentioned: None (Dataset link in SIH JSON is empty "") [PS].
• B. Data Required by Inference: Weather warnings, hydrological levels, topography/DEM, administrative ward boundaries, victim GPS coordinates, rescue inventory lists [INFERENCE].
• C. Data That Must Be Collected: Live victim SOS distress texts, field damage photos, camp capacity logs [INFERENCE].
• D. Data That Can Be Synthetically Generated: Simulated network mesh node positions, synthetic IDRN equipment tables, mock drone image feeds [ASSUMPTION].
• E. Data That Still Needs Validation: Real-time production API access permissions for live CWC/IMD C-DOT CAP alert streams [NEEDS VALIDATION].

8. Existing Solutions & Gap Analysis

9. Candidate Solution Approaches

Approach 1: Monolithic Web GIS Command Portal (Traditional)

• Mechanism: A centralized cloud web portal (Django + Leaflet) where government admins view weather overlays and manage manual field reports submitted via online forms [INFERENCE].
• Required Data: REST feeds from IMD/CWC, online web forms, static GeoJSON layers [INFERENCE].
• Architecture: Standard Client-Server 3-Tier Architecture on Cloud VMs [INFERENCE].
• Evaluative Matrix:
  • Problem Fit: Low (Fails during network collapse) [INFERENCE].
  • Accuracy Potential: Moderate (Dependent on manual reporting) [INFERENCE].
  • Complexity: Low [INFERENCE].
  • Explainability: High [INFERENCE].
  • Cost: Low cloud hosting costs [INFERENCE].
  • Scalability: Medium [INFERENCE].
  • Hackathon Feasibility: High (Easy to build in 36 hours) [INFERENCE].
  • Production Feasibility: Low (Inoperable in field conditions) [INFERENCE].

Approach 2: Cloud-Centric AI Deep Learning Platform

• Mechanism: Heavy cloud platform utilizing deep learning models for satellite image analysis, automated disaster social media scraping, and LLM-powered chatbot dispatch [INFERENCE].
• Required Data: High-res satellite feeds, continuous Twitter/X streams, cloud GPU cluster [INFERENCE].
• Architecture: Cloud Microservices with Kubernetes, PyTorch Model Servers, and OpenAI API integrations [INFERENCE].
• Evaluative Matrix:
  • Problem Fit: Moderate (Good analytics, but useless without field connectivity) [INFERENCE].
  • Accuracy Potential: High [INFERENCE].
  • Complexity: Very High [INFERENCE].
  • Explainability: Low (Black-box deep models / LLM hallucination risk) [INFERENCE].
  • Cost: Very High (Cloud GPU costs) [INFERENCE].
  • Scalability: High (Cloud native) [INFERENCE].
  • Hackathon Feasibility: Moderate (High API/cloud dependencies) [INFERENCE].
  • Production Feasibility: Low (High operating cost & single point of failure at cloud gateway) [INFERENCE].

Approach 3: ResilNet - Hybrid Edge-First Multi-Phase Disaster Ecosystem (Proposed)

• Mechanism: A multi-layered architecture featuring: (1) Pre-Disaster GIS Risk Micro-Zonation using open spatial inputs; (2) During-Disaster Offline BLE Mesh P2P SOS Propagation with edge-quantized NLP message triaging on mobile devices; (3) Post-Disaster Drone/Satellite Computer Vision Damage Assessment and CouchDB/PouchDB distributed offline inventory synchronization [INFERENCE].
• Required Data: Open-Meteo/IMD RSS, SRTM DEM, OpenStreetMap, local BLE/GPS logs, aerial images [RESEARCHED].
• Architecture: Edge-First Hybrid P2P Mobile Native App (React Native + SQLite/PouchDB) + Central Node.js Cloud Control Plane + Web GIS Dashboard (React + Mapbox/Maplibre) [INFERENCE].
• Evaluative Matrix:
  • Problem Fit: Exceptional (Addresses all 3 lifecycle phases and handles network failure) [INFERENCE].
  • Accuracy Potential: High (Multi-source ground + satellite validation) [INFERENCE].
  • Complexity: Moderate-High [INFERENCE].
  • Explainability: High (Rule-guided ML + transparent risk scoring) [INFERENCE].
  • Cost: Low-Moderate (Edge compute offloads cloud costs) [INFERENCE].
  • Scalability: Very High (Decentralized peer mesh) [INFERENCE].
  • Hackathon Feasibility: High (Modular architecture allows prototype demonstration) [ASSUMPTION].
  • Production Feasibility: Exceptional (Aligned with Indian field conditions) [INFERENCE].

10. Recommended Approach & Why

Selected Solution

Approach 3: ResilNet - Hybrid Edge-First Multi-Phase Disaster Lifecycle Ecosystem [ASSUMPTION].

Why Alternatives Were Rejected

1. Rejection of Approach 1 (Monolithic Cloud Portal): Relies 100% on continuous cloud connectivity. In real Indian disaster events (e.g., severe cyclones or floods), cellular towers lose power within 2 hours [KNOWN]. A purely online portal becomes completely useless to field rescue workers and victims exactly when needed most [INFERENCE].
2. Rejection of Approach 2 (Cloud-Centric Deep Learning / LLM System): Unviable due to high operational latency, expensive GPU infrastructure requirements, LLM hallucination risks in life-critical emergency contexts, and total dependence on active internet backhauls [INFERENCE].

Architectural Superiority of ResilNet

ResilNet solves the central paradox of disaster software: How to provide intelligent decision-making when central systems are cut off. By putting light ML models (ONNX Runtime) and P2P communication protocols (Bluetooth Low Energy / Wi-Fi Direct mesh) onto citizen and responder mobile devices, ResilNet forms an ad-hoc local emergency network [INFERENCE]. When any single phone in the mesh touches an edge node with internet (e.g., a satellite-linked command vehicle or restored tower), it automatically uploads the entire local crisis registry to the central DDMA Command Portal [INFERENCE].

11. Technical Architecture

===================================================================================================
                                      RESILNET SYSTEM ARCHITECTURE
===================================================================================================

[ PHASE 1: PRE-DISASTER ]         [ PHASE 2: DURING DISASTER ]        [ PHASE 3: POST-DISASTER ]
 +-----------------------+         +--------------------------+        +------------------------+
 | IMD / Open-Meteo Feeds|         | Citizen Mobile SOS App   |        | Drone / Aerial Photos  |
 | CWC Hydrological Data |         | (BLE / Wi-Fi Direct Mesh)|        | Camp Inventory Logs    |
 | ISRO SRTM Elevation   |         +------------+-------------+        +-----------+------------+
 +-----------+-----------+                      |                              |
             |                                  | (Offline P2P Hop)            |
             v                                  v                              v
+-------------------------------------------------------------------------------------------------+
|                                 EDGE LAYER (FIELD MOBILE APPS)                                  |
|  - Local PouchDB / SQLite Store (CRDT Sync Engine)                                              |
|  - Quantized Edge NLP Engine (DistilBERT ONNX for Local Multi-Lingual SOS Triaging)            |
|  - Offline Vector Map Tile Server (MBTiles / Maplibre Native)                                  |
+-------------------------------------------------------------------------------------------------+
                                                |
                                                | (Sync when Gateway / Satellite Uplink Available)
                                                v
+-------------------------------------------------------------------------------------------------+
|                               CENTRAL CONTROL LAYER (CLOUD / COMMAND)                           |
|  +---------------------------+   +----------------------------+   +--------------------------+  |
|  | Ingestion & CAP Normalizer|   | AI Analytics & CV Server   |   | Data Processing & Sync   |  |
|  | - C-DOT CAP XML Parser    |   | - YOLOv8 Structural Damage |   | - Node.js Sync Service   |  |
|  | - Geospatial Ingestion    |   | - XGBoost Risk Zonation    |   | - PostgreSQL / PostGIS   |  |
|  +---------------------------+   +----------------------------+   +--------------------------+  |
+-------------------------------------------------------------------------------------------------+
                                                |
                                                v
+-------------------------------------------------------------------------------------------------+
|                              PRESENTATION LAYER (DDMA COMMAND PORTAL)                            |
|  - Web GIS Situational Map (Maplibre GL JS + Deck.gl Hazard Heatmaps)                           |
|  - Real-Time Priority SOS Dispatch Queue & Triage Interface                                     |
|  - IDRN Resource Allocation & Dynamic Logistics Matching Dashboard                              |
+-------------------------------------------------------------------------------------------------+

Detailed Data-Flow Narrative

1. Pre-Disaster Flow (Mitigation & Zonation):

   • Central backend periodically pulls weather alerts (IMD RSS/CAP) [RESEARCHED] and river levels (CWC) [RESEARCHED].
   • PostGIS spatial engine overlays hazard data onto elevation (SRTM) and ward boundary maps to compute a 1–10 Risk Zonation Index [INFERENCE].
   • Pre-computed risk polygons and nearby emergency shelter coordinates are pushed to citizen mobile devices as lightweight MBTiles vector basemaps during normal network operations [INFERENCE].

2. During-Disaster Flow (Offline SOS & Mesh Dispatch):

   • User triggers an emergency distress signal (SOS) without cellular connection [INFERENCE].
   • On-device edge NLP model (quantized DistilBERT ONNX) categorizes the alert (e.g., "Medical Emergency", "Trapped in Water", "Food Need") and assigns a priority score (P1–P4) [INFERENCE].
   • Mobile app broadcasts payload via BLE & Wi-Fi Direct advertising packets. Nearby phones running the app receive, store, and re-broadcast the packet using a Store-and-Forward Mesh Algorithm [INFERENCE].
   • As soon as any responder or citizen in the mesh enters range of an active network gateway (e.g., NDRF Satellite Vehicle or working tower), all queued SOS packets are synced to the PostGIS Cloud Database via WebSockets [INFERENCE].
   • Command Dashboard updates instantly, displaying color-coded SOS clusters prioritized by severity and victim vulnerability [INFERENCE].

3. Post-Disaster Flow (Damage Assessment & Relief):

   • Reconnaissance drone imagery is uploaded to the Command Dashboard.
   • YOLOv8-Seg Computer Vision model processes the images, outlining damaged structures and estimating destruction percentages [INFERENCE].
   • Relief camp managers enter stock requirements into their mobile app in offline mode. PouchDB syncs inventory state with central PostgreSQL, matching camp demands against IDRN-cataloged regional supplies [INFERENCE].

12. Technology Stack

13. AI/ML Justification

AI Component 1: Multi-Lingual SOS Distress Triaging (Edge NLP)

1. Exact Problem Solved: Automatically categorizing raw victim distress messages/transcripts into standardized emergency types (Medical, Trapped, Structural Collapse, Food/Water) and prioritizing urgency [INFERENCE].
2. Input: Raw text string or speech audio transcript in English, Hindi, or regional languages [INFERENCE].
3. Output: Category Label (e.g., CRITICAL_MEDICAL) + Priority Score (1–5) + Extracted Medical Entities [INFERENCE].
4. Why Rule System Fails: Keywords like "water" could mean "I need drinking water" (Low Urgency) or "Water level is rising to roof, cannot breathe" (Extreme Critical Urgency). NLP understands semantic context [INFERENCE].
5. Data Required: Multi-lingual disaster intent dataset (annotated synthetic SMS/tweet dataset based on crisis taxonomies) [ASSUMPTION].
6. Evaluation Metric: Macro F1-Score (Target >0.88) and Critical Class Recall (Target >0.95 to avoid missing life-threatening calls) [INFERENCE].
7. Failure Mitigation: If NLP confidence score is <0.60, system defaults packet to "Priority 2 - Unclassified Manual Review" [INFERENCE].
8. Training/Fine-Tuning: Fine-tuning a lightweight mBERT or DistilBERT model, exported to quantized 8-bit ONNX format (~25MB) [ASSUMPTION].
9. Fine-Tuning Required: Yes.
10. RAG Required: No.
11. Computer Vision Required: No.
12. Speech Processing Required: Optional local Whisper-Tiny for voice-to-text conversion [ASSUMPTION].
13. Forecasting Required: No.
14. Human Oversight: High. Incident Command dispatchers review and re-prioritize triaged queues before deploying teams [INFERENCE].

AI Component 2: Satellite/Drone Aerial Damage Assessment (Computer Vision)

1. Exact Problem Solved: Detecting and quantifying structural building destruction across wide post-disaster areas [INFERENCE].
2. Input: GeoTIFF or JPEG aerial/drone ortho-mosaic image tiles [INFERENCE].
3. Output: Polygons of detected structures categorized into 4 damage tiers: No Damage, Minor Damage, Major Damage, Destroyed [INFERENCE].
4. Why Rule System Fails: Pixel color thresholds cannot distinguish between roof tiles, shadows, debris, and collapsed concrete [INFERENCE].
5. Data Required: xBD Disaster Satellite Dataset / Disaster City Drone Dataset [RESEARCHED].
6. Evaluation Metric: mean Average Precision at IoU 0.5 ([email protected] > 0.80) [INFERENCE].
7. Failure Mitigation: Model outputs confidence heatmaps; low-confidence zones are flagged for manual drone re-flight or ground team verification [INFERENCE].
8. Training/Fine-Tuning: YOLOv8-Seg model fine-tuned on pre/post disaster building pairs [ASSUMPTION].
9. Fine-Tuning Required: Yes.
10. RAG Required: No.
11. Computer Vision Required: Yes.
12. Speech Processing Required: No.
13. Forecasting Required: No.
14. Human Oversight: Required before finalizing financial compensation or urban reconstruction estimates [INFERENCE].

Where AI Should NOT Be Used

• Rescue Team Routing: Pathfinding through hazardous zones must use deterministic GIS network algorithms (Dijkstra / A* on updated PostGIS road network with known flood barriers) rather than non-deterministic AI models to guarantee safe traversal [INFERENCE].
• Official Warning Authorization: Generating and issuing public evacuation alerts must remain strictly under human authority (DDMA / Collector sign-off) to prevent false panic broadcasts [INFERENCE].

14. Data Architecture & Offline/Low-Network Design

===================================================================================================
                                  OFFLINE-FIRST SYNCHRONIZATION FLOW
===================================================================================================

[ MOBILE CLIENT A ] --- (BLE Mesh Packet) ---> [ MOBILE CLIENT B ] --- (Cellular/Sat Uplink) ---> [ CENTRAL DB ]
(Local SQLite /                                (Store & Forward                                  (PostgreSQL /
 IndexedDB)                                     Buffer)                                           PostGIS)

Database Schema (Core Tables - PostgreSQL / PostGIS)

-- Emergency SOS Distress Signals Table
CREATE TABLE emergency_sos (
    sos_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    device_fingerprint VARCHAR(64) NOT NULL,
    victim_name VARCHAR(100),
    contact_phone VARCHAR(15),
    category VARCHAR(30) CHECK (category IN ('MEDICAL', 'TRAPPED', 'FOOD_WATER', 'EVACUATION', 'UNKNOWN')),
    priority_level INT CHECK (priority_level BETWEEN 1 AND 5),
    raw_message TEXT NOT NULL,
    location GEOMETRY(Point, 4326) NOT NULL,
    mesh_hop_count INT DEFAULT 0,
    sync_status VARCHAR(20) DEFAULT 'PENDING' CHECK (sync_status IN ('PENDING', 'RELAYED', 'SYNCED_CLOUD')),
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

-- Resource Inventory Table (IDRN Aligned)
CREATE TABLE resource_inventory (
    resource_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    warehouse_name VARCHAR(100) NOT NULL,
    item_category VARCHAR(50) NOT NULL, -- e.g., 'Inflatable Boat', 'Life Jacket', 'De-watering Pump'
    quantity_available INT NOT NULL CHECK (quantity_available >= 0),
    district_code VARCHAR(10) NOT NULL,
    location GEOMETRY(Point, 4326) NOT NULL,
    last_updated_by VARCHAR(50),
    sync_version BIGINT NOT NULL DEFAULT 1
);

-- Spatial Indices
CREATE INDEX idx_sos_location ON emergency_sos USING GIST(location);
CREATE INDEX idx_sos_priority ON emergency_sos(priority_level, sync_status);
CREATE INDEX idx_resource_location ON resource_inventory USING GIST(location);

Offline & Sync Architecture Strategy

1. Local Storage Engine: The mobile client utilizes RxDB backed by SQLite on mobile native (via React Native Async Storage / SQLite plugin) and IndexedDB on web browsers [ASSUMPTION].
2. Synchronization Protocol: Uses CouchDB Conflict-Free Replicated Data Types (CRDT) delta synchronization [INFERENCE]. Changes are tracked via incremental sync_version sequence numbers.
3. Conflict Resolution Policy:
   • SOS Messages: Append-only design pattern. SOS records from different devices are immutable and uniquely identified by UUID; conflicts cannot occur [INFERENCE].
   • Inventory Adjustments: Last-Write-Wins (LWW) based on verified authority timestamps, backed by an audit transactional ledger [INFERENCE].
4. Bandwidth Minimization:
   • Vector maps pre-packaged as .mbtiles files per district (~15MB per district) [INFERENCE].
   • SOS payloads serialized using Protocol Buffers (Protobuf) or ultra-compact JSON (<200 bytes per packet) to fit inside BLE advertisement payload windows [INFERENCE].

15. Security, Privacy & Governance

1. Personal Data & Location Privacy:

   • Distress calls require transmitting GPS coordinates [INFERENCE]. Location data is encrypted on-device using AES-256 before BLE broadcast [INFERENCE].
   • Public command views display aggregated spatial density heatmaps rather than raw personal identity markers to prevent tracking or misuse [INFERENCE].

2. Authentication & Access Control (RBAC):

   • Citizens: Anonymous session generation tied to local hardware UUID for instant SOS capability without password friction [INFERENCE].
   • Field Responders & Admins: OAuth2.0 / JWT-based login integrated with government e-Governance portals (e.g., MeriPahchan / Mobile OTP) with strict Role-Based Access Control (Roles: CITIZEN, VOLUNTEER, RESPONDER_NDRF, DISTRICT_ADMIN) [ASSUMPTION].

3. Data Integrity & Audit Logging:

   • Every inventory adjustment, SOS resolution status change, and official advisory issuance is logged in an append-only audit trail capturing User ID, Timestamp, and Digital Signature [INFERENCE].

4. Regulatory & Governance Compliance:

   • Designed in alignment with India's Digital Personal Data Protection (DPDP) Act 2023 [KNOWN]. Emergency data processing is justified under the "Certain Legitimate Uses" provision (medical emergencies and disaster response) [KNOWN].
   • System outputs are explicitly framed as Decision Support Tools; final deployment mandates official authorization under the Disaster Management Act 2005 [RESEARCHED].

16. MVP Scope (Hackathon Build)

+-------------------------------------------------------------------------------------------------+
|                                     HACKATHON MVP SCOPE                                         |
+-------------------------------------------------------------------------------------------------+
| [MUST BUILD]                                                                                    |
|  1. Web Command Dashboard with interactive Maplibre GIS showing risk zones & SOS markers.      |
|  2. Mobile App (Android) with one-touch SOS distress button & offline BLE P2P relay simulation.|
|  3. On-Device quantized ONNX NLP model classifying SOS texts into 4 priority buckets.           |
|  4. Synthetic IDRN resource matching engine (Auto-assigning nearest boats/pumps to SOS calls).  |
|                                                                                                 |
| [SHOULD BUILD]                                                                                  |
|  1. Pre-trained YOLOv8-Seg image uploader for rapid structural damage tagging from drone photos.|
|  2. Multi-lingual UI toggle (English, Hindi, Tamil/Bengali).                                    |
|                                                                                                 |
| [NICE TO HAVE]                                                                                  |
|  1. Text-to-Speech audio alert playback for low-literacy users.                                 |
|  2. Simulated satellite uplink status indicator.                                                |
+-------------------------------------------------------------------------------------------------+

Explicitly Out of Scope for Hackathon (Described in Architecture Only)

• Direct real-time hardware integration with official C-DOT Cell Broadcast servers (requires telecom operator root access) [RESEARCHED].
• Live drone hardware flight control software [ASSUMPTION].
• Integration with encrypted MHA satellite communications networks [RESEARCHED].

17. Live Demo Simulation Plan

To deliver a compelling, flawless live demonstration during SIH judging without relying on live government APIs or actual physical disasters:

===================================================================================================
                                      LIVE DEMO SIMULATION FLOW
===================================================================================================

[ STEP 1: PRE-DISASTER ]         [ STEP 2: CRISIS & CUT-OFF ]       [ STEP 3: MESH RELAY & SYNC ]
 Display Maplibre GIS dashboard   Turn off Wi-Fi/Data on Mobile A.   Mobile A transmits SOS over BLE
 showing live hazard zonation     Trigger "Flash Flood" event.       to Mobile B (Responder phone).
 for a target district.           Tower status changes to RED.       Mobile B enters online zone &
                                                                     auto-syncs SOS to Control Dashboard.

1. Simulating Government Alert & Weather Feeds:

   • Pre-program a mock C-DOT CAP XML feed generator that emits realistic alert payloads (e.g., "Flash Flood Warning for District Uttarkashi, Severity: Extreme") [ASSUMPTION].

2. Demonstrating Zero-Connectivity Mesh Relay:

   • Place Phone A (Victim) in complete Airplane Mode (Cellular OFF, Wi-Fi OFF, Bluetooth ON) [ASSUMPTION].
   • Press "Emergency SOS" on Phone A. Show that the quantized ONNX NLP model locally classifies the message as CRITICAL_TRAPPED and generates an encrypted BLE payload [ASSUMPTION].
   • Bring Phone B (Responder / Mesh Node) within 10 meters. Phone B detects the BLE beacon, stores it locally, and displays "1 Relayed SOS In Queue" [ASSUMPTION].
   • Re-enable Wi-Fi on Phone B. Watch the Web Command Dashboard update instantly in real-time via WebSockets, plotting the victim's exact pin and severity badge [ASSUMPTION].

3. Demonstrating AI Damage Assessment:

   • Upload sample post-cyclone drone ortho-photos (from xBD dataset) [RESEARCHED].
   • Show YOLOv8-Seg inferencing live on screen, drawing bounding polygons around collapsed roofs and outputting a damage summary report [ASSUMPTION].

18. Implementation Roadmap

Target Deadline: 30 September 2026 [PS] (Available timeline: ~3-4 weeks from current date [PS]).

===================================================================================================
                                     IMPLEMENTATION TIMELINE
===================================================================================================

[ WEEK 1: FOUNDATION ] --------> [ WEEK 2: EDGE & P2P ] -------> [ WEEK 3: AI & DASHBOARD ] -----> [ WEEK 4: INTEGRATION & DEMO ]
- DB Schema & PostGIS Setup      - BLE Mesh Protocol Impl.       - Quantized NLP Model Impl.       - End-to-End Mesh Testing
- Base Web GIS Architecture      - PouchDB Local Sync Engine     - YOLOv8 Damage Pipeline          - Simulated Demo Dry Runs
- Synthetic Data Generation      - Mobile App UI Shell           - IDRN Matching Engine            - Final Dossier & Deck

Detailed Sprint Schedule

• Phase 1: Architecture & Data Foundations (Days 1–5)

  • Set up PostgreSQL/PostGIS database instance [ASSUMPTION].
  • Scrape and clean open spatial data (OpenStreetMap district boundary, SRTM DEM) [ASSUMPTION].
  • Create synthetic datasets for IDRN resource inventory and C-DOT CAP alert feeds [ASSUMPTION].

• Phase 2: Mobile Offline Core & Mesh Relay (Days 6–12)

  • Implement React Native mobile app with RxDB/SQLite local persistence [ASSUMPTION].
  • Develop native BLE advertising & discovery background module for phone-to-phone store-and-forward [ASSUMPTION].
  • Build UI screens for Citizen SOS trigger and Responder field survey [ASSUMPTION].

• Phase 3: AI Engine & Command Dashboard (Days 13–19)

  • Quantize DistilBERT NLP multi-lingual model to ONNX format and integrate into mobile runtime [ASSUMPTION].
  • Train/fine-tune YOLOv8-Seg model on sample aerial building damage dataset [ASSUMPTION].
  • Develop React.js Command Dashboard with Maplibre vector hazard visualization and live WebSocket queue [ASSUMPTION].

• Phase 4: Integration, Testing & Demo Polish (Days 20–25)

  • Perform stress testing on BLE mesh propagation latency across 4 physical devices [ASSUMPTION].
  • Run offline sync stress tests with simulated network drops [ASSUMPTION].
  • Rehearse live 5-minute SIH demo story [ASSUMPTION].

19. Testing & Validation Plan

20. Risk Register

21. Cost & Scalability

Hackathon Phase Costs

• Infrastructure: ₹0 (All components run on local developer laptops, free tier Vercel/Render cloud hosting, and free open-source software libraries) [ASSUMPTION].
• Hardware: Existing student Android mobile phones [ASSUMPTION].
• APIs: Free-tier Open-Meteo, OpenStreetMap tile servers [RESEARCHED].

Production Deployment Costs (District Level - Estimated)

• Cloud Control Plane (Managed Kubernetes + PostGIS): Estimated ₹15,000 – ₹30,000 / month on AWS/Azure or National Informatics Centre (NIC) MeghRaj Cloud [INFERENCE].
• Satellite Uplink Vehicles (Edge Gateways): Existing NDRF/SDMA communications equipment (CapEx covered under government disaster management budgets) [RESEARCHED].
• Mobile Client App: Zero marginal cost per citizen user (distributed freely via Google Play Store / APK) [INFERENCE].

Scalability Strategy

• Decentralized P2P mesh offloads compute and network traffic away from central servers during peak crisis hours [INFERENCE].
• Static map tiles served via CDN / localized device caching reduce GIS bandwidth consumption by 90% [INFERENCE].

22. Differentiation

23. Future Scope

1. LoRa Mesh Hardware Dongle Integration: Designing low-cost USB-C LoRa radio dongles (~₹500 per unit) for field responders to extend offline communication range up to 5–10 kilometers [INFERENCE].
2. Automated Drone Flight Path Generation: Interfacing the CV damage assessment engine directly with open drone APIs (e.g., MAVLink / PX4) to auto-pilot reconnaissance drones over high-density SOS clusters [INFERENCE].
3. INCOIS Tsunami & Coastal Surge Real-Time Integration: Expanding telemetry pipelines to ingest live buoy sensors from the Indian National Centre for Ocean Information Services (INCOIS) for coastal alert automation [RESEARCHED].

24. Assumptions & Open Items Log

Consolidated Assumptions Log

• [ASSUMPTION-1]: ResilNet name and specific UI layouts selected to give the student team a cohesive brand and clear hackathon story.
• [ASSUMPTION-2]: React Native and Node.js selected as primary stacks based on typical student developer familiarity and rapid prototyping speed.
• [ASSUMPTION-3]: Standard 3-4 week hackathon build window assumed aligned with the 30 September 2026 deadline [PS].
• [ASSUMPTION-4]: Physical testing of BLE mesh will be performed using at least 3-4 physical Android smartphones.

Consolidated Open Items & Validation Log

• [NEEDS VALIDATION-1]: Verification of live C-DOT CAP RSS/XML endpoint permissions for direct integration during production deployment [NEEDS VALIDATION].
• [NEEDS VALIDATION-2]: Maximum achievable BLE multi-hop payload delivery rate in dense urban concrete building environments without line-of-sight [NEEDS VALIDATION].
• [NEEDS VALIDATION-3]: Exact district-level authorization protocols required under the DM Act 2005 for syncing third-party app data into DDMA Emergency Operations Control rooms [NEEDS VALIDATION].

Final Decision & Execution Summary

Final Recommendation

Proceed with building ResilNet (Approach 3). It is technically superior, directly addresses all explicit requirements of SIH26206, and provides a compelling offline demonstration that will stand out during judging [INFERENCE].

Recommended Stack

• Frontend: React.js, Maplibre GL JS, Tailwind CSS [ASSUMPTION].
• Mobile: React Native (Expo), RxDB / SQLite, Native BLE Modules [ASSUMPTION].
• Backend: Node.js (TypeScript), Express, WebSockets [ASSUMPTION].
• Database: PostgreSQL 16 + PostGIS 3.4 [KNOWN].
• AI/ML: PyTorch (Training), ONNX Runtime Mobile (Quantized Edge NLP), YOLOv8-Seg (CV Damage) [RESEARCHED].

Key Project Parameters

• Biggest Dependency: Native Android Bluetooth Low Energy (BLE) peripheral/central dual-mode driver stability across diverse phone models [INFERENCE].
• Biggest Risk: Battery drain and OS-level background process suppression on low-end Android smartphones during active mesh scanning [INFERENCE].
• Biggest Technical Challenge: Implementing reliable store-and-forward multi-hop packet deduplication and CRDT state synchronization across unstable offline nodes [INFERENCE].

First 5 Actions for Team

1. Set up the Git repository and initialize the React Native mobile shell and Node.js/PostGIS backend [ASSUMPTION].
2. Create a working prototype of BLE advertising and discovery between two Android phones in Airplane Mode [ASSUMPTION].
3. Download and prepare the SRTM 30m elevation data and district OpenStreetMap GeoJSON files for the target demo area [RESEARCHED].
4. Quantize a fine-tuned DistilBERT multi-lingual classification model into ONNX format and test local mobile execution latency [ASSUMPTION].
5. Build the Web GIS dashboard shell using Maplibre GL JS and test rendering mock SOS WebSocket pins [ASSUMPTION].

Validation Before Coding

• Verify that all student developer mobile phones support BLE Peripheral Mode (required for advertising without active connection) [INFERENCE].
• Confirm local Node.js environment compatibility with PostGIS spatial extension [ASSUMPTION].

Quantitative Assessment

• Buildability Score: 88/100 (Highly feasible for a 4–6 student team within the deadline using standard web/mobile frameworks and quantized ML runtime) [INFERENCE].
• Confidence Level: High (Grounded in proven technical standards like Common Alerting Protocol and validated open-source software libraries) [INFERENCE].

Research Sources

1. Title: National Disaster Alert Portal: SACHET - NDMA
   URL: https://sachet.ndma.gov.in/ [RESEARCHED]
   Source Type: Official Government Portal (NDMA / C-DOT)
   Supported Claim: Documents India's official CAP-based disaster alert system, supporting 12 regional languages and geo-targeted alerts.
   Reliability: High (Official Government Source).

2. Title: Integrated Alert System (SACHET) Press Release - PIB Delhi
   URL: https://www.pib.gov.in/PressReleasePage.aspx?PRID=2256706&reg=3&lang=1 [RESEARCHED]
   Source Type: Official Press Information Bureau Release
   Supported Claim: Confirms C-DOT development of CAP-based disaster alerting and deployment of Cell Broadcast technology in India.
   Reliability: High (Official Government Source).

3. Title: National Database for Emergency Management (NDEM) - ISRO
   URL: https://www.isro.gov.in/DBEM.html [RESEARCHED]
   Source Type: Official Space Agency Documentation (ISRO / NRSC)
   Supported Claim: Confirms availability of multi-scale geospatial repository and decision support tools for emergency management.
   Reliability: High (Official Government Source).

4. Title: Central Water Commission Flood Forecasting Portal
   URL: https://www.cwc.gov.in/en/flood-forecast [RESEARCHED]
   Source Type: Official Government Department Portal (Ministry of Jal Shakti)
   Supported Claim: Validates CWC's network of 325+ flood forecasting gauge stations and FloodWatch advisory services.
   Reliability: High (Official Government Source).

5. Title: India Disaster Resource Network (IDRN) - NIDM
   URL: https://idrn.nidm.gov.in/ [RESEARCHED]
   Source Type: Official Government Resource Inventory Portal (NIDM / MHA)
   Supported Claim: Documents the national web-based inventory platform cataloging equipment, human resources, and critical emergency supplies across districts.
   Reliability: High (Official Government Source).