The Command Line That Never Died

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

Walk into any Air India ticketing office. Find an experienced agent. Watch their hands.

They are not using a website. They are not navigating a dropdown. They are typing something that looks, at first glance, like a cat walked across the keyboard:

AN08FEBNAGDEL

In under half a second, every seat on every flight from Nagpur to Delhi on 8 February appears on their screen: formatted, structured, and actionable, without a web-style loading spinner or mouse-driven form flow.

This is Amadeus cryptic mode: a command-line interface designed in the 1960s, when characters cost money and response time was measured against the speed of a teletype. It is still the primary interface used by travel agents worldwide to build, modify, and retrieve airline bookings. For a trained operator, it is still faster than a typical consumer-style graphical interface for the same booking workflow.

Let me show you how it built my ContainerDays booking.

Why Cryptic Still Exists

The design philosophy of cryptic mode was born from a hard constraint: teletype terminals in the 1960s billed by the character transmitted. Every keystroke cost money. A command that took 50 characters instead of 10 cost five times as much. Commands were compressed to the absolute minimum.

The result is a domain-specific language with a syntax shaped entirely by economics. AN for Availability Next. SS for Sell Segment. NM for Name. ER for End and Retrieve. No vowels wasted. No words spelled out.

What survived the teletype era is not the economic constraint, but the interface it produced, and that interface turns out to have properties that matter independently of cost:

Expert throughput. A trained Amadeus agent can build a complex multi-city, multi-passenger PNR faster in cryptic than in a typical agent GUI that forces pages, dropdowns, and field-by-field navigation. Every operation is a single line. The cognitive overhead, once the syntax is internalised, is lower than navigating that kind of visual interface.

Low ambiguity within a host. On Amadeus, cryptic commands map deterministically to operations: you type XE2 and element 2 is cancelled; you type ER and the PNR is saved and retrieved. There is no wizard-shaped hidden state where the meaning of an action depends on which screen you came from. Sabre spells the same operations differently (see below): the point is per-dialect clarity, not one universal grammar across vendors.

No round-trips for rendering. In a web interface, every interaction potentially involves a network call, a server render, and a DOM update. In cryptic, the display is updated by the GDS response, which arrives in a single structured string. The terminal renders it immediately.

Cryptic mode is, in the language of modern software, a REPL for airline inventory. It predates the concept by twenty years.

Building My Booking: Command by Command

What follows is a reconstruction of how my NAG→DEL→LHR booking (DDTCIV) would have been built by an Amadeus agent, using the actual flight data from my e-ticket.

Step 1: Check Availability

AN08FEBNAGDEL

AN → Availability Next
08FEB → 8 February
NAG → Nagpur (IATA code)
DEL → Delhi (IATA code)

Response:

** AMADEUS AVAILABILITY - AN ** NAG DEL SU 08FEB 0000
1 AI 416 Z9 C9 D9 Y9 B9 NAG DEL 0840 1030 32A 0
2 AI 416 M9 H9 K9 Q9 T9 NAG DEL 0840 1030 32A 0
3 6E 5317 S9 T9 W9 V9 Q9 NAG DEL 0840 0755 32A 0

Reading this:

AI 416
└── Carrier: Air India, Flight 416
 
Z9 C9 D9 Y9 B9
└── Each letter is a fare class (cabin/booking class combination)
 Z = Business (upgraded)
 C, D = Business published
 Y, B = Economy full
 The digit = seats available in that class (9 = 9 or more)
 
NAG DEL 0840 1030
└── Origin, destination, departure, arrival
 
32A
└── Aircraft type: Airbus A320 family (domestic narrow-body)
 
0
└── Number of stops: non-stop

Line 3 is IndiGo. The 6E availability is visible in Amadeus even though IndiGo runs Navitaire: this is the GDS distribution layer: IndiGo pushes its inventory into Amadeus so that travel agents can book it without leaving the GDS. The booking, if made through Amadeus, routes back into Navitaire. The customer sees one system. The agents see one terminal. Three PSS platforms are involved.

Step 2: Sell the First Segment

SS1Z1

SS → Sell Segment
1 → 1 passenger
Z → Z class (the business class booking code on this fare)
1 → Line 1 from the availability display (AI416)

Response:

 2 AI 416 Z 08FEB 7 NAGDEL HK1 0840 1030 E 0 32A

HK1: Holding Confirmed, 1 passenger. The seat is now held in Amadeus and has been confirmed with Air India's Altéa PSS. The handshake between Amadeus and Altéa happens in this moment: the GDS sends a segment sell message to the airline's system, which confirms inventory and returns the HK status.

