93% of the Hard Corporate Links Never Reach the Matcher

Suppose your supplier database contains these two companies:

Blue Aerospace LLC

and

HEICO Corporation

Your system is asked a simple business question:

Do these records belong to the same corporate family?

A string matcher has almost nothing to work with.

No shared company name. No useful token overlap. No spelling variation to normalize. An embedding model can decide that both names sound vaguely aerospace-related, but that is not evidence of ownership.

The relationship exists because one company acquired the other.

And that fact does not live in either name.

That distinction is the whole story behind a new benchmark called CorpFam, and it exposes a weakness in entity-resolution systems that is easy to miss when we obsess over the final matching model.

The matcher may not be your bottleneck.

The true pair may never reach it.

Matching two records is not the same as discovering a relationship

Entity resolution usually asks:

Are these two records the same real-world thing?

IBM Corp and International Business Machines may describe the same company.

That is a matching problem.

Corporate-family resolution asks something different:

Are these two different companies connected through ownership?

A subsidiary and its ultimate parent are supposed to have different identities.

If two records refer to the same organization, surface similarity can be evidence. Name, address, phone number and identifiers may all overlap.

If one company bought another company that still trades under its old name, there may be no surface similarity at all.

You are no longer asking whether two strings describe the same thing.

You are asking whether a fact exists between two things.

That fact may only exist in an ownership filing, corporate registry, acquisition record or knowledge graph.

The new paper argues that we have been treating too much of this second problem like the first. (arXiv paper)

Before matching comes blocking

You cannot compare every company with every other company.

If you have n records, naive pairwise comparison grows roughly with n². This is why practical entity-resolution pipelines first perform blocking, sometimes called candidate generation: generate a manageable set of pairs that seem plausible, then run the expensive matcher on those pairs.

Think of it as a two-stage system:

Candidate generation → Matching

The first stage asks:

Which pairs are worth examining?

The second asks:

Which of those pairs are actually matches?

This architecture should look familiar if you work on search or recommendations.

Retrieval first.

Ranking second.

And the same rule applies:

A perfect ranker cannot rank an item that retrieval never returned.

That is where CorpFam finds the real failure.

The benchmark starts with 6.6 million contract rows

The study processes 6,638,350 FY2025 federal contract rows and builds a benchmark of 54,864 pairs across 10,307 corporate families. The labels come from suppliers’ declared ultimate-parent information rather than from a model assigning labels to its own inputs. The underlying federal award data is available through the official USAspending API.

The researchers divide positive links into three groups:

• Identical: normalized company names are the same.
• Visible: names differ but share at least one distinctive token.
• Invisible: names share no distinctive token.

That last category is the interesting one.

An acquisition can leave a subsidiary operating under its old brand for years. A holding company may own dozens of businesses whose names bear no resemblance to its own.

Those are not weird edge cases.

They are often exactly the relationships a procurement, credit-risk or sanctions system needs to discover.

More than half the benchmark was easy enough to hide the failure

Of the benchmark’s positive pairs, 55% have identical normalized names. Another 21.5% fall into the visible group, while 23.5% are name-invisible.

That composition creates a trap.

If most of your test set contains easy cases, an aggregate score can look respectable while performance on the cases you actually care about is terrible.

One character 3-gram TF-IDF matcher reaches an overall F1 of 76.8.

Looks decent.

Break the result apart and its recall is:

Relationship type	Recall
Identical names	100.0%
Visible names	49.9%
Invisible names	4.2%

The MiniLM sentence-embedding matcher improves the visible group to 64.3% recall.

On the invisible group?

4.7%.

A neural representation gives a useful improvement when the relationship leaves some trace in the names.

When the fact is absent from the names, the embedding has little to recover.

Embeddings can understand similarity.

They cannot manufacture missing evidence.

Then the paper tests the part that matters more

Pairwise matching results are not even the most consequential finding.

In production, those pairs first have to survive candidate generation.

Across a roster of 114,230 entities, the naive comparison space contains more than 6.5 billion possible pairs. So some form of blocking is unavoidable.

The researchers try seven approaches, including character q-grams, sorted-neighbourhood blocking, Soundex phonetic keys, ZIP and city/state attributes, and semantic nearest-neighbour retrieval using MiniLM embeddings.

The best single non-trivial method retrieves fewer than 3% of the invisible relationships.

Even taking the union of every strategy gets to only 6.77%.

In other words:

93.2% of the hardest true relationships disappear during candidate generation.

They never become input to the matching model.

“Use a better embedding model” is the wrong fix

There is a standard response whenever matching performs poorly:

Use embeddings. Use a larger encoder. Fine-tune the model. Maybe use an LLM.

But think about the information available.

Imagine Blue Aerospace LLC and HEICO Corporation.

You could train the world’s most elegant representation of both strings.

What mathematical transformation of those two names proves an acquisition occurred?

None.

The missing variable is not representation quality.

It is knowledge.

You need an external piece of evidence: a corporate filing, an ownership registry, an acquisition announcement or a trusted company graph.

That changes the architecture of the problem.

Instead of:

Record A + Record B → similarity → match

you need something closer to:

Record A → retrieve ownership evidence → generate plausible parent candidates → verify relationship

Now candidate generation is not merely lexical filtering.

It is retrieval.

The benchmark itself nearly learned the wrong thing

One of the most useful parts of the paper is a failed experiment.

An earlier benchmark version sampled negative examples incorrectly.

Positive examples connected a child company with a parent company. But the negatives connected children with other children.

That sounds innocent.

It was not.

Parent holding companies often do not transact directly, which means their records frequently lack operational attributes such as addresses.

A supervised model discovered the shortcut.

