Offline Emergency Reference

The exploration

Most “offline-capable” apps are online apps with a cache and an apology. This exploration inverts the premise: what does it take to build software that is dead-reliable at the worst moment of someone’s day — a kitchen burn, a choking child, a hiking injury two valleys from signal? The requirements are brutally simple to state: open to usable guidance in under two seconds, from a cold start, in airplane mode, on a five-year-old phone at 8% battery. Everything else in the architecture is derived from that sentence.

There is no AI at runtime, by design. In an emergency, a plausible answer is a hazard; this product’s entire value is that its content is exactly what medical reviewers signed off, rendered exactly the same way every time. Reliability over cleverness is the thesis, not a compromise.

Requirements, stated as budgets

• Cold start to first procedure step: under 2 seconds on the reference low-end device, measured from icon tap, radios off
• Zero network dependency on any emergency path — no lazy-loaded images, no font fetches, no analytics call blocking anything
• Storage: a 150 MB ceiling per installed language, because an app this important gets deleted first when storage pressure hits
• Battery: near-zero background cost — no wake-ups, no location, sync only when charging and on Wi-Fi by default
• Interaction depth: any procedure reachable in three taps or fewer from launch

These are design budgets, not measured achievements — the point of the exploration is to find out what breaks first when they are enforced together.

Why offline-first is usually a lie

The failure modes hide in the seams. A bundled content set that quietly fetches its images. A database migration that runs on first launch after an update — during the emergency. A crash loop with no network to fetch the fixed config. A “helpful” update prompt modal in front of the burns procedure. This exploration treats every seam as an adversary: content ships in complete, self-contained versioned packs; a pack is either fully present and valid or not offered at all; updates apply by atomic swap with instant rollback to the last good pack; and the launch path renders from a precompiled index with no migration, no parsing of loose files, and nothing that can block on a lock.

Content architecture

Content is the product, so content gets the strictest engineering. Each pack is an immutable, signed bundle: procedures, illustrations, compiled search index, and a manifest carrying the medical-review version and applicable region. Devices sync opportunistically when online — diff-based, resumable, verified before activation — and the previous pack remains installed until the new one proves itself with a post-activation self-check.

1. Editorial draft procedures authored against a strict schema
2. Medical review clinician sign-off, versioned per region
3. Localization translation plus per-language medical re-review
4. Pack build compiled, signed, size-budgeted per language
5. Staged rollout device self-check before old pack is dropped
6. On-device immutable, atomic, offline forever after

Both amber steps are human sign-offs, and both are load-bearing: no pack ships any region or language without a named clinical reviewer for that version.

The localization pipeline problem

Translating first aid is not translation. Emergency numbers differ by country; defibrillator availability, ambulance response norms, and even recommended compression guidance revisions differ by region and by the guideline body a country follows. The pipeline therefore treats language and region as separate axes: a language pack carries the prose; a region layer carries numbers, legal notes, and guideline variants; and the medical re-review step is per combination that ships, not per source text. This is the most expensive decision in the concept and the least negotiable — a correctly translated procedure with the wrong emergency number fails the only test that matters.

The editorial-responsibility boundary

The sharpest design question is not technical: where does guidance end and medicine begin? The exploration’s rules are explicit. The app instructs only within established lay-responder first-aid guidance. Every procedure opens with the escalation decision — call emergency services first conditions rendered before any steps, not after. The app never triages beyond its content (“this is probably nothing” does not exist as an output), never doses medication beyond guideline lay instructions, and renders its review provenance — which body’s guidance, which version, reviewed when — one tap away on every procedure. When content and confidence run out, the screen says to call for help, in large type.

Interface under stress

Panic changes users. Motor precision drops, reading comprehension drops, and phones are held one-handed by people doing something else with the other hand. The interface budget follows: one-handed reach for all navigation, step-by-step mode with one instruction per screen in type readable at arm’s length, numbered voice-over of steps for hands-busy situations (recorded audio, not synthesis), a persistent emergency-call button on every screen, and high-contrast rendering that ignores the system’s dark-mode aesthetics in favor of legibility. Accessibility work here is not a compliance section; a stressed user is a temporarily impaired user, so the accessible path is the main path.

Where the cleverness is allowed to live

Banning AI at runtime does not ban it from the workshop. Off-device, models assist editors: consistency checks across translations, readability scoring against a plain-language target, and search-index synonym generation (“can’t breathe” must find choking) — all reviewed by humans before a pack builds. The runtime search itself is a deterministic compiled index with typo tolerance. Same skills, different side of the review boundary.

Prototype scope

Two languages, one region layer each, twenty procedures spanning the common household and outdoor emergencies, running on a deliberately old test device fleet. The build exists to answer engineering questions, not to ship: can the two-second budget survive real content volume, does atomic pack swap hold up across OS storage quirks, and does the three-tap depth rule survive twenty procedures’ worth of information architecture.

Evaluation plan

• Cold-start measurement across the device fleet, radios off, storage nearly full — against the 2-second budget
• Chaos drills: kill the app mid-update, corrupt a pack, downgrade the OS — the last good pack must always open
• Stress usability sessions: timed procedure retrieval under distraction load, one-handed
• Localization audit: every region layer checked against current national guidance by an independent reviewer
• Battery trace over a simulated month: background cost must be indistinguishable from zero

Risks and open questions

• Liability and regulation: health-adjacent guidance may trigger medical-device classification in some markets; legal review gates any release, and the answer may reshape the content boundary
• Review economics: per-language-per-region clinical sign-off scales cost linearly with reach; the honest ceiling on supported locales is unknown
• Update tension: guidance revisions must propagate fast, but aggressive sync fights the battery budget; “when charging” may be too slow for a critical correction
• Trust bootstrap: an unknown studio asking to be trusted in emergencies needs visible provenance — the reviewer trail may matter more than any feature

Delivery phases

1. Engineering spike: pack format, atomic swap, cold-start budget on the reference device
2. Editorial pipeline with clinical review partners; two-language pilot content
3. Stress-usability rounds and chaos testing; legal and classification review per target market
4. Region-layer expansion only as fast as review capacity honestly allows