DATA GOVERNANCE · CASE

One Call Sign, Two Aircraft: Why Identity Is the Foundation of Every Data Strategy

Just after midnight on 14 August 2026, an air traffic controller in Phoenix was talking to two different aircraft that answered to the same name. Both were “American 2482”, one climbing out of the airport, one descending toward it. Every instruction the controller sent could be taken by the wrong jet.

No system had failed. Each one did exactly what it was built to do. What had failed was quieter: an identifier had stopped being unique. And keeping identifiers unique is the one thing data governance exists to do.

What data governance actually secures

Strip data governance back to its core and a single job remains: to make sure that every object an organisation decides on, a customer, a supplier, a product, a contract, can be told apart from every other one, across systems, processes and time. Everything else we file under governance, quality, compliance, automation, reporting, assumes this already holds. When it does not, all of it inherits the error.

The requirement runs in two directions. One key must point to exactly one object, and one object must carry exactly one leading key. The night over Phoenix broke both at once.

What went wrong over Phoenix

A flight number is not the stable label it appears to be. “American 2482” identifies a scheduled service on a given day, not a physical aircraft, yet on the radio it is the only address a controller has. The number space is small, four digits against thousands of daily flights and codeshares that consume their own, and it silently reuses each number every day. That reuse is safe only while yesterday’s flight has landed before today’s departs.

On 14 August it did not. The inbound 737 from Chicago was held on the ground by weather while the return leg to Chicago took off on schedule as a second aircraft, under the same call sign. For a few minutes both were airborne in the same sector as “American 2482”, until the delayed inbound finally landed and the overlap closed (Flightradar24). Each 737-800 seats roughly 170; the number of people actually on board was never published.

Why a duplicate key becomes dangerous

Here is the part that matters for anyone who runs data. The controller had one channel to each aircraft and one way to address it: the call sign. So an instruction meant for one jet was heard by both. A clearance to climb to 9,000 feet, meant for the departing aircraft, was read back by the arriving one as it descended through 11,000. One instruction, two aircraft acting on it. “I’ve been working air traffic for 25 years,” the controller said afterwards on the published recording. “I’ve never seen two aircraft pretty much merge with the same call sign” (Associated Press).

Notice where the conflict actually lived. Not in a database: every system held clean, correct records. It lived in the moment of communication, where a human read a name and decided who was meant. That is the general lesson. A duplicate identifier is harmless while it sits in storage and dangerous the instant someone acts on it, and how dangerous depends entirely on what the key controls. Here it controlled altitude.

The rescue was a person, and that is the problem

The situation was resolved in under three minutes, by the controller, not by any system. He extended the key on the spot with an improvised discriminator, “American 2482 on the arrival” and “American 2482 on the departure”, then separated the two vertically until the crews had each other in sight. It worked.

Aviation actually has a designed fix for exactly this, called stubbing: 2482 becomes 482P before the flight ever departs, so the duplicate never reaches the air. The contrast is the point. A rule at the moment of assignment would have prevented the conflict outright; instead it was caught downstream, by one experienced person under time pressure with no backup. In many master data landscapes, that downstream catch is not the emergency. It is the standard way duplicates get found.

The same pattern, in business partner data

The mechanism that put two jets under one call sign is the same one that quietly distorts business partner master data in most large enterprises. It shows up in two directions.

One key, two partners. Two unrelated companies end up under the same business partner ID in different systems, often after a migration or a merge. Picture a payment run that pulls the bank details attached to that shared ID: the money leaves on time, cleanly, for the wrong recipient. The same collision can put a credit limit on the wrong company, attribute revenue to the wrong account, or block an innocent party because a sanctions hit landed on the shared key.

One partner, many keys. The more common direction. A single supplier is created separately in ERP, CRM, procurement and accounting, each with its own ID. Now picture a supplier-risk review: three of those records look clean, two carry an overdue compliance flag, and the screening that signs off the supplier happens to run against a clean one. The risk is real and documented, and it is missed anyway, because no single record is the supplier. The same fragmentation means no one can see the total exposure to that partner, negotiated terms apply in only some systems, and the same invoice can be paid twice.

No lives are at stake here. Money, compliance and trust are. And the difference from the cockpit is exactly what makes the business case harder: there is no controller watching two blips converge, nothing merges on a screen. The conflict can sit undetected for months, until an auditor, a doubled payment or a missed sanctions match finally surfaces it.

What this should change about how you govern data

The Phoenix save worked, but relying on that kind of save is a decision to be rescued rather than protected. If the last line of defence against an identity collision is an experienced person noticing in time, it is not a control. Four things follow.

First, check uniqueness where the object is created, not afterwards. A partner record validated and matched against authoritative sources before it is ever saved never becomes next quarter’s duplicate, which is the whole idea behind risk-free business partner creation. Cleaning up downstream, the aviation “catch it in the air” model, is always the more expensive one.

Second, write down what each key identifies, and what it does not. The flight number identified a service, not an aircraft, and no one ever made that boundary explicit. Granularity is a decision to take deliberately, not a property to discover after a collision.

Third, decide the discriminator before you need it. When two objects do share a key, how will you tell them apart? Aviation has stubbing. An answer improvised under pressure, however skilful, is not a rule.

Fourth, watch continuously instead of hoping someone notices. Surfacing duplicates and collisions as they arise, rather than at audit time, is what we at CDQ mean by collaborative data observability: business partner data checked continuously against authoritative external sources and shared community signals through the CDQ Data Mirror, with duplicate detection running as a standing control rather than a periodic cleanup.

The mechanism is the same

In aviation, a broken identifier can, at the extreme, cost lives. In business partner data it costs payments sent to the wrong party, invoices paid twice, compliance gaps, and a picture of the customer that simply is not real. The stakes are different; the failure is identical.

That is why we treat unique identity not as one data quality discipline among others but as the ground the others stand on. Every automation, every AI model, every compliance check assumes that one name means one thing. If you cannot identify your objects uniquely, you cannot manage them either. Phoenix is a three-minute reminder of how fast that assumption can break, and how much sits on top of it.

Want more perspectives like this? Subscribe to the CDQ blog for practical thinking on data governance, master data and trusted data. If you are building the governance case internally, our modern data governance research is a useful next read.

Sources

Associated Press, on the course of events, the controller’s account, and the responses from American Airlines and the FAA: apnews.com

Flightradar24, on the flight tracking data and playback of both flights, 14 August 2026: flightradar24.com

The number of passengers on board estimated on the capacity of an American Airlines Boeing 737-800.