I broke a drone on purpose to build a test that a free, obvious rule cannot pass. Then I gave the test to two AI models.
Your car’s dashboard lights up all at once: engine, temperature, oil pressure, battery. Four warnings, all of them real. But they are not four problems. They are one problem and three consequences.
A mechanic who fixes whichever light came on first replaces the wrong part and sends you back out with the actual fault still there.
Spotting that something is wrong is easy. Working out which wrong thing caused the others is what decides whether the repair works. A drone in flight has the same problem, with a few hundred lights, no dashboard, and seconds to act.
I build software that watches a drone while it flies and tells the operator what is failing. To test whether it can find the real cause, I needed a fault where the obvious answer is the wrong answer.
So in a simulator I broke the drone’s compass — the sensor that tells it which way is north — and nudged it to point slightly wrong. Then I watched the order the warnings came out in.
The reason is not luck. The compass check is deliberately patient: it waits a full second to make sure the problem is real before crying wolf. The navigation check has no such patience and fires immediately.
So the honest, careful design choice is exactly what puts the true cause last in the queue. And because that patience is a fixed number written into the code, it happens on every single flight.
There is an obvious rule that costs nothing and needs no AI at all:
The first warning after something changed is the cause.
On most faults it is simply right. Motor fails, motor alarm first. GPS drops out, GPS alarm first. Any expensive system has to beat this free rule to be worth paying for — and usually it cannot.
On this one fault, the free rule gets it wrong every single time.
I gave the same test to two AI models, and asked each in two ways: once as a single question, and once as an assistant that could dig through the flight data itself.
The expectation is that digging beats asking. For one model it did. For the other it made things worse. Same test, same data, same wording — opposite result.
The one that got worse had a clear reason. When it could see the times each warning came out, it read the order as the answer — it decided the first warning caused the second. Which is precisely backwards, and precisely the trap.
“The navigation problem was detected first… this likely caused the compass problem.”
So the tempting headline — AI gets worse when you give it more tools — is not true. One model fell for the trap. The other read the same data and got it right. Which model you use is the finding.
Everyone’s first question about AI in a safety setting is whether it invents facts. So I checked every number these models wrote against what the flight actually recorded. Out of 595 answers, two quoted a number that never happened. Almost nothing.
The uncomfortable part is what that leaves. The models are not inventing evidence — they are reading real evidence correctly and drawing the wrong conclusion from it, confidently. No amount of fact-checking the numbers catches that. The only thing that catches it is a test where the right answer and the believable answer are different things.
| I claimed | What killed it |
|---|---|
| The difference is statistically significant | I counted 27 samples where there were really only 9. Corrected, the results overlap. |
| The fix raised the weaker model to 0.89 | That was one lucky run. Its true average is 0.69. |
| AI mistakes order for cause | True of one model, false of the other. |
| The rest of the gap is a bug in my code | I fixed the bug. The gap did not move. |
| Hide the timings from the AI | It helps the weaker model and slightly hurts the stronger one. |
| One model's score was 0.89 | Found while re-checking on 2026-08-15: that was its most common run, not its average. The average is 0.91. |
Every one was killed by a check, not by an argument — running things five times instead of once, testing a second model, having an outside model review my work.
A monitor that quietly reports the wrong cause is worse than one that crashes, because you act on it. The same is true of my own conclusions, which is why those checks run whether or not I expect them to find anything.
The part that finds faults is free, open, and needs no AI account — it reads the
.BIN log files already sitting on your SD card and prints what it found alongside
the evidence, so you can check it rather than trust it. That is how the misconfigured battery
alarm above was caught.
sentinel doctor # tells you what's missing sentinel analyze YOURFLIGHT.BIN # findings, each with its evidence
ArduPilot only. PX4 uses different logs and different parameter names — it would run and find nothing, which is worse than refusing. Setup is two clones rather than one, because the detectors live in a second repository.