Driver safety has to run on the phone in real time; the cloud should receive JSON alerts and telemetry—never a live video feed.

Corazor Technology designed and built Saarthi end to end: a cross-platform driver monitoring and road-safety product for commercial fleets. Saarthi runs real-time safety intelligence—fatigue, distraction, microsleep, and sleep detection—entirely on the driver's phone, while fleet operations sync through governed cloud APIs. No live video ever leaves the device during monitoring.

Corazor delivered a four-repository production architecture: a Flutter mobile app for on-device detection, a unified backend for fleet APIs, an ML and web reference stack, and an admin model control plane. The result is a field-viable driver-safety platform on a single iOS and Android codebase, engineered for the thermal, latency, and privacy realities of a real truck cab. See our AI development & automation service for how we ship production AI.

About the Client

Saarthi serves the transportation and fleet-safety market. It combines real-time driver monitoring—fatigue, distraction, microsleep, and sleep—with road-condition intelligence drawn from vehicle IMU, GPS, and optional on-device road-vision models. Target buyers are fleet operators and commercial driving programs in India and abroad, where missed fatigue events create real liability and over-alerting erodes driver trust.

The Challenge

Putting driver-safety AI into drivers' hands is not a mobile-wrapper problem—it is a systems problem. Continuous camera inference plus 50 Hz IMU sampling is thermally intensive on a phone mounted in a hot cab. iOS restricts background camera access, and dual-camera road vision requires explicit multi-camera design. Drivers need sub-second alerts and offline resilience on unreliable networks. And safety detection has to stay reliable at real-world frame rates and sample counts, where calibration and model behavior fail in ways that never show up in a browser demo.

Underneath sat an architectural question that reopened privacy, latency, and cost debates on every pilot: what must run on the device versus in the cloud? Without a clear on-device versus cloud-JSON boundary—covering onboarding (face login and Indian driving-licence OCR), real-time ML, session APIs, and road ingestion—the product could not scale past a demo.

The stakes were sharp: a safety product that misses events is a liability, and one that cries wolf gets switched off. Scope and quality gates had to be defined before scale, not after.

"Driver safety has to run on the phone in real time; the cloud should receive JSON alerts and telemetry—never a live video feed."

Corazor Editorial

AI Product Engineering

❞

Why Corazor

Saarthi chose Corazor for outcome ownership across build, audit, and production readiness—one accountable team spanning Flutter mobile, backend consolidation, ML parity, Azure integrations, and deployment documentation, rather than disconnected component handoffs. The engagement demanded genuine AI and platform depth: on-device computer vision, TensorFlow Lite conversion, temporal ML, Indian driving-licence document OCR, and batch road analytics. Milestones were tied to outcomes, scope was governed before scale, and the handover was built so internal teams could run it—not demo code that fails in a moving vehicle. Explore our services across build, audit, and compliance.

Our Approach

Discovery and architecture. We defined the system boundaries first: WebSocket topology, the calibration state machine, sensor-fusion rules, identity policy, driving-licence paths, and data collections. A key decision anchored everything—treat a Python pipeline as the behavioral reference, and have mobile port the decision core deterministically while moving inference to the edge. That gave us provable parity between platforms instead of per-platform re-tuning.

Scope governance across four repositories. The Flutter mobile app owns on-device driver monitoring, alerts, identity, and road IMU capture. A unified FastAPI backend owns auth and driving-licence onboarding, sessions, alerts, and the road APIs. An ML and web reference stack in Python holds the server pipeline, demo, and training scripts. An admin control plane owns the model registry, the road-roughness (IRI) engine, and TensorFlow Lite conversion.

Explicit trade-offs and deferrals. We chose MobileFaceNet in TensorFlow Lite for on-device identity with clear re-enrollment rules, and documented the parity path to heavier server-side recognition. Geometric distraction detection shipped on mobile first, with an LSTM temporal model deferred but specified. Dual-camera road vision and background monitoring were explicitly placed on the roadmap rather than smuggled into v1 as surprises. Read our guide on building an AI MVP for the same scope-first discipline.

The Solution in Detail

The on-device safety loop: the front camera feeds MediaPipe facial landmarks into a Dart decision core that computes PERCLOS, eye- and mouth-aspect ratios, distraction duration, and yawn and head-nod cues, then fuses them with a strict priority order—microsleep over sleep over distraction over fatigue—before firing two-tier audio, haptic, and text-to-speech alerts. MobileFaceNet in TensorFlow Lite handles event-driven identity re-verification. The IMU gates alerts on rough roads to suppress false positives, and GPS geotags every cloud alert. Crucially, no live video is uploaded during monitoring.

The cloud plane: MongoDB stores drivers, sessions, and alerts; Azure Blob Storage ingests raw IMU chunks; Azure Document Intelligence performs driving-licence OCR at onboarding; and a Kubernetes-hosted gateway serves the ML and API surface. The backend was consolidated so the mobile app talks to a single origin for auth, alerts, and road ingestion behind one service contract.

Road-safety intelligence, in parallel: 50 Hz IMU and GPS data is captured in 60-second chunks and processed admin-side into a road-roughness index, with optional pothole and crack detection via YOLO models converted to TensorFlow Lite—kept off by default until dual-camera capture is verified on iOS.

Quality and risk controls: dual-modality identity uses margin thresholds to prevent false association; critical alerts are blocked on low-quality or occluded frames; the admin registry is the single source of truth for models; and heavier capabilities like on-mobile temporal models and background monitoring were deliberately deferred from v1. Parity unit tests keep the Dart and Python decision logic in lockstep.

Results & Impact

Corazor delivered a field-viable driver-safety platform on a single Flutter codebase spanning iOS and Android, with a complete flow from login through driving-licence onboarding, calibration, and live monitoring. Safety detection runs on-device with deterministic parity to the Python reference, so behavior is consistent and debuggable across platforms. The mobile app talks to one consolidated backend origin instead of a fragmented set of services, and an admin control plane governs models and road analytics without adding driver-facing noise.

Just as important, the platform ships with honest operational boundaries: documented limits on calibration, background monitoring, and dual-camera road vision, plus enterprise-ready data paths through Azure Blob Storage and Document Intelligence. As Saarthi moves into fleet pilots, Corazor is instrumenting the outcomes that matter most—alert latency, false-alert rates, and detection reliability in the field—so future results can be reported with measured evidence. See our guide on AI integration in existing systems for related patterns.

Key Takeaways

Split the safety loop from the sync loop: run detection on-device, and send the cloud JSON alerts and telemetry rather than video. Port behavior, not just code: a shared decision core with identical thresholds beats re-tuning per platform. Govern scope with explicit deferrals, so temporal models, dual-camera road vision, and background monitoring are roadmap items, not v1 surprises. Give mobile a single backend origin for auth, alerts, and road ingestion. And design safety AI for real field conditions—thermal load, offline networks, and occlusion—because those are where demos quietly fail.

Conclusion

Building AI that must survive field conditions—not slide decks? Corazor Technology designs, engineers, and ships production AI products with one accountable team, from architecture and on-device models through cloud APIs and deployment. Talk to Corazor about your product.

Corazor Editorial