AI-171: what the fault history must contain

When an intermittent fault keeps returning on an aircraft, the history that must be produced is precise: each dated occurrence, each traced reset, each documented troubleshooting action, each deferred defect with its deadline. That is exactly the chain of evidence that, according to Indian media reports, the pilots' federation has just asked the AI-171 investigation to review.

What the Indian pilots' federation is asking

On 12 June 2025, Boeing 787-8 registration VT-ANB, operating Air India flight 171 from Ahmedabad to London, crashed shortly after takeoff: 241 of the 242 occupants and 19 people on the ground lost their lives. The preliminary report from the Indian accident investigation bureau, published on 12 July 2025, set out the recorded facts without concluding. In its interim statement of 12 June 2026, the AAIB said the final report will be released once all investigative activities and the international review and consultation prescribed by ICAO Annex 13 are completed, without giving a date; it is the draft final report that was placed around October 2026 in proceedings before the Indian Supreme Court.

On 18 September 2026, the Federation of Indian Pilots wrote to the AAIB Director General, as reported by IANS dispatches and several Indian outlets (Free Press Journal, Asianet Newsable). The letter calls for a comprehensive evaluation of evidence linked to the electrical, electronic and avionics systems, and a review of the aircraft's entire maintenance and reliability history: technical log entries, deferred defects, repetitive defect reports, troubleshooting records, component replacements, service difficulty reports, reliability monitoring data and engineering corrective actions.

The letter also mentions technical material passed to the investigation by the Foundation for Aviation Safety on the aircraft's operational history, and states that the AAIB acknowledged receiving information through the expert from the UK accident investigation bureau (AAIB UK) assisting the investigation, according to the federation. These elements are press-reported; the text of the letter itself had not been published online by the FIP at the time of writing.

That detail matters: a request from a pilots' federation is not an investigator's conclusion. It says something else, more useful to any operator: if a fault keeps returning, someone must be able to produce its complete history.

What the rules already require you to keep

Air India falls under Indian regulations, the DGCA's CAR-M and CAR-145, but the expected family of records is similar across the frameworks documented here. Under European law, Regulation 1321/2014 sets the reference framework: point M.A.305 organises the continuing airworthiness record system, with the status of airworthiness directives, modifications and repairs, the progress of the maintenance programme, tasks and defects whose correction is deferred, the status of life-limited parts and time-controlled components, certificates of release to service and detailed maintenance records. For commercial operators (commercial air transport, commercial aerial work, commercial training organisations), point M.A.306 adds the technical log, where the crew records every defect observed in flight and maintenance records every action; for every operator, point M.A.403(d) requires any defect not corrected to be recorded before flight.

The rule also sets durations: point M.A.305(e)(1) requires the technical log to keep data covering the 36 months preceding the last entry, and the whole file outlives the sale of the aircraft since point M.A.307 requires its transfer to the buyer. In other words, the history is not an internal convenience: it is part of the product.

A recurring fault must stay readable occurrence by occurrence

The awkward case is not the hard fault, which grounds the aircraft and gets repaired. It is the intermittent fault: the message that lights up, disappears after a reset, then returns three flights later. If each occurrence is not dated and traced, the history shrinks to a workshop memory. The word "intermittent" is ours: the letter speaks of repetitive defects. This article draws a general operating lesson from it, with no established link to this accident.

For an intermittent fault to remain readable, each occurrence must bring together four things: the date, the flight and the message as the crew saw them; the reset or immediate action, with its author; the troubleshooting carried out and its outcome, including "no fault found", which is an outcome; and, if the defect is deferred, its repair category and deadline. The FIP letter lists the same families of records, from the investigator's side this time: repetitive defect reports, component replacements, reliability data.

A fictional case: producing the history on demand

Take an invented example. Mina runs the CAMO of a regional operator. A sensor alert has been returning on a turboprop at irregular intervals for four months. The authority asks for the history.

If the file is kept properly, producing it takes an hour: seven dated occurrences, four of them closed as "no fault found", two documented resets, a sensor replaced last month, and the reliability monitoring showing the recurrence. If the file is patchy, the same request becomes an internal investigation: who saw what, on which day, and why nothing was written down. The difference does not play out on the day of an accident; it plays out every week, at the first question asked.

The history documents, it does not conclude

What the FIP is asking for AI-171 is a complete reading of the technical trail, and the investigation will decide what it establishes. For an operator, the lesson is shorter and independent of the outcome: a fault that keeps returning must be re-readable occurrence by occurrence, without relying on memory. That is also the lesson of our article on Korean Air's maintenance records, where the readability of the file conditioned everything else.

The question to ask your own file is simple: for the latest intermittent fault in your fleet, could you produce tomorrow every dated occurrence and every documented troubleshooting action?