I wonder what fraction of the space is occupied at any given time.
> Every airline has a 3-digit IATA numeric code. 098 = Air India. British Airways is 125. IndiGo is 526. These codes predate the familiar 2-letter IATA codes (AI, BA, 6E): they were used when teletypes could not reliably transmit letters and numbers interchangeably.
"This ticket was priced in GBP, not INR. Because the journey originated in Manchester, the fare is denominated in the currency of the origin country: the United Kingdom."
So: the currency is the one for the country of origin.
Bear in mind that this doesn't apply to charter airlines, only public passenger ones.
Given there are about 200 countries in the world, you'd need 5 large airlines per country, which is a lot! Most of them don't have any and rely on other countries. Still more have a single national carrier.
Part 2 of 6 in the Iron Core series: the 60-year-old infrastructure that flies 4.5 billion people a year.
My Air India e-ticket has a line on it that looks like a typographical error:
NAG AI X/DEL AI LON Q DELLON14.00Q DELLON21.00 228.08 NUC263.08END ROE88.687919
It is not a typographical error. It is a fare calculation: expressed in a notation system designed in the 1970s, referencing a currency that does not exist (NUC), and priced to a city code (LON) rather than an airport. Every field in that string is meaningful. By the end of this piece, you will be able to read it.
But first: the six characters at the top of the ticket.
DDTCIV.
This is my PNR: Passenger Name Record. The booking reference. The confirmation code. The six characters that identify me to Air India, to the airport check-in system, and to the departure gate scanner in London. They appear on every document related to my flight: the e-ticket, the myBiz confirmation, the boarding pass, the baggage tag.
Here is what most people, and many engineers who build systems that interact with aviation, do not know about those six characters.
They are not globally unique.
A Passenger Name Record is the canonical data structure of commercial air travel. Essentially every IATA-scheduled passenger booking has one. The concept was defined by IATA (International Air Transport Association) in the 1960s, formalised as Recommended Practice 1830, and has remained structurally consistent since.
The PNR is not a database record in the conventional sense. It is a structured document, closer to an append-only log, held inside the GDS that created it. In my case, that is Amadeus. The PNR is associated with a locator: a short identifier generated by the GDS at the moment the booking is saved.
That locator, DDTCIV, is six characters long. It is unique within Amadeus's system. It is not guaranteed to be unique across all GDS systems globally. A Sabre PNR and an Amadeus PNR can both carry the locator DDTCIV, belonging to completely different passengers on completely different airlines.
DDTCIV (Amadeus) → Ajitem Sahasrabuddhe, NAG→LHR, 08 Feb 2026
DDTCIV (Sabre) → Could be anyone, anywhere, any date
This is why airlines maintain their own Record Locator: a separate identifier in their own PSS, cross-referenced to the GDS locator. When you check in directly with Air India, they may show you a different reference. The GDS locator is what your travel agent sees. The airline locator is what the airline's own system calls your booking. They point to the same journey. They are not the same code.
IATA Recommended Practice 1830 specifies five mandatory elements that must be present before a PNR can be "ended": saved and assigned a locator. Without all five, the booking does not exist.
1. NM: Name element (passenger surname/given name/title)
2. IT: Itinerary (at least one flight segment)
3. AP: Address/Phone (contact number or email)
4. TK: Ticketing element (ticket time limit or confirmation)
5. RF: Received From (who authorised the booking)
These five elements are the contract between the booking system and the airline. They exist because in 1964, American Airlines needed a minimum viable data structure that could be transmitted across a teletype network, processed in milliseconds, and stored in a fixed-size memory cell.
What is notably absent from the mandatory set: passport number, payment details, seat preference, meal request, frequent flyer number. All of these are optional enrichments. The bare minimum is name, flight, contact, ticketing status, and an audit trail of who made the booking.
Here is what my DDTCIV booking looks like in Amadeus native display format. I have reconstructed this from my e-ticket data: this is what a travel agent terminal would show if they retrieved it by typing RTDDTCIV.
--- 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 01A
3 AI 2015 Z 08FEB 7 DELLHR HK1 1515 2030 E 0 04K
4 APM-9XXXXXXXXXX
5 [email protected]
6 TKOK
7 RF-MYBIZ ONLINE
8 SSR HNML AI HK1/SEG2
9 SSR UPGP AI HK1/SEG2
Field by field:
--- RLR ---
Record Locator Retrieved: confirms you are reading a live PNR
RP/NAGAI2101/NAGAI2101
RP = Record created at this office
NAGAI2101 = Office ID: NAG (Nagpur) + AI (Air India) + 2101 (office sequence)
Second NAGAI2101 = last office to modify the record
AI/SU 05DEC25/0000Z DDTCIV
AI = airline (Air India)
SU = modifier code (MakeMyTrip agent identifier)
05DEC25/0000Z = created 5 December 2025, midnight UTC
DDTCIV = locator
1. SAHASRABUDDHE/AJITEM MR
NM element: surname/given name title
Surname first: always. IATA mandates this order.
2 AI 416 Z 08FEB 7 NAGDEL HK1 0840 1030 E 0 01A
AI=carrier Z=class 7=Sunday NAG=origin DEL=dest
HK=confirmed 1=1 pax 0840=depart 1030=arrive
E=e-ticket 0=non-stop 01A=seat
4 APM-9XXXXXXXXXX ← AP element, M=Mobile
5 APE-... ← AP element, E=Email
6 TKOK ← TK element: ticket OK (no time limit)
7 RF-MYBIZ ONLINE ← RF element: received from MakeMyTrip
8 SSR HNML AI HK1/SEG2 ← Hindu meal, confirmed, segment 2
9 SSR UPGP AI HK1/SEG2 ← PlusGrade upgrade charge, confirmed
The HK status on each segment is load-bearing. HK means Holding Confirmed: the airline has acknowledged the seat. Other segment statuses you will encounter in the wild:
| Status | Meaning |
|---|---|
| HK | Holding Confirmed: seat guaranteed |
| HL | Holding: waitlisted |
| RR | Reconfirmed |
| UN | Unable: airline cannot confirm |
| XX | Cancelled: segment voided |
| TK | Schedule change acknowledged |
When my flight was cancelled in February, those HK entries became XX. New HK entries were inserted for the replacement routing. I cover that in forensic detail in Part 5.
At the top of my Air India e-ticket:
TICKET NUMBER: 098 5801178331
The structure of this number is not arbitrary:
098 → Air India's IATA numeric airline code
5801178331 → 10-digit serial number, globally unique within AI
Full: 098-5801178331
Every airline has a 3-digit IATA numeric code. 098 = Air India. British Airways is 125. IndiGo is 526. These codes predate the familiar 2-letter IATA codes (AI, BA, 6E): they were used when teletypes could not reliably transmit letters and numbers interchangeably.
The e-ticket number, not the PNR locator, is the true primary key of your booking. The PNR can change status, gain and lose segments, be transferred between offices. The e-ticket number, once issued, is permanent. It lives in Air India's ETD (Electronic Ticket Database), not in the GDS. When you board, the gate scanner validates your ticket number against the ETD. The PNR locator is what the travel agent sees; the e-ticket number is what the airline's systems use as ground truth.
My return journey used a different ticket number, 098-5801178359, for all three legs: BA1361 (operated by British Airways), AI112 (LHR→DEL), and AI415 (DEL→NAG). Even the British Airways leg was ticketed under Air India's numeric code, because Air India was the ticketing carrier for the entire itinerary. BA was merely the operating carrier on the feeder leg.
When the itinerary was re-accommodated after the bird strike, the ticket number did not change. The PNR segments changed. The e-ticket was reissued against new flights. The number, 098-5801178359, remained the same. It is the one truly stable identifier in the system.
Back to that string on my e-ticket:
NAG AI X/DEL AI LON Q DELLON14.00Q DELLON21.00 228.08 NUC263.08END ROE88.687919
This is IATA fare construction notation: a domain-specific language for expressing how a fare is built from its component parts. It was standardised in the 1970s as part of IATA's global fare construction rules.
Token by token:
NAG
Origin city: Nagpur
AI
Carrier for this fare component: Air India
X/DEL
X/ prefix = transit point (not a stopover, not a fare break)
DEL = Delhi
The X is critical: it means Delhi does not reset the fare.
Without it, "DEL" alone would split this into two separate fares.
X/DEL prices the whole journey as one fare component.
AI
Carrier continues: Air India
LON
Destination: London: city code, not airport code.
LON covers Heathrow (LHR), City (LCY), Gatwick (LGW), Stansted (STN).
IATA fares are priced city-to-city, not airport-to-airport.
My ticket lands at LHR, but the fare is to LON.
Q DELLON14.00
Q = construction surcharge on the DEL→LON sector, NUC 14.00
These Q surcharges are legacy artefacts from 1970s fare construction.
They represent add-ons that could not be folded into the base fare.
Q DELLON21.00
Second Q surcharge on the same sector, NUC 21.00
228.08
Base fare component in NUC
NUC263.08
Total: 228.08 + 14.00 + 21.00 = 263.08 NUC
NUC = Neutral Unit of Construction
A currency-neutral intermediate that does not exist in the real world.
Every IATA fare is priced in NUC first, then converted.
END
End of fare calculation
ROE88.687919
Rate of Exchange: 1 NUC = INR 88.687919
Published weekly by IATA. Applied at ticketing time.
The maths:
263.08 NUC × 88.687919 = INR 23,330 ≈ Base fare INR 23,335 ✓
The NUC system exists because airlines price internationally but currencies fluctuate. By pricing in a currency-neutral unit and applying the exchange rate at the point of ticketing, IATA allows a fare to be quoted consistently across markets without being hostage to currency movements between the time a fare is filed and the time it is purchased. This is a 1970s solution to the multi-currency pricing problem, and it still functions for IATA's specific use case: centralised rate publication, weekly cadence, single conversion point at ticketing.
The Q surcharges, 14.00 and 21.00, are not fuel surcharges (those are YQ, visible separately on the ticket). They are fare construction surcharges: fees that IATA's pricing rules require when certain routing combinations are used. They persist because changing IATA fare rules requires global multilateral agreement across member airlines. Adding a new surcharge type is easier than retiring an existing one.
My return ticket (DHB4AL) has a different fare calculation:
MAN BA X/LON AI X/DEL AI NAG 282.67 NUC282.67END ROE0.763485
The same structure. But notice the ROE:
ROE0.763485
1 NUC = GBP 0.763485
This ticket was priced in GBP, not INR. Because the journey originated in Manchester, the fare is denominated in the currency of the origin country: the United Kingdom. The base fare of GBP 216.00 on the ticket is:
282.67 NUC × 0.763485 = GBP 215.8 ≈ GBP 216.00 ✓
Then converted to INR 25,880 for the total. Two tickets, two currencies of denomination, one underlying NUC arithmetic tying them together.
The routing notation follows the same X/ logic:
MAN BA X/LON AI X/DEL AI NAG
| |
LON is a transit (X/): fare does not break
DEL is a transit (X/): fare does not break
One fare. Four cities. Two airlines. One NUC calculation.
One more field worth noting, buried in the payment section:
Tour Code: INNT010
This is Technogise's corporate account identifier with MakeMyTrip. When the PNR was created, this code was embedded in the ticketing element. It travels with the booking through BSP settlement: IATA's Billing and Settlement Plan, the mechanism by which airlines invoice travel agents and travel agents invoice corporate clients.
The tour code is how Air India's revenue accounting system knows to apply Technogise's negotiated corporate rate. It is how MakeMyTrip's finance team knows to invoice Technogise rather than a consumer. It is how Technogise's accounts payable team reconciles the charge. One 9-character string, sitting in a PNR field, threading across four organisations' financial systems.
Not all identifiers are primary keys. The PNR locator is a session handle: unique within one GDS, not across all of them. The e-ticket number is the primary key: globally unique within the issuing airline, stable across re-accommodations. Conflating them would be like treating a URL as a database row ID. In aviation, this distinction determines whether re-accommodation works at all: the ticket number persists even as the routing underneath it is entirely rebuilt.
The NUC system solves multi-currency pricing for IATA's specific context: centralised rates, weekly publication, single conversion point at ticketing. The pattern, pricing in a neutral unit and converting at transaction time, transfers to other domains where pricing must be stable across currency fluctuations. The constraints matter: it works because IATA controls the rate publication cadence and the conversion timing.
The Q surcharges look like noise; they are scar tissue. Every field in an IATA document exists because someone, somewhere, got on the wrong flight, or paid the wrong price, or could not prove what they were entitled to, and a rule was added. The complexity is not accidental. Retiring a field requires multilateral agreement across the airline industry. Adding one does not.
Next: Part 3: The Command Line That Never Died. The cryptic terminal language that built my booking, and why it is still often faster than a general-purpose GUI for the same agent workflow.
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.