All Projects
·4 min read

CrashFNOL: AI-Powered Crash Reconstruction for Insurance Reports

Android PoC that generates professional FNOL (First Notice of Loss) insurance reports by combining simulated telematics data with real-time location, weather, and traffic context, processed on-device via MediaPipe Gemma.

AndroidKotlinMediaPipeGemmaOn-Device AIInsurance TechPDF GenerationJetpack Compose
View on GitHub

What this is

This is an add-on feature, not a standalone crash detection app.

Apps like Life360, Zendrive, Cambridge Mobile Telematics, and OtoZen already detect when a crash happens using accelerometer data and phone sensors. The moment they detect a crash is exactly where this module picks up. It takes the crash event data (speed, location, timestamp) and generates a complete insurance FNOL report automatically.

Think of it as the post-crash documentation layer that any telematics or safety app could plug in after their crash detection fires.

What it does

Once a crash event is received, the driver types 2-3 lines describing what happened. The app handles everything else:

  1. Pulls in 40 seconds of simulated telematics data (GPS, accelerometer, gyroscope, 7.5G collision event)
  2. Enriches it with real context: address via Nominatim, nearby traffic signals via Overpass API, weather via Open-Meteo
  3. Builds a structured prompt and runs it through Gemma 3.1B on-device
  4. Generates a multi-page PDF FNOL report the user can open immediately

No cloud AI. No API keys for inference. The entire reconstruction pipeline runs locally on the device.

Architecture

Crash event received (from detection layer / simulated in this PoC)
        +
EnrichmentService (Nominatim + Overpass + Open-Meteo APIs)
        +
User statement (2-3 lines)
        ↓
PromptBuilder → structured LLM prompt
        ↓
LlmEngine → MediaPipe Gemma 3.1B (on-device inference)
        ↓
PdfHelper → multi-page formatted PDF
        ↓
FnolViewModel → FnolScreen (Compose UI)

Processing stages shown to the user in real-time: Starting → Reverse geocoding → Fetching OSM features → Fetching weather → Building prompt → Calling LLM → Generating PDF → Done

Tech Stack

| Layer | Technology | |---|---| | Language | Kotlin 2.0.0 | | UI | Jetpack Compose + Material 3 | | On-device LLM | MediaPipe Gemma 3.1B quantized INT4 (tasks-genai 0.10.23) | | Networking | OkHttp3 4.11.0 | | PDF Generation | Android built-in android.graphics.pdf | | Async | Kotlin Coroutines (Dispatchers.IO) | | Architecture | MVVM |

External APIs (all free, no auth required)

| API | What it provides | |---|---| | Nominatim (OpenStreetMap) | Reverse geocoding: lat/lon to human-readable address | | Overpass API | Traffic signals, pedestrian crossings, road features within 80m of crash | | Open-Meteo | Historical weather at crash location and time |

Simulated Telematics (FakeTripProvider)

In this PoC, the telematics data is simulated to demonstrate the pipeline:

  • Location: Downtown Los Angeles (34.0522, -118.2437)
  • Duration: 40 seconds at 1 sample per second
  • Profile: 20 m/s initial speed, right turn at t=15s, hard brake at t=25-27s (20 to 12 m/s), collision at t=30s at 7.5G impact force
  • Realistic accelerometer and gyroscope (yaw rate) values simulated for each maneuver

In a real integration, this would be replaced by actual sensor data from the host app's crash detection SDK.

PDF Generation

PdfHelper generates multi-page reports with automatic page breaks, word-wrapped text, and proper section formatting:

FIRST NOTICE OF LOSS REPORT
Motor Vehicle Accident - AI Reconstructed

CLAIMANT STATEMENT
[User input]

ACCIDENT ANALYSIS & RECONSTRUCTION
- INCIDENT INFORMATION (date, time, location, weather)
- VEHICLE DATA (speeds, impact force, maneuvers)
- ACCIDENT RECONSTRUCTION (AI narrative)
- CRITICAL REMARKS

Text cleaning strips markdown artifacts from the LLM output before rendering to PDF.

Key Implementation Details

  • Graceful degradation: Each API call is wrapped in try-catch. If Nominatim fails, the location field is left blank and the pipeline continues rather than stopping
  • FileProvider: PDFs stored in app-private storage and shared to the system viewer via FileProvider
  • Coroutine structure: All network and inference work runs on Dispatchers.IO, UI updates via StateFlow
  • Prompt engineering: The prompt gives Gemma an exact format to follow, which makes PDF generation deterministic and avoids free-form output that is hard to parse
  • Model: Gemma 3.1B INT4 pushed to /data/local/tmp/llm/ via ADB before running

What I Learned

  1. Free public APIs give you a lot. Nominatim + Overpass + Open-Meteo together produce rich real-world context with zero cost and no sign-up.
  2. Prompt format is everything for structured output. Giving the model an exact section template produces reliable, parseable output. Free-form prompts produce free-form chaos.
  3. Multi-page PDF in pure Android is very capable. No third-party library needed for professional-looking documents.
  4. The interesting part is the enrichment layer. Knowing that a crash happened at an intersection with a traffic signal changes the narrative significantly compared to just knowing GPS coordinates.
← All ProjectsShare on LinkedIn