Instead of learning:

Does this child belong to this parent?

it learned something closer to:

Does one side look like a holding company?

The result was an F1 of 88 on the hard group.

It looked like a breakthrough.

It was a dataset bug.

The corrected benchmark pairs children with unrelated parents for negative examples, preserving the same role structure as the positives.

That one design change destroys the shortcut.

This is exactly the kind of mistake that produces excellent notebooks and useless production systems.

There is another metric trap here

The paper also refuses to compare per-group F1 scores as though they meant the same thing.

Why?

Because the positive rates across the three strata are very different.

A classifier that predicts yes for everything can therefore receive a surprisingly high F1 in some groups without learning anything.

That is why the paper emphasizes recall within each visibility stratum and evaluates precision globally against the shared negative pool.

This is a general benchmark lesson.

A metric is not meaningful because it has a familiar name.

You have to ask what the denominator contains.

If the class balance, sampling process or difficulty distribution changes between slices, the same metric can stop answering the same question.

The headline number may still be mathematically correct.

It can also be practically misleading.

The ground truth is imperfect, and the paper says so

The benchmark relies on corporate-parent information reported through federal registration data, but government registry data is not internally perfect. The paper finds meaningful disagreement between different registry views and treats that inconsistency as a limit rather than quietly cleaning it away.

For a subset of larger corporate families, the researcher also checks declared relationships against SEC Exhibit 21, the section used to list subsidiaries of a registrant.

In the validation sample, 510 of 794 name-invisible relationships were corroborated by the appropriate subsidiary filings—64.2%—while two different null tests produced rates near zero.

That is strong evidence that many of the strange-looking links really are relationships rather than simply dirty company names.

Not all of them can be confirmed, and Exhibit 21 has its own coverage limitations.

That is the right conclusion.

Validation should reduce uncertainty, not pretend to abolish it.

The production lesson: evaluate the whole funnel

If I were building an entity-resolution system tomorrow, I would stop reporting only matcher F1.

I would evaluate the pipeline in stages.

1. Candidate recall

Of all true relationships, how many ever enter the candidate set?

2. Candidate budget

How many pairs did I have to generate to achieve that recall?

3. Matching quality

Of the candidates presented, how accurately can the model distinguish real from false relationships?

4. End-to-end business recovery

Did we reconstruct the actual customer, supplier, patient or organizational groups correctly?

Those metrics answer different questions.

Collapsing them into one F1 score makes debugging almost impossible.

The same principle appears in recommendation systems. If candidate generation never retrieves the product, your ranking model cannot recommend it.

It appears in RAG. If retrieval misses the relevant document, the language model cannot reason over it.

It appears in search. If the index never surfaces the result, reranking does nothing.

And it appears here.

Reranking cannot rescue something that retrieval removed.

What would make me wrong?

This is a strong benchmark, not the final word on corporate-family resolution.

The study is currently an arXiv preprint by an independent researcher, not a completed peer-reviewed result.

The ground truth comes from one country and one fiscal year. Multinational corporate structures are only represented through their U.S.-registered activity, and the benchmark evaluates child-to-ultimate-parent relationships rather than every intermediate ownership layer.

Its five pairwise matchers and seven blockers are useful baselines, not an exhaustive search over every current method.

The multi-attribute experiment also suffers from a structural coverage problem: many holding companies do not transact directly, so attributes such as addresses and phone numbers simply do not exist for both sides of most relationships.

A sufficiently strong retrieval system built over corporate filings, acquisition data or a reliable ownership graph may recover far more than 6.8%.

In fact, that is exactly the point.

If somebody beats this benchmark by retrieving external evidence, they will not merely have built a better matcher.

They will have corrected the problem definition.

The checklist I would keep beside any matching pipeline

Before celebrating an entity-resolution score, ask:

1. What percentage of true links survive candidate generation?
2. What kinds of positives are easy enough to dominate the aggregate metric?
3. Do hard positives actually contain enough information for pairwise matching?
4. Were negatives constructed with the same entity roles as positives?
5. Could the model exploit missingness, formatting or source artifacts instead of the relationship?
6. Are train and test separated at the real entity or family level rather than just at the row level?
7. Does your evaluation include realistic hard negatives rather than mostly random ones?
8. Are you scoring the final deliverable, or only an intermediate model?

The benchmark repository releases pair data, adjudication material and scripts for rebuilding and evaluating the benchmark, including a deterministic build pipeline.

That makes this one worth reproducing, not just reading.

Key takeaways

1. Corporate-family resolution is not ordinary entity matching. The two companies may intentionally have completely different identities.
2. Candidate generation sets the ceiling. In CorpFam, the union of seven blocking strategies retrieves only 6.8% of name-invisible true links.
3. 93.2% of those hard relationships never reach the matcher. A better ranking model cannot recover them.
4. Embeddings help when the evidence exists in the representation. They do little when the relationship depends on an external fact.
5. Aggregate metrics can hide the population you actually care about. More than half of the benchmark’s positive pairs have identical normalized names.
6. Negative sampling can create fake breakthroughs. One earlier setup reached F1 88 by learning whether a record looked like a parent company rather than learning ownership.
7. Measure retrieval before ranking. This is as true for entity resolution as it is for search, recommendations and RAG.

The question I would ask any matching team now is not:

How accurate is your matcher?

I would ask:

How many correct pairs does your matcher never get the chance to see?

Primary sources

• Harshit Gupta, “Corporate-Family Resolution Is Not a String-Matching Problem: A Public Benchmark Stratified by Name Visibility,” arXiv
  .04269, submitted September 2, 2026.
• CorpFam benchmark repository
• USAspending API