Six Characters

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.

What a PNR Actually Is

A Passenger Name Record is the canonical data structure of commercial air travel. Every booking in the world 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 ever 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 have 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.

The Five Mandatory Elements

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: your passport number, your payment details, your seat preference, your meal request, your frequent flyer number. All of these are optional enrichments. The bare minimum — the legally necessary core — is name, flight, contact, ticketing status, and an audit trail of who made the booking.

My PNR, Decoded

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:

When my flight was cancelled in February, those HK entries became XX. New HK entries were inserted for the replacement routing. I will cover that moment in forensic detail in Part 5.

The E-Ticket Number

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 couldn't 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 the same 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.

The Fare Calculation Line

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, and it has not changed in any meaningful way since.

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.
    If it were simply "DEL", you'd be pricing 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 couldn't 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 doesn't 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.

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 date back to when the pricing geography was defined, and they persist because changing IATA fare rules requires global multilateral agreement. It is easier to leave a 14.00 NUC ghost in the fare calculation than to renegotiate the pricing manual.

The Return Fare Line — A Different Currency

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
  ↑           ↑          ↑
MAN is origin (Manchester)
BA operates MAN→LON, but LON is a transit (X/) — fare doesn't break
AI operates LON→DEL, but DEL is a transit (X/) — fare doesn't break
AI operates DEL→NAG, which is the destination

One fare. Four cities. Two airlines. One NUC calculation.

The Tour Code

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.

Lessons Learned

Primary keys matter — and not all identifiers are primary keys. The PNR locator is a session handle. The e-ticket number is the primary key. The ticket number is the stable reference; the locator is the access mechanism. Conflating them would be like treating a URL as a database row ID. In aviation, this distinction is load-bearing — it is why re-accommodations work: the ticket number persists even as the routing underneath it is entirely rebuilt.

Currency neutrality is a solved problem. NUC is a 1970s solution to a problem that developers still wrestle with today — how do you price internationally without coupling your pricing logic to currency fluctuations? The answer is a layer of indirection: price in a neutral unit, apply exchange rates at transaction time, publish those rates centrally. There are worse approaches.

Every field has a reason. The fare calculation line looks like noise. The Q surcharges look like artefacts. The NVB/NVA dates look redundant. Every single field in an IATA document exists because someone, somewhere, once got on the wrong flight, or paid the wrong price, or couldn't prove what they were entitled to — and a rule was added to prevent it happening again. The complexity is not accidental. It is scar tissue.

Next: Part 3 — The Command Line That Never Died. The cryptic terminal language that built my booking, and why it is still faster than any GUI ever built for this purpose.

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.