Entity resolution

Kernel's proprietary entity resolution mechanism intelligently matches records in your system record with Kernel's database similarly to how a human would do it - with full context

Problem: Account identity mismatches

All systems of records suffer from master entity data that is inconsistent, incorrect, or stale, all of which may lead to ambiguity when matching to a canonical entity database like Kernel's.

Traditional vendors rely on simple look-up fields against a static database. These lookup fields are usually the company's website or name.

Name	Website	Ambiguity
Pepsi	fritolay.com	Which company is this? Pepsi or Fritolay? Fritolay is a subsidiary of Pepsi, but is operating on its own.
Dove	unilever.com	Dove is a brand within Unilever, not a legal entity on its own. But some GTM teams may still want this to resolve to Dove.
Oracle		This is likely the Oracle Corporation, but it may also refer to a Vancouver-based investment company, which is also called Oracle. Or it may refer any of the Oracle Corporation's subsidiary.
Kernel		This could refer both to Kernel, the UK-based startup building a entity database of all companies in the world, or to the US-based neuroscience startup founded by Bryan Johnson

As a human, to resolve this you would look at peripheral data in the system:

• Are there alternative names and websites associated with the record? e.g., if the Kernel record has 'kernel.ai' written somewhere, this helps narrow the confusion

• Is there an address? Pepsi is headquartered in New York, whereas Fritolay is in Texas

• What contacts are associated with the record? If all contact emails end in "oracle.com", this is likely the Oracle Corporation. But if all contacts are located in Spain, it is more likely to be Oracle Ibérica, S.R.L.,, the Spanish regional subsidiary of Oracle

• Which notes have previous users left behind? Previous opportunity and deal names may show the user's intent ("Dove | Pilot - Closed Lost") indicates the rep though of the record as a business unit rather than the legal entity itself

Reasoning-based entity resolution

A customer record may have a mix of information in its core field, describing it as both PepsiCo and Frito-Lay. This means that a simple name/website lookup does not guarantee that we match it to the KERN ID that the customer intended.

To resolve this, Kernel's entity resolution reviews internal and external data related to the account - from the name and website, to the address, alternative domains, existing parent relationship, related contact domains, associated opportunity names, and more.

Kernel uses the following data (where available) to make its recommendation:

• Company name

• Company website

• Alternative websites and company names

• Legal name

• Billing/Shipping address

• LinkedIn Company URL

• Account/billing emails

• Account notes

• Parent ID

• Related opportunity names

• Related contact domains

• Crawling the website of the company website (as listed)

Kernel uses all data points listed above under the assumption that not all are correct nor internally consistent.

Entity resolution output

The output of the analysis is to output a KERN ID, all its component fields, as well as a human-readable reasoning justifyin the decision and a confidence level, which is either High, Medium, or Low.

"Low" confidence means there was latent ambiguity, i.e., not enough information to singularly establish the correct identity without doubt. Resolving "Oracle" to the Oracle Corporation is an example of this; most humans would agree that this is sensible, but strictly speaking there are more companies in the world named Oracle.

The confidence level allows the user to trade-off coverage against certainty.