In remembrance of all who were lost on AI171 — and in the cause of their safety, ours.
One year later, an interim report must not merely repeat the mystery. It must prove that the investigation followed the book.
A modern airliner is run by computers, electrical power and a data network that all have to work together. This article argues that the recorder showing the fuel switches as “OFF” is not the explanation everyone is waiting for — it is only a clue.
Before anyone blames a switch or a person, the investigation must rule out whether the electrical power, the aircraft’s data network, or the brakes and wheels were already in trouble in the few seconds around take-off. As you read, the shaded notes marked “In plain terms” explain each technical point in everyday language, and there is a full glossary of all the abbreviations at the very end.
On the first anniversary of AI171, the families, the aviation community and the travelling public deserve more than silence, selective leaks or a narrow narrative. If an interim report is indeed released, it must do more than say that the fuel-control switches were recorded as moving to CUTOFF.
That is not enough.
The recorded CUTOFF state is a symptom. The root cause lies deeper.
The real question is no longer:
Who moved the fuel switches?
That question belongs to a narrative of blame.
The proper accident-investigation question is:
What failed before the aircraft recorded, interpreted or acted upon CUTOFF?
That question leads to cause. And cause is what prevents recurrence.
Think of a smoke alarm going off. The beeping (the symptom) tells you something is wrong, but it doesn’t tell you whether it’s burnt toast or an electrical fire (the root cause). Here, the recorder noting the fuel switches as “CUTOFF” is the beeping alarm.
CUTOFF is simply the switch position that shuts fuel off to an engine — the opposite of RUN, which lets fuel flow. Knowing the alarm sounded is not the same as knowing what set it off.
Why an Interim Report Matters
An interim report after one year is not automatically a sign of failure. Complex investigations do take time. Modern aircraft accidents may involve recorder analysis, component teardown, laboratory testing, manufacturer inputs, simulator reconstruction, maintenance-history review, MEL analysis, software review, wiring checks, data-network correlation and human-factors review.
But time alone is not the problem.
The real test is whether the interim report convinces the reader that the investigators have followed the book.
A credible interim report must show:
- what evidence has been recovered;
- what hypotheses were framed;
- which hypotheses were tested;
- which possible causes were eliminated;
- which technical paths remain open;
- what further work is pending;
- how expert inputs were received and assessed;
- and whether the investigation has remained independent of institutional pressure.
An interim report should not be a placeholder. It should be a window into investigative discipline.
If the cause is not yet final, the method must at least be visible.
An interim report is a progress update — like a doctor who hasn’t finished every test yet. That is perfectly normal. What matters is that they show their working: which tests they ran, what they have ruled out, and what they are still checking — not just a one-line “still investigating.”
What We Know for Sure
From the preliminary sequence already in the public domain, we know the aircraft became airborne, reached the initial climb phase, and soon thereafter both engine fuel-control switches were recorded as transitioning from RUN to CUTOFF.
We also know that the RAT was seen deployed very early. The RAT hydraulic pump began supplying hydraulic power only seconds after liftoff. That timing is central.
A RAT does not deploy, extend, spin up and become effective instantaneously. If the aircraft was still over or close to the runway with the RAT already deployed, then the deployment command likely occurred extremely early — at or very close to rotation/liftoff.
That means the RAT may not be merely a consequence of both engines winding down after fuel cutoff. It may be evidence that an emergency electrical or power event was already underway before the recorded CUTOFF state became effective.
The RAT (Ram Air Turbine) is a small wind-powered emergency generator. It stays folded away in normal flight and only drops out into the airflow when the aircraft has lost its normal electrical or hydraulic power — a true last resort, like a hand-crank torch that only matters once the mains is gone.
So the key clue is timing. If the RAT was already out at the moment of lift-off, the aircraft had most likely lost power before the fuel reading went to OFF. In plain words: a power problem may have come first — the switch reading may be a result, not the cause.
This single issue changes the whole case.
If the RAT deployed only after both engines had spooled down, it may be a consequence. But if it deployed at or near rotation, it becomes an upstream clue.
That is why the final or interim report must disclose the exact RAT deploy command time and trigger logic. Not merely when the RAT produced hydraulic power. The command time is the forensic key.
The Fuel Switch Was the Symptom
The recorder may show a CUTOFF state. But a recorded state does not automatically prove physical cockpit movement.
The investigation must determine whether the CUTOFF state was:
- a physical movement of the cockpit switches;
- an interpreted electronic state;
- a Remote Data Concentrator input anomaly;
- a loss of power to fuel-switch channels;
- a bus-voltage or ground-reference disturbance;
- a BPCU, gateway or Core Network event;
- a relay or HPSOV control-power failure;
- or a fail-safe response to loss of a valid RUN state.
Until these possibilities are technically separated, the phrase “fuel switches moved to CUTOFF” is incomplete.
It describes what was recorded. It does not explain what failed.
The CUTOFF state is not the root cause. It is the clue.
A recorder shows what a system reported — not necessarily what physically happened. A reading of “fuel OFF” could mean a hand moved the switch, or it could mean the electrics and computers lost power or got confused and reported “OFF” on their own.
It is like your phone suddenly showing 0% and dying: sometimes the battery really is empty, sometimes the sensor was simply wrong. The list above is just the investigators’ checklist of every way that “OFF” reading could have appeared. Until they separate these, “the switch was OFF” explains nothing.
Four Pieces of Evidence That Shift the Case from WHO to WHAT
- The emergency wind turbine (RAT) was already out — power was already failing.
- The aircraft took about 10 seconds longer to get airborne — as if something was holding it back, like a brake not fully releasing.
- Smoke appeared near the wheels at lift-off — a cockpit switch cannot make smoke at the wheels, but a dragging brake or tyre can.
- The aircraft’s central data network had a known fault, and several different systems complained at once — one switch cannot upset that many systems together.
1. RAT Deployed Very Early
The early RAT deployment is the strongest reason why the fuel-switch narrative cannot be accepted at face value. If emergency power logic was already active at rotation or immediately after liftoff, the investigation must first explain the power-system event.
The interim report must reveal:
- RAT deploy command time;
- RAT trigger source;
- AC and DC bus status at the time of command;
- BPCU status;
- generator control breaker status;
- and whether the RAT command preceded the recorded CUTOFF transition.
2. Ten Seconds Longer Ground Roll
The reported 10-second longer ground roll cannot be ignored. A delayed airborne point is a physical performance clue.
If weight, thrust, temperature, runway condition, wind and configuration do not explain the delay, then abnormal rolling resistance becomes a serious line of inquiry.
That could include brake drag, tyre scrub, wheel bearing friction, a partially engaged electric brake actuator, anti-skid activity or asymmetric wheel/brake behaviour.
This matters because it places a possible abnormal condition before the recorded CUTOFF state.
Ground roll is the run an aircraft makes along the runway before it lifts off. Taking 10 seconds longer than expected is like a car that suddenly accelerates more slowly — often a sign of drag (here, “rolling resistance”), such as a brake that hasn’t fully let go. That points to a problem already present on the runway, before the fuel reading ever changed.
3. Smoke Plume at Liftoff
The smoke plume at liftoff is not a minor visual detail. A cockpit switch does not create smoke near the main gear.
A plume at rotation is more consistent with energy dissipation at the tyre, brake, wheel or runway interface. During rotation, weight comes off the wheels. If a wheel or brake assembly is already under abnormal drag, it can begin to scrub or skid, producing a brief smoke plume.
The interim report must therefore explain the smoke source. It must disclose whether investigators examined:
- tyre flat-spotting;
- runway rubber marks;
- brake-pack heat damage;
- wheel-speed traces;
- EBAC/EBA fault memory;
- anti-skid activity;
- and gear-up wheel-braking commands.
Smoke near the wheels usually means heat and friction down there — a tyre scrubbing or a brake dragging — not anything happening on a switch in the cockpit. It is the same smoke you might see from a car wheel when a brake is stuck on. So the report has to explain where that smoke came from, by examining the tyres, brakes and wheel sensors.
4. Core Network MEL and Multi-System Messages
The aircraft reportedly had a Core Network MEL active. That fact must not be buried.
A Core Network MEL is not a broken seat tray or cosmetic cabin item. On a Boeing 787, the network architecture is part of how systems communicate, validate, route and report data.
If the aircraft also generated BPCU Gateway OPS, FCM, GPM, HYDIM and CMCF-type messages, the investigation must explain whether those were historical, active, consequential or causal.
The crew may not have seen those messages on EICAS. But that does not make them irrelevant. They may be maintenance or aircraft-health-monitoring messages. Their importance lies in the fact that they span multiple systems.
A single cockpit action does not naturally explain a multi-system gateway/power/network message burst.
The Boeing 787 runs much of itself through a central computing-and-data network — its Core Network. Picture it as the aircraft’s nervous system, or a building’s central telephone exchange: it carries messages between the engines, electrics, brakes, cockpit displays and recorders so they can all talk to one another.
A MEL (Minimum Equipment List) entry means a piece of equipment was allowed to be partly unserviceable for that flight, under strict conditions — rather like being legally allowed to drive for a limited time with one fog-light out.
Why this matters: if the nerve centre is even slightly degraded, messages between systems can be delayed, mis-routed or lost — like a telephone exchange where calls drop or get crossed. A reading on the recorder might then reflect a network or data hiccup rather than a real physical event. That is exactly why a “Core Network MEL” plus a burst of complaints from several different units — electrical, gateway, processor and the maintenance computer — cannot be brushed aside. One cockpit switch cannot set off that many systems at once; a sick central network can. (Full forms of BPCU, GPM, FCM, HYDIM, CMCF and EICAS are in the glossary below.)
The Interim Report Must Show the Investigation Followed the Book
If an interim report is issued, it must do more than repeat facts. It must show investigative method.
A serious interim report should include a clear hypothesis table. For each possible cause, it should state:
- what evidence supports it;
- what evidence contradicts it;
- what tests were performed;
- what has been eliminated;
- what remains open;
- and what work is pending.
For AI171, such a table should include at least:
- physical movement of fuel-control switches;
- electronic false CUTOFF state;
- fuel-switch channel power loss;
- HPSOV or fuel-valve control-power failure;
- BPCU / electrical bus disturbance;
- Core Network / gateway / data-routing issue;
- RAT-triggering power event;
- wheel/brake/tyre abnormal rolling resistance;
- electric brake actuator or EBAC abnormality;
- maintenance or MEL interaction;
- and any human-factors scenario considered.
Only such a structure can convince the reader that the investigation is not following a narrative, but following evidence.
A good investigation lists every possible explanation, then for each one says: what supports it, what rules it out, and what was tested. It is the difference between a detective who shows the whole board of suspects and how each was cleared, versus one who simply names a culprit. The list above is that board of suspects for AI171.
Independence Must Be Visible
Independence is not merely a legal label. It must be visible in the report.
The interim report must show that the investigators were not simply accepting the easiest explanation, the most convenient narrative, or the position of any stakeholder — whether airline, manufacturer, regulator or government.
A credible report should disclose:
- which agencies participated;
- which accredited representatives assisted;
- what data each party accessed;
- what technical tests were performed independently;
- what manufacturer interpretations were accepted or rejected;
- what disagreements existed, if any;
- and whether all alternative hypotheses were tested before being eliminated.
The public does not need confidential proprietary design data. But it does need confidence that the investigation was not steered toward a predetermined conclusion.
Independence must not merely be claimed. It must be demonstrated through method.
Investigators must not simply take the word of the airline, the manufacturer or the government — they have to show they checked things for themselves. It is like getting your own independent surveyor before buying a house, instead of trusting the seller’s description.
How Were Expert Inputs Handled?
In an accident of this nature, external expert inputs are not a distraction. They are a safety resource.
Experts may submit alternative technical explanations, system observations, data correlations, timing concerns, MEL-related questions, or component-level failure possibilities. The investigation does not have to accept every submission. But it must show that serious submissions were received, assessed and disposed of properly.
A credible interim report should include an appendix or summary table showing:
- how many expert submissions were received;
- the broad technical categories of those submissions;
- whether they related to electrical power, fuel-control logic, engine systems, human factors, maintenance, MEL, braking, network architecture or recorder interpretation;
- which submissions triggered additional tests;
- which were accepted as relevant;
- which were rejected;
- and the technical reason for rejection.
This is not about giving every expert the final word. It is about showing that the investigation did not ignore credible safety concerns.
For AI171, expert inputs concerning early RAT deployment, Core Network MEL, BPCU Gateway messages, raw fuel-switch channels, smoke at liftoff, longer ground roll and brake/wheel/EBA evidence should be specifically addressed.
A simple line saying “inputs were considered” is not enough.
The report should show how they were considered.
Outside experts often spot things the core team misses, so their submissions are a safety resource, not interference. The investigation doesn’t have to agree with every one — but it should show it actually read them and explain why each was accepted or set aside, rather than a vague “we considered all inputs.”
What the Final or Interim Report Must Reveal
1. RAT Deploy Command Time and Trigger Reason
The report must reveal the command time and trigger reason for RAT deployment. The time when hydraulic power became available is not enough.
2. Raw Fuel-Switch Channel Data
The report must disclose raw channel data, not only decoded CUTOFF. It must show whether the channels behaved like a physical movement or like an electrical/data anomaly.
3. HPSOV / Fuel-Valve Command and Actual State
The report must separate command from position. Did the valves close because they were commanded closed, because holding power was lost, or because the system interpreted a false CUTOFF?
4. BPCU, GPM, FCM and CMCF Event Chronology
The report must align every relevant message by occurrence time, detection time, latching time, transmission time and reset time.
5. Exact Core Network MEL Details
The report must identify the exact MEL item, affected LRU or network path, dispatch condition, redundancy loss and operational effect.
6. Wheel, Brake, Tyre, EBAC/EBA and Smoke-Source Evidence
The report must explain the reported longer ground roll and smoke plume with physical evidence.
7. Bus Voltage, Battery, Contactor and Network Integrity Timeline
The report must disclose the second-by-second power and network state around liftoff, CUTOFF, RAT deployment and relight.
These seven points ask for the raw, second-by-second record — not a tidied-up summary. The difference matters: a “decoded” reading just says OFF, while the raw data can show whether that “OFF” behaved like a real hand-flicked switch or like an electrical glitch. Point 3 is the same idea for the fuel valve: did it close because it was told to, or because it lost power? Those are very different stories.
Why “Inconclusive” Would Not Be Enough
In some accidents, an inconclusive finding may be unavoidable. But AI171 had recorded data, system messages, maintenance history, MEL status, wreckage, engines, switch positions, RAT timing and physical visual evidence.
If the report remains inconclusive, it must explain why the evidence could not resolve the cause despite all tests.
It must not be inconclusive because uncomfortable technical paths were not pursued.
If the cause is technical, it must be found. A technical cause does not end with one crew. It may affect every aircraft exposed to a similar combination of failures, deferred defects, power transients, network degradation, brake anomalies or software/data interpretation problems.
A technical cause, if it exists, must be identified to protect every other aircraft exposed to the same chain of events.
With this much evidence — the recorders, the wreckage, the engines, the switches, the maintenance records — “we couldn’t tell” is only acceptable if every avenue was genuinely exhausted. And if the cause turns out to be a technical fault, it is not a one-off: every other aircraft of the same type could be carrying the same hidden risk. Just as a carmaker recalls every car with a faulty brake, a technical cause here must be found and fixed across the whole fleet.
Conclusion: One Year Later, AI171 Deserves More Than a Narrative
On the first anniversary, the families deserve more than a line in an interim report. The profession deserves more than speculation. The public deserves more than a narrative.
If an interim report is released, it must show that the investigators have followed the book, tested competing hypotheses, eliminated alternatives, examined technical evidence, disposed of expert inputs, and acted independently.
The fuel switch was the symptom.
The root cause lies deeper.
The real question is not who moved a switch.
The real question is:
What failed before the aircraft recorded CUTOFF?
That is the question the interim report must confront.
That is the question the final report must answer.
A Plain-English Glossary
Every abbreviation used above, with its full form and what it means in everyday language.
- RAT — Ram Air Turbine
- A small wind-driven emergency generator that drops into the airflow to provide power only when normal power is lost. If it is deployed, the aircraft had already lost its normal electrical or hydraulic power.
- RUN / CUTOFF
- The two positions of an engine’s fuel-control switch. RUN lets fuel flow to the engine; CUTOFF shuts it off.
- Fuel-control switch
- The cockpit switch that allows or stops fuel reaching an engine.
- HPSOV — High-Pressure Shut-Off Valve
- The valve that physically stops high-pressure fuel entering the engine — in effect, the “tap” at the engine itself. It can close because it was told to, or because it lost power.
- Core Network
- The aircraft’s central data network — its “nervous system” — that carries messages between systems. If it degrades, messages can be lost, delayed or mis-routed.
- MEL — Minimum Equipment List
- The approved list of equipment that may be temporarily out of service for a flight, under set conditions. Like being legally allowed to drive for a limited time with a minor item not working.
- BPCU — Bus Power Control Unit
- The “manager” of the electrical system, deciding which power source feeds which electrical circuits. Think of it as the brain of the fuse-box.
- Bus (AC bus / DC bus)
- A shared electrical bar that distributes power to many circuits — similar to a household distribution board.
- Contactor
- A heavy-duty automatic electrical switch that connects or disconnects power sources.
- GPM — General Processor Module
- One of the shared computers in the 787’s central system that run many of the aircraft’s software functions.
- CMCF — Central Maintenance Computing Function
- The aircraft’s built-in self-diagnostic system that records and reports faults — much like a car’s “check-engine” computer.
- Gateway
- Equipment that passes data between different networks or systems on the aircraft — a junction or relay point for information.
- FCM
- A control/monitoring module that appeared with a fault in the recorded messages. (The exact manufacturer full form is not publicly standardised; treat it as one of the system modules that flagged a problem.)
- HYDIM
- A hydraulics interface module — the unit that links the hydraulic system to the data network. (Designation per manufacturer usage; named here as reported.)
- RDC — Remote Data Concentrator
- A unit that collects signals from switches and sensors and puts them onto the data network — a local “translator” between wiring and the network.
- EICAS — Engine Indicating and Crew Alerting System
- The cockpit display that shows the crew warnings and system messages — the “dashboard” alerts. Many maintenance messages never appear here.
- EBAC / EBA — Electric Brake Actuator (Controller)
- The 787 uses electric brakes; these units control and apply them. A partly-engaged brake could drag the aircraft.
- Anti-skid
- A system that stops the wheels locking up — the aircraft equivalent of ABS on a car.
- Flat-spotting
- A flattened, worn patch on a tyre caused by skidding.
- APU — Auxiliary Power Unit
- A small engine, usually in the tail, that supplies electrical power and air — used on the ground and as a backup in flight.
- Relight
- Restarting an engine that has stopped, while still airborne.
- LRU — Line-Replaceable Unit
- A self-contained box or module that can be swapped out quickly during maintenance, without rewiring.
- Ground roll
- The distance and time the aircraft spends accelerating on the runway before lifting off.
- Rolling resistance
- Friction that resists the wheels rolling — for example a dragging brake — which makes the aircraft accelerate more slowly.
- V1 / Vr
- Take-off speeds. V1 is the “decision speed” (the last point at which a take-off can be safely abandoned); Vr is the “rotation speed” (the speed at which the pilot raises the nose to fly).
- CVR / FDR
- Cockpit Voice Recorder and Flight Data Recorder — the “black boxes.”
Discover more from Safety Matters Foundation
Subscribe to get the latest posts sent to your email.
