Last week, the Aircraft Accident Investigation Bureau (AAIB) of India released its preliminary report on the Air India 171 plane crash, which occurred on June 12, 2025. The media quickly focused on a specific detail in the report that mentioned a ‘fuel cutoff switch’ and a paraphrased conversation between the pilots, and insinuated deliberate pilot action. A prominent aviation safety expert and retired pilot escalated this narrative asserting that the pilot was experiencing mental health issues. Aviation experts on social media initially attributed the crash to pilot error citing the unretracted landing gear on liftoff and perceived incorrect flap settings. Following the report’s release, they doubled down on deliberate pilot action and emphasized the necessity for psychiatric counseling for pilots.
We analyze the report in detail and show for a fact that it was not pilot error or deliberate pilot action. We reached this conclusion based solely on the information provided in the preliminary report and with a high level of confidence can state the root cause and detail the sequence of events that lead to the crash. Before we get to the report, we must first understand how modern planes fly.
A Computer with Wings
Airbus was the first to use fly-by-wire controls beginning with their A320 series. A common joke among Boeing747 pilots at their Airbus counterparts was – a Boeing is a plane with a computer, an Airbus is a computer with wings. Another was – the Boeing you can fly, the Airbus you program the computer to fly it for you.
A fly-by-wire aircraft can be made lighter than a similar design with pneumatic controls. With scores of sensors monitoring every aspect of engine performance and external flight conditions, it allowed stability parameters of the aircraft to be relaxed. The wing stabilizers could be smaller, leading to overall lower weight and lower operational costs.
Boeing soon realized that they could make more efficient aircraft by moving to fly-by-wire technology. In 1995, the Boeing 777 entered service with the 747’s mechanical control systems replaced by fly-by-wire technology. Boeing, too, had become a computer with wings. The Boeing pilot jokes had stopped by then.
The brains of a fly-by-wire aircraft is a computer system called FADEC (Full Authority Digital Engine Controls). The FADEC consists of a digital computer called the Electronic Engine Controller (EEC), scores of sensors that feed data to the EEC, and actuators that can physically move and control system components. The EEC is the software brain and the actuators are the muscles ensuring optimal engine performance and aircraft stability.
Pressure sensors on the wheels of the plane tell the FADEC that it is on-land or in-air. As soon as a plane takes off, the FADEC will switch its state to ‘in-air’, and similarly when it lands, the pressure sensor informs the FADEC and it switches its state to ‘on-ground’. On take off, when a pilot pushes the Gear Up lever, a ‘gear up’ digital signal goes to the FADEC, which checks its internal state. If its state is ‘in-air’, the FADEC will signal the appropriate actuator to perform the action and the actuator brings the wheels up. If its state is ‘on-ground’, the FADEC will ignore the Gear Up command. The FADEC is programmed to preserve aircraft integrity and minimize human error. While a pilot in the cockpit assumes that they are in control, the real intelligence is in the FADEC. It has the full authority to override a command from the cockpit.
It is also important to understand that the FADEC can initiate actions without any input from the cockpit. Similar to the Gear Up command from the pilot being ignored while on ground, the FADEC can initiate actions, without the pilot’s prompt, to preserve the integrity of the aircraft.
Use Cases and FADEC Patches
In 1989, a British Midland Airways Boeing 737 crashed, while making an emergency landing at East Midlands Airport, because the pilot shut down the wrong engine. The accident report confirmed that the pilot had shut down his apparently good right engine after a turbine blade broke in the left engine and set it on fire. The flight data recorder proved that cockpit instruments had shown correctly that it was the left engine that was in trouble.
For the FADEC software, this scenario becomes a use case. A use case is how a software enhancement request is communicated. Humans make mistakes; machines don’t panic, don’t stress out under pressure situations. If the sensors detected the failure correctly, couldn’t the FADEC software automatically shut down the faulty engine preventing further engine damage and fire spreading? The goal of FADEC is to minimize pilot error. A software rule gets added to FADEC – on detection of engine damage, initiate engine shutdown sequence and cutoff fuel, and inform cockpit, in that order.
Once this new software rule is added, it is tested out by test pilots under various scenarios and if the tests pass, a software patch is created and an advisory issued to airlines to update to the latest revision. Airlines have their own schedules for patch updation, and so at a time, there could be the same model of a plane flying that may display different behaviors under different conditions.
The Boeing 737 Max is the fourth generation Boeing 737 that offered better fuel economy and operational efficiency, thanks to a new engine. These engines were larger than the Boeing 737 engines and had to be placed forward and higher on the wings to avoid compromising ground clearance. This change in engine placement altered the aerodynamics of the aircraft and to compensate and prevent stalls, Boeing introduced a software solution called MCAS (Maneuvering Characteristics Augmentation System). MCAS would read the Angle of Attack (AoA) sensor (the angle at which incoming air meets the wing) and if it determined that the angle was too high for its speed, then it would automatically initiate a ‘nose down’ to lower the angle of attack to prevent a stall. Boeing did not send out any advisory notifying airlines of this change or even the existence of the MCAS module in FADEC.
In October 2018, a Lion Air 737 Max crashed into the Java sea 13 minutes after takeoff. The crash was blamed on pilot error. In March 2019, an Ethiopian Airlines 737 Max crashed 6 minutes after takeoff. This second crash in less than 6 months prompted airlines to ground their Boeing 737 Max aircraft. The crashes were attributed to MCAS, which relied on a single AoA sensor to initiate its ‘nose down’ action. A defective sensor reading could activate MCAS and push the nose down without any pilot action. Boeing eventually came up with a software patch that took readings from two AoA sensors. It did not activate MCAS if the readings varied significantly and provided a pilot override.
The reality today is that modern fly-by-wire aircraft can autonomously act to preserve hull integrity, even without pilot input. Since, humans program these machines, and humans are prone to error, it must logically follow that machines too can make mistakes. We need to internalize this before getting into the AI 171 preliminary accident report.
A Red Herring
The Aircraft Accident Investigation Bureau (AAIB) of India released its preliminary report on the AI 171 crash on July 11, 2025, exactly 30 days after the accident. It is a 15 page report, but one line stood out from the analysis of the flight data recorder.
Engine 1 and Engine 2 fuel cutoff switches transitioned from RUN to CUTOFF position one after another with a time gap of 01 sec.
In the above, I have highlighted ‘fuel cutoff switches’ and ‘position’ (they are not highlighted in the report). The Fuel Cutoff switches are in the cockpit. If their position transitioned from RUN to CUTOFF, then it had to be pilot action. Media, aviation experts, and youtube influencers were quick to pronounce their judgement based on this and a paraphrased communication between the pilots.
The flight data recorder logs events. The sensor for the fuel cutoff is not on the switch but on the fuel cutoff valve. It is the state of the valve that is recorded. It is very likely that this report was written by an experienced pilot. Fuel Cutoff switch and the RUN/CUTOFF position are familiar metaphors for a pilot. A digital systems engineer knowing that the sensor is on the valves, might have phrased that sentence differently.
Engine 1 and Engine 2 fuel cutoff valves transitioned from RUN to CUTOFF state one after another with a time gap of 01 sec.
We have established that the FADEC can take actions to preserve the integrity of the aircraft without pilot involvement. If we assume that the pilot did not initiate the fuel cutoff, we then have to establish the reason for FADEC to initiate an engine shutdown. Was there any event that preceded the cutoff that would lead the FADEC to initiate an engine shutdown? For that, we have to look at the temporal sequence of events.
Temporal Causality
To determine the root cause of a failure, digital forensics investigators use a technique called Temporal Causality – you pick an event, go back in time in the logs and find the event that caused it. You repeat this process going back in time till you find the root cause.
The below is the temporal sequence of events as detailed in the report.
08:08:33 UTC V1 speed achieved
08:08:35 UTC VR speed achieved
08:08:39 UTC Lift off. Sensors transitioned to air mode
08:08:39 UTC RAT deployed
08:08:42 UTC Engine 1 fuel valve transitions to CUTOFF
08:08:43 UTC Engine 2 fuel valve transitions to CUTOFF
08:08:47 UTC RAT begins supplying hydraulic power
08:08:52 UTC Engine 1 fuel valve transitions to RUN
08:08:54 UTC APU (Auxiliary Power Unit) Inlet door opens
08:08:56 UTC Engine 2 fuel valve transitions to RUN
08:09:05 UTC MAYDAY MAYDAY MAYDAY transmitted
08:09:11 UTC Reporting stopped
Just prior to the fuel valves on both engines transitioning to CUTOFF, the RAT is deployed. The Ram Air Turbine (RAT) acts similar to a windmill, a small wind turbine that uses air movement to spin blades and generate power. The RAT is stored in the Dreamliner’s fuselage and is only deployed in case of an emergency like a catastrophic electrical failure.
Ram Air Turbine (RAT) deployed immediately after takeoff (08:08:39 UTC)
We know that the RAT deployed. We know that V2 speed was not achieved. The deployment of the RAT indicates a catastrophic electrical failure. Is there anything in the report that could indicate an internal electrical failure?
There is and it has been staring at us in plain sight. Before we come to that let us assume for now that a catastrophic failure did happen and the RAT deployed. In this scenario, would the FADEC initiate an engine shutdown and fuel CUTOFF sequence?
FADEC Sensor Manager’s Dilemma
The FADEC continuously monitors sensor input data on engine performance and outside air conditions. The sensor manager component of the FADEC gets a stream of data from pressure sensors, temperature sensors, fuel flow sensors, vibration sensors, voltage sensors, air density sensors, crankshaft position sensors and a host of other sensors. It processes the data in real-time and activates actuators as needed to stabilize the plane and optimize engine performance.
At 08:08:39 UTC, we have assumed that a catastrophic electric failure happened that led to the RAT being deployed. The FADEC has built in redundancy and multiple power inputs. Let us assume a scenario where the electric failure takes out the data bus from the engine health monitoring sensors. The FADEC stops receiving engine health status. What should the FADEC do? Can the FADEC afford to do nothing?
The FADEC has to decide – no data for engine health could indicate a compromised engine (which is catastrophic), or it could be the result of a data network breach (which is non-catastrophic). It can’t tell. If the engine were compromised, and fuel continued to flow into the engine, it would be just a matter of time before the fire spread and compromised the aircraft’s hull. If it waits for the RAT to restore power, it might be too late, so it issues a fuel cutoff action. Each engine has its own FADEC, and each reaches that decision independently.
At 08:08:47 UTC, the RAT restores a power channel. The FADEC starts receiving engine health status data, realizes that the engines are fine and then initiates an engine restart and opens the fuel valves for Engine 1 at 08:08:52 UTC. Engine 1 restarts, its core deceleration stops, reverses, and starts to progress to recovery. At 08:08:56 UTC the fuel valve for Engine 2 transitions to RUN. Engine 2 attempts a restart, fuel goes in but it keeps sputtering and its Auxiliary Power Unit (APU) inlet door does not open.
The APU functions similar to a car’s 12V battery when starting the engine. In winters, when you start your car and the engine keeps sputtering, it is because the battery voltage is low. To start, you need to jumpstart the car battery and then drive it around for it to charge. The Boeing 787 Dreamliner was the first to use Lithium-ion batteries to power up its APUs. There is one thing that has been well documented that Li-ion batteries are prone to catching fires.
The Boeing 787 Dreamliner was grounded in 2013 due to safety concerns associated with Li-ion batteries. Japan Airlines and ANA had reported smoke and fire from the APU’s Li-ion battery. Boeing determined the possibility of a short-circuit within a cell leading to a fire but could not determine the root cause of the problem. Boeing redesigned the battery casing and heat venting systems, added improved insulation between cells and had it approved by the US Federal Aviation Administration (FAA).
This approval was based on an assumption that a short circuit in one cell would potentially cause a fire but would be isolated to that cell and not cause a thermal runaway, where a temperature increase in one cell can lead to uncontrollable temperature increases as the increasing heat creates short circuits in the other cells. Is there any evidence of a thermal runaway event?
Thermal Runaway
We have established the temporal causality of events post 08:08:39 UTC. We have been assuming that the RAT deployed because of a catastrophic electrical failure. Does the preliminary report give any indication that a thermal incident happened prior to 08:08:39 UTC?
According to the preliminary report, the Boeing 787 Dreamliner is equipped with two black boxes (Enhanced Airborne Flight Recorders (EAFR)), one in the tail section and one in the front. Both are similar in construction and designed to withstand an impact of 3400 g-force and temperatures of 1000℃.
The aft EAFR was located on June 13 2025 on the rooftop of a building where the tail section of the aircraft was embedded. It had impact and thermal damages to its housing. The aft EAFR was substantially damaged and data could not be downloaded through conventional means. There was extensive damage to the memory card.
The forward EAFR was located on Jun 16 2025 from the wreckage debris on the ground. The Underwater Locator Beacon (ULB) was still connected to the housing and the Li-ion battery was also attached to the equipment.
The rear EAFR on the left and the forward EAFR on the right
In 2018, an Apple engineer driving his Tesla Model X to work dozed off when the car on AutoPilot veered off the highway and struck a concrete barrier at the intersection of US 101 and SR 85, in Mountain View, California. The accident vaporized half his car. Gasoline fires melt paint, a thermal runaway fire from a Li-ion battery can melt metal. EAFRs were designed to withstand gasoline fires, not Li-ion battery fires.
The aft EAFR was found where the tail section was embedded in the roof. The tail section did not show any external evidence of fire damage. The damage to the aft EAFR can only be explained by a thermal runaway event in a Li-ion battery that melted its housing and the ULB.
Investigators should be able to easily determine the cause of damage to the aft EAFR. Neither a gasoline fire nor an impact can explain this extent of damage. We now have the root cause and can replay the causal sequence.
Immediately after takeoff, at 08:08:39 UTC, the Li-ion battery for APU 2 goes into a thermal runaway and flames out causing a catastrophic electrical failure. The electrical failure causes the RAT to deploy. The electric failure stops engine health data from coming to the FADECs for both engines. The FADEC assumes an engine failure event and initiates an engine shutdown and closes the fuel valves. At 08:08:47 UTC, the RAT restores power to the data bus. The FADEC starts receiving engine health data from its sensors, determines that engines are not compromised, and then initiates an engine restart action that leads to the fuel valves being reopened. Engine 1 restarts. Engine 2 keeps sputtering as APU 2 has been compromised.
Indian investigators should focus on APU 2 and its Li-ion battery. We can visually determine by the state of the aft EAFR that there was a thermal runaway. Is there a way to determine what caused this thermal runaway?
Tracing Back, Looking Forward
The aircraft arrived at Ahmedabad airport from Delhi as AI 423. It landed at 05:47 UTC and the crew made a Pilot Defect Report (PDR) entry “STAB POS XDCR” in the tech log. This refers to the stabilizer position transducer, a sensor that communicates the horizontal stabilizer’s trim position to the FADEC. Troubleshooting was carried out and the aircraft was released for flight at 0640 UTC.
This does not tell us much, but a passenger on AI 423 had made a video and put it out on social media. In it, he complains about electrical systems not working and the AC being down and it being hot in the cabin. The APU, besides being crucial to start the engines, also operates cabin lighting, air conditioning, and other essential systems, especially when external power sources are unavailable. It points to a potential problem with the APU prior to its arrival in Ahmedabad that went unreported. There is no mention of this in the Pilot Defect Report.
Now, we can recreate the complete timeline for AI 171. The aircraft landed in Ahmedabad with a defective APU 2. As the aircraft starts rolling at 08:07:37 UTC and accelerates for takeoff, APU 2 being compromised, Engine 2 starts drawing power from the Li-ion battery backup. The Li-ion battery is not designed for sustained engine operations and as thrust increases, Engine 2 starts demanding more and more power at a very fast rate. The Li-ion battery backup for APU 2 starts overheating and triggers a thermal runaway.
An aircraft is a very complex system. The Preliminary Accident Report lists that experienced pilots, engineers, Aviation Medicine Specialists, Aviation Psychologists, and Flight Data Recorder specialists have been included in the investigation team as subject matter experts.
More and more flying functions are being automated. The investigation team should include computer specialists and fire specialists, who can tell the difference between a gasoline fire and a thermal runaway fire caused by a Li-ion battery. The team also needs a spokesperson, who is media savvy and capable of explaining complex systems in simple language. This person should be the main media contact person and key to quashing rumors before they start.
Cockpit conversations should not be paraphrased but must be reported verbatim. The report mentions a pilot saying – why did he cutoff? This was misinterpreted and various media outlets paraphrased that as – why did you cutoff? Some even went further and published it as – why did you cutoff fuel?
The ‘he’ that the pilot was referring to was not the other pilot but FADEC. Investigators must understand pilot-speak and also FADEC-speak. Accident investigators and spokespersons must learn to measure every word they write or speak.
Regaining Flyer Trust
Li-ion batteries are a clear and present danger. In congressional hearings, after the 2013 grounding of the Dreamliner, Boeing acknowledged that despite 200,000 hours of engineering efforts, they could not definitively identify a root cause for the fires. There were also critical shortcomings in battery certification. FAA certification also did not require thermal runaway testing as part of the certification.
It is for the investigators to determine and prove that a thermal runaway fire did occur. The fire in itself did not cause the crash. The fire caused an electrical failure that disconnected the FADEC from its sensors, which resulted in the FADEC initiating an engine shutdown sequence. It is the FADEC initiating the engine shutdown sequence that made the plane crash. What if, in this scenario, the FADEC software had an extra rule – if a plane is below a certain altitude, do not initiate engine shutdown sequence?
In this case, the fire would have caused an electrical failure, the RAT would have deployed, the FADEC would be in a state where it is not getting any engine-health parameters and determined that it is below the cutoff altitude and taken no action. The RAT would have restored power, the FADEC would have started receiving engine health parameters, and determined that engines are fine and would not have intervened. The pilots would have been notified of smoke in the tail section and could have safely landed the plane back.
It wasn’t one failure but a set of cascading failures. When doing software testing, the rarest of rare cases are called edge cases. Edge cases are extremely hard to recreate and test for, as Boeing acknowledged in their congressional hearings. But edge cases do happen, and edge cases kill.
Everyone involved in the aviation industry, including manufacturers, regulators, airports, airlines, and flyers are collectively invested in a better flying experience and safer flights. In the interests of all, AAIB should request aircraft manufacturers to disclose all use-cases where the FADEC can act without pilot awareness. Additionally, the flight data recorder should log whether the cockpit or FADEC initiated an event. If damage to the rear black box is attributed to a thermal runaway fire by a Li-ion battery, it raises concerns about the battery’s proximity to the black box and the 1000-degree Celsius temperature rating of its enclosure.
Under the International Civil Aviation Organization (ICAO) rules, the sole objective of the investigation of an Accident/Incident is the prevention of accidents and incidents and not to apportion blame or liability. This is an opportunity for AAIB to step up and create an accident report that is transparent, backed by scientific evidence gathering, using measured words, and suggesting best practices that will restore confidence in the process, help flyers regain trust in the aviation industry, and lead towards making the flying experience seamless, sustainable, and safe.
Read our latest article where we use high-school physics and show for a fact that it was not pilot error or deliberate pilot action, and the sequence of events in the final 32 seconds of Flight AI 171 — Eyes Wide Shut – Deliberate Misdirection or Gross Incompetence
Further Reading
Data-driven reliability analysis of Boeing 787 Dreamliner. Guru Pandian, Michael Pecht, Enrico Zio, Melinda Hodkiewicz. Chinese Journal of Aeronautics. Volume 33, Issue 7. July 2020, Pages 1969-1979. Available at https://www.sciencedirect.com/science/article/pii/S1000936120300546#s0020
Free fall: The turbulent state of Indian aviation. Suruchi Kapur-Gomes. The Indian Express. Available at https://www.newindianexpress.com/magazine/2025/Jul/13/free-fall-the-turbulent-state-of-indian-aviation
Disclaimer
At Hawkai Data, we are not pilots. We have no background in aeronautical engineering. We have no experience with the FADEC software. We understand complex systems. We understand asynchronous digital agents. We understand data forensics. We understand coders and the short cuts they take. We understand human behavior. We can critically analyze and reason. We may not have all the answers but we always know the right questions to ask.
Everything that is written here is a hypothesis based on data provided in the preliminary accident report. Everything needs to be validated by investigators and till then it must be considered just that, a hypothesis.
When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth – Sherlock Holmes. The Adventure of the Speckled Band, Arthur Conan Doyle.
Credits
All images used in this document are from AAIB’s Preliminary Report.
If you want to learn more about complex digital systems, AI and the future of work, read our articles at https://hawkai.net/digital-transformation/
If you have any questions, talk to us at info@hawkai.net, or follow us on LinkedIn at https://www.linkedin.com/company/hawkai-data/, or connect with us at https://hawkai.net.
