This is a submission for the Gemma 4 Challenge: Build with Gemma 4
What I Built
A while back I was watching a documentary about disaster response teams during a major earthquake. What struck me wasn't only the destruction — it was also the communication breakdown. Cell networks were gone. And while voice radios were still working, they weren't enough.
Here's the thing about voice radio in a large-scale disaster: it works, until it doesn't. Twenty field teams radioing in simultaneously saturate the channel. Critical details get lost — wrong street names, garbled injury counts, conflicting reports about the same location. Every message requires a human on the other end to listen, interpret, and manually log what was said. And none of it can be automatically parsed, prioritized, or routed to the right team. A coordinator drowning in voice traffic can't act fast enough.
There's also a harder problem: some of the most capable mesh networks used in disaster response — LoRa and Meshtastic — are data-only. They don't carry voice at all. They exist specifically to move small packets of structured data across long distances with minimal power. They're incredibly robust in disaster conditions. But they cap at around 228 bytes per packet. You can't send an image over them. You can barely send a sentence.
That's where the real gap is. A responder standing in front of a collapsed building has critical visual information — how many people, what type of structural failure, what equipment is needed — that voice can't convey accurately under stress, and that existing data networks physically cannot carry as an image.
That planted a question I couldn't shake: what if a responder could photograph what they're seeing, and have AI distill it into something small enough to actually transmit?
CrisisLens is my answer to that.
It runs entirely on the phone in your pocket — no servers, no internet, no infrastructure of any kind. A responder photographs what they're facing: a blocked road, a structural collapse, an injured person. CrisisLens reads the device's live GPS coordinates, feeds the image to Gemma 4 running on-device, and distills everything into a structured JSON payload of 200 bytes or less — ready to broadcast over any LoRa or Bluetooth mesh network available.
The result looks like this:
{"loc":"12.8406,77.6784","type":"flood","sev":"crit","inj":2,"desc":"Road submerged 3ft","act":"avoid south entry","conf":"high"}
107 bytes. Precise GPS coordinates, incident type, severity, injury count, a scene description, a recommended action, and the model's own confidence in what it saw. Ready to travel over infrastructure that was built for the 1990s.
Stack: Gemma 4 E2B · LiteRT-LM · Kotlin · Jetpack Compose · Fully on-device · No internet required
But Why Can't a Human Just Do This?
A trained responder can fill a structured form manually — protocols like METHANE exist precisely for this reason. So it's a fair question.
The answer isn't that humans can't. It's that humans under acute stress don't. Standing in front of a burning building with people screaming is cognitively brutal. Fields get skipped. Street names get garbled. Injury counts come in as "maybe three or four." And structured reporting protocols only work if every responder has been trained on them.
CrisisLens exists for everyone else — the volunteer, the civilian, the off-duty nurse who happened to be there first. One photo. No training required. Consistent, parseable output every time. And the camera sees what stress makes you miss: a human might report one visible casualty; the model looking at the photo might catch two more people partially obscured in the debris.
There's also something the model does that no voice protocol can: it produces machine-readable output. A coordinator receiving 20 structured payloads can sort by severity in a spreadsheet. A coordinator receiving 20 voice messages is just drowning.
Demo
Code
How I Used Gemma 4
Why E2B
The model choice here wasn't a preference — it was a hard constraint that made everything else follow logically.
CrisisLens has to work when the internet doesn't. That eliminates every cloud API. The model has to run on the device a responder is already carrying. That eliminates every model too large for a phone. And it has to work for any responder, not just the ones with a $1200 flagship device.
The Gemma 4 E2B — a 2B effective parameter model built specifically for ultra-mobile and edge deployment — is the only model in the Gemma 4 family that satisfies all three constraints simultaneously. The 31B Dense model requires server-grade hardware. The E4B needs 8GB+ RAM, limiting it to flagship phones. The E2B runs on mid-range Android devices with 4GB+ RAM, and even on hardware as lean as a Raspberry Pi 5.
A rescue worker shouldn't need a $1200 phone to use this tool. E2B makes that true.
And crucially — the vision task here isn't complex reasoning. It's constrained categorization: classify a scene into one of six incident types, assign a severity level, count visible casualties, write a 60-character description. A well-prompted 2B model with a rigid schema handles this reliably. The constraint is the point — by removing open-ended generation and forcing the model into a fixed vocabulary, accuracy becomes a function of prompt engineering, not raw parameter count.
The model isn't a chatbot here. It's a translator — converting heavy visual data into lightweight, actionable intelligence that can physically travel over primitive radio networks.
The Problems I Actually Had to Solve
Building this exposed four problems that were harder than they looked.
Problem 1: Location Was Useless When Generated by the Model
The first version of CrisisLens asked the model to describe the location from the image. The outputs were accurate but useless in context: "urban ruins," "flooded street," "collapsed structure." In a disaster zone, everywhere looks like that. No responder can act on "urban ruins."
The fix was to remove location from the model's responsibilities entirely. The app reads live GPS coordinates from the device at the moment of capture and injects them directly into the payload — the model never touches the loc field. Coordinates like 12.8406,77.6784 are 15 characters, globally unambiguous, and work even when the entire scene looks like rubble. If GPS is unavailable after 10 seconds, the app falls back to "loc":"GPS unavailable" and still processes the image — the analysis is never blocked waiting for a signal.
Problem 2: Getting Gemma 4 to Output Consistent JSON
Gemma 4 is a generative model — it wants to explain, elaborate, and hedge. Ask it to analyze a disaster photo and it might produce a well-written paragraph. Ask it for JSON and it might return JSON wrapped in markdown code fences, or JSON preceded by a sentence, or subtly malformed JSON that breaks the parser downstream.
I solved this in two layers. The system prompt became a formal specification — not "return JSON" but a complete field-by-field schema with types, allowed values, character budgets, and an embedded example of correct output. Second, I added a validation-and-retry loop: if the response doesn't parse cleanly, the app retries up to three times with an increasingly constrained prompt before returning a fallback error state. In practice, the retry loop almost never fires — the schema prompt alone reduced malformed outputs to near zero.
Problem 3: Enforcing 200 Bytes Without Corrupting the Payload
Even with a tight schema prompt, the model occasionally produces valid JSON that runs slightly over 200 bytes. Naive truncation at byte 200 breaks the JSON structure entirely — which is worse than being slightly over limit.
I stopped treating this as a model problem and moved it to post-processing. The schema defines a hard character budget for every field. Critical fields — type, sev, inj, conf — are constrained to enums and integers, so they can never grow. Only desc and act are variable-length. If the total payload exceeds 200 bytes after generation, the app trims desc first, then act, always cutting at word boundaries to keep the text readable. The JSON structure is never touched. The result is always valid, always parseable, always under the limit.
Problem 4: Prompt Engineering for Disaster Scenarios
A generic prompt produces generic output. The first useful breakthrough came from realizing the model needed a closed vocabulary, not open-ended instructions.
Rather than asking Gemma 4 to describe what it sees freely, I gave it a constrained set of incident types (flood, fire, injury, blockage, structural, hazmat) and severity levels (low, med, high, crit). This forced the model to map visual input onto a vocabulary that receiving systems can act on directly — no interpretation needed on the other end. The conf field came from the same principle: if the model is uncertain about what it's seeing, the payload should say so explicitly, so responders can decide whether to verify before acting.
The difference between an open prompt and a constrained one was dramatic. Open prompts produced outputs that were accurate but unpredictable in structure. Constrained prompts produced outputs that were slightly less nuanced but completely reliable — and in an emergency, reliability beats nuance.