From GDS to Gate

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

8 February 2026. 05:30. Dr. Babasaheb Ambedkar International Airport, Nagpur.

The Air India counter is open. The check-in queue is short. I place my passport on the desk. The agent types something, glances at her screen, and tags my bag without hesitation.

She is not looking at the GDS.

The GDS, Amadeus, the system that created PNR DDTCIV back in December, finished its job months ago. It confirmed the seat, issued the e-ticket, and stored the booking. It has not been meaningfully involved since. What the agent is looking at is Amadeus Altéa DCS: the Departure Control System. A separate application, built on a separate data layer, optimised for a completely different job.

The handoff from booking to departure is one of the least understood transitions in aviation systems. Most passengers assume the departure gate is querying the same database that took their booking. It is not. Understanding why requires understanding what actually happens in the 12 hours before a flight.

The System Handoff

The GDS holds the commercial record of your booking. The PSS (Passenger Service System), in Air India's case Amadeus Altéa, holds the operational record. These are distinct but linked.

When a flight is created in the airline's scheduling system, it triggers a cascade:

The DCS is activated roughly 24 hours before departure (the exact window varies by airline policy and configuration; T-24 is a useful mental model, not a universal constant). At that point, it pulls the passenger manifest from the PSS: all bookings with their PNR data, seat assignments, SSR requests, and APIS information. From this moment, the DCS is the system of record for the flight. The GDS is a read-only historical reference.

When the check-in agent queries my booking at NAG, she is querying the DCS: looking up the flight AI416 manifest for 8 February, finding my name, and confirming my e-ticket status against the ETD (Electronic Ticket Database).

What the Check-in Agent Actually Does

The sequence at the counter:

The through-tagging of bags, a single tag routing NAG→DEL→LHR, is itself a systems problem. The baggage routing system must know that AI416 connects to AI2015 on the same PNR, that both segments are in the same booking class, and that the connection at Delhi is within the baggage transfer window. If any of those conditions were not met, the agent would tag two separate bags for two separate segments.

The BCBP Barcode: What the Gate Scanner Reads

Every boarding pass, printed, mobile, or digital, contains a barcode following IATA Resolution 792: the Bar Coded Boarding Pass standard. It encodes a structured data string that the gate scanner reads in milliseconds.

The format for my NAG→DEL boarding pass would look like this:

M1SAHASRABUDDHE/AJITEM DDTCIV NAGDEL AI 0416 039Y001A0000

Breaking it down:

M1
  Format code M (BCBP), 1 leg (this boarding pass covers one segment)
 
SAHASRABUDDHE/AJITEM
  Passenger name: surname/given name, space-padded to 20 chars
 
DDTCIV
  PNR locator: the six characters from the booking
 
NAG
  Origin airport IATA code
 
DEL
  Destination airport IATA code
 
AI
  Airline IATA code
 
0416
  Flight number, zero-padded to 4 digits
 
039
  Julian date: day 039 of 2026 = 8 February
 
Y
  Compartment code (cabin class for operational purposes)
  Note: Y here is the cabin code, not the fare class Z
  Business cabin on AI domestic is operationally Y on a narrow-body
  where business is the front rows of a single cabin
 
001A
  Seat number: row 1, seat A
 
0000
  Check-in sequence number

The gate scanner reads this barcode, validates the PNR locator against the DCS manifest, confirms the e-ticket is OPEN (not used) in the ETD, marks the coupon as USED, and opens the gate. The DCS updates the boarding count. The load and balance system receives confirmation that seat 01A is occupied. If the aircraft hits its boarding deadline with unoccupied seats, the gate agent queries the DCS to identify which passengers have not boarded, and the offloading process begins.

APIS: The Invisible Border Check

Before I boarded AI2015 from Delhi to London, Air India transmitted my passport data to the UK Home Office via APIS: Advance Passenger Information System. This is mandatory for all flights entering the UK, and has been since 2003.

The data flow:

If the Home Office system returns a flag, a visa discrepancy, a watchlist match, an incomplete submission, Air India receives a "No Board" notification before the aircraft departs. The passenger is denied boarding on the ground, not at the UK border. This is deliberate: identifying inadmissible passengers before departure is significantly cheaper and operationally simpler than handling them after the aircraft crosses into UK airspace.

