Airbus builds redundant flight computers with different chips, teams, and languages. Aviation's independence principle is the standard AI root-cause analysis should be held to.

The Monitoring Pilot Never Flies: Aviation's Rule for Verifying AI Diagnoses

TL;DR: Meaningful verification of an AI-generated root cause analysis requires independent verification—using a different model, a different evidence path, and a different method than the one that created the diagnosis. To avoid "common-mode failures" where an AI simply confirms its own hallucinations, engineering teams must adopt aviation's "dissimilar redundancy" standard for autonomous operations.

In the cockpit of a commercial airliner, two pilots sit side-by-side. One is the Pilot Flying (PF), responsible for the physical manipulation of controls. The other is the Pilot Monitoring (PM), whose entire job is to observe, cross-check, and challenge. At no point during a critical maneuver does the Monitoring Pilot also fly. If they did, the redundancy of the cockpit would vanish, replaced by a single point of failure: one human mind’s blind spots.

As engineering teams turn to Large Language Models (LLMs) for automated incident response, we are ignoring this fundamental safety principle. Most existing tools rely on "self-critique" or a single-model loop to verify a diagnosis. In aviation terms, this is a pilot checking their own altimeter reading and declaring it correct because they were the one who read it.

To build trust in automated systems, we must understand verifying ai root cause analysis through the lens of independent verification and the aviation concept of cross-check culture.

Two pilots, one rule: the monitoring pilot never flies

The aviation industry operates on the principle that humans are fallible but systems can be robust. According to [SKYbrary], the cross-checking process is the "comparison of information from one source with information from another" to ensure accuracy. This isn't just about double-checking a number; it is a rigid protocol where the Pilot Flying announces an intended action, and the Pilot Monitoring must independently verify the state of the aircraft before acknowledging.

The [FAA AC 120-71B] advisory circular emphasizes that "monitoring is as important as flying." The moment the Monitoring Pilot stops being a skeptical observer and starts helping with the controls, they lose the "outside view" necessary to catch a mistake. This separation ensures that two different sets of eyes are processing the same reality. If you apply this to verifying ai root cause analysis, the model that proposes the "why" should never be the same model that signs off on the "how."

Dissimilar redundancy: Airbus's bet against common-mode error

Safety-critical engineering takes this a step further with "dissimilar redundancy." When Airbus designed its digital flight control systems, they didn't just put two computers in the nose of the plane. They knew that if both computers ran the same code, a single software bug (a "common-mode failure") could crash both simultaneously.

According to [Right Attitudes], Airbus avoids this by using different processors (e.g., Intel and AMD), different vendors, and entirely different programming languages for their primary and secondary flight control computers. Each team writes its own version of the logic so that a flaw in one is highly unlikely to exist in the other.

Key Takeaway: Independent verification is only valid when the reviewer uses a different method and a different evidence path than the original author, preventing shared blind spots from masquerading as consensus.

The software failure this predicts: AI that grades its own homework

In SRE and DevOps, the current "llm self-verification problem" is the tech equivalent of a common-mode failure. If you ask a single LLM to investigate a Kubernetes crash, it develops a "prior"—a narrative of what it thinks happened based on the first few logs it sees.

If you then tell that same model, "Review your own work for errors," it will almost always find reasons to support its initial hypothesis. It isn't being "lazy"; it is operating within the same latent space and statistical probabilities that led to the first wrong answer.

A classic failure pattern:

Model A sees a 504 error and blames a database lock because it saw "DB" in a trace.
Model A (Self-Review) looks at the same trace, ignores the "Network Timeout" flag because it's already focused on the DB, and concludes, "Yes, the DB lock caused the 504."
The SRE receives a plausible but incorrect diagnosis that leads to 30 minutes of wasted remediation.

What independent verification looks like in automated RCA

True verifying ai root cause analysis requires breaking the loop. This means the verification agent must meet three criteria of independence:

Independent Model: The verifier should be a different model family or at least a highly distinct instance with a zero-bias prompt.
Raw Evidence Access: The verifier shouldn't just read the summary provided by the first AI; it must go back to the raw telemetry (logs, traces, and schema).
The Power of Red: The verification step must be empowered to reject the hypothesis entirely without suggesting a "fix" for it, forcing a re-investigation.

An evaluation checklist: 5 questions for AI RCA tools

When evaluating an AI-driven SRE platform, use this checklist to see if they follow the pilots' "cross-check" standard:

Who is the reviewer? Does the same model instance that proposed the RCA also perform the verification?
What is the evidence source? Does the verifier look at the raw data, or only the summary provided by the first agent?
Is it "Dissimilar"? Does the system use different prompts, logic gates, or model architectures for the "Audit" phase?
Can it say 'No'? Is there a clear path for the system to flag a diagnosis as "Low Confidence" and escalate to a human, or does it always try to force a conclusion?
Is there an audit trail? Can you see exactly which piece of evidence the verifier used to "cross-check" the proposer's claim?

Limits of the analogy: Cockpits are not clusters

While the cockpit analogy is powerful, software systems have a level of complexity and "state" that is far more volatile than an aircraft in level flight. According to [Rootly], incident response in software often involves changing the system while you are diagnosing it—something pilots rarely do with flight physics.

Verification in AI RCA also struggles with the "hallucination of evidence." Unlike a physical altimeter, an AI might imagine a log line that doesn't exist. This is why verification must be anchored in a retrieve-and-verify loop against the actual database or logging provider, not just a mental model of the incident.

Sources & further reading

According to [SKYbrary], cross-checking is a critical defense against postural or mental slips in high-stakes environments.
The [FAA AC 120-71B] defines the roles of PF/PM as the primary safeguard against individual human error.
According to [Right Attitudes], Airbus’s use of dissimilar hardware and software teams is the gold standard for avoiding common-mode failures.

Why this matters now

Engineering leaders are becoming increasingly skeptical of "black box" AI that produces confident-sounding RCA without proof. As discussed in recent [Reddit r/sre] threads regarding automated incident responders, the "grading your own homework" problem is the primary barrier to SREs trusting AI enough to let it touch production.

At Operate, we've designed our architecture to respect this history of safety engineering. Our four-agent pipeline includes a dedicated Verification agent that is deliberately separated from the Investigation agent. It uses independent logic to cross-check conclusions against raw evidence—bringing the "dissimilar redundancy" pattern to the world of AI operations. By ensuring the monitoring pilot never flies, we provide the auditability and accuracy that SREs require to move from manual toil to overseen autonomy.