Keep people, shelters, hospitals, responders, and critical supplies connected when conditions are unstable.
Code with Cisco Hackathon — Innovation + Proof of Concept
SANJEEVANI is a working disaster-response network that is designed for the moment ordinary connectivity stops being dependable. It combines 10 citizen field pods, 9 role-specific responder coordinators, an Emergency Operations Center (EOC), local and cloud triage, Cisco-aligned industrial networking, signed alerts, environmental sensing, collaboration alerts, observability, and an aerial drone relay that can reconnect an isolated pod.
The proof of concept runs as a 29-service Docker Compose topology. It does not pretend the network is always available: satellite and cellular links can be degraded or stopped, pods can enter island mode, messages can wait in persistent local queues, and a drone can be deployed as a temporary network path. The system is built around one operational promise:
An accepted SOS may be delayed, rerouted, relayed, or queued—but custody of the message is retained until another node confirms receipt.
The complete journey—from a citizen's SOS, through a resilient field pod and aerial relay, to the EOC and response teams—is summarized below. The same flow keeps hospitals, shelters, rescue teams, and supply depots coordinated during infrastructure outages.
During floods, earthquakes, fires, landslides, and severe storms, communication infrastructure can fail at the same time demand for help peaks. Towers lose power, fiber routes are cut, backhaul becomes congested, and field teams lose a shared operating picture.
The people affected are not only citizens trying to report an emergency:
| User | Pain point during a disaster | What SANJEEVANI provides |
|---|---|---|
| Citizens | No mobile data, no familiar app, language barriers, uncertain location | A local pod portal with 13 languages, voice input, map-assisted location, and offline acceptance |
| Hospitals | Incomplete medical requests, bed shortages, duplicate dispatch | Role-routed requests, resource visibility, claims, acknowledgements, and resolution tracking |
| Shelters | Changing occupancy, food, water, and blanket availability | Editable resource state, shortage alerts, and rerouting to available facilities |
| Fire and flood teams | Hazards may appear before a citizen can report them | Sensor-triggered early warnings and direct local delivery to teams in radio range |
| Workforce coordinators | Volunteers and equipment must be assigned rapidly | Dispatch boards, task status, volunteer assignment, and shared incident context |
| EOC operators | Field nodes disappear from view and delayed data looks current | Honest timestamps, route status, queues, receipts, live topology, and after-action events |
SANJEEVANI treats zero connectivity as a supported operating state, not as an application error.
This repository demonstrates the core idea end to end rather than stopping at a frontend mock-up:
- 29 running services model citizens, edge nodes, links, coordinators, the EOC, storage, AI, sensors, and aerial operations.
- Every SOS is accepted by a real backend, triaged, persisted locally, routed through a link service, stored in MongoDB, delivered to role-matched coordinators, and closed through a human response action.
- Infrastructure controls stop and restore real Docker services, so failover is observable rather than decorative.
- Local queues, deduplication, batching, delivery receipts, and retry workers implement the data-plane behavior.
- Cisco Webex, Meraki Dashboard API, IOS XE RESTCONF, and Splunk HEC adapters provide concrete integration seams.
- A provider-neutral drone service supplies missions, approval controls, telemetry, video, payload handling, and aerial network relay.
- Security and failure behavior are tested, including forged-alert rejection, AI failure, observability failure, rate limiting, queue recovery, and drone mission controls.
- Write before send. A pod persists a request locally before attempting any external delivery.
- Every crossing pays network physics. Link nodes apply configured latency, packet loss, and degraded/down state.
- Severity only climbs. A duplicate, stale copy, or late route cannot downgrade an escalation.
- AI enhances; it never gates. Rule-based routing completes before the model is consulted.
- Trust is verified at the edge. Pods verify EOC alerts locally using an enrolled Ed25519 public key.
- Island mode is valid. Queued work survives until satellite, cellular, drone relay, or mesh becomes usable.
flowchart LR
Citizen["Citizen phone<br/>local captive portal"] --> Pod["Field Pod x10<br/>React + Node edge agent"]
Sensors["Meraki MT-style sensors<br/>and MT30 help button"] --> Pod
Pod --> Queue["Persistent local queue<br/>rule-based triage"]
Queue --> Router{"Best usable path"}
Router -->|1. healthy| Sat["Satellite link node"]
Router -->|2. healthy| Cell["Cellular link node"]
Router -->|3. degraded fallback| Degraded["Surviving degraded link"]
Router -->|4. deployed| Drone["Aerial drone relay"]
Router -->|5. neighbor available| Mesh["Pod-to-pod mesh relay"]
Router -->|6. no path| Island["Island mode<br/>retain and retry"]
Sat --> Cloud["Cloud API + MongoDB"]
Cell --> Cloud
Degraded --> Cloud
Drone --> Cloud
Mesh --> Neighbor["Neighbor pod with a cloud path"] --> Cloud
Island --> Router
Pod -. "direct local delivery" .-> Coordinators["9 responder coordinators"]
Cloud --> Coordinators
Coordinators -->|acknowledge / resolve / resources| Cloud
Cloud <--> EOC["EOC Command Center"]
Cloud --> Webex["Cisco Webex alerts"]
Cloud --> Splunk["Splunk HEC events"]
- A citizen connects to a nearby pod and submits an SOS.
- The pod performs deterministic keyword triage and persists the request in
queue.jsonusing an atomic temporary-file rename. - The pod returns an acceptance response immediately; cloud availability is not required.
- The routing ladder selects satellite, cellular, a degraded surviving link, aerial drone relay, pod mesh, or island mode.
- The cloud deduplicates by request ID, preserves the earliest origin time, stores the request in MongoDB, and classifies responder roles.
- The request reaches coordinators through two independent paths: cloud delivery and direct local pod-to-coordinator delivery.
- A local Ollama model re-reads the stored request asynchronously and can only increase urgency or add roles.
- Critical events can alert responders through Cisco Webex; operational events can stream to Splunk.
- A coordinator acknowledges or resolves the request. The receipt travels back to the cloud and EOC, completing the loop.
“Cisco-powered” is not treated as a product-name checklist. Each Cisco technology is assigned a specific operational responsibility, and the repository clearly separates implemented integrations, simulated hardware contracts, and the production deployment blueprint.
| Cisco technology | Role in SANJEEVANI | POC status |
|---|---|---|
| Cisco Meraki Dashboard API | Imports real organization, device, and MT sensor telemetry into the same hazard pipeline used by simulated sensors | Implemented adapter in integrations/meraki_live.py; credentials optional |
| Cisco Meraki MT sensors / MT30 | Temperature, water, indoor-air-quality, and physical help-button inputs for early warning | Contract simulated every 4 seconds; real Dashboard API feed supported |
| Cisco Meraki MR / MG / MX pattern | Citizen Wi-Fi access, cellular backhaul, and policy-driven multi-path edge connectivity | Represented by software services in the POC; hardware deployment blueprint |
| Cisco IOS XE RESTCONF | Reads interfaces and demonstrates configuration-by-code for zero-touch segmentation/QoS workflows | Implemented adapter in integrations/catalyst_restconf.py, including a DevNet Catalyst 8000V path |
| Cisco Catalyst IR1800 + IOx | Rugged production field-pod platform capable of hosting the pod agent at the edge | Production target; Docker container is the application seam demonstrated today |
| Cisco Catalyst IW9165E + Ultra-Reliable Wireless Backhaul (URWB) | Ground mesh and UAV-mounted mobile backhaul for broken or moving networks | URWB behavior simulated by gossip/relay services; physical radios are the deployment target |
| Cisco Webex Messaging API | Sends actionable critical-SOS, AI-upgrade, sensor-warning, resource-saturation, and drone-milestone alerts to responder spaces | Implemented live integration with bot room discovery, retry, deduplication, and rate limits |
| Cisco Catalyst SD-WAN Manager | Central policy, segmentation, transport selection, and fleet-scale configuration across rugged routers | Production blueprint; the POC implements the path-selection policy in code |
| Cisco ThousandEyes | End-to-end assurance and early detection of degraded WAN paths | Production blueprint; the POC exposes equivalent latency/loss state through link nodes and the EOC |
| Cisco Secure Firewall, Umbrella, Duo, Cyber Vision | Safe-zone perimeter, DNS protection, responder identity, and OT visibility | Production security blueprint, not claimed as part of the Docker POC |
| Splunk | Searchable event timeline and after-action investigation using HEC | Implemented optional integration; 8/8 forwarding/failure tests pass |
The production design replaces simulated link and sensor services without rewriting the application contracts: a Catalyst IR1800/IOx field pod, Meraki sensing and citizen access, Catalyst IW9165E URWB mesh, multi-transport Cisco Catalyst SD-WAN, safe-zone security, Webex incident collaboration, and ThousandEyes/Splunk visibility.
Honesty boundary: the image above is the hardware-day blueprint. The repository currently implements the application layer, real Webex/Meraki/RESTCONF/Splunk integration seams, software link physics, and a mock/FlytBase drone-provider boundary. It does not claim that every pictured Cisco appliance is present in the Docker demo.
The drone is not only a camera. In SANJEEVANI, aerial_relay is a first-class network mission.
A flood, landslide, or bridge collapse can isolate a functioning pod from every fixed uplink. Citizens may still reach that pod over local Wi-Fi, and nearby responders may still receive direct local alerts, but the EOC cannot see the growing queue. A relay aircraft can temporarily bridge that gap without waiting for a tower or road to be repaired.
- The EOC creates an Aerial Network Relay mission and selects a target pod.
- The mission remains
requesteduntil a human operator clicks Approve. - The operator selects an aircraft or allows automatic selection and clicks Launch.
- The service simulates flight telemetry: GPS position, altitude, battery, signal, progress, payload, and video state.
- When the aircraft reaches
on_station, the cloud authorizes the target pod to use the drone service as a temporary link node. - The pod inserts
drone-relayinto its routing ladder after surviving direct links and before ground mesh. - Queued requests are forwarded individually or as a batch through
/api/forwardor/api/forward-batchand stored withsynced-via-aerial-drone-relayevidence. - Return Home or Emergency Land revokes the path. The pod automatically recalculates its next usable route.
requested -> approved -> launching -> en_route -> on_station -> returning -> completed
Additional operator actions include pause, resume, return home, emergency land, and release medical payload when an aircraft is on station.
| Mission type | Operational purpose |
|---|---|
aerial_relay |
Restore temporary data connectivity for an isolated pod |
victim_search |
Detect simulated thermal signatures near a marked location |
flood_survey |
Provide aerial flood-zone observation and progress telemetry |
bridge_inspection |
Report route or bridge hazards before ground dispatch |
medical_payload |
Carry and release an emergency medical payload |
The default DRONE_MODE=mock includes three aircraft with different battery, home location, and payload capabilities. A provider-neutral adapter keeps credentials on the server side; DRONE_MODE=flytbase activates the FlytBase seam configured in .env.
In a field deployment, an aircraft carrying a Cisco Catalyst IW9165E-class URWB radio becomes another mobile mesh neighbor. The application does not need a drone-specific queue: it only needs a new authenticated link with health and forwarding contracts.
Each pod is an independent edge site with its own UI, backend, data directory, triage rules, route state, queues, sensors, and mesh neighbors.
- 13-language interface: English, Hindi, Telugu, Tamil, Kannada, Malayalam, Marathi, Bengali, Gujarati, Punjabi, Urdu, Odia, and Assamese.
- Voice-assisted reporting: browser speech recognition writes captured speech into the emergency description using the selected locale when the browser supports it.
- Structured SOS intake: name, age, phone, emergency category, zone/shelter, landmark or address, and a detailed message.
- Five request categories: Medical, Rescue, Food, Water, and Shelter.
- Map-assisted location: citizens can choose a known zone and refine the exact point in a map dialog.
- Local deterministic triage: critical medical/rescue keywords produce severity 9, essential supply/shelter terms produce severity 6, and general assistance produces severity 3.
- Write-before-send queue: the request is persisted before the sync worker attempts delivery.
- Immediate local acknowledgement: the citizen sees that the request has been accepted even if the pod is in island mode.
- Network-path visibility: Satellite, Cellular, and Mesh controls show which paths are locally enabled.
- Local-path controls: disabling a path at one pod does not alter other pods.
- On-site sensor view: current reading, units, NORMAL/WATCH/CRITICAL state, hazard type, and freshness.
- Local warnings: a pod warns citizens immediately when its own hazard pack fires, even with no uplink.
- Rate limiting: repeated submissions from one device receive HTTP 429 without blocking other citizens.
- Persistent identity and settings: pod display names and route preferences survive restarts through mounted data directories.
The routing engine recalculates from live health and local policy:
- Healthy satellite
- Healthy permitted cell tower
- Degraded satellite or cellular path if it is the only direct route
- Authorized aerial drone relay
- Best pod-mesh neighbor with a known cloud path
- Island mode with local retention
Additional behavior:
- Predictive degradation: a link with at least 25% configured packet loss is marked degraded; a healthy alternative outranks it.
- Link physics: each link node applies latency and probabilistic packet loss on every forwarding attempt.
- Gossip routing: pods advertise hop distance and route history to configured neighbors.
- Loop prevention: route trails reject revisits and enforce a maximum of 12 mesh hops.
- Retry worker: every pod checks the queue immediately after submission and then every 5 seconds.
- Health-change recovery: restoring infrastructure makes the queued work eligible for the next sync cycle.
- Surge batching: more than three queued requests on a direct route are sent in one batch, paying the simulated link latency once.
- Idempotent merge: duplicate IDs merge instead of multiplying incidents;
seenVia,relayTrail, andforwardedBypreserve evidence. - Honest time: the origin timestamp remains separate from received and synchronized timestamps.
Nine coordinator services share one implementation but load role-specific templates:
| Port | Coordinator | Primary responsibility |
|---|---|---|
| 8101 | Hospital 1 Command | Medical triage, beds, ambulances, oxygen, critical patients |
| 8102 | Hospital 2 Command | Medical overflow and alternate capacity |
| 8103 | Shelter A | Shelter intake, food, water, blankets, vacant capacity |
| 8104 | Shelter B | Shelter intake and alternate regional capacity |
| 8105 | Shelter C | Shelter intake and alternate regional capacity |
| 8106 | Workforce Camp 1 | Volunteers, assignments, transport, staging |
| 8107 | Workforce Camp 2 | Workforce overflow and alternate coverage |
| 8108 | Fire Coordinator | Pumps, breathing kits, route clearance, safety response |
| 8109 | Flood Coordinator | Boats, life jackets, rope kits, rescue teams |
Coordinator capabilities:
- Operations: active dispatch target, ambulance selection, volunteer selection, staging points, and operation logs.
- Incoming requests: role-matched requests from cloud and direct pod mesh, with severity, transport, location, AI reasoning, and delay timestamps.
- Acknowledge: records that a team is responding and publishes a claim to other coordinators.
- Mark handled: moves the request into Past History and sends a resolution event to the EOC.
- Peer-claim visibility: duplicate recipient teams see who already acknowledged or handled the request; this reduces duplicate dispatch without introducing a dangerous hard lock.
- Resources and network: editable stock/capacity fields, live link state, manual sync, shortage badges, and local path controls.
- Shortage-aware routing: zero stock marks a facility out of stock; at 10% or below it is low stock. New same-role requests prefer another facility with capacity.
- Never-silence fallback: if every coordinator in a role is exhausted, the request is still delivered as a last-resort escalation.
- Cloud and local delivery: cloud routing and direct pod radio delivery merge by request ID.
- Offline actions: acknowledgements, resource changes, and resolutions queue locally and synchronize when a route returns.
- Live hazard telemetry: coordinators see field readings for the pods in their response area.
The EOC is a real-time React/Vite operator console backed by the cloud API, Socket.IO, MongoDB, and polling fallback.
| Page | Functionality |
|---|---|
| Dashboard | Open/critical KPIs, pods online, active network mode, live requests, AI SITREP, sensor feed, network summary, topology map, and activity feed |
| Requests | Active and past cases, severity, lifecycle, routing reason, AI evidence, coordinator receipts, transport, timestamps, and resolution |
| Pods | Per-pod identity, connectivity, queues, active SOS state, and route details |
| Network | Live zone topology, satellite/tower status, coordinator reachability, route decisions, fail/restore controls, and Restore All |
| Sensors | Live Meraki-style readings, risk summary, search, status/type/zone filters, sorting, and sensor map |
| Aerial Ops | Mission creation, approval, aircraft selection, telemetry, video, findings, medical payload, and aerial relay |
| Resources | Coordinator-reported inventory, capacity bars, low/out-of-stock warnings, and freshness |
| Volunteers | Workforce availability and coordinator-reported assignments |
| Alerts | Unread notification state, signed alert broadcast, hazard/security records, and forged-alert evidence |
The dashboard also includes global search across pods, requests, sensors, and locations, plus browser-persisted unseen-alert counts.
The sensor simulator represents a Cisco Meraki MT-style fleet and posts a reading every 4 seconds. The same JSON contract can receive real Meraki Dashboard telemetry.
| Sensor input | POC metric | Hazard pack | Default trigger |
|---|---|---|---|
| MT10-style temperature | temperature |
Heatwave | 45 °C |
| Meraki water-input contract (MT12-style) | simulated water_level depth |
Flood | 150 cm |
| MT14-style air quality | air_quality / PM2.5 |
Wildfire smoke | 250 µg/m³ |
| IOx-connected accelerometer | shake_g |
Earthquake | 0.4 g |
| MT30-style button | physical help press | Critical SOS | Immediate severity 9 |
When a threshold or configured fast-rise rule fires:
- The origin pod stores a local citizen warning.
- An EARLY-WARNING event joins the normal resilient queue.
- Nearby role-matched coordinators receive a direct local copy.
- The cloud stores the event and signs a broadcast for pods.
- Webex can notify responders even when nobody is watching the dashboard.
- Hysteresis/re-arm logic prevents a hovering sensor from spamming duplicate alerts.
The Simulation Controller at http://localhost:9300 can spike/reset each sensor and press selected MT30 buttons.
The cloud tier runs Ollama with qwen2.5:3b. The model is intentionally outside the critical acceptance path.
- Asynchronous: the request is already stored and routed before inference starts.
- Upgrade-only: AI may raise severity or add responder roles; it may never lower severity or remove a deterministic match.
- Late-upgrade propagation: newly required coordinators receive the corrected request.
- Evidence: request cards show the model reason and whether the verdict upgraded or confirmed the rule result.
- Safe failure: when Ollama is loading or unavailable, the original rule verdict remains valid.
- SITREP: the EOC can generate a roughly 30-second briefing using open incidents, critical cases, shortages, sensors, and link state, organized as SITUATION / CRITICAL / RESOURCES / ACTIONS.
- Local runtime: after the one-time model pull, inference stays inside the cluster rather than sending citizen emergencies to an external AI API.
Example designed to prove the value of upgrade-only AI:
"My chest feels heavy and I am dizzy."
The phrase avoids the most obvious critical keywords, begins with the deterministic low-severity fallback, and can then be upgraded by the model to a possible cardiac emergency with hospital routing.
The Sanjeevni-Sentinel bot uses the Webex Messaging API to publish formatted responder alerts for:
- a newly stored critical SOS;
- an AI-upgraded critical emergency;
- a sensor early warning;
- role-wide resource saturation; and
- important drone mission milestones.
Operational guardrails:
- room discovery instead of hard-coded room IDs;
- fire-and-forget calls with timeout;
- retry queue with room rediscovery;
- one alert per incident key;
- maximum alert rate to avoid flooding responders; and
- stale/demo-seed suppression.
The SOS pipeline never waits for Webex. Collaboration improves awareness but cannot block emergency handling.
- Ed25519 signed alerts: the cloud signs broadcasts; pods cache the public key and verify locally.
- Anti-replay sequence: a valid old message is rejected if its sequence does not advance.
- Scope enforcement: a pod rejects a signed message that is not addressed to it or to all pods.
- Fail closed: unsigned alerts, bad signatures, unavailable trust anchors, and forged
verified: truefields are rejected. - Security evidence: rejected attempts create events that climb the ordinary resilient queue to the EOC security log.
- Control tokens: infrastructure, manager, and drone-control endpoints require server-side keys.
- Rate limiting: citizen submission and external enhancers have independent protections.
- Secret isolation:
.envis ignored by Git; Webex, Splunk, Meraki, IOS XE, and drone credentials are not embedded in frontend code.
This application-layer authenticity is complementary to—not a replacement for—production transport encryption, identity, firewalling, and device security.
Every important state transition can become an event:
- request created and routed;
- link/path selected or degraded;
- delivery accepted, queued, rejected, acknowledged, or resolved;
- shortage declared or recovered;
- sensor early warning;
- AI upgrade;
- Webex outcome;
- drone mission milestone; and
- security rejection.
The EOC shows the operational timeline. Optional Splunk HEC forwarding batches structured events with fields such as pod, severity, transport, responder targets, hazard, and AI-upgrade state. Splunk is also an asynchronous enhancer: an unreachable HEC endpoint does not delay storage or routing.
Example search:
source="sanjeevani" severity>=8
| Layer | Working now in this repository | Simulated with a defined contract | Production evolution |
|---|---|---|---|
| Citizen access | React pod portal, 13 languages, voice and location | Local captive-Wi-Fi experience | Meraki MR or IR1800 Wi-Fi with local DNS/captive portal |
| Edge compute | Node pod agent, local triage, queue, sensors, sync worker | Hardware power and enclosure | Catalyst IR1800 hosting the application through IOx |
| WAN | Link health, latency/loss, satellite/cellular failover | Physical satellite and cellular networks | Cisco Catalyst SD-WAN across LEO, 5G/private LTE, broadband, and policy overlays |
| Mesh | Gossip, hop selection, loop prevention, direct relay | RF propagation and mobility | Catalyst IW9165E URWB ground and UAV nodes |
| Sensors | Live simulator plus real Meraki API adapter | Default MT fleet | Meraki MT/MT30/MV hardware and Dashboard webhooks/API |
| Drone | Three-aircraft mission engine, telemetry/video, relay, FlytBase adapter | Flight physics and camera feed | Real UAV provider with IW9165E-class radio and governed air operations |
| Collaboration | Live Webex Messaging API adapter | Phone push depends on configured bot/space | Webex incident spaces and operational workflows |
| Observability | EOC activity stream and optional Splunk HEC | ThousandEyes-like link impairment | Cisco ThousandEyes assurance plus Splunk operational analytics |
| Security | Ed25519, anti-replay, scope, tokens, rate limits | Full device identity and encrypted WAN | Catalyst SD-WAN security, Secure Firewall, Umbrella, Duo, Cyber Vision |
This explicit boundary is intentional: the containers are the rehearsal environment, while the APIs and service contracts are the swap-in points for field hardware.
- Docker Desktop with Docker Compose
- Sufficient disk space for images and the Ollama model
- Optional credentials only if demonstrating Webex, Splunk, Meraki, IOS XE, or FlytBase
docker compose up -d --buildThe first start pulls qwen2.5:3b into the ollama-models volume and may take a few minutes. All non-AI paths work while the model is loading.
EOC Command Center: http://localhost:9400
Simulation Controller: http://localhost:9300
Cloud API health: http://localhost:9000/api/health
Drone service health: http://localhost:9600/health
Sensor simulator status: http://localhost:9500/status
Citizen pods: http://localhost:8001 ... http://localhost:8010
Responder coordinators: http://localhost:8101 ... http://localhost:8109
Satellite link: http://localhost:9100/health
Cell tower 1: http://localhost:9201/health
Cell tower 2: http://localhost:9202/health
docker compose psThe winning story is not “here are all our pages.” It is one emergency that survives a network failure, reaches a responder locally, and later reaches the EOC through an aerial relay. Use short edited cuts for AI, sensors, resources, security, and integrations.
Open these tabs from left to right:
- EOC Dashboard —
http://localhost:9400 - Simulation Controller —
http://localhost:9300 - POD-06 —
http://localhost:8006 - Flood Coordinator —
http://localhost:8109 - Aerial Ops — open from the EOC navigation
- EOC Requests and Sensors — open from the EOC navigation
Before recording:
- restore Satellite, Tower 1, and Tower 2;
- reset any spiked sensors;
- verify all 29 services are running;
- keep an aerial-relay mission ready to approve or use an edited time cut while it flies; and
- if showing Webex, test the bot before the final take.
| Time | What to show | What to say |
|---|---|---|
| 0:00–0:18 | EOC dashboard and topology | “When disaster strikes, the network is often the first casualty. SANJEEVANI keeps citizens, hospitals, shelters, responders, and supplies connected even when satellite and cellular paths fail.” |
| 0:18–0:36 | POD-06 language selector, sensors, and SOS form | “Citizens connect to a nearby field pod—no app install required. The portal supports 13 languages, voice-assisted reporting, local hazard telemetry, and exact location capture.” |
| 0:36–0:55 | Simulation Controller: stop Satellite, Tower 1, and Tower 2; return to POD-06 | “I am now removing every fixed uplink. The pod does not crash; it enters island mode, which is a supported state.” |
| 0:55–1:14 | Submit a flood/rescue SOS from POD-06 | “The SOS is triaged and written locally before any send attempt. The citizen receives an acknowledgement immediately, while the request remains in the persistent queue.” |
| 1:14–1:32 | Flood Coordinator Incoming Requests | “The EOC is temporarily blind, but the nearby flood team still receives a direct local copy. Cloud delivery and local radio delivery are independent, then deduplicated by request ID.” |
| 1:32–1:58 | EOC Aerial Ops: choose Aerial Network Relay, target POD-06, approve, launch; cut to on-station | “A drone is more than a camera. The EOC deploys an approval-controlled aerial relay. When it reaches the isolated pod, it becomes a temporary network node.” |
| 1:58–2:15 | POD-06 queue drains; EOC request appears with drone relay evidence | “The pod automatically selects drone-relay, flushes its queued SOS, and records exactly how the request reached the cloud. No application rewrite and no manual re-entry.” |
| 2:15–2:33 | Coordinator Acknowledge/Mark handled; EOC lifecycle/receipt | “Responders acknowledge and resolve the case. Honest delivery receipts and timestamps close the loop at the Command Center.” |
| 2:33–2:48 | Fast cuts: sensor spike, AI upgrade, Webex message, resources | “The same platform supports Meraki-style early warnings, upgrade-only local AI, Webex responder alerts, and shortage-aware routing between hospitals and shelters.” |
| 2:48–3:00 | Network map, architecture image, final logo | “The POC runs end to end today. Cisco Catalyst edge compute, URWB, SD-WAN, Webex, Meraki, ThousandEyes, security, and Splunk provide a credible path from simulation to field deployment.” |
Name: Asha Rao
Category: Rescue
Location: Remote Village / POD-06
Message: Floodwater is rising. Six people are trapped on a roof. One person is unconscious and needs insulin.
This produces a critical request and demonstrates flood, hospital, and shelter coordination.
Submit the following while a normal cloud path is available:
My chest feels heavy and I am dizzy.
Say:
“The deterministic edge rule accepts and routes first. The local cloud AI then detects a possible cardiac event, upgrades severity, adds the hospital role, and propagates the correction. If the model fails, the original request still moves.”
curl.exe -X POST http://localhost:8001/api/requests `
-H "Content-Type: application/json" `
-d '{"name":"Ramesh Kumar","age":68,"phone":"+91 9876543210","category":"Medical","message":"My grandfather needs insulin and cannot walk","location":"Kothapalli Zone 3"}'curl.exe http://localhost:8001/api/pod/status
curl.exe http://localhost:8001/api/queuecurl.exe -X POST http://localhost:9300/api/infra/satellite/fail `
-H "Content-Type: application/json" `
-H "x-infra-token: sanjeevani-infra-demo-key" -d '{}'
curl.exe -X POST http://localhost:9300/api/infra/satellite/restore `
-H "Content-Type: application/json" `
-H "x-infra-token: sanjeevani-infra-demo-key" -d '{}'The same endpoints accept celltower-1 and celltower-2 in place of satellite.
curl.exe -X POST http://localhost:9300/api/sensors/spike/POD-06/air_quality `
-H "Content-Type: application/json" -d '{}'Supported metrics include temperature, water_level, shake_g, and air_quality according to each pod's installed hazard pack.
curl.exe -X POST http://localhost:8001/api/sync `
-H "Content-Type: application/json" -d '{}'curl.exe http://localhost:9000/api/ai/health
curl.exe http://localhost:9000/api/webex/health
curl.exe http://localhost:9600/healthCopy .env.example to .env, set WEBEX_BOT_TOKEN, add sanjeevni_sentinel@webex.bot to a Webex space, and restart cloud-api.
curl.exe -X POST http://localhost:9000/api/webex/test$env:MERAKI_API_KEY="<key>"
py integrations\meraki_live.py --feed-control-center --pod-id POD-01Local no-credential contract demo:
py integrations\meraki_live.py --demo --pod-id POD-01$env:IOSXE_HOST="<device>"
$env:IOSXE_USER="<user>"
$env:IOSXE_PASS="<password>"
py integrations\catalyst_restconf.py --configure --pod-id POD-01Local no-credential contract demo:
py integrations\catalyst_restconf.py --demo --pod-id POD-01SPLUNK_HEC_URL=http://host.docker.internal:8088
SPLUNK_HEC_TOKEN=<token>
Restart cloud-api after changing the environment.
Set DRONE_MODE=flytbase and the FlytBase tenant, authentication, and endpoint variables documented in .env.example. Browser code continues to call only SANJEEVANI's server-side API.
# Core routing, signed alerts, forgery rejection, hazard broadcast,
# degradation, rate limiting, blackout queue, and batch recovery
py integrations\integration_test.py
# AI upgrade-only behavior, SITREP, and model-down fallback
py integrations\ai_triage_test.py
# Splunk HEC format, authentication, and non-blocking failure
py integrations\splunk_test.py
# Drone mission state and operator actions
node drone-service\smoke-test.jsVerified for this README update:
- core resilience integration suite: pass;
- AI triage chain: 12/12 pass;
- Splunk HEC chain: 8/8 pass; and
- drone mission smoke test: pass.
.
|-- docker-compose.yml
|-- Command-Center/
| |-- Frontend/ # React/Vite EOC and Node aggregation proxy
| `-- Backend/ # Cloud API, MongoDB, routing, AI, Webex, Splunk
|-- pod-agent/
| |-- client/ # 13-language citizen interface
| |-- services/ # queue, triage, connectivity, gossip, hazards
| `-- server.js # pod API, direct delivery, alert verification
|-- coordinators/
| |-- client/ # operations, intake, resources, history
| `-- server.js # role templates, inbox, claims, offline sync
|-- link-node/ # satellite and cellular latency/loss forwarding
|-- simulation-controller/ # infrastructure failure and sensor drill UI
|-- sensor-simulator/ # Meraki MT-style sensor and MT30 event source
|-- drone-service/
| |-- providers/ # mock and FlytBase provider boundary
| `-- server.js # fleet, mission, telemetry, video, relay API
|-- integrations/ # Meraki, RESTCONF, Webex/Splunk verification tools
|-- docs/architecture/ # architecture visuals adapted from the pitch decks
|-- pod-data/ # generated local pod state
`-- coordinator-data/ # generated coordinator state and sync queues
- Horizontal pod model: every new field pod uses the same image and receives identity, neighbors, cell coverage, and coordinator range through environment configuration.
- Role-template coordinators: hospitals, shelters, workforce, fire, and flood services share code while preserving specialized resources and workflows.
- Swap-in seams: link nodes, sensor feeds, drone providers, observability, and collaboration are isolated behind HTTP contracts.
- Data-plane independence: Webex, Splunk, and AI failures cannot stop SOS acceptance or deterministic routing.
- Batch recovery: backlog transmission reduces latency cost on thin or newly restored links.
- Distributed custody: local persistence, direct delivery, cloud storage, and coordinator storage prevent one database from being the only copy.
- Production management path: Catalyst SD-WAN Manager can centralize routing policy, segmentation, and rugged-router lifecycle while ThousandEyes supplies assurance.
SANJEEVANI is intended to improve:
- time from citizen report to the correct response team;
- continuity of emergency reporting during infrastructure failure;
- inclusion for citizens who do not use English or cannot type easily;
- awareness of hospital, shelter, equipment, and volunteer shortages;
- responder coordination without making a cloud dashboard the only control point; and
- auditability of what was known, when it was received, and how it was handled.
The repository proves technical feasibility; field impact would need validation with disaster-management authorities, hospitals, accessibility experts, radio planners, aviation regulators, and affected communities.
This is an innovation POC, not a certified emergency system.
- Satellite, cellular, RF propagation, and link failure are modeled in containers.
- The default sensor fleet and drone flight are simulated; real integration seams are present.
- Ed25519 message authenticity does not replace a production PKI, encrypted transport, secure boot, device attestation, or responder identity.
- Real aerial relay requires spectrum planning, aviation approval, redundancy, battery rotation, and weather testing.
- Field hardware, power budgets, environmental enclosures, accessibility, load testing, high availability, and formal threat modeling remain future work.
- A production pilot should add Catalyst IR1800/IOx pods, IW9165E URWB radios, SD-WAN policy, ThousandEyes assurance, Secure Firewall, and governed Webex incident workflows.
The next milestone is a small field pilot with two physical pods, one mobile relay, one EOC, one hospital, and one shelter—measuring delivery time and recovery behavior under controlled link loss.
Stop the topology:
docker compose downTo remove generated pod/coordinator state and restart a clean demo:
Remove-Item -LiteralPath .\pod-data,.\coordinator-data -Recurse -Force
docker compose up -d --buildDo not delete .env if it contains integration configuration. Never commit credentials.
- Cisco Catalyst IR1800 IOx application hosting
- Cisco Catalyst IR1800 Rugged Series data sheet
- Cisco Catalyst IW9165 Series and URWB
- Cisco Ultra-Reliable Wireless Backhaul
- Cisco Meraki Dashboard API: latest sensor readings
- Cisco Meraki MT30 smart automation button
- Cisco Webex Messaging API
- Cisco Catalyst SD-WAN for industrial networks
- Cisco ThousandEyes integration with Catalyst SD-WAN Manager
SANJEEVANI — connecting the disconnected when it matters most.