Every telematics program has detection and scoring. Most stop there. The score goes to a dashboard. The fleet manager looks at it when time allows. The driver never sees it. The behavior never changes. We built the part that comes after — and this page is exactly how it works, including where it breaks.
The loop has four stages. Each one depends on the one before it. If detection misses, the profile is incomplete. If the profile is incomplete, the coaching is wrong. If the coaching is wrong, the nudge arrives with no context. We’re going to walk through all four — including what we have today and what we’re building next.
Every trip, Sampark captures three signals without driver input or network connection. Phone use — identified by ML running on the device. Hard braking — flagged from 10 Hz IMU. Rapid acceleration — same IMU pipeline, scored alongside hard braking. At trip end, all three signals are packaged with GPS route data, encrypted on-device, and queued for upload.
A single hard brake is noise. A driver who hard-brakes in the top quartile for the fleet, uses their phone on 60% of trips, and accelerates aggressively after every stop — that is an actionable risk profile. We build it across trips, not just per trip. Per-trip scoring is live. Multi-trip behavioral profiling is in development with data from our first cohort.
The coaching handoff is the most manual part of the loop — and deliberately so. The fleet manager or insurer knows their drivers. We give them the data. They run the intervention. The data layer is live. Scored trip data is available via API and dashboard. The structured coaching workflow — ranked reports, trend lines — is what we are building next.
After every trip, Bodha Drive shows the driver their own pattern — phone use this trip, where the hard brakes happened, how this week compares to last. Most of the time, a driver who sees their own pattern changes it. No phone call from a manager required. Live now with our first cohort of drivers.
We built all four stages because we’ve run programs where only one of them existed — and watched the others fail quietly.
The behavior change loop requires detection that does not miss. The first thing every telematics vendor will show you is a graph. Detection accuracy 97%, battery impact under 2%, trip pickup within 30 seconds. The graph is real. What the graph hides is the device it was measured on.
The Indian, Southeast Asian, and Latin American driver markets — the ones where UBI and BBI policies actually grow — do not run on reference hardware. They run on budget Android OEMs. These OEMs ship aggressive process killers, custom doze policies, and app-lock layers stacked on top of stock Android. Telematics SDKs that work in the test lab quietly fail in production because the OS keeps killing them.
A telematics SDK that stops detecting trips after 10 minutes of force-kill is not a telematics SDK.
We know this because we ran telematics programs as the operator before we built a vendor. The 11 pm fleet-client call about missing trips was about a mid-range Android phone. The dropped UBI cohort in the Karnataka pilot was on a budget Android handset. The SDK worked in the demo. It didn’t work in the country.
So when we built Sampark, the test plan was inverted. Don’t prove it works on the easy phones — prove it works on the phones that quietly break everything else. Then prove it again on the easy phones, just to confirm we hadn’t over-fit. 1,00,000 km, 5 device families, 11 months. The kill clock below is what we measured. The fixes are what we shipped.
Measured Q1 2026 on factory-reset devices, default battery saver, no whitelisting. A “working” telematics SDK on the top four lines of this table needs to recover from being killed — not avoid it.
Below: how the 1,00,000 km broke down, the seven failure modes we encountered, and the calibration loop we run before any program goes live.
Bengaluru-to-Mysuru highway runs. Local Koramangala stop-and-go. Two-wheeler commutes through monsoon. Cold-boot detection tests at 6 am after 8 hours of force-kill. Every kilometre on a phone that real customers actually use.
Every entry below is a bug we hit in 1,00,000 km of testing. Vendors that pretend these don’t exist haven’t shipped at scale. We name them because the customer is going to hit them in the first month either way.
Each failure mode below is a way the loop breaks. Each fix is how we close it.
Trips end mid-drive. App force-stopped by the OEM’s background app manager. No event, no log line. The SDK simply stops existing.
Persistent foreground service with a low-importance notification, plus geofence and AR transition wake-ups. SDK recovers within 90 seconds of new motion even after a hard kill.
Driver installs app, grants location, never grants auto-start. SDK never restarts after device reboot. Cohort silently drops out at week one.
Install flow detects the OEM skin and walks the user through three OEM-specific toggles: Auto-start, Battery saver lockout, Background activity. Detection of grant state is verified before the SDK reports “ready.”
During a long highway drive, GPS callbacks suddenly batch every 3-7 minutes instead of 1 Hz. Trip route looks like a polygon. Distance and speed estimates corrupt.
Root cause is calling stopUpdatingLocation() while backgrounded — it destroys the iOS “foreground-established” assertion. We never stop the stream in background; accuracy and distance filter mutate on the live manager. Confirmed by 10-hour drive logs from Feb 2026.
User swipes the app off the recents tray. Most SDKs interpret this as a permanent “don’t run me” signal. No more trips that day — a 60% loss in trip volume in the first week of every program we ran.
Layered recovery: significant-location-change (iOS), geofence-exit + activity-recognition transitions (Android). SDK re-arms within 30-90 seconds of the next motion event. Validated across 1,00,000 km.
User flies internationally, comes back to find their last 14 days of trips partially missing. SQLite WAL never flushed. Some trips uploaded as partial records.
SQLite WAL checkpoint on every trip end. Idempotent upload with signed presigned URLs — backend dedupes by trip ID. We honestly admit: at 14+ days of buffered data, aggressive devices may still lose tail trips. We surface a user-visible heartbeat at day 7.
Rust calls into Kotlin/Swift, waits for a response. Kotlin/Swift, mid-callback, calls back into Rust. Bridge deadlocks. SDK hangs silently. Confirmed via Perfetto traces (Mar 2026).
Never .await platform callbacks from UniFFI async. Always runtime.spawn(). Android resumes via withContext(Main). Documented in our internal “UniFFI async safety rules.”
Caught during CPU regression in our own driver app: 167-195% CPU at idle on iOS, 28% on Android. Two repeating animations + an observable that re-rendered the entire dashboard.
Rule across all our software: zero repeating animations at idle. Live trip indicator pulse is the only allowed loop. Both platforms now show 0% idle CPU. We share this rule with integrators because it’s easy to violate accidentally.
Our 1,00,000 km is the floor, not the ceiling. Every program runs through a four-stage calibration loop against your fleet, your geography, your driver mix — before a single policy goes live.
Your top 6 device families, ranked by share. We confirm coverage and flag any OEM we haven’t certified yet.
100-200 drivers, 7 days. We pull anonymised raw IMU and trip metadata. Detection thresholds and scoring weights re-tuned against actual behaviour.
We review every dropped trip, every battery complaint, every false-positive event. Fixes ship the same week. Calibration sign-off before policy go-live.
Device share shifts. New OEM updates ship. Driver mix changes. We re-tune at quarterly cadence and notify you of any envelope changes.
First conversation is 30 minutes with the engineer who’d own your integration. Bring your device list, your geography, and your timeline. We’ll tell you what the first 90 days look like for your specific program — and we’ll be honest about what isn’t ready yet.
Book the call →If we’re not the right fit, we’ll tell you who is. No follow-up sequence.