LIKAS: An offline disaster companion for the Philippines, powered by on-device Gemma 4 E2B

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

LIKAS — your companion when calamity strikes the nation.

Likas, in Filipino, means nature — and also to evacuate. LIKAS is an offline, AI-powered disaster companion that helps Filipinos get to safety when nature turns against them.

In the Philippines, the disaster is the connectivity outage. The 2024 typhoon season alone brought six major storms in 30 days; the country averages ~20 typhoons, 100–150 felt earthquakes, and recurring volcanic activity yearly, with 74% of the population in disaster-prone areas. When a typhoon makes landfall or a fault ruptures, cell towers fail and the internet drops at the exact moment a family needs to know where the nearest evacuation center is and how to reach it. Every "disaster app" I tried assumed the one thing never true in a disaster: a working network.

LIKAS is a React Native app (Android/iOS) that turns a phone into a self-contained survival tool. Maps, evacuation centers, a pre-computed OSM pedestrian routing graph, NDRRMC/PAGASA/PHIVOLCS protocols, and a fine-tuned Gemma 4 E2B model are bundled at install time. Zero network calls at runtime — by mandate, not as a fallback.

The centerpiece is an AI assistant that deliberately does not behave like a chatbot. A 2B model that free-forms safety advice is a liability; one that routes intent to grounded data is an asset. So LIKAS uses Gemma 4 as a task-specific tool-dispatcher: every turn it emits exactly one JSON envelope — a tool call or a spoken reply, never prose around it.

One real query, end to end: the user types, in Taglish, "Saan kami pwedeng lumikas? May aso at lola ako" ("Where can we evacuate? I have a dog and a grandmother"). Turn 1 — the model emits {"action":"tool","name":"route_to_nearest_evacuation","args":{}}. The app resolves this entirely on-device: Dijkstra over the pedestrian graph finds walkable routes, then a weighted scorer ranks centers (distance·0.4 + pwd·0.3 + pet·0.2 + capacity·0.1). Turn 2 — fed the result, the model produces the final answer personalized from the on-device profile: it surfaces the pet-friendly, PWD-accessible center because the question named a dog and a lola, in Taglish. No byte left the phone.

Four tools ground every safety-critical answer in authority data, not the model's parameters:

• get_protocol quotes NDRRMC/PHIVOLCS/PAGASA steps verbatim (inventing safety steps is forbidden)
• route_to_nearest_evacuation does offline, profile-aware routing
• find_nearby is offline POI search (hospital, school, gym, multi-purpose hall, covered court)
• get_user_profile supplies on-device personalization (conditions, companions, meeting points)

Demo

📺 Video walkthrough: https://www.youtube.com/watch?v=kHHcDSyip-Q

Code

🔗 GitHub: https://github.com/JpCurada/likas

Supporting artifacts (all public):

Resource	Link
Training Dataset	https://www.kaggle.com/datasets/jeypiic/likas-ai-datasets/
Fine-Tuning Notebook (Unsloth)	https://www.kaggle.com/code/jeypiic/likas-fine-tuning-gemma-4-e2b-with-unsloth
GGUF Export Notebook	https://www.kaggle.com/code/jeypiic/likas-with-llama-ccp-llama-rn-gguf-export
Sample Prompts Notebook	https://www.kaggle.com/code/jeypiic/likas-sample-prompts-for-the-fine-tuned-model
Fine-Tuned Model (GGUF)	https://huggingface.co/jpcurada/likas-gemma4-e2b-gguf
LoRA Adapter	https://huggingface.co/jpcurada/likas-gemma4-e2b-lora

How I Used Gemma 4

I chose Gemma 4 E2B — the 2B effective-parameter edge variant — because the entire premise of LIKAS is that the model has to live inside a phone that just lost signal. The 4B and 31B variants would have been more capable; they would also have been impossible. E2B was the only flavor where a Q4_K_M quantization (~1.8 GB) fits comfortably in the RAM budget of a mid-range Android phone someone already owns, alongside MapLibre, the pedestrian graph, and the OSM POI data. The judges' question — "show us why your model was the right tool for the job" — has a sharp answer here: the disaster is the connectivity outage, so the model must run where the disaster is, and only E2B can.

But putting a 2B model in the safety-critical path required two design moves that I think are the most interesting things about this submission:

1. Fine-tuning Gemma 4 E2B for one specific, life-or-death task — not as a better chatbot. Using Unsloth's LoRA pipeline I trained Gemma 4 E2B against the same 9-rule system prompt the app ships: verbatim protocol quoting, mandatory tool use for safety/evacuation queries, profile personalization, off-topic refusal, same-language response across English / Filipino / Taglish. Because training and inference share one prompt verbatim, there is zero distribution shift between the evaluation notebook and the phone. The dataset was the hard part — v3 generated 692 conversations but only ~30% of assistant turns were unique (the verbatim-quote rule mapped many paraphrased questions to the same protocol texts). The signature was unmistakable: train loss collapsed 3.47→0.31 in 24 steps while validation barely moved. The fix was a rule-preserving paraphrase generator whose extract_rules() pass parses every NDRRMC/PHIVOLCS step out of the source and asserts its presence in every variant — so surface form varies (terse / numbered / urgent / reassuring) without ever dropping a safety instruction.

2. Running Gemma 4 on-device via llama.cpp with a GBNF grammar around it. The fine-tuned model is quantized to Q4_K_M GGUF and runs entirely on-device through llama.rn (^0.12.0) — the full llama.cpp engine in-process on the phone (n_ctx: 4096, n_threads: 4, full GPU-layer offload, no server). Sampling is locked low (temperature 0.4): a disaster dispatcher should not be creative. Every turn must be exactly one parseable envelope, on a phone, with no server to retry against. Prompting alone can't guarantee that — so the decoder is constrained by a GBNF grammar built from the live tool registry: one speak production or one of four tool productions, with tool names and argument enums baked in as literals. The decoder physically cannot emit an invalid tool name or a half-formed object.

A grammar guarantees shape, not choice. The fine-tuned model is reliable but inconsistent — for an evacuation question it sometimes emits the clean tool call and sometimes narrates the tool inside a speak reply, leaving nothing on the map at the exact moment it matters most. So the dispatch loop is wrapped in a deterministic rescue: if the user's message unambiguously asks for evacuation or a nearby POI and the matching tool never ran, the app invokes that tool itself and pushes the route/pins to the map regardless of which shape the model chose. There is also a full no-LLM fallback: if the model fails to load or the battery is below 15%, the same keyword router still resolves evacuation and POI queries against the on-device data. The grounding survives even a dead model.

This separation is the heart of my use of Gemma 4: native function calling on the edge keeps a small model honest. Gemma owns what it is good at — parsing messy, code-switched Filipino intent and producing fluent, personalized replies. The device owns what must never be hallucinated — routes, distances, protocol text, personal data. The model never recalls a safety step; it fetches one. That is what makes a 2B model trustworthy enough to put in front of someone mid-evacuation.

Everything is verifiable: Likas/src/services/aiAssistantService.ts runs the dispatch loop, aiGrammar.ts builds the GBNF from the tool registry, Likas/scripts/build_dataset_v4.py contains the overfit numbers, and notebooks/Likas_Sample_Prompts.ipynb reproduces the exact production prompt and grammar at the same n_ctx=4096 — so on-device behavior is inspectable without building the app.