Bird Strike, Terminal 2

Part 5 of 6 in the Iron Core series: the 60-year-old infrastructure that flies 4.5 billion people a year.

BA1361 was late leaving Manchester.

I watched the departure board tick past 09:40 with no gate movement. I had already pulled up FlightRadar24. The aircraft, callsign SHT3R, showed its first GPS ping at 10:28 UTC, still on the ground at Manchester Terminal 2. First movement at 10:35. Wheels up at 10:49: sixty-nine minutes behind schedule.

I did the maths on the descent. Landing around 11:40. Terminal 5 to Terminal 2 at Heathrow: at minimum 35 minutes, accounting for the inter-terminal shuttle, security, and the walk. AI112 was scheduled to depart at 13:00. I had, in the best case, about 45 minutes of margin.

It would not be enough if the incoming aircraft was already late.

The incoming aircraft was late.

The Incoming Aircraft: VT-AEQ, AI111

AI112 (LHR→DEL) is an outbound rotation. The aircraft that operates it arrives from Delhi as AI111. In aviation, the inbound and outbound legs of a rotation share a tail number: the same physical aircraft, turning around at the destination.

On 16 February 2026, that aircraft was VT-AEQ: a Boeing 787-8 Dreamliner registered to Air India. It had departed Delhi at 02:09 UTC, operating as AI111.

I know this because FlightRadar24's ADS-B data captures the entire flight. From the CSV export:

Callsign:  AIC111
Departure: 2026-02-16T02:09:50Z (Delhi: VIDP)
Arrival:   2026-02-16T12:41:33Z (London Heathrow: EGLL)
At gate:   2026-02-16T12:52:33Z
 
Route:
 02:09Z Delhi (28.56°N, 77.08°E) takeoff
 03:07Z Gujarat coast (23.73°N, 72.17°E) FL300, 442 kts
 04:31Z Oman coast (23.30°N, 61.33°E) FL300, 442 kts
 05:50Z Persian Gulf (26.61°N, 51.23°E) FL340, 454 kts
 06:54Z Iraq (32.51°N, 45.01°E) FL340, 468 kts
 09:24Z Black Sea (42.66°N, 28.28°E) FL360, 466 kts
 10:19Z Hungary (46.44°N, 19.94°E) FL360, 450 kts
 11:52Z Netherlands coast (51.67°N, 4.52°E) FL360, 430 kts
 12:24Z Descending over Essex (51.55°N, 0.23°E) 11,900 ft
 12:41Z Wheels down, Heathrow
 12:52Z At gate, Terminal 2

10 hours and 32 minutes from wheels-up in Delhi to wheels-down in London. AI111's scheduled arrival at LHR is around 12:15. VT-AEQ landed 26 minutes behind schedule.

The Tightening Window: Minute by Minute

Parallel to VT-AEQ's descent into Heathrow:

11:40Z  BA1361 wheels down, Heathrow Terminal 5
        SHT3R telemetry confirms: 53.47°N, -0.49°E, LHR runway 27L
 
11:49Z  BA1361 at gate, Terminal 5
        54 minutes late against the 10:55 scheduled arrival
 
        I have to reach Terminal 2.
 
        Options:
        A) Heathrow Express underground link T5→T3→T2 (~20 min)
        B) Inter-terminal bus service (~25 min)
 
        AI112 scheduled departure: 13:00Z
        Time available: 71 minutes
        Terminal transfer: ~35 minutes minimum
        Margin: 36 minutes, if AI112 is on time.
 
~12:30Z I clear into Terminal 2. Departure board: AI112 DELAYED.
        Relief. Conditional relief.
 
        I check FlightRadar24. AIC111 is on final approach.
12:41Z  I watch the telemetry stop descending.
12:52Z  The aircraft is at the gate.
 
        The departure board updates: AI112 → 14:15

The 14:15 is not arbitrary. Minimum ground time for a Boeing 787 wide-body is typically 60 to 75 minutes: offboard passengers, clean cabin, board new passengers, fuel, catering, load bags, pushback. VT-AEQ at the gate at 12:52 plus 75 minutes minimum equals 14:07. The 14:15 departure is the system's calculated realistic earliest departure.