Step 3: Check Onward Availability (DEL→LHR)

AN08FEBDELLHR/AAI416

The /A suffix constrains the search to connections arriving on AI416. This tells Amadeus to show only onward flights that are valid connections from the first segment: respecting the MCT (Minimum Connection Time) at Delhi T3, which for international-to-international is typically 90 minutes.

** AMADEUS AVAILABILITY - AN ** DEL LHR SU 08FEB 1030
1 AI 2015 Z9 C9 D9 Y9 B9 DEL LHR 1515 2030 789 0
2 AI 117 Z9 C9 D9 Y9 B9 DEL LHR 2105 0415+1 789 0

789
└── Aircraft type: Boeing 787-9 Dreamliner (wide-body long-haul)
 
1515 2030
└── Depart 15:15, arrive 20:30: same day
 4h 45m layover at DEL: comfortable, above MCT

Step 4: Sell the Second Segment

SS1Z1

Same command. Line 1 is now AI2015 from the new availability display.

Step 5: Name Element

NM1SAHASRABUDDHE/AJITEM MR

NM → Name element
1 → 1 passenger
SAHASRABUDDHE → Surname (must match passport exactly)
/AJITEM → Given name
MR → Title

This is the first mandatory IATA element satisfied. The name must match the passport. If it doesn't, the passenger may be denied boarding. This is enforced by the DCS (Departure Control System) at check-in: which we will cover in Part 4.

Step 6: Contact Details

APM-9XXXXXXXXXX
[email protected]

AP → Address/Phone element
M → Mobile
E → Email

Second mandatory element: contact information.

Step 7: Ticketing Element

TKOK

TK = Ticketing element. OK = no time limit; ticket to be issued immediately or on-demand. The alternative is a time limit:

TKTL08FEB/1200
└── Ticket must be issued by 8 February 12:00 or the booking auto-cancels

This is the mechanism behind "Book within 2 hours or your price may change" on consumer booking sites. The OTA sets a ticketing time limit when it creates the PNR. If the customer abandons the booking without paying, the TK element expires, the segments are released, and the inventory returns to the pool.

Step 8: Received From

RFMYBIZ ONLINE

The fifth mandatory element. This is the audit trail: who authorised the booking. IATA requires it. Without it, the PNR cannot be ended. It is the origin of the "Booked by" field you see on every confirmation email.

Step 9: Special Service Requests

SR HNML AI HK1/SEG2
SR UPGP AI HK1/SEG2

SR → Special Service Request
HNML → Hindu meal (non-beef, non-pork, vegetarian options)
AI → Directed to: Air India
HK1 → Status: Holding Confirmed, 1 passenger
/SEG2 → On segment 2 (DEL→LHR: the long-haul leg that serves meals)
UPGP → PlusGrade upgrade charge (bid upgrade confirmed)

SSR codes are standardised globally by IATA. Every airline's system understands HNML. Every GDS transmits it in the same format. The airline must respond: confirming (HK) or declining (UN), and that response updates the PNR.

A selection of the SSR codes you will encounter:

WCHR → Wheelchair: can walk to seat, needs ramp chair at gate
WCHC → Wheelchair: must be carried to seat
VGML → Vegetarian meal (lacto-ovo)
VJML → Jain vegetarian (no root vegetables)
KSML → Kosher meal
MOML → Muslim meal (halal)
DBML → Diabetic meal
BLND → Blind passenger
DEAF → Deaf passenger
UMNR → Unaccompanied minor
DOCS → Passport/travel document data
DOCA → Address at destination (required for US-bound flights)
APIS → Advance Passenger Information (full passport data)

Step 10: Passport Entry

SR DOCS AI HK1/P/IND/PXXXXXXXX/IND/DDMMMYY/M/DDMMMYY/SAHASRABUDDHE/AJITEM

P → Document type: Passport
IND → Issuing country: India
PXXXXXXXX → Passport number
IND → Nationality
DDMMMYY → Date of birth
M → Gender
DDMMMYY → Expiry date

This data populates APIS: the Advance Passenger Information System. For UK-bound flights, APIS data must be transmitted to the UK Home Office before departure. The data flows from the GDS to the airline's PSS to the government border control system. It arrives before the aircraft does.

Step 11: End and Retrieve

ER

Two characters. This is the commit.

When ER fires, Amadeus:

1. Validates all five mandatory elements are present
2. Sends a final confirmation message to Air India's Altéa PSS
3. Generates the PNR locator (DDTCIV)
4. Timestamps the record
5. Returns the complete PNR display

