When infrastructure fails, nearby phones become the infrastructure.

JeevaGrid turns nearby smartphones into a cooperative, offline edge-AI emergency network. Together they locate possible survivors, read crowd movement, map hazards, and guide civilians and responders to safer routes.

See JeevaGrid in action Explore architecture

Loading building model

T+00sInternet unavailable. Phones advertising over BLE.

Network: LOCAL
Internet: UNAVAILABLE
Active nodes: 0
CrisisGraph: WAITING
Edge AI: ACTIVE

Disasters break more than buildings.

Fires, earthquakes, collapses, floods and crowd crushes rarely fail one thing at a time. Several systems go down together, just when people need them.

What fails at once

Cellular connectivity
Towers overloaded or without power
Degraded
Evacuation routes
Stairs and corridors blocked by debris or smoke
Blocked
Crowd movement
Density builds at the exits everyone knows
Unsafe
Trapped people
Hard to locate behind walls and rubble
Unknown
Responder picture
Radio fragments, no shared map
Fragmented
Cloud AI
Unreachable without a network
Unavailable

Large emergency systems normally need dedicated infrastructure: towers, servers, installed sensors. Those are the first things a disaster takes out.

What almost everyone is already carrying

Microphone
hears calls and knocking
Camera
sees crowds and obstructions
Inertial sensors
track motion and heading
Compute and NPU
run models locally
Battery
hours of independent power
Radio
talks to nearby phones
Screen
shows the way
Haptic motor
guides without looking

What if those phones could cooperate?

One phone is one sensor.

Many phones are temporary emergency infrastructure.

Microphones+Cameras+Motion sensors+Local AI+Peer networking+Graph intelligence=JEEVAGRID

Each phone watches and listens to its own surroundings.

It doesn't stream raw audio or video. It turns what it notices into small events: possible knock, Room G, 88%.

Nearby phones swap those events and each builds the same picture of the crisis. No server sits in the middle.

The phone isn't running the system. The phones are the system.

01
SENSE
Each phone observes locally: sound, crowd, obstructions, motion.
Dhwani · CrowdPulse · Scouts
02
FUSE
Observations become compact semantic events and merge into one shared model.
CrisisGraph
03
DECIDE
Risk-weighted routing picks safer paths as conditions change.
PathMesh
04
GUIDE
Civilians and responders get arrows, haptics and voice, not raw data.
Civilian · Responder

The network creates capabilities no single phone has.

“We can estimate where it came from.”

Two independent hyperbolas cross. The intersection is the estimate, and its size is the uncertainty.

Same for crowds. “The whole local crowd flow is changing.”

Module 1 · Dhwani

Many microphones. One virtual ear.

Dhwani lets nearby phones jointly recognise emergency sounds and estimate where they came from: calls for help, repeated knocking, whistles, alarms, impacts.

01Microphone
16 kHz PCM, ring-buffered on device
02Local audio model
Small on-device classifier, 1 s windows
03Emergency event detection
Knock, call for help, whistle, alarm, impact
04Cross-device correlation
Match the same event across phones by class and time
05Time difference of arrival
Onset timestamps compared on a shared clock
06Source localisation
Intersect hyperbolas, estimate region and spread
07CrisisGraph
ACOUSTIC_TARGET event with confidence and age

Filtered out on-device

Machinery
Wind
Traffic
Ambient speech
Random impacts
Environmental noise

Acoustic calibration

Before search starts, each phone plays a short chirp from its speaker. The others time it, which gives pairwise distances and clock offsets. The dashed cyan lines in the field show this.

Acoustic field · 7.2 × 5.2 mTDoA + acoustic cross-correlation

Drag the phones or the sound, then emit a knock. The sound is visible to you, not to the phones. They only have their timestamps.

Arrival timestamps per phone
Node	Arrival	Range diff
NODE A	—	—
NODE B	—	—
NODE C	—	—

Awaiting acoustic event

Wording is deliberate. Dhwani reports a possible human acoustic event with a confidence. It never says a survivor is confirmed. A responder makes that call.

Module 2 · CrowdPulse

Understand movement before congestion becomes dangerous.

Phones watching a corridor estimate people count, density, dominant direction, walking speed and counter-flow on-device, then flag conditions that tend to come before a choke point.

Cameras observe locally. Meaning travels. Video does not.

Sentinel view · corridor B → doorway moving slowed counter-flow

Crowd inflow2.6 p/s

Density: LOW; 0.0 p/m²
Speed: 1.1 m/s; baseline 1.1 m/s
Counter-flow: LOW; 0% of people
Congestion risk: 0.10; within normal range

Shared with the mesh~180 bytes

{
  "type": "CROWD_STATE",
  "zone": "corridor_b",
  "density": 0,
  "heading": 91,
  "meanSpeed": 1.1,
  "counterflow": 0,
  "congestionRisk": 0.1
}

