Company Intelligence · Capability
Contact verification with provenance
Contact verification means knowing what is verified, what is inferred, and what is safe to write to CRM. Lumitra verifies who the person is, whether they work at the target company now, how their identity was anchored, and where each email or phone came from — then gates CRM writeback on that provenance.
Why “enriched” is not the same as “true”
Enrichment providers return fields; they don’t return accountability. A pattern-constructed email looks identical to a verified one in a CSV — until the sequence bounces, the domain gets flagged, or the rep calls the wrong person. Company intelligence you can act on requires every contact channel to carry its provenance, and requires the CRM gate to respect it.
What happens to the data
| CRM-eligible | Lumitra-only / labeled | Rejected |
|---|---|---|
| Selected, consolidated contact with a valid email and no existing CRM ID · site-published or fetched-source email · provider email with verified status · intentional generic inbox, labeled non-person-level | Pattern-constructed email · provider-guessed or provider-unverified email · phone-only contact · contactable person not selected for writeback · evidence awaiting a stronger verification event | Masked name, email, or phone teaser · invalid or ungrounded email · ungrounded person · wrong-person return from an exact LinkedIn match · record with no valid email or phone |
How verification works
- Ground. Find a real person and evidence tying them to the target company — names must be grounded in evidence fetched during the run.
- Verify. Check current employment (the company’s own site is strong evidence), recency of dated evidence, location consistency, and exact identity anchors like normalized LinkedIn URLs and provider IDs.
- Classify. Compute verification checks and label every channel: observed, verified, generic, inferred, or guessed. The labels stay attached to the contact.
- Gate. Dedupe against known CRM and Lumitra people before paid enrichment, consolidate duplicate representations, persist contactable records, and sync only CRM-eligible contacts — CRM reconciliation preserves the authoritative IDs that come back.
Verification runs on the contacts that account discovery selects, and the same provenance travels with the person when they later show up as a known website visitor.
Frequently asked questions
What does contact verification actually verify?
Several separate facts, not one score: that the person is real (a full name grounded in evidence fetched during the run — masked or invented names are rejected), that they work at the target company now (the company's own site is strong evidence; provider history and dated evidence are checked for recency), how their identity was anchored, and where each email or phone came from.
Why do identity anchors matter?
Because fuzzy person-matching is how the wrong John Smith ends up in your CRM. LinkedIn profile URLs are normalized and used as identity and dedupe keys; provider enrichment can anchor on the exact LinkedIn URL, and a returned person with a different profile URL is rejected rather than accepted as close enough.
How are emails classified?
By provenance. Site-published, fetched page/PDF, and provider-verified emails count as real. A generic inbox is real but explicitly not person-level. Pattern-constructed, provider-guessed, and provider-unverified emails remain labeled as inferred or guessed — useful for research, but never CRM truth. Masked directory teasers are rejected outright.
What is blocked from CRM writeback?
Guessed and provider-unverified emails are explicitly blocked, along with ungrounded people and wrong-person returns from exact identity matches. CRM writeback runs only from the selected, consolidated set — inferred data stays in Lumitra, labeled, until a stronger verification event upgrades it.
What happens when verification fails?
It stops instead of passing silently. Closed employment ranges or company and location conflicts trigger a verification stop. A final record with no valid email or phone is excluded from persistence entirely — a contact that can't be contacted isn't a contact.
See provenance on a real contact
Book a demo and inspect exactly which fields were verified, inferred, or blocked before a contact reached the CRM.