The APIS submission uses a structured message format transmitted over SITA's network: the same SITA Type B messaging infrastructure described in Part 1. A message format from 1949 still carrying passport data in 2026.

Air India's Altéa Migration: Why This Matters

Before 2023, Air India ran on a legacy SITA DCS system. The migration to Amadeus Altéa, completed in phases across 2022 and 2023, was one of the largest PSS migrations in Asian aviation history.

The migration involved:

Moving the active PNR database, decades of booking history, into Altéa's data model
Re-integrating the Flying Returns loyalty programme
Retraining thousands of airport agents across India and international stations
Rebuilding the interface between Air India's revenue management system and Altéa's inventory module
Migrating interline and codeshare agreements into the new system
Rebuilding the APIS transmission layer

In the months following the migration, there were reports of check-in system slowdowns at peak periods, interline booking inconsistencies, and loyalty point reconciliation issues. These are predictable outcomes of moving a live system from one substrate to another while it continues to operate. The complexity is not a reflection of Altéa's quality; it is a property of the migration problem itself. Every dependency that was not mapped during planning became a production incident after go-live.

What Air India gained: a modern, cloud-adjacent PSS with better NDC capability, improved self-service tooling, and a shared infrastructure with dozens of other airlines on the same platform. The network effect of Amadeus Altéa, where improvements to the platform benefit all member airlines, is the long-term payoff.

IndiGo's Different Path: Navitaire at NAG

IndiGo runs Navitaire NewSkies: a PSS built from the ground up for low-cost, high-frequency, point-to-point flying.

Where Altéa is a monolithic platform covering reservations, departure control, and revenue accounting, Navitaire is more modular. Its DCS, AirportConnect Open, is designed for fast check-in flows with minimal complexity, optimised for an airline that turns around aircraft in 25 minutes rather than 75.

The trade-offs are visible at the airport:

Navitaire works for IndiGo for the same reason TPF works for airline inventory: hard specialisation for a specific workload, with the interoperability cost accepted as deliberate rather than accidental. The complexity that handles my NAG→DEL→LHR through-ticketing, SSR meal requests, and APIS data is overhead that IndiGo's model does not require and does not pay for.

The Departure Board: What Updates It

The departure boards at NAG are fed from the Altéa/Navitaire DCS, which receives updates from the airline's operations control system.

When AI416 is delayed, the sequence is:

The GDS receives a passive update: a notification that the schedule has changed, which it records in the PNR without requiring agent action. This is how the AI112 schedule change from 13:00 to 14:15 happened silently between December and February: the airline changed its operational schedule, Altéa propagated it to the GDS, and the GDS updated the PNR without triggering active passenger notification.

This behaviour is by design. A 75-minute schedule change is within normal operational variance. The system only triggers active notification above a configurable threshold, because notifying every passenger of every sub-90-minute adjustment would erode trust in notifications by generating more noise than signal. The threshold is a product decision, not a technical limitation.

Lessons Learned

Separating commercial and operational concerns avoids cross-system load coupling. The GDS and the DCS serve different masters: commercial and operational respectively. Coupling them tightly would mean check-in performance depends on booking system load and vice versa. The system avoids this with an explicit handoff at a defined moment (roughly T-24), after which the GDS becomes a read reference and the DCS becomes the authority. The same pattern applies whenever two systems have different load profiles and different consistency requirements: define the handoff point, specify who owns what after it, and treat the prior system as read-only.

Explicit ownership boundaries resolve agent disputes. At the moment of check-in, exactly one system owns the passenger's status: the DCS. The GDS, loyalty system, and baggage system all receive updates, but the DCS is the arbiter when they disagree. Without a defined authority, every conflict between screens becomes an unsolvable ambiguity for the agent standing in front of a passenger.

Notification thresholds are a design decision, not a default. The passive GDS update that changed AI112's departure time without notifying me was the correct behaviour for a 75-minute shift. The threshold for active notification should be set to the point where the change requires passenger action. Below that threshold, silent propagation is correct. The threshold itself needs to be explicit in the system configuration, not implicit in the code.

Next: Part 5: Bird Strike, Terminal 2. What happened when everything broke, and what a 60-year-old system did about it.

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.