CrowdPulse never predicts a stampede. It reports measured conditions, such as rising density, falling speed and counter-flow, that are associated with unsafe crowding, so people can decide early.

Module 3 · PathMesh

The shortest route is not always the safest route.

PathMesh recomputes routes over CrisisGraph as reports arrive. Every corridor carries distance, passability, hazard risk, crowd risk, uncertainty and the time of its last update.

Click a corridor to block or clear it

Civilian: current position B → safest exit

Safety first, then distance. Both exits are evaluated on every update.

Reports near Exit A

Crowd risk0.10

Hazard risk0.05

Exit A

Selected

Distance: 32 m
Crowd risk: 0.10
Hazard risk: 0.05
Route cost: 49.4

Exit B

Rejected

Distance: 51 m
Crowd risk: 0.18
Hazard risk: 0.12
Route cost: 90.7

route cost = distance + hazard + crowd + uncertainty

Per corridor: length × (1 + 4·hazard + 3·crowd + 1·uncertainty). Blocked corridors are removed. Solved with Dijkstra on this floor; A* with a straight-line heuristic on larger imported maps.

Shared world model · CrisisGraph

One shared understanding of the emergency.

Every JeevaGrid phone keeps its own copy of CrisisGraph: places, the corridors between them, and what is known about each. Dhwani, CrowdPulse and PathMesh all read from it and write to it.

Incoming events

Waiting for events from the mesh.

CrisisGraph v2 · 3/3 nodes agree

Graph structure

CRISISGRAPH

├── Locations

│ ├── Room G

│ ├── Corridor B–C

│ ├── Junction C

│ ├── Exit A

│ └── Exit B

├── Edges

│ ├── passability

│ ├── hazard risk

│ ├── crowd risk

│ └── confidence

└── Entities

├── devices

├── acoustic targets

├── crowd states

├── hazards

└── responders

Information goes stale. JeevaGrid knows how stale.

Every observation carries its confidence, source, timestamp, age and the number of phones that corroborate it. Recent observations count for more. Old ones fade unless another phone confirms them.

confidence(t) = confidence₀ × e^−λΔt

new event95%

after 30 s81%

after 2 min51%

Live observations with decaying confidence
Observation	Source	Age	Nodes	Confidence	Action

Possible human acoustic event

Audio classifier: 91%
Cross-node agreement: 3 / 3
Localisation quality: 83%
Repeated event: YES
Combined confidence: 88%

Uncertainty is always on screen

JeevaGrid only uses graded words. A person upgrades a report; the system never does it alone.

unverified
possible
likely
human-confirmed

Live scenario

A building, a collapse, no internet.

Seven steps, one shared model. Watch three phones sense, fuse, decide and guide, with no cloud involved at any point.

Phones advertising0 nodes connectedCloud requests: 0InternetOffline

Loading building model

Press launch to start the scenario

SENSE
FUSE
DECIDE
GUIDE

Internet unavailable

3 JeevaGrid phones are in the building

A partial collapse has cut power and the cell tower is overloaded. A civilian stands at junction B. Somewhere in Room G, someone is knocking.

Event log2 entries

10:41:10INTERNET unavailable · cellular degraded
10:41:103 JeevaGrid phones online · advertising

10:41MESH 3

Turn right

one long pulse

vibration pattern · 320 ms

Guidance you can feel.

In smoke, darkness, panic or noise, staring at a screen is unsafe. JeevaGrid encodes each instruction as a distinct vibration so people can navigate with the phone in their pocket.

On an Android phone these buttons really vibrate.

One app. Four roles.

Every phone runs the same software. What it shows depends on what the person holding it needs right now.

“Where should I go?”

Giant direction arrow
Distance to exit
Hazard warning
Haptic cues
Optional voice directions

10:41MESH 3

Route changed

Turn right

at junction C · Exit B · 51 m

Avoid Exit A

Congestion reported 12 s ago

Haptics on Voice on

No cloud. No central server required.

Phones find each other over Bluetooth LE, then move to faster peer links: Nearby Connections, Wi-Fi Direct or Wi-Fi Aware. Events spread by gossip: each phone forwards what it hasn't seen yet, until the time-to-live runs out.

Discovery
BLE advertising
Transport
Nearby · Wi-Fi Direct · Wi-Fi Aware
Forwarding
Gossip, duplicate-suppressed
Consistency
Versioned events, merge on reconnect

Graceful degradation instead of total failure.

InternetOffline

{
  "eventId": "evt_7f50",
  "source": "N-C",
  "timestamp": "10:42:10.402",
  "ttl": 4,
  "confidence": 0.91,
  "version": 4
}

Every event carries an ID, source, timestamp, TTL, confidence and version. Duplicates are dropped by ID. A phone that rejoins asks for everything newer than its last version.

Share intelligence, not surveillance.