I had two hours. I found a seat in Terminal 2 and ordered coffee.

The Bird Strike: What Actually Happened

Somewhere between 12:52Z and 14:57Z, VT-AEQ suffered a bird strike.

I do not have the engineering inspection report. What I know is what the Air India ground staff at Terminal 2 told me, and what the subsequent rebooking implied: the aircraft was grounded. The distinction between a delay and a grounding matters enormously.

A delay means the aircraft will eventually depart. Ground operations continue, passengers wait, the departure time updates on the board.

A grounding means the aircraft is removed from service pending inspection or maintenance. Any flights that depend on it are cancelled. The passengers on those cancelled flights become the responsibility of the airline's disruption management system, and of every human agent at a desk at that moment.

VT-AEQ was grounded. AI112 was cancelled.

The PNR in Real Time: DHB4AL Under Stress

At 14:57 UTC, the Air India disruption management system fired a change notification:

Subject: Change in Flights for DHB4AL
 
We would like to inform you that your booking under reference DHB4AL
has been updated. Please note that your booking on the original
flight has been cancelled/modified.
 
ORIGINAL FLIGHTS:
  AI 112 LHR → DEL  14:15 → 05:10+1
  AI 415 DEL → NAG  06:20 → 08:05
 
UPDATED FLIGHTS:
  AI 130 LHR → [BOM]  21:00 → [arrival]
  AI 2583 [BOM] → NAG  19:55 → 21:30

This notification is the output of the automated re-accommodation: the system's first pass at finding an alternative. Within minutes of the cancellation decision, Altéa's disruption module had:

Identified all passengers on AI112 with onward connections
Queried available inventory on alternative routings
Provisionally assigned passengers to new flights
Updated the PNR segments
Triggered outbound notifications

The speed is a consequence of automation at scale. The result is acceptable. The Air India ground staff at Terminal 2 knew it was not optimal.

The PNR State Machine: Four Transitions in One Day

DHB4AL went through four distinct states on 16 February. Each transition was a set of segment status changes inside Amadeus Altéa:

STATE 1: Original booking (05 December 2025):
  BA1361 MAN→LHR HK1  09:40  ← British Airways leg
  AI112  LHR→DEL HK1  13:00  ← confirmed, original time
  AI415  DEL→NAG HK1  06:20  ← confirmed
 
STATE 2: Silent schedule change (January–February):
  BA1361 MAN→LHR HK1  09:40  ← unchanged
  AI112  LHR→DEL HK1  14:15  ← departure time updated, no notification
  AI415  DEL→NAG HK1  06:20  ← unchanged
 
STATE 3: Post-cancellation automated re-accommodation:
  BA1361 MAN→LHR HK1  09:40  ← flew ✓
  AI112  LHR→DEL XX1  14:15  ← voided: status flipped to XX
  AI415  DEL→NAG XX1  06:20  ← cascading void
  AI130  LHR→BOM HK1  21:00  ← new segment inserted
  AI2583 BOM→NAG HK1  19:55  ← new segment inserted
 
STATE 4: Manual agent override (Terminal 2 desk):
  BA1361 MAN→LHR HK1  09:40  ← flew ✓
  AI112  LHR→DEL XX1  14:15  ← voided (unchanged from state 3)
  AI415  DEL→NAG XX1  06:20  ← voided (unchanged from state 3)
  AI???  LHR→BOM HK1  ??:??  ← agent found better option
  AI???  BOM→NAG HK1  ??:??  ← routing via Mumbai

In States 3 and 4, the PNR locator DHB4AL did not change. The ticket number 098-5801178359 did not change. What changed was everything the locator pointed to. The six characters are stable. The data structure underneath is entirely rebuilt.

This is what eventual consistency looks like in a system that predates the concept by forty years.

The SSR Problem: What the System Missed

When segments are cancelled and new ones inserted, the SSRs (Special Service Requests) become orphaned. My HNML (Hindu meal) request was confirmed on AI112. AI112 no longer exists in my booking. The new segments do not automatically inherit the SSR.

