Gemma Soteria: QR-First Chemical Emergency Guidance for Plantation Workers

Subtitle: A Gemma 4 powered mobile app with benchmarked SDS grounding, controller-gated cloud guidance, multilingual worker flow, and in-app offline emergency backup.

Problem and Method

Plantation chemical exposure is not a good moment for a generic chatbot. A worker may be in a remote or hilly area, under time pressure, with weak connectivity and a language barrier. The worker does not need a long conversation; they need the fastest safe path from chemical identification to immediate first-aid actions.

We did not start by building the app. First, we created a public plantation chemical first-aid benchmark dataset: https://huggingface.co/datasets/ImayaYogi/plantation-chemical-first-aid-benchmark. The benchmark covers emergency-response scenarios across English, Malay, Bangla, and Bahasa Indonesia, with LLM-judge QC used to check generated cases, expected answers, and scoring behavior.

That benchmark became the go/no-go gate. We evaluated Gemma 4 in two modes: without SDS context, and with SDS-grounded context. If the model had not performed well enough, the next step would have been fine-tuning. Instead, the strict Phase 6 evaluation showed a strong grounded lift:

• baseline average hybrid_total_100: 38.582
• grounded average hybrid_total_100: 92.008
• absolute gain: +53.426

So we kept the base Gemma 4 model and moved to application engineering. The key lesson was that grounding, not generic model fluency, was the main performance lever.

Worker Flow

Gemma Soteria is intentionally narrow: plantation chemical exposure first aid only. It is not a broad SDS assistant, PPE recommender, general medical assistant, or “ask anything” chatbot.

The app starts with language selection, then chemical identification. The primary path is QR-first: scan the chemical QR, resolve it to a known catalog item, lock the chemical, then ask what happened. Manual chemical selection remains available because labels get dirty, QR codes may fail, and camera permissions can break.

The Android QR path has been proven on a real phone: scan Roundup / Glyphosate, lock the chemical, enter “spray went in my eye,” and receive a full guided response. Responses are rendered as emergency cards, not chat transcripts: incident summary, immediate actions, do-not-do guidance, escalation, response mode, and evidence basis.

Architecture and Gemma 4 Use

The online path uses a thin backend gateway rather than calling the model server directly. The app talks to routes for health, catalog, QR resolution, and emergency response generation. This keeps the mobile app thin and isolates model-serving and controller logic from the UI.

Gemma 4 is used inside a controlled response pipeline, not as a freeform chatbot. The chosen architecture is Family-Aware Dual Path with Slot Verification and Fallback Release Gate. Gemma helps with incident normalization and response composition, while deterministic control surfaces check required safety slots and decide what can be released.

The controller can emit:

• full_guided_response
• guarded_minimum_response
• guarded_escalate_now

This matters because plain grounded chat can still over-answer. If the family is strong, confidence is high, and required slots are satisfied, the system can release fuller guidance. If not, it deliberately downgrades to guarded guidance rather than producing a confident but unsafe answer.

Online / Offline Product Split

The final active split is honest:

• Online: direct cloud full-response path.
• Offline: on-device Offline Emergency Mode for guarded emergency guidance.

I use “Offline Emergency Mode” deliberately: it is a real on-device model path, but it remains guarded rather than pretending to be a full offline SDS-grounded assistant.

The cloud path remains the primary judge/demo path because it is the strongest validated response engine. The on-device offline model exists for the plantation connectivity problem: when the backend is unavailable, the app can provide limited local emergency guidance. It does not claim full offline SDS-grounded reasoning. It gives immediate actions, do-not-do guidance, and escalation, or stops honestly if safe classification is not possible.

We explored an earlier online local-first quick-card flow, but it is not the current behavior. Local latency and response quality made direct cloud the better online path.

In-App Offline Backup

The on-device offline model (google/gemma-4-E2B-it running through the Android Cactus native runtime) is still not bundled inside the APK, but the app now supports in-app offline emergency backup setup. A worker can install the APK, use the cloud path immediately, and optionally tap “Download backup on Wi‑Fi.”

The offline download flow is non-blocking: the app remains usable while the download runs. The UI shows progress percentage, then moves through verification and install states. Offline backup is marked ready only after download, SHA-256 verification, unpack/install into the runtime path, and local readiness checks succeed.

Multilingual Reality

English alone is not enough for plantation use. The app supports English, Malay, Bangla, and Bahasa Indonesia in-session. Language affects status banners, readiness text, manual recovery path wording, incident labels, loading/error states, response labels, and offline backup wording.

QA covered online and offline flows in all four languages. English was strongest. Malay and Bahasa Indonesia were coherent and usable. Bangla was meaningful and usable, but less polished.

Why These Choices Were Right

Grounding came first because evaluation proved it was the main performance lever. The controller was added because safety-critical guidance needs release control, not just fluent generation. QR-first entry reduces chemical ambiguity. Manual recovery path makes the field flow resilient. The thin backend keeps mobile independent from model-serving complexity. Direct cloud stayed primary because it is the strongest validated path. Local Gemma is limited to guarded offline fallback because poor connectivity is real, but full offline SDS-grounded guidance would be an overclaim. In-app backup provisioning makes that fallback practical without blocking the online experience.

Limitations

This is not a broad SDS/PPE assistant. Offline mode is guarded and limited, not full SDS-grounded guidance. The on-device offline model remains separate from the APK. Offline response may be slower than cloud. Multilingual behavior is real but not equally polished across languages. The current demo should use the strongest validated flows, not every benchmark family.