Entity resolution is the process of determining which real-world company or organization a record represents, then linking that record to a stable identity. Kernel AI compares the account name and website with the wider context in the CRM and evidence from external sources before assigning a KERN ID.
A CRM record can point in more than one direction. An account named Pepsi with fritolay.com as its website could refer to PepsiCo or Frito-Lay. Dove with unilever.com might represent the Dove brand rather than Unilever itself. Oracle could mean Oracle Corporation, a regional subsidiary, or an unrelated company with the same name. A name or domain lookup alone cannot reliably resolve these cases.
A CRM cannot maintain accurate account data if it does not know which entity each record represents. That gap shows up in three places.
Deduplication. The same company can appear under a legal name, trading name, brand, regional subsidiary, or old name. Without a shared identity, duplicate records remain separate and activity gets split across accounts.
Data enrichment. Firmographic and hierarchy data are only useful when they are attached to the right entity. A correct revenue figure for the wrong company is still incorrect CRM data.
Territory design and routing. If a brand, subsidiary, and parent are resolved incorrectly, teams can assign related accounts to different owners, route an expansion opportunity as net new, or report one company several times.
Kernel AI resolves the identity first, before adding firmographics, hierarchy relationships, or other account data. That gives every downstream field a clear answer to a basic question: which entity does this information describe?
Once every account is linked to a stable entity, a few things become possible that were not reliable before:
Deduplication based on shared identity rather than similar account names
Firmographic enrichment attached to the correct legal entity, brand, business unit, or operating location
Corporate hierarchies that connect parents and subsidiaries without collapsing them into one record
Territory and account allocation built on the actual company structure behind each CRM account
Crosswalks between CRM records, data warehouses, enrichment providers, and other systems using one persistent identifier
AI and automation workflows that act on a consistent account identity instead of ambiguous names and domains
These use cases depend on resolving identity before trying to clean or enrich the record. If the initial match is wrong, every field and workflow built on top of it inherits the error.
Traditional entity matching usually treats a company name or website as the lookup key. Kernel AI treats every available field as evidence and reasons across the full context of the record.
Kernel can use internal CRM data including:
Account name and website
Legal name, alternative names, and alternative domains
LinkedIn company URL, account emails, and billing or shipping address
Domains from related contacts
Names from related opportunities
Existing parent relationships and other account context
Kernel then checks external evidence, including the company website, corporate registries, and third-party sources, to confirm or challenge what is already in the CRM. No single field is assumed to be correct. A confidently wrong address or inherited domain can be less useful than leaving the field blank, so Kernel weighs each input in context rather than trusting it automatically.
When a name and website point to different entities and the other evidence does not settle the question, Kernel can apply one of two bias modes:
URL bias. Kernel leans toward the website. This is the default and is useful when records came from web forms, enrichment, or email domains.
Name bias. Kernel leans toward the account name. This is useful when names were entered and maintained deliberately by reps.
A bias breaks a tie. It does not override stronger evidence from an address, legal name, LinkedIn URL, contact domain, or another corroborating signal.
The output is a KERN ID, a unique and persistent identifier for the resolved entity, together with its component identity fields, human-readable reasoning, and a High, Medium, or Low confidence level. KERN ID can represent legal companies as well as brands, business units, government institutions, regional subsidiaries, and individual establishments, so the CRM can reflect the entities a GTM team actually sells to rather than only those found in a company registry.
The identity viewer in the Kernel platform shows the resolved entity, supporting reasoning, and confidence before a team takes action. This makes ambiguous matches inspectable instead of hiding the decision inside a black-box lookup.
Full technical documentation is available at docs.kernel.ai/concepts/entity-resolution and docs.kernel.ai/concepts/kern-id. The background to KERN ID is covered in Introducing the KERN ID.
Entity resolution is the process of determining which real-world entity a record represents and linking it to a stable identity. It uses available evidence to distinguish between companies, subsidiaries, brands, business units, and other organizations that may share names or domains.
Deduplication identifies records that represent the same entity. Entity resolution establishes the identity those records belong to. Once records share a resolved identity, they can be merged, linked, or managed separately without losing their relationship.
Kernel can use account names, websites, legal and alternative names, addresses, LinkedIn URLs, related contact domains, opportunity names, parent relationships, company websites, corporate registries, and third-party sources. It weighs these inputs together instead of trusting one field by default.
A KERN ID is Kernel's unique, persistent identifier for a resolved entity. It can represent legal companies and non-legal entities such as brands, business units, regional subsidiaries, government institutions, and individual establishments.
Kernel reviews the wider record for corroborating evidence. If the remaining evidence does not resolve the conflict, URL bias can lean toward the website or name bias can lean toward the account name. The bias only breaks the tie and does not override stronger evidence.
A traditional match usually looks up one or two fields in a static database. Kernel reasons across structured and unstructured CRM context, checks external evidence, resolves conflicts, and returns the selected KERN ID with human-readable reasoning and a confidence level.