In the automated re-accommodation (State 3), the disruption system may or may not re-associate SSRs to the new segments: this depends on Altéa's configuration and whether the disruption was flagged as involuntary. In practice, SSR handling after involuntary re-routing is inconsistent across implementations, and re-confirming meal requests is standard advice from airline customer service teams after any involuntary rebook.

In State 4, the agent who manually rebooked me had to:

Cancel the automated State 3 segments
Sell new segments for the LHR→BOM→NAG routing
Re-add the SSR elements to the new segments
Confirm the upgrade status (or void it, if the upgraded cabin was not available on the new flights)
Reissue the boarding passes

From the passenger side, this took about ten minutes at the desk. From the systems side, it was roughly 15 to 20 cryptic commands executed in the Altéa agent interface: each one precisely modifying a specific element of a specific PNR, with no undo.

The Human in the Loop

The automated re-accommodation system did what it was designed to do: found available seats, allocated them, updated the PNR, and notified the passenger, all within a few minutes of the cancellation.

The Air India agent at Terminal 2 looked at AI130 and AI2583 and found a better routing via Mumbai that gave me a more manageable connection time home. She knew the schedule, knew which flights had availability in my booking class, and knew the Nagpur connection options from Mumbai better than the algorithm, because she had made this kind of judgement many times.

The automated system was not failing when it returned a suboptimal answer. At scale, when hundreds of flights disrupt simultaneously, automated re-accommodation handles thousands of passengers in seconds. No human team could do that. The algorithm optimises for speed and inventory availability under time pressure, not for schedule knowledge that comes from operational familiarity.

The architecture that allows a human agent to override automated decisions within defined guardrails is not a workaround. It is a correct choice about where automation's value ends. The automated path handles scale; the human handles the cases the algorithm did not model.

What This Journey Cost the System

The disruption to DHB4AL on 16 February was an involuntary re-routing caused by the airline. Under UK aviation regulations (UK261, derived from EU261), I was entitled to:

Rebooking on the next available flight to my destination at no additional cost ✓
Meals and refreshments during the wait (Air India provided vouchers) ✓
Hotel accommodation if the wait extended overnight (it did not) ✓
Compensation if the delay at destination exceeded 3 hours (it did, by several hours)

The compensation calculation under UK261 for a flight over 3,500km delayed by more than 4 hours at destination is £520 GBP. Air India's systems log the disruption cause, re-accommodation details, and delay at destination: all of which feed into the compensation processing system. That system is a domain problem in its own right, determining liability, calculating entitlement, and processing claims at scale across thousands of disrupted passengers.

I will not detail it here. It is, I am told, not a fast one.

Lessons Learned

Make your state machine explicit before you model your happy path. DHB4AL went through four states in a single day. The system handled each transition because the PNR is an explicit state machine: segment statuses (HK, XX, TK) are first-class values, not inferred from boolean flag combinations. When a segment is cancelled, the system records that it is cancelled. When a new segment is inserted, it carries a defined status. That explicitness applies to itinerary structure; ancillary data can still drift, as my HNML SSR demonstrated. Build your domain models with the same principle: explicit states, explicit transitions, invalid combinations pushed to unrepresentable paths where possible.

Automated re-accommodation is correct for scale; human override is correct for edge cases. The disruption system found available inventory and kept DHB4AL moving. The agent found a better itinerary the algorithm had not ranked first. An architecture that allows both, automation for the common case and human override within guardrails for the edge case, is the right design, not a compromise between two inadequate options.

Cascading dependencies belong in the domain model, not the application code. When AI112 was cancelled, AI415 was also voided automatically: a passenger who cannot reach Delhi cannot board a Delhi→Nagpur flight. The system understood this dependency and voided the downstream segment without requiring explicit agent action. That understanding was in the data model, expressed as a PNR dependency between connected segments. Application code that manually cascades cancellations is fragile; the domain model that makes the dependency explicit is not.

Next: Part 6: The Revolution That's Taking Forever. NDC, the political economy of airline distribution, and why my ContainerDays booking still went through Amadeus cryptic in 2026.

The Iron Core is a six-part series by Ajitem Sahasrabuddhe. Ajitem is a software engineer at Technogise and spoke at ContainerDays 2026 in London.