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 record 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 subsidiaries.
Kernel		This could refer both to Kernel, the UK-based startup building an 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 thought 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 fields, 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.

Internal data (from your CRM)

This is the data Kernel reads from your system of record. The table groups the inputs by type and shows where each one usually lives in Salesforce as an example.

If you store a value somewhere else (for example, a custom "Website" field), point Kernel at that field instead. Only the account name and website are required; every other field improves accuracy where it is available.

Field type	Salesforce field (example)	Required?
Account name	Account.Name	Required
Website / domain	Account.Website	Required
Legal name	Custom Account field	Optional
Alternative names & websites	Custom Account field	Optional
LinkedIn company URL	Custom Account field	Optional
Account / billing emails	Custom Account field	Optional
Billing / shipping address	Account.BillingAddress (street, city, state, country)	Optional
Related contact email domains	Contact.Email on related contacts	Optional
Related opportunity names	Opportunity.Name on related opportunities	Optional

This is a conceptual summary of the inputs used for identity resolution. The full field-by-field Salesforce requirements - access, related objects, and write-back - are covered separately in the Salesforce integration guides.

External data (gathered by Kernel)

Kernel does not rely only on what is already in your CRM. It also gathers corroborating evidence on its own to confirm or challenge the internal data.

Source	What it provides
Company website	Kernel crawls the website listed on the record to confirm the entity and pull supporting detail.
Corporate registries & third-party sources	Kernel researches official registries and other external sources to disambiguate and verify the entity.

Kernel weighs all of these inputs together on the assumption that not all of them are correct or internally consistent, which is why it resolves conflicts through reasoning rather than trusting any single field.

More input data usually helps with difficult or ambiguous records - but only when it is trustworthy. A field that is confidently wrong can make resolution harder, not easier. For example, an address populated by another data vendor may point to the wrong location and pull the match toward the wrong entity. When a field is known to be unreliable, it is better to leave it out than to feed it in.

Bias modes

When a record's name and website point to different companies and nothing else is decisive (see example below), which should Kernel lean on? That usually depends on how the CRM was built and maintained - where the records came from, and which field the team kept clean.

Kernel treats this as a bias, not a hard rule.

The same ambiguous record resolves differently depending on the bias - but a bias only breaks the tie.

• URL bias (default) - lean on the website. Best when records came from web forms, enrichment, or email domains, where the domain is the reliable key, or when a previous vendor has been used that keys on domain.

• Name bias - lean on the company name as the strongest statement of what the record was meant to represent. Best when reps typed account names by hand or when a previous vendor has been used that keys on company name.

A bias only breaks a tie. When the address, legal name, LinkedIn, or contact domains clearly corroborate one entity, that evidence wins.

Entity resolution output

The output of the analysis is a KERN ID, all its component fields, as well as a human-readable reasoning justifying 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.

Identity viewer (app)

The identity viewer in the Kernel app gives you direct visibility into the resolution process. For each account, you can inspect what Kernel has resolved the identity to and the reasoning behind it - helping you verify the match before taking any action.