Phones run inference on-device. Raw audio and video stay on the phone that captured them wherever possible. Only compact semantic events cross the network.

Stays on the phone

RAW VIDEO

RAW AUDIO

8 MB

per phone, every few seconds

Crosses the network

density=0.82
direction=E
confidence=.91

2 KB

about 4,000 times smaller

Less bandwidth
More privacy
Lower network load
Works offline
Faster local decisions

The smartphone is not the interface. It is the infrastructure.

Different emergencies, different priorities.

JeevaGrid shifts battery, compute and attention toward the module that matters most for the situation.

Dhwani: 10
PathMesh: 8
CrowdPulse: 4

Primary purpose. Locate possible trapped people and guide responders to them.

Inside a JeevaGrid node.

Every phone runs the full stack. Select a layer to see what it does and what it produces.

CIVILIANRESPONDER

Semantic event layer

Model outputs become compact, typed events with confidence and a timestamp: a few hundred bytes instead of megabytes.

{ "type": "ACOUSTIC_TARGET", "zone": "room_g",
  "class": "human_distress", "confidence": 0.88 }

Built on what Android already has.

MOBILE: KotlinJetpack ComposeAndroid native APIs
EDGE AI: LiteRT / TensorFlow LiteMediaPipeLightweight custom DSP
AUDIO: AudioRecordDSPCross-correlationTDoA
VISION: Person detectionTrackingOptical flowHazard recognition
NETWORK: Nearby ConnectionsWi-Fi DirectWi-Fi AwareBLE
DATA: Room / SQLiteLocal CrisisGraph
ALGORITHMS: DijkstraA*TDoA multilaterationSensor fusionConfidence decayEvent reconciliationDistributed gossip

AI where perception is needed. Deterministic algorithms where correctness matters.

This split is deliberate. JeevaGrid is not an LLM wrapper. Models interpret noisy sensor data; everything that decides where a person walks is inspectable, repeatable code.

Learned models

Classify acoustic events
Identify people and obstacles
Understand local visual context

Deterministic code

Route optimisation
Graph propagation
TDoA geometry
Confidence calculations
Event reconciliation

When a subsystem fails, the product keeps working.

Each module has a ladder of fallbacks. Knock out the active tier and see what takes over.

DHWANI

BESTTDoA localisation
FB1Relative region estimation
FB2Multi-device acoustic consensus

CROWDPULSE

BESTTracking + optical flow
FB1Person density estimation
FB2Peer density + IMU

PATHMESH

BESTFully dynamic AI-fed graph
FB1Manual hazard marking + dynamic routing

Useful wherever phones already are.

Resilient, supplemental emergency intelligence, using devices already present at the scene.

JeevaGrid doesn't replace professional emergency systems, responders or dedicated rescue hardware. It fills the gap in the first minutes, and in places those systems can't reach.

Disasters

Earthquakes
Building collapse
Fires
Floods

Hard environments

Industrial sites
Underground spaces
Remote rescue

Crowds

Concerts
Railway stations
Religious gatherings
Stadiums
Campuses
Evacuation drills

What we're building, and what comes next.

01Now
City Battle MVP
- 3-device peer network
- CrisisGraph
- Offline event exchange
- Person-density CrowdPulse
- Dhwani event consensus
- TDoA experiment
- Hazard marking
- Dynamic PathMesh routing
- Civilian and responder modes
- Haptic guidance
02Next
Grand Finale
- Robust acoustic calibration
- Multi-hop event propagation
- Better crowd-flow estimation
- Distributed SLAM
- Automatic indoor mapping
- Smarter sensor fusion
- Responder coordination
- Offline map import
03Later
Future
- LoRa gateways
- Drones
- Wearables
- Emergency-service integrations
- BIM / floor-plan ingestion
- Temporary disaster network deployment
- Interoperability with rescue hardware

Team Starfire

Three engineers who build across AI, Android, networking and signal processing.

Shoaib Sadiq Salehmohamed
Team Leader
Focus
System architecture, AI, Distributed systems, Integration
Background
- Smart India Hackathon 2025 Winner
- Paytm × Sarvam × HackCulture Build for India Winner
- Autonomous systems
- Local and open-source LLM research
- AI reliability
- Edge computing
Hansika Aredla
Member
Focus
Android, Product experience, Application engineering, UX
Anoosh Dhamshetty
Member
Focus
Networking, Sensing, Integration, Testing

Why Starfire

AI / ML
Android
Edge computing
Computer vision
Distributed systems
Signal processing
Networking
Graph algorithms
Autonomous systems
Hardware–software integration

We're used to hackathon conditions: turning ambitious, multi-domain ideas into prototypes that actually run.

Loading building model

When infrastructure disappears, intelligence shouldn't.

JEEVAGRID

Distributed Offline Emergency Intelligence

Explore system architecture

The phones were already there. JeevaGrid makes them work together.