Two founders, and a clear line between them.

Dhruv is a Computer Science and Mathematics student at the University of Michigan and the engineer behind most of what runs inside NADIR. He owns the detection stack end to end: the ingest path that normalises telematics and repair-order feeds into a single scored timeline, the cross-sensor residual model that turns four disagreeing sensors into one calibrated number, the conformal machinery that puts a stated coverage bound on that number, and the evidence pipeline that signs the result so that somebody who does not trust us can still check it.

Why the double major matters here

The mathematics is not decoration. Post-repair drift detection is a problem where the naive approach — a threshold per axis — fails in a specific and expensive way, because yaw and range residuals are correlated and a vehicle can sit inside both limits while sitting well outside the joint distribution. The scoring path uses Mahalanobis distance over the residual covariance for exactly that reason, Kalman innovation testing to separate a genuine state change from one rough afternoon, and split-conformal prediction to produce an interval with a stated coverage that holds without assuming the residuals are Gaussian. Each of those is a deliberate choice with a defensible alternative, and he can argue all of them.

The computer science is what makes it run in production rather than in a notebook: a Python SDK, two REST endpoints, an on-premise edge pack for fleets whose data is not permitted to leave the building, and a scoring path that keeps up with roughly 1.24 million frames a day without a GPU anywhere in the loop.

Before NADIR

At Visa he built an autonomous remediation pipeline and sub-second payment telemetry — systems where a false negative is measured in fraud losses and latency is measured in abandoned transactions. That is closer to ADAS health monitoring than it first sounds. Both are high-volume streaming problems in which the interesting event is rare, the ground truth arrives late, and the operator's tolerance for noise is finite and quickly exhausted. The habit of placing an operating point deliberately, and defending it, rather than accepting whatever a model happens to produce, came from that work. So did the reflex to build the remediation path before the detector, because a detection nobody can act on is a report.

Published work and open source

He is a published author, with papers indexed on Google Scholar, and maintains open-source quantitative and computer-vision tooling on GitHub. Writing in public has a particular effect on engineering judgement: a claim that has to survive review is a claim you specify carefully. Most of the numbers on this site carry their method alongside them because he insisted that a result without its provenance is not a result — a position that shows up directly in the evidence bundle, where the model version, the pinned weight hash and the configured thresholds are signed fields rather than metadata.

What he argues for internally

He is consistently the one pushing for the narrower claim. NADIR has no ECU write path, and that was not a limitation discovered late — it was a constraint set on day one, because a system that can only observe can go onto a working fleet next month, while a system that can actuate goes onto one after a validation campaign measured in vehicle-years. He would rather ship a product that is provably advisory than one that is ambiguously autonomous.

Concretely, he wrote the residual engine, the tiering policy, the evidence signing and verification path, the Python SDK, the Pulse edge pack, and the generative instrumentation rendering throughout this site. If a number on nadirai.net is wrong, it is his to fix.

Sri is a Computer Engineering student at the University of Michigan College of Engineering, working at the layer where software stops being an abstraction — firmware, GPU software and embedded systems. At NADIR he owns the product roadmap, the design language, hardware validation, and growth. In practice that means he decides what the product claims, and then makes sure the claim is true against real hardware before anyone is allowed to say it out loud.

Why an embedded background changes the product

Most software written about vehicles is written by people who have never had to care what a CAN bus actually exposes, at what rate, with what clock discipline, and with which fields quietly absent on a six-year-old tractor unit. Sri has. That knowledge is the difference between a product that assumes a signal exists and one that ships against the eleven signals a given fleet genuinely publishes.

The coverage matrix on the Monitor page is his doing — the one that admits radar status arrives on 72 percent of tractor units and 18 percent of legacy ones. It would have been easier to omit. He insisted the product be explicit about what it cannot see before a single line of scoring code was written, on the grounds that a monitoring layer which overstates its own inputs is worse than no monitoring layer at all, because it manufactures confidence.

Hardware validation, literally

Every geometric claim NADIR makes has to survive contact with an instrument. That nine tenths of a degree of yaw becomes 1.57 metres of lateral error at a hundred metres; that a tenth of a degree of pitch turns a true sixty-metre range into an estimated fifty-six; that a camera bracket moves 0.0104 degrees per kelvin and therefore drifts more than half a degree between a cold morning and a hot afternoon. Sri is the one who takes those numbers to a bench and finds out whether they hold. Several of them changed after he did.

Roadmap, which mostly means refusal

As CEO he owns what gets built, which at this stage mostly means owning what does not. The Resolve page states outright that NADIR has no intention of building a calibration bay, and draws two of the six steps in the loop as dashed outlines because they do not exist yet. That page reads the way it does because Sri would rather lose a deal than win one on a capability that is a quarter away.

The same discipline governs how pilots are scoped. One metric — MTTFF-RE, the median hours from repair-order close to first flag — agreed in writing before the pilot begins, pass or fail, with no renegotiating the target once the data is in. It is an uncomfortable way to sell and a very fast way to find out whether a product works.

Design and growth

The editorial position of this site is his: instruments drawn rather than screenshots staged, because a fleet safety manager should be able to evaluate the argument without booking a demo call, and because a company that shows its working is easier to trust than one that shows a logo wall. On growth, he does the unglamorous part — sitting with fleet maintenance leads, collision network operators and insurers, and listening for the moment they stop asking about the model and start asking about the deadline clock. That switch is reliably where the conversation becomes real.