Analytics · Anonymized

Ten million rows, and a warranty dispute rests on the answer.

A live analytics pipeline that decides whether a failing battery is a component defect or how it was driven.

This is a production system we built and ran, described here without the client, the industry specifics, or any commercial detail, because that delivery is confidential. What can be said is the part that matters to a buyer: the pipeline exists in a place where the answer it produces is used to settle money between two parties.

The operational risk is easy to state. When a vehicle battery degrades, someone is accountable for it — and the accountability depends entirely on why it degraded. A manufacturing or component defect points one way; the way the vehicle was actually driven points another. Get that classification wrong and you either absorb a cost that was not yours to absorb, or you deny a claim that should have been honoured. Either error is expensive, and it is not the kind of error that stays hidden, because the other side is looking at the same evidence.

A system in that position cannot be a black box that emits a verdict. It has to hold its working, over a volume of data no person is going to re-check by hand, so that the answer can be defended when it is challenged.

What the system does

The pipeline runs a live analytics workload of more than 10.1 million rows. Underneath that figure are 8.46 million telemetry rows and 1.68 million GPS rows, gathered across 285 vehicles — the raw record of how each battery behaved and how each vehicle moved.

On top of that data sits an eight-stage battery-degradation engine. The stages take the raw telemetry and GPS record and turn it into a picture of how a specific battery has aged, rather than a single reading at a single moment. Degradation is a trajectory, not a snapshot, and the engine is built to see the trajectory.

The stage that carries the weight is a root-cause classifier. Its job is the distinction the whole system exists for: separating a component defect from driver behaviour. That is the line the money falls on, and it is the line the pipeline was built to draw from evidence rather than from an adjuster's impression. Warranty disputes are settled on its output.

What we can prove

The published facts, and the claims we refuse to invent.

Hard, published facts

A live analytics pipeline of more than 10.1M rows.
8.46M telemetry rows and 1.68M GPS rows, across 285 vehicles.
An eight-stage battery-degradation engine over that data.
A root-cause classifier that separates component defect from driver behaviour.
Warranty disputes are settled on its output.

Not claimed, on purpose

No client, brand, or industry named.
No accuracy percentage, precision, or error rate.
No cost saved, disputes won, or revenue moved.
No dates, deployment timeline, or team size.

Everything above the line is a published fact about a system we ran. There is no case-study outcome here — no ROI figure, no “we improved X by Y%”, no testimonial — because presenting one would mean inventing it, and a page about settling disputes on evidence cannot do that.

What this means for an automation build

The transferable lesson is not about batteries. It is that when an automated answer decides something contested, auditability is not a feature you add later — it is the point of the build. The reason this pipeline could stand behind a warranty dispute is that its working is reconstructable: the raw rows are there, the stages are there, and the classification can be traced back to the evidence that produced it.

That is the discipline we bring to any analytics automation. Before we build, we agree the one metric that has to move and confirm it is already counted in your systems — because a number the automation itself invents is a number nobody can check. Scale is what makes this hard and also what makes it worth doing: no team is going to hand-verify ten million rows, so the system has to be trustworthy at a volume where trust cannot come from spot-checking. It comes from the working being visible.

The practical instruction for your own build is small and specific: pick the decision the automation is really making, ask who will be angry if it is wrong, and make sure that person can see how the answer was reached. If they can't, you have a demo, not a system.

What we would not hand to the machine

The classifier separates defect from behaviour; it does not, on its own, close the case. Where a wrong answer has a financial and legal consequence, the automation produces the evidence and the reasoning — it does not get to be the final, unreviewable authority that denies a claim with no human able to inspect the working. That would be automating exactly the part that most needs to be defensible.

So the honest boundary is this: we automate the analysis at a scale a person cannot match, and we keep a person able to read and challenge the result. The system earns its keep by making the human decision faster and better-grounded, not by removing the human from a decision that has someone's money on it.

Will it reach production on your workflow?

Score your workflow before you talk to anyone: six questions against what actually stops automation reaching production. The result is immediate, no email required, and it will sometimes tell you not to hire us.

Take the readiness test See the Data Analysis Agent

The same discipline — an answer with its working shown, auditable rather than trusted blind — is what our Data Analysis Agent brings to your own warehouse.