Any tool can list what a code might mean. The hard part, the part a 30-year veteran does without thinking, is deciding which one it actually is, and knowing how sure you’re allowed to sound.
Hand a tech six causes ranked by frequency and you’ve handed the diagnosis back to them with extra steps.
A code is a claim. A measurement is a fact. AceDx weighs them differently, and shows you which kind it used.
It isn’t decoration and it isn’t a score. It tells you how much weight the call will carry, so you know whether to swap the part or run the test first.
A high number says the cheapest thing you can do is fix it. A middling number says the cheapest thing you can do is test it. AceDx names which test: the one that would prove its own call wrong fastest.
A tool that always produces a confident answer is a tool that is confidently wrong on a regular schedule.
When the data supports a direction but not a component, AceDx says the direction and stops. A fabricated part number is worse than an admission.
When two causes explain the same data the tool does not coin-flip. It names the single measurement that separates them, so ten minutes of testing replaces an hour of parts-swapping.
Color is the fastest thing a person reads across a bay. If it can be spent cheaply, it stops meaning anything.
A verdict goes green only after the repair is confirmed on retest and logged to the repair order. Not when the part goes in, not when the tech is fairly sure. It’s a record of what worked, not a hopeful guess.
Red is a safety stop: a fault that says don’t hand this vehicle back yet. It’s rare on purpose. A tool that flashes red at everything gets tuned out by Thursday, and then it’s useless on the day it matters.
Plenty of tools will now discuss your car with you. Discussion isn’t the job.
| A chat assistant | AceDx | |
|---|---|---|
| What you get back | A paragraph listing several possible causes, in no committed order. | One ranked call, named specifically enough to order the part. |
| Where it came from | Somewhere in the training data. You cannot check it. | The codes, counters, and freeze-frame values are printed under the call. |
| When it isn’t sure | Sounds exactly as confident as when it is sure. | Says so, with a number, and names the test that would settle it. |
| When it’s wrong | Nothing happens. It never finds out. | The retest catches it, the call never goes green, and the miss is on the record. |
| What it leaves behind | A chat log nobody reads twice. | A repair order the next tech can actually use. |
The retest catches it and the call never goes green. That’s the whole reason the loop exists. A tool that can’t be caught being wrong can’t be trusted when it’s right.
We’d rather ship a tool that visibly misses sometimes than one that quietly misses always.
No. The tech signs the repair order. AceDx makes a call and shows its work; overruling it takes one tap, and the disagreement gets logged too. If the tool is wrong in a particular way on a particular platform, that’s worth knowing.
Not yet, and we won’t print numbers we haven’t earned. We’re pre-pilot. The point of running with working shops this fall is to generate exactly that: measured against real ROs, on real vehicles, with the misses counted.
When we have them, they’ll go on this page with the methodology next to them.
No. Those are libraries of procedures, diagrams, and confirmed fixes. AceDx is the part that reads this specific vehicle and decides what’s wrong with it. It sits beside what you already pay for, not on top of it.
The pilot runs on real ROs in working shops. If the engine is wrong on your platforms, we want to find out on your bay floor, not in a slide deck.