ENTITY RESOLUTION - Which Engine Is This, actually?

In the last piece I said an ontology resolves identity, gave it a paragraph, and moved on. That paragraph was carrying more weight than the rest of the post combined, so here it is properly.

The general problem, briefly

Entity resolution is working out which records refer to the same real-world thing. Two rows, four systems, one object.Everything downstream depends on getting it right, and almost nothing downstream will tell you when you got it wrong.

Gartner's own research names inconsistency of data across sources as the hardest data quality problem to solve, arising from data held in silos with overlaps and gaps between them. That finding gets quoted far less than the dollar figures from the same body of research, which tells you something about how this material gets consumed.

While we are here: I went looking for a credible survey quantifying what entity resolution failure costs, and there isn't one. The widely repeated figures either come from customers of data quality vendors estimating their own losses, or from a decade-old study whose methodology was never published. I would rather say that plainly than pass one of them along.

If you know of one that holds up, I would genuinely like to see it. Something with a published methodology, ideally not funded by a vendor selling the fix. Leave it in the comments or send it over and I will update this piece and credit you.

So instead of a borrowed number, here is what the problem actually looks like in aviation, which is the sharpest version of it I know.

Aviation has genuinely unstable identity

In most industries an entity mismatch is a data hygiene failure. Two customer records, one customer, somebody typed the address differently. Annoying, fixable, and in principle avoidable.

Aviation is not like that.Here the identity of an asset changes legitimately over its life, and the systems tracking it are supposed to disagree.

An engine carries an ESN and moves between airframes. Over twenty years it may sit under several. The airframe carries an MSN that never changes and a registration that does change, usually at lease transfer, sometimes more than once. A landing gear shipset has its own serials and its own movement history. Part numbers supersede. An LLP is tracked individually and outlives most of the assemblies it sits inside.

Then the recording systems diverge. The MRO writes a serial one way. The lessor's asset management system writes it another. The operator's tech log writes it a third way, often by hand, often into a scan. The OEM has a fourth convention. A release certificate arrives under an MRO's trading name rather than the legal entity your contracts reference, so a name match fails on a document that is completely valid.

None of those are mistakes.They are four institutions correctly recording the same physical object according to four different conventions, none of which was designed with the others in mind.

The industry has already admitted this

The strongest evidence that identity is a structural problem in aviation is that the industry built a standard to deal with it.

ATA Spec 2500 exists to standardise how aircraft records are interchanged between parties and systems, using a defined markup so that records can move between an operator, a lessor, an MRO, and a buyer without being reinterpreted at every handover.Nobody builds an interchange specification for a problem that isn't real.

Spec 2500 helps enormously at the transfer boundary. It does not retroactively resolve twenty years of records already sitting on a shared drive under four naming conventions, which is the position most portfolios are actually in.

What it costs when it breaks

Two ways, and the second one is the expensive one.

The first is analytical. Ask a portfolio question, say average time on wing, and a well-built metric definition will apply itself consistently across records that are not all the same engine.The arithmetic is correct. The answer is wrong.Nothing in the pipeline raises a hand, because nothing in the pipeline is checking that the entities agree.

The second is contractual. Life limited parts need back-to-birth trace, and where that trace cannot be produced, the lessee is generally looking at replacing the part or compensating the lessor for the value lost.So the bill for an identity failure is not a data cleanup cost. It is the value of a component.

Worth noting that the trace often exists. It sits in the pack under a serial format the search never matched, or under a repairer's trade name nobody mapped.The document is there and the join isn't.That is an entity resolution failure wearing the costume of a missing document.

Timing makes it worse. IATA's guidance sets out a twelve month redelivery footprint, and appraisers including mba Aviation have noted that lessors generally find lessees starting the process later than they should, which raises cost and creates schedule uncertainty.Identity problems found early are search problems. Found late, they are negotiating positions you no longer hold.

What resolving it actually takes

One canonical asset per physical object. Every alias each source system uses for it, held explicitly rather than inferred at query time. The relationships between engine, airframe, shipset, and lease, including their validity periods, because an engine belonged to one airframe until it didn't.

Then two things people underbuild. A confidence score on every match, because probabilistic matching that pretends to be deterministic is how bad merges enter a system silently. And a review lane, so uncertain matches route to somebody who knows the fleet rather than resolving themselves.

The reason this belongs in an ontology rather than inside transformation code is reviewability. A technical records manager can read a mapping that says these four serials are one engine and tell you whether that is true.Nobody can review a join condition buried in a pipeline, which means nobody does.

What we see in our own data

In practice, a single engine may carry 4–6 different serial number representations across OEM records, MRO work orders, lessor asset registers, and operator tech logs, none of which are inherently 'wrong' but all of which prevent automated matching.

A robust ontology must expect to resolve multiple aliases per asset, including ESN variations, MSN linkages, registration changes, and part number supersessions over the asset's lifecycle

Conflicts between document headers and content are common, particularly when release certificates arrive under an MRO's trading name rather than the legal entity referenced in contracts, causing name matches to fail on valid documents.

The short version

Check that your entities resolve before you trust your metrics.

A precise number computed over the wrong asset is not a partial success. It is a wrong answer that survives review, because everything about it looks right except the thing nobody checked.

And the open question stands. If anyone has seen a study that credibly prices what identity failure costs, in aviation or outside it, I want to read it.

KeepFlying builds the aviation FinTwin on Databricks and Azure. A knowledge graph holds canonical assets and their aliases across source systems, and extraction agents tuned to airframe, engine, APU, and landing gear records turn documents into queryable assets with lineage back to the source page.

Sources referenced.ATA Spec 2500 (records interchange standard), IATA Guidance Material and Best Practices for Aircraft Leases (twelve month redelivery footprint), mba Aviation commentary on redelivery timing, Gartner research on cross-source inconsistency. All paraphrased, none quoted at length.