Evidence Before Confidence
In trycompai/crm, the question is not whether an AI agent can produce a plausible CRM value. The question is whether the value is supported well enough to change a record. The evidence design answers that question by separating what a source actually shows from what a model feels about the answer. That distinction lets the reader judge why one observation can become a fact, another can become a proposal, and a third should not be retained at all.
A confidence score is not an observation
A model can assign itself a high confidence to almost anything. The number describes the model's posture toward its answer, not the world outside the model. If the model is wrong, a self-reported confidence score gives the CRM no useful way to diagnose the error. It only makes the error look more complete.
Comp AI CRM takes the authority away from that number. Its fact-recording tool asks for evidence entries. Each entry names a kind of observation, describes what the source actually said, and can include a URL that a representative can open. The agent does not say, “I am 92 percent sure this person is a security executive.” It says, for example, that an email signature stated a title, or that a profile published the address under review. The ledger then prices those observations according to rules defined outside the model's immediate answer.
This changes the object being stored. A ContactFact is not only a value such as a title or employer. It also retains a score, a band, the evidence, the method, the source URL, the session that observed it, and the observation time. Later, a person can inspect the basis of the claim. The record does not need to trust a number that has no visible connection to a source.
The score still has a useful job. It gives the write path a consistent way to compare different observations and produce a readable rationale. It is not a probability that the fact is true. The repository's weights and thresholds are first-party engineering choices, not an independently validated statistical model. The system is calibrated around evidence categories and consequences, not certified by the number it calculates.
Evidence has a hierarchy because sources do different work
The ledger divides observations into primary evidence, supporting evidence, and contradiction. The categories are about identity and directness, not about whether a source feels impressive.
Primary evidence can identify the person behind a record. A profile that publishes the email address the CRM holds is direct. A LinkedIn profile where the employer and name match the contact's clues is direct enough for the system's identity policy. A reply from the address on a synced CRM thread is direct evidence that the person behind the address interacted with the organization. An email signature can state a job title in the person's own words. GitHub account identity and calendar attendance can also be primary observations when they connect the individual to the claimed record.
Supporting evidence can strengthen a claim without identifying the person by itself. A cited web page can state that someone holds a role. A search result can point to a relevant profile. A handle can resemble a person's name. An employer can match while the name does not. These observations can be useful, but they are compatible with more than one explanation. A person who works at the right company is not necessarily the person behind a particular address.
That distinction prevents a common error in automated research: treating several weak clues as if they were several independent confirmations. Two facts on one page are still one page. A profile whose name and employer both match is one observation from that profile, not two unrelated sources. Counting the same page twice would reward duplication rather than independent support.
The evidence detail also matters. “Signature match confirmed” tells a representative very little. “Their signature on 14 July reads ‘Head of Security, Acme’” describes an observation that another person can understand and check. The difference is not style. A specific detail preserves the connection between the claim and the source that supports it.
The practical result is a set of different outcomes. A strong primary source and a high combined score can support a write. A weaker result can be retained as a suggestion for a representative. Evidence that does not clear the minimum for keeping is not polished into a visible claim. The agent does not need to search forever for another source merely to move an answer across a threshold. Stopping with a bounded result is part of the design.
Identity is a verdict, not a lookup
Identity makes the hierarchy concrete. A work email and an employer provide useful clues, but they do not name a person on their own. The repository's identity workflow therefore separates finding a candidate from deciding whether the candidate is the contact in the CRM.
The first step is internal. The agent reads the contact's CRM history before using a paid or external source. A reply from the address under review can already be primary evidence. A signature can provide a title. The contact's company, deals, meetings, and colleagues add context without pretending that context is identity. The agent should spend a vendor call only when the internal record leaves a material question unresolved.
If the CRM has no profile URL, the resolver can send the email, company name, domain, and any name already held as clues. If the record already contains a LinkedIn URL, the profile reader can inspect that URL. In either case, the returned profile is a candidate until the verdict is read.
An external lookup can also fail in several meaningful ways. It can find no person, return a profile without a usable public URL, or produce a candidate that does not meet the provider's own matching floor. A search result can point toward a profile without proving anything about its owner. These are not interchangeable outcomes. “No candidate,” “candidate without a source to cite,” and “candidate with one matching clue” each leave the CRM with a different reason not to write an identity as settled.
The verdict checks three relationships. emailMatches asks whether the profile itself publishes the address being identified. employerMatches asks whether a current role matches the company name or domain held by the CRM. nameMatches asks whether the real name is consistent with the email's local part and the existing record. These checks do not all carry the same meaning.
A published email settles the identity on its own because the person placed that address on the profile. Without that direct match, employer and name must both pass. One check is not a weaker version of a complete identity match. It is a different state. A profile can belong to somebody at the same company. A name can resemble the local part of an address shared by several people. The resolver can return that candidate for review, but it must not silently copy the candidate's career history into the contact.
The same principle governs the photo. When the profile reader receives a contact ID, it copies a portrait only if the identity verdict is positive. The system does not search for a face by name and hope that the result belongs to the record. It first establishes the identifier, then uses the identifier to locate the permitted source. Guess where to look; do not guess what the source will contain.
The stop condition is as important as the matching condition. If no candidate passes, the correct result is an unresolved CRM name. An empty or placeholder field tells a human that work remains. A stranger's name, employer, and history make the record look finished while hiding the mistake.
From observations to record outcomes
The relationship among evidence, score, and outcome can be represented as a decision path.
The diagram separates evidence classification from the final record outcome. The band tells the system how much support the observations carry. The write path then maps that band to a controlled result: strong support can be written, weaker support can be offered to a representative, and insufficient support is not stored. A score does not decide truth. It makes the treatment of an observation consistent and explainable.
A proposal is useful only when its basis remains visible. The representative can see whether the value came from a cited web claim, a search result that pointed to a profile, or another supporting observation. The source detail and URL preserve a path back to what was actually observed. The human is not asked to trust a bare value produced by a model; they are asked to judge a bounded claim with its evidence attached.
Contradiction is a state, not a small penalty
Weak evidence and contradictory evidence are not the same. Weak evidence says that a claim has some support but does not identify the person directly. Contradictory evidence says that the available sources cannot currently agree. Averaging those conditions into one middle score would hide the reason a human needs to look.
The ledger therefore gives contradiction a hard effect. When a contradiction appears, the score is capped at 0.45, and the rationale says that the claim is held because another source disagrees. That score can remain in a possible band, but it cannot become verified through the arithmetic of additional clues. The conflict must be resolved as a conflict.
Imagine a profile that identifies someone as working for one employer while a recent signature says another. The system does not decide that the person is 70 percent at one company and 30 percent at the other. The sources might represent a job change, an outdated profile, a shared address, or a mistaken match. Each explanation requires different action. A held claim preserves that distinction.
This behavior also limits a subtle form of model pressure. If the agent is rewarded only for filling fields, it has an incentive to find one more clue and keep searching until the desired answer looks defensible. A contradiction interrupts that incentive. The correct action is to report the clash, retain the relevant evidence, and stop pretending that more arithmetic will resolve it.
Calibration has limits, and that is part of the contract
The evidence model does not make outside sources current. It does not guarantee that a person has a public profile, that an employer domain represents every corporate relationship, or that every internal thread was ingested. A provider can return no usable profile. A search can point to several plausible people. A signature can be old. The repository's rules reduce these risks by making their consequences explicit, not by eliminating the risks.
The model also does not replace human judgment. It decides when an observation qualifies for a particular system outcome. A representative still resolves a proposal, interprets a genuine business ambiguity, and decides whether a record should carry a value that the system cannot establish directly. The agent's job is to narrow the question and preserve the evidence, not to make uncertainty disappear.
That is the deeper meaning of evidence before confidence. A trustworthy CRM does not ask an AI system to sound less certain. It gives the system a smaller authority: observe, classify, explain, and write only through a path that respects the evidence and the state of the record. The next test is what happens when this policy meets an incomplete contact in practice. Sometimes the safest name is no name. Sometimes a useful clue belongs in front of a representative. The difference comes from the relationship between the source, the claim, and what the record already contains.