"When data fails, SANKAT speaks. Every phone a lifeline. Every tower a dispatch point."
The original concept — dial *144#, select "Flood" or "Medical," dispatch gets an SMS — is directionally correct and emotionally compelling. But as a hackathon prototype it has three dangerous gaps that judges will probe immediately.
Selecting "1 for Flood, 2 for Medical" and then getting an SMS tells a judge this took 90 minutes to build. Two choices is not a system — it's a proof of concept. What happens when 50 people in the same flood zone all press 1 simultaneously? What's the queue logic? How does dispatch know which village? The current design has no answers.
The MVP sends an SMS to dispatch but gives zero location data beyond "someone, somewhere, pressed Flood." A dispatcher receiving "HELP FLOOD" with no coordinate data cannot deploy anyone. The prototype literally cannot perform its core function. This is not an edge case — it's the entire purpose of the tool.
Track 1 Problem Statement 01 explicitly lists: disaster response, DV victim follow-up, missing persons, low-connectivity areas, and case status for victims. The current USSD-Mesh addresses only disaster alerts. Judges know the problem statement. A solution addressing 1/5 of it is a partial answer.
The "fatal weakness" listed in the original analysis (telecom provider buy-in) is actually NOT a problem for a hackathon MVP. Africa's Talking provides a fully functional USSD simulator that works like a real telecom network for development. NTA has already standardized USSD shortcodes across NTC and Ncell — the regulatory pathway exists. This weakness is misclassified as fatal; it's an implementation milestone, not a blocker.
The judges' problem statement asks: "How can technology help someone in an emergency reach the right help, fast — even in remote or low-connectivity areas?" A USSD-based system is the most honest, technically grounded answer possible. It works on the oldest Nokia. No data. No app. No charging cable in a flood. This is the right problem and the right channel. Don't abandon it — build it properly.
No other Track 1 idea has a more viscerally powerful demo moment. You can show a feature phone in airplane mode dialing a shortcode and watch a dispatch map update in real-time. That 10-second moment communicates the entire value proposition to every police officer in the room faster than any slide deck.
Before designing the system, understand the exact scenarios where it must operate. These are drawn from the Track 1 statistics the judges published.
Roughly 60% of Nepal's population outside Kathmandu valley still uses feature phones (Nokia 106, Symphony, itel). No WhatsApp. No app stores. No data plans. A disaster app that requires Android 10+ is useless in Karnali, Sudurpashchim, and most of Lumbini's rural wards. USSD works on every phone made since 1997.
30,000+ rescue personnel coordinated via individual phone calls across 21 districts. When cell towers go down in floods, voice calls fail first. USSD and SMS use signaling channels — they often work minutes or hours longer than voice calls after a tower is overloaded or partially functioning.
23,621 missing persons, 17,000+ DV cases — and after filing, victims have zero structured mechanism to signal safety or distress. Calling 100 is not safe (abuser may hear). WhatsApp leaves digital traces. A periodic USSD disguised as a balance check is the safest possible check-in for victims under surveillance.
Dispatch has no mechanism to push emergency alerts TO citizens in a specific area. When a gas pipeline ruptures or a dam overflows, police must broadcast evacuation orders. Currently: individual phone calls + Facebook posts. USSD Cell Broadcast can push text to every phone in a tower's coverage zone in 30 seconds.
Six interconnected pipelines transform the original 2-option SMS relay into Nepal's first structured USSD emergency communication platform, addressin every gap in Track 1 Problem #01.
Solves the "2-option dead-end" flaw
Three input modes all funnel into the same backend pipeline. USSD (*999#) — full structured menu, works on any 2G phone, preferred path. SMS keyword fallback — user texts "HELP FLOOD" / "HELP MEDICAL" / "HELP TRAP" to a short number when USSD is unavailable; regex parser extracts incident type, phone number provides cell ID. IVR voice fallback — for illiterate users, call the shortcode, an automated Nepali voice menu uses keypress detection (1=Flood, 2=Medical, etc.); works even when data and USSD are degraded but voice still works.
All three inputs write to the same incidents table in PostgreSQL. No matter how a citizen contacts the system, the backend treats the data identically. This is critical for real disaster scenarios where network conditions vary second to second.
The technical differentiator — location without GPS
This is the single most technically impressive piece — and it's free and pre-built. Africa's Talking USSD API passes the caller's Cell ID + Location Area Code (LAC) in every webhook request header. By pre-loading a filtered SQLite extract of Nepal's towers from OpenCelliD (CC BY-SA 4.0 license, free download, approximately 15,000 NTC/Ncell towers in Nepal, compressed to ~2MB), the backend can map any incoming alert to an approximate GPS coordinate within 500m–3km. No GPS chip required. No phone location permissions. Just the tower the caller is connected to.
The dispatch map renders a circle whose radius equals the tower's coverage area — a visual representation of exactly how precise the location estimate is. In Butwal (urban), this is a 400m circle. In Dang (rural), it may be a 2.5km circle. Either way it is infinitely more useful than "someone in Nepal pressed a button."
Separates analysis from a simple notification system
A deterministic scoring algorithm runs every time a new incident is created or updated, sorting the dispatch queue automatically. Base severity scores: Trapped = 10, Medical Cardiac/Unconscious = 10, Active Violence = 9, Fire = 8, Medical Injury = 7, Missing Child = 8, Flood = 7. Modifiers applied on top:
Geographic cluster multiplier: If 3+ alerts arrive from the same tower zone within 30 minutes, the system detects a possible mass casualty event and raises all those incidents by +3, triggering a red "MASS CASUALTY ALERT" banner on the dashboard — automated detection that would take a human dispatcher minutes to notice.
Time decay: Unacknowledged alerts gain +0.1 priority points per minute. An ignored critical alert automatically escalates to the top of the queue, preventing dispatcher attention blindness during busy periods. DV welfare override: A registered DV victim's missed check-in automatically generates an incident with base score 9 after 48 hours of silence.
The operational nerve center
A React frontend with WebSocket real-time updates. Left panel: the priority triage queue, color-coded by incident type (red = trapped/violence, orange = medical, blue = missing, grey = hazard report), with response time counter ticking up. Center: a Leaflet map showing cell tower coverage circles for each incident, color-coded by type, with unit location markers (GPS from their mobile devices). Right panel: available units (Police, Ambulance, APF, Fire) with current assignment status.
Dispatcher clicks an incident → clicks a unit → "Assign" button. Unit receives an SMS automatically: "SANKAT DISPATCH: Medical emergency at Tilottama-4 area. Tower coverage: 27.68°N, 83.52°E. Case ID: SANK-2042. Reply ACK-2042 to confirm." System logs acknowledgement time and starts a response timer. All of this — from citizen USSD dial to dispatcher click — can happen in under 60 seconds.
The emotionally resonant Track 1 differentiator
This single pipeline directly answers the Track 1 problem statement quote: "Many cannot safely make a call during a crisis" and "DV survivors have no follow-up mechanism after filing." Officers register a DV victim's phone number in the system at the time of case filing. From that point, the system behaves differently for that number.
Weekly check-in: The system triggers a USSD push that appears on the victim's phone as: "NTC Service: Your balance is Rs. 47.20. Data pack expires 2082-04-17. Press 1 to continue or 2 for more options." This is indistinguishable from a routine NTC balance notification to anyone watching the phone screen. Internally: Press 1 = I am safe (dashboard turns green), Press 2 = I need help (silent alert, no sound, no notification on victim's phone, but the assigned officer's dashboard goes red). No response in 48h = automated welfare check dispatch. The abuser sees nothing. The phone makes no sound. The screen shows a normal telecom prompt.
Nepal's own Wireless Emergency Alert system
Most emergency systems are one-directional: citizen → police. SANKAT flips this. A senior officer draws a radius on the dispatch map (e.g., covering 3 cell tower zones around a dam breach). Types an evacuation message in Nepali: "सावधान: बाढीको खतरा। तत्काल उच्च स्थानमा जानुहोस्।" Clicks "Broadcast Zone." The backend queries all registered SANKAT users within that geographic area and sends an SMS blast — and where possible, an inbound USSD push — to every phone in the zone.
For the hackathon MVP, this uses Africa's Talking bulk SMS with phone numbers filtered by their last known tower zone from the incidents table. No telecom integration required. For production, this becomes a proper Cell Broadcast message (CB) sent via NTA's infrastructure — the technical pathway already exists (HACOM-type systems are deployed globally). The hackathon demo uses SMS broadcast; the judges will immediately understand how this scales.
The React dashboard is the system's brain. Every panel is operationally justified — no decorative charts. Each panel below answers a specific question a dispatcher asks every single shift.
Leaflet map centered on Lumbini Province. Cell tower coverage circles colored by incident type (red = trapped/violence, orange = medical, blue = missing). Unit location markers update every 30s via GPS SMS. Toggle: satellite view for rural navigation. Toggle: tower zone density heat layer.
Sorted list by algorithmic priority score. Shows: incident type icon, case ID, location (tower zone name), time since alert, current score. Color-coded rows. Mass casualty banner triggers at top if cluster detected. One-click "Assign" button opens unit selection modal.
Table of all registered at-risk individuals. Columns: name alias (coded), assigned officer, last check-in time, status (green / yellow 24h / red 48h). One-click manual welfare check dispatch. Officers can add notes. 48h no-response auto-generates incident.
All available units: Police (beat number), Ambulance (vehicle ID), APF, Fire. Status: Available / En-Route / On-Scene / Off-Duty. Drag to assign from triage queue. ETA calculated from last GPS position to tower circle centroid using Haversine. SMS auto-sent on assignment.
Draw a zone on the map (Leaflet draw). Type message in Nepali (Unicode). Select channels: SMS blast + USSD push. Preview recipient count (estimate from tower population data). One-click send. Delivery receipt counter. Message log with timestamp and zone ID.
Mini-map showing coverage towers colored by status: green (last incident <10min ago = active), grey (no recent activity), red (known outage — manual override). During disasters, offline towers appear immediately. Shows which zones have ZERO coverage — critical for rescue routing.
Tracked assets: ambulances, patrol cars, fire trucks, rescue boats (monsoon season toggle), helicopters. Status: Available / Deployed / Maintenance. Depleted medical supply flags. Auto-suggested resource for incident type (medical → ambulance; flood → boat + APF). Logged history per deployment.
Live KPIs: average alert-to-dispatch time, incidents resolved vs open, incident type distribution donut chart, hourly frequency sparkline. 7-day trend comparison. Hotspot detection: top 3 tower zones by incident count in last 24h. Exportable PDF shift report for senior commanders.
Dark mode only. Compact information density. No decorative graphics. Color is used exclusively for operational meaning: red = action required, amber = monitoring, green = resolved, grey = inactive. Font: monospace for IDs and coordinates, sans-serif for labels. Every element earns its place by answering a dispatcher question. This visual language communicates professionalism and operational seriousness to judge panels who are actual police officers.
The entire system runs on a single Node.js + Python process on one machine. No cloud dependencies except Africa's Talking (which has an excellent offline simulator for demos). Zero hardware procurement.
| Layer | Technology | Why This Choice |
|---|---|---|
| USSD / SMS Gateway | Africa's Talking API |
The only API with a built-in USSD simulator (ngrok tunnel → AT sandbox). Handles both USSD session management and SMS in one SDK. Free sandbox tier covers entire hackathon demo. Nepal-targeted: AT serves South/Southeast Asia. |
| Backend API | FastAPI (Python 3.11) |
Async WebSocket support built-in. AT webhook endpoint + dashboard API in one process. Background tasks for triage scoring cron and DV check-in scheduler. Under 15 minutes to set up. |
| Cell Tower Geolocation | SQLite + OpenCelliD CSV |
Pre-filter OpenCelliD for Nepal (MCC 429 for NTC, 429 Ncell), resulting in ~15,000 rows, ~2MB SQLite file. Single SQL query: SELECT lat, lon, range FROM towers WHERE mcc=429 AND lac=? AND cell_id=?. Fully offline. Zero API calls. |
| Database | PostgreSQL + PostGIS |
PostGIS enables geographic queries (nearest police station to a tower coordinate). incidents, units, registrations, broadcasts, audit_log tables. SQLAlchemy ORM for clean model layer. |
| Real-Time Sync | WebSockets (FastAPI) |
Dashboard subscribes to /ws/incidents channel. Every new USSD event broadcasts instantly to all connected dispatchers. No polling. Sub-second latency on LAN (critical for demo reliability). |
| Frontend | React + Vite |
Leaflet.js for maps (OpenStreetMap tiles). Leaflet.draw for broadcast zone drawing. Recharts for analytics. Dark-mode police aesthetic with custom CSS. react-query for data fetching. No UI library — custom components only for authenticity. |
| Maps & Tiles | Leaflet.js + OSM |
OpenStreetMap has excellent Nepal coverage including village-level detail in Lumbini Province. Tile cache can be pre-loaded for offline demo. Free, no API key, no rate limits. |
| IVR (P1 bonus) | Twilio TwiML |
Twilio's TwiML (XML-based voice scripting) handles IVR keypress detection in under 20 lines. Nepali text-to-speech via Google TTS API (free tier). Adds significant demo depth for literacy-gap use case. |
| Deployment | Docker Compose |
Single docker-compose up starts Postgres + FastAPI + React dev server. Reliable demo start on any machine. AT ngrok tunnel pre-configured. No "it works on my machine" failures during presentation. |
| Capability | USSD-Mesh (original) | SANKAT (enhanced) |
|---|---|---|
| Input types | ✕ USSD only, 2 options | ✓ USSD (6-option tree) + SMS keywords + IVR voice |
| Location data | ✕ None — no coordinates sent | ✓ Cell Tower → OpenCelliD → GPS circle on Leaflet map |
| DV / at-risk follow-up | ✕ Not addressed at all | ✓ Silent stealth USSD check-in, 48h auto-escalation |
| Missing persons | ✕ Not addressed | ✓ Reporting flow: age, gender, duration — SMS case ID issued |
| Triage / prioritization | ✕ All alerts equal — FIFO queue | ✓ Algorithmic scoring: type + time + cluster multiplier |
| Mass casualty detection | ✕ None | ✓ Auto-flag: 3+ alerts from same tower zone in 30min |
| Multi-agency dispatch | ✕ SMS to one number | ✓ Police / Ambulance / APF / Fire assigned from dashboard |
| Reverse broadcast | ✕ Not addressed | ✓ Draw zone → SMS blast to all registered phones in area |
| Case status for victims | ✕ No follow-up | ✓ Dial *999# → Option 3 → Enter case ID → SMS status update |
| Dashboard | ✕ "Plots a point on a map" | ✓ 8-panel ops center: map, queue, units, welfare, broadcast, analytics |
| Track 1 Problem #01 coverage | ✕ 1 of 5 problem areas | ✓ All 5: disaster, DV, missing, low-connectivity, case follow-up |
| Vibe-codeable in a day? | ✕ Yes — 4-6 hours solo | ✓ No — requires full 4-person team, genuine system integration |
Docker Compose skeleton (FastAPI + PostgreSQL + React Vite). Database schema: incidents, units, registrations, broadcasts tables. Register Africa's Talking sandbox account and configure USSD flow (this takes ~30 min via their web UI). Generate synthetic dataset: 40 incidents across 8 tower zones in Lumbini Province (Butwal, Rupandehi, Palpa, Nawalparasi). Pre-load OpenCelliD Nepal extract into SQLite. This data drives the entire demo — design it carefully so the demo reveals patterns.
Build the Africa's Talking USSD webhook handler. Implement the full 2-level menu tree in Python (state machine: session_id → current_menu_state). Implement Cell Tower lookup: extract LAC + Cell ID from AT request, query SQLite, return lat/lon/range. Write unit tests for all 6 main menu branches + DV stealth branch. This is the hardest piece — assign the strongest backend developer. The USSD state machine has ~35 states; map them on paper first.
Implement the scoring algorithm (base score + cluster detection + time decay). FastAPI background task runs every 60 seconds, recalculates all open incident scores, updates PostgreSQL. WebSocket /ws/incidents channel broadcasts the full sorted queue to all connected dashboard sessions on every update. Also build unit assignment endpoint: POST /incidents/{id}/assign/{unit_id} that triggers AT SMS to the unit's phone number.
Build the 8-panel dashboard layout. Leaflet map with circle rendering (lat/lon/radius from tower data), color-coded by incident type. Priority queue component (sorted list, color rows, expand/collapse). Unit status board. WebSocket useEffect hook subscribed to incident updates. Dark-mode police aesthetic: #050708 background, #f97316 accent, Share Tech Mono for IDs. The map must work on a laptop + external monitor (demo will be projected).
Connect all pipelines end-to-end: USSD dial → webhook → cell lookup → incident creation → WebSocket push → dashboard update. Fix integration bugs — budget 3 hours for this. Build the DV stealth module: registration endpoint, disguised USSD flow for registered numbers, silent alert vs check-in branching. Implement the 48h cron job for missed check-in escalation. Test full DV demo flow: register number → trigger fake balance check → press 2 → watch dashboard alert silently.
Build the DV Welfare panel (table with last check-in, color status, manual dispatch button). Build the Emergency Broadcast console (Leaflet draw zone, SMS blast endpoint using AT bulk SMS, delivery counter). Build the analytics panel (Recharts: hourly sparkline, incident type donut, average response time KPI). These are all relatively straightforward — one developer can complete them in 12 hours.
USSD Option 3 (case status): accept 6-digit ID, query PostgreSQL, format AT SMS reply. USSD Option 4 (nearest services): use tower lat/lon, PostGIS ST_Distance query to find nearest police station from a seeded facilities table. UI polish: loading states, animated incident arrival pulse on map, mass casualty banner animation. Harden against AT webhook failures (retry logic, session timeout handling).
Run the complete demo flow 15 times until it's smooth and under 90 seconds. Harden: what happens if AT sandbox is slow? (Pre-loaded demo dataset with pre-triggered incidents as fallback). What if ngrok tunnel drops? (Local backup demo with pre-recorded video of USSD session). Load the "Nokia feature phone" demo device with AT sandbox number pre-configured. Prepare the "Before" slide showing a plain SMS log next to SANKAT's map — the contrast is the story.
Every judge panel includes active Nepal Police officers from Lumbini Province. The following script is calibrated for them specifically — not for software developers.
"During the 2024 floods, 30,000 rescue workers coordinated via phone calls. Not a shared map. Not a dispatch system. Phone calls. When the towers were overloaded, even those failed. We asked: what is the one communication technology that still works on a cheap phone, in a flood zone, without internet, without a data plan, without charging? USSD."
"This is a Nokia 106. It cost Rs. 2,800 at a Butwal market. No WhatsApp. No app store. No data plan. This is the phone that exists in the hands of people in Pyuthan and Rolpa when a landslide hits."
[Hold up phone. Dial *999#. Pause for effect.]"The SANKAT menu appears. No internet used. No data charged. We select: 1 for Emergency. 1 for Natural Disaster. 1 for Trapped. Press OK."
[Navigate menu on Nokia. Press OK. Show phone screen to judges.]"An acknowledgement SMS arrives in 3 seconds: 'SANKAT: Help dispatched. Your Cell ID has been located. Case ID: SANK-2049.'"
"Watch this map. A new circle just appeared — Butwal-3 area. No GPS. No internet. Just the cell tower this Nokia was connected to. The circle radius is the tower's coverage area — about 600 meters. That is enough for dispatch to know which ward to send to."
"Priority score: 10. Incident type: TRAPPED. It is already at the top of the queue — our triage engine scored it automatically."
"Now watch what happens for a different kind of crisis. This phone belongs to a registered domestic violence survivor. She receives what appears to be a routine NTC balance notification."
[Team member shows phone screen: "NTC Service: Balance Rs.47.20. Press 1 to continue or 2 for more options."]"She is not safe. She presses 2."
[Press 2. 3 seconds of silence. Dashboard alert: DV WELFARE ALERT - UNIT 7 assigned. Red indicator, no sound from phone.]"No call. No sound. No notification visible on her phone. Only the police console knows. Her abuser sees nothing but a normal telecom message."
"SANKAT works on every phone in Lumbini Province. It works without data. It works when towers are overloaded. It follows up on survivors without putting them in danger. And when a dam breaks, dispatch can push an evacuation order to every phone in three ward zones in 30 seconds."
"Nepal Police already has the infrastructure. NTC and Ncell already have the towers. NTA has already standardized the shortcodes. SANKAT is the backend that finally connects them. Thank you."
Both are strong proposals. The decision comes down to your team's specific capability profile, not which idea is objectively better.
USSD Emergency Network
Best for teams with strong frontend/React skills and one solid backend developer. The Africa's Talking USSD API has excellent documentation — setup takes ~2 hours. The OpenCelliD SQLite lookup is a single SQL query. Demo is emotionally resonant for police judges. Track 1 has fewer technically strong teams; winning here may be easier.
Cybercrime Graph Intelligence
Best for teams with strong Python/ML skills and at least one developer comfortable with OCR pipelines (PaddleOCR + Ollama). Track 3 has the highest technical ceiling but also the hardest competition. Judge Inspector Khadka explicitly directed attention to Track 3. The demo is technically impressive but requires stable Ollama setup which can fail under pressure.
SANKAT has one demo moment that SarpaNet cannot replicate: a physical Nokia phone dialing a USSD code. This is tactile. It is real. Every police officer in the room has carried a Nokia. Watching a feature phone trigger a dispatch alert on a map is a more visceral demonstration of value than watching OCR extract a phone number from a screenshot — even though the latter is more technically sophisticated. If your team is equally strong in both stacks, choose SANKAT for the demo moment alone.
SANKAT's P2 (Cell Tower Geolocation) and SarpaNet's P1 (Evidence Ingestion) are architecturally independent. A very strong 4-person team could build SANKAT as the primary submission while baking in a "bonus demo": investigators can upload screenshots of USSD fraud evidence directly into a basic graph view. This addresses both Track 1 and demonstrates awareness of Track 3. Only attempt this if the integration sprint (hours 10–20) completes cleanly and you have 4+ hours of buffer before demo time.
Operational Impact: 10 · Innovation: 9 · Feasibility: 8.5 · Judge Appeal: 10
Directly addresses every bullet point in Track 1 Problem Statement #01.
The strongest Track 1 submission at Hack4Safety 2083 will be the one that makes a police officer from Rolpa say: "My officers need this right now." Build SANKAT.