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 the phone’s motion sensor, sampled 10 times a second. Rapid acceleration — same motion-sensor data, scored right 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 usage-based (UBI) and behavior-based (BBI) insurance policies actually grow — do not run on reference hardware. They run on budget Android OEMs. These OEMs ship aggressive process killers, custom battery-saving modes, 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 updates suddenly arrive every 3-7 minutes instead of once a second. The trip route turns into a rough polygon instead of a smooth line. Distance and speed estimates go bad.
Root cause: calling stopUpdatingLocation() while the app is in the background. iOS reads that as “this app is done needing location” and quietly revokes the background permission that was keeping GPS updates flowing — even though we ask for them again seconds later. Our fix: never stop the GPS stream while backgrounded. When we need higher or lower accuracy, we adjust the tracker that’s already running instead of restarting it. 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.
We layered several backup wake-up triggers on top of each other: iOS’s significant-location-change signal, and on Android, geofence exits plus activity-recognition transitions. Whichever one fires first, the SDK comes back online within 30-90 seconds of the next time the phone moves. Validated across 1,00,000 km.
User flies internationally, comes back to find their last 14 days of trips partially missing. The phone’s local trip database never got a chance to save its most recent writes to disk. Some trips uploaded as partial records.
We now save trip data to disk the moment every trip ends, instead of leaving it to sit in a buffer. Uploads are safe to retry — if the same trip gets sent twice, our backend recognizes it by its trip ID and only keeps one copy. We honestly admit: at 14+ days of buffered data, aggressive devices may still lose the last few trips. We surface a user-visible heartbeat at day 7 so this doesn’t go unnoticed.
The SDK’s core engine and the iOS/Android app layer talk to each other constantly across a language boundary. Under certain patterns, both sides end up waiting on each other and neither ever lets go — the SDK just hangs, with no log line and no crash. Trips stop uploading. Confirmed via device profiler traces (Mar 2026).
We found the exact cause — code on one side calling back into the other side while it was still mid-operation — and wrote a hard rule against it, enforced everywhere in the codebase: never call back into the other language while it’s still busy with you. Every place that rule applies is documented. No silent hangs since the fix shipped in March 2026.
Caught during a CPU check on our own driver app: 167-195% CPU at idle on iOS, 28% on Android. The cause was two looping animations plus a piece of app state that was re-rendering the entire dashboard on every tiny change.
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 motion-sensor and trip data. Detection thresholds and scoring weights get re-tuned against how your drivers actually behave.
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.