You don't get it. Software should easily pick these up! The fact that it does not is the problem.
You're right that root cause analysis demands discipline. But discipline begins with asking whether the system architecture itself permits meaningful diagnosis in the first place.
If a sealed software system accepts flawed inputs, fails to escalate anomalies, and continues execution without exposing its logic, then waiting for DFDR and CVR data only tells us what the outcome was—not why the system behaved as it did. That is a post-mortem, not a design audit.
The cockpit voice and flight data recorders will give us telemetry and crew actions. They will not show us whether the automation flagged improbable thrust calculations, whether FADEC overruled a valid crew request, or whether fuel management logic suppressed critical thresholds without alerting the pilots. Those elements live deep within proprietary logic trees that are rarely subjected to external review.
The concern raised here is not speculative. It is structural. We have created systems that remove human agency while preserving human accountability. The question is not whether the pilots followed the correct checklist. The question is whether the system ever gave them the tools to know what was going wrong in time to intervene.
Root cause analysis means you look at the whole root, not just the tip. In this case, the root is software opacity, control asymmetry, and automation that neither explains itself nor asks for help when its assumptions break.
Let’s not confuse silence from a system with correctness. HAL was silent, too.
I’ve made no assumptions on what occurred, so I’m not willing to agree with your statement.
Fact is all we know is a plane crashed and one guy who’s likely to have significant emotional trauma for the rest of his life survived. Beyond that, we know nothing.