If any mandatory element is missing, ER returns an error: not a warning, an error, and the PNR is not saved. The system enforces the data contract before any record exists.

The Complete Reconstructed PNR

--- RLR ---
RP/NAGAI2101/NAGAI2101 AI/SU 05DEC25/0000Z DDTCIV
 1.SAHASRABUDDHE/AJITEM MR
 2 AI 416 Z 08FEB 7 NAGDEL HK1 0840 1030 E 0 32A /01A
 3 AI 2015 Z 08FEB 7 DELLHR HK1 1515 2030 E 0 789 /04K
 4 APM-9XXXXXXXXXX
 5 [email protected]
 6 TKOK
 7 RF-MYBIZ ONLINE
 8 SR HNML AI HK1/SEG3
 9 SR UPGP AI HK1/SEG2
 10 SR UPGP AI HK1/SEG3

Eleven lines. Two segments. One passenger. Five mandatory elements satisfied. The entire booking state, in a format designed to be transmitted over a 1960s teletype at 110 baud.

Retrieving the PNR

After booking, retrieval is equally terse:

RTDDTCIV ← Retrieve by locator
RT SAHASRABUDDHE ← Retrieve by surname (if you've forgotten the locator)
RT AI416/08FEB ← Retrieve all PNRs on this flight/date

Cancelling a segment:

XE2 ← Cancel element 2 (first flight segment)
XI ← Cancel all itinerary segments

Modifying the booking: changing a seat, adding a bag, updating the ticketing element: each has its own terse command. The full Amadeus cryptic manual runs to hundreds of pages. A skilled agent has the most common 50 commands in muscle memory.

Sabre: The Other Major Syntax

Sabre uses different syntax for the same operations. Both systems descended from the same 1960s design philosophy: maximum information density per character: but they evolved independently, like languages that share a common ancestor.

Same mental model. Different vocabulary. A skilled Amadeus agent and a skilled Sabre agent are effectively bilingual in the same underlying domain.

What This Means for the Rust Simulator

In Parts 1 and 2 of this series I mentioned a plan to build an interactive cryptic simulator: a Rust + WASM module that lets you type these commands and receive realistic GDS responses. The parser structure follows directly from the command grammar you've seen here.

Each command maps cleanly to a variant in a Rust enum:

enum Command {
 Availability(AvailabilityQuery), // AN08FEBNAGDEL
 SellSegment(SellQuery), // SS1Z1
 AddName(PassengerName), // NM1...
 AddPhone(ContactDetail), // APM-...
 AddTicketing(TicketingElement), // TKOK / TKTL...
 ReceivedFrom(String), // RF...
 SpecialServiceRequest(SsrEntry), // SR HNML...
 EndAndRetrieve, // ER
 RetrievePnr(String), // RTDDTCIV
 CancelElement(u8), // XE2
 Unknown(String),
}

The grammar is regular enough that a simple prefix-matching lexer handles 90% of commands. There are no ambiguous productions, no operator precedence rules, no whitespace sensitivity in most positions. It is, in fact, a remarkably clean language to parse: which is itself a consequence of its teletype origins. Ambiguity was not affordable when every character cost money.

Lessons Learned

Expert interfaces and novice interfaces are different things. Cryptic mode is incomprehensible to someone who has never used it. For a trained agent, it is faster than a typical consumer-style GUI for the same booking workflow. These are not contradictory facts. The mistake is building one interface for both audiences, and ending up with something that serves neither well. Aviation separated the concerns: agents use cryptic, consumers use web UIs, both speak to the same underlying system.

Terse syntax is a feature, not a bug. The pressure that produced AN08FEBNAGDEL instead of something verbose was economic, but the result: a command that carries exactly the information needed and nothing more: is genuinely good interface design. There is no noise to parse. Every character carries signal. Modern API design could learn from this.

Data contracts enforced at write time prevent class of errors at read time. The fact that ER refuses to commit without all five mandatory elements means a committed PNR cannot be persisted without a name, contact, and ticketing element. The system makes that invalid state unrepresentable at the normal commit path: not by a type system, but by a validation gate before persistence. PNRs retrieved through that path are therefore expected to be structurally valid; edge cases and repairs still happen in operations, but they are not the default. The pattern transfers: validation at the write path is more reliable than validation applied after the fact at read time.

Next: Part 4: From GDS to Gate. What happens at 05:30 when I walk into Dr. Babasaheb Ambedkar International Airport and the GDS steps out of the picture entirely.

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.