Identity resolution answers which entity a signal describes. Enrichment adds information after that subject is known. Havilo keeps these jobs separate so that a new email, profile, or public page can improve an existing entity instead of creating a duplicate or attaching facts to the wrong one.
Signals enter from email participants, calendar attendees, imported rows, scanned business cards, LinkedIn connections, meeting attendees, and relationships mentioned during research. Each source contributes a signal; no single source defines the whole entity.
One entity, several identifiers
Names are useful context, but they are not reliable identity keys. Two people can share a name, and one person can appear under several names.
Havilo can associate several reliable identifiers with the same entity, including work email addresses, LinkedIn and Crunchbase profiles, and company websites. Once Maya's email and LinkedIn profile both point to her entity, a future calendar invitation or imported row can resolve to the same person.
Resolving a signal
Havilo checks reliable identifiers already known to the workspace before attempting discovery. An exact email or public profile can resolve a signal directly. A similar name cannot.
When the available evidence is insufficient, Havilo can hold the signal rather than force a match. A later email, relationship, meeting, or imported value may supply the missing context. This allows the network to become more complete without filling it with a new person every time the same individual appears in another system.
Identity discovery
An operator can request identity discovery for exact entities that are missing a LinkedIn person profile or Crunchbase organization profile. Havilo uses the context already available—such as aliases, email domains, official websites, locations, organizations, schools, programs, investment focus, known relationships, and explicit references in saved workspace content—to plan public research.
Havilo does not manufacture a profile URL from a name. A candidate must appear in search results or on a public page, and public evidence must connect it to durable facts about the subject. Private workspace context can suggest what to search for, but it cannot authorize the match. A second, adversarial check looks for a different person or organization that fits as well, including similarly named or renamed organizations.
A proof gap can trigger a small number of targeted follow-up searches. A supported match can then be applied to the entity; a completed search can instead conclude that no provider identity exists or that the subject is ambiguous. Anything still unresolved remains unapplied. Discovery never scans a workspace or starts automatically from mail, calendar, meeting, or entity-resolution activity.
Enrichment
Once the subject is known, enrichment can collect from an authenticated LinkedIn profile, Crunchbase, company and fund websites, and other sources. Different connectors expose different facts, but the useful outputs share the same data model:
- Field values add structured information to the entity.
- Notes preserve longer research, such as company dossiers, employment, education, or funding history.
- Relationships connect people and organizations when both endpoints can be resolved safely.
Enriched facts remain connected to the source material that supports them. A value that cannot be located or supported is rejected instead of entering the entity.
The same standard applies to relationships. If research mentions an investor or employee but does not establish who that person is, Havilo can preserve the mention in a Note without creating the wrong entity or connection.
Changes and refreshes
Public information changes. Havilo can refresh enrichment in the background and prioritize research needed for an upcoming meeting or direct request. A refresh updates the same entity rather than creating a new copy.
Automated changes retain their source and prior value. Grounded enrichment may update an existing field, including a manually entered value, and records that overwrite in its history. Identity URL materialization is stricter: it does not replace a different non-empty identity, and its writes can be reviewed or reversed without overwriting newer work.
See Data model for the entities, fields, and relationships these processes update. Provenance and history explains their sources, decisions, and reversal history.