When an Empty Name Is the Correct Result

For trycompai/crm, the practical test of evidence-first design is an incomplete contact. The system must decide not only whether it found a plausible answer, but what that answer is allowed to do to the record. Following one work email through internal history, identity checks, and the fact-writing path shows why an empty name, an applied value, a proposal, and a held claim are all meaningful outcomes.

Start with the record that already exists

Imagine a contact whose record contains a work email, an employer, and a name derived from the email address. No LinkedIn URL is present. The contact needs research, but the first move is not a search query. The agent reads the CRM history.

That read can change the entire decision. A reply from the contact's own address is primary evidence of identity. An email signature can state a title in the person's own words. A meeting can show attendance. The contact's company, deals, and colleagues supply context for interpreting those observations. If the CRM already contains a decisive reply or signature, an external lookup adds cost without adding the most valuable evidence.

The record read is also a protection against answering the wrong question. A company can have several people with similar names. A deal can involve several contacts. A colleague can work at the same employer without being the person behind the address under review. The history tools return neighboring record IDs so the agent can continue with the exact contact, company, or deal it opened. Context stays connected to the record that owns it.

Suppose the contact has replied and the signature says “Head of Security.” The agent does not need to infer a name from the email local part or search for a matching profile. It can report the reply as crm.thread-reply and the signature as crm.signature-block. The evidence ledger then evaluates two independent observations with different roles: one supports identity, and the other supports the title. The result is stronger because the sources are distinct and directly connected to the person.

Now suppose the record contains no reply, no signature, and no meeting attendance. The absence does not prove that the contact is unreal. It means the internal record cannot settle the question. The agent can use an external resolver, but it carries the uncertainty forward. Internal silence is a reason to look elsewhere, not permission to invent an answer.

A candidate still needs a verdict

When no profile URL exists, the resolver can use the email address, employer name, employer domain, and any first or last name already held as clues. When a profile URL does exist, the profile reader can inspect that specific profile. Both routes return a candidate. Neither route turns retrieval into identity automatically.

The identity verdict checks three relationships. emailMatches asks whether the profile publishes the address being identified. employerMatches asks whether a current role matches the company held by the CRM. nameMatches asks whether the person's real name is consistent with the email local part and the record's existing clues.

These checks have different meanings. A published email is a direct statement by the person that connects the profile to the address. Employer matching is contextual. Name matching is useful but can be ambiguous. A candidate whose employer matches but whose name does not is not “almost confirmed.” The candidate has passed one test and failed another.