Identity Verification

A session that mentions a known visitor's email or phone shouldn't automatically get full access to that visitor's history — otherwise anyone who guesses someone's email could harvest their prior conversations. The Identity Graph splits "claimed" from "verified" so the AI agent only sees cross-session context when we're confident this is really the same human on the same device.

Trust levels

Every session has an identity_trust level:

Level	What the AI sees
anonymous	Nothing — no identity has been claimed or verified.
claimed	Visitor's name and email/phone are surfaced, plus everything that happened in this session. No cross-session history.
verified	Full Identity Graph — past conversations, CRM context, extracted facts, mirrored bookings, behavioural signals across sessions.

Within a single session, anything the visitor shares in that session is always available to the AI in that session. Verification only gates cross-session reach.

Direct triggers (instant verify)

Five direct triggers will immediately verify a session, regardless of policy:

1. First Person Profile — the visitor is being identified to your tenant for the very first time. There's no prior data to gate, so the first identifying session establishes the baseline and is treated as verified.
2. First-party form on your site — a form submission picked up by the website form intercept. Submitted on your domain by the visitor's actual browser, so it's as trustworthy as a form fill.
3. CRM-tracked landing — visitor arrives carrying a HubSpot hubspotutk cookie or a GoHighLevel contact_id query parameter. The widget detects either at session bootstrap.
4. Returning known device — the same browser / device fingerprint identifier is already on this visitor's verified set.
5. Inbound voice call — the inbound caller-ID matches a known phone for this visitor, and your tenant has caller-ID verification enabled.

Score-based verification

If no direct trigger fires but the session still claims an identifier, the verifier scores the session against the visitor's previously-collected signals:

Signal	Points
Same user_session_id as a verified session	+100
FingerprintJS hash matches	+60
Soft browser signature matches	+25
Exact IP match within last 30 days	+20
/24 IP subnet match within last 30 days	+10
Email already known on this profile	+15
Phone already known on this profile	+15

The total score is compared against the policy threshold (below). If it clears the bar, the session is auto-verified and the audit log records why.

Per-tenant verification policy

Set by the super admin (see Admin Controls) — globally for every tenant, or as a per-company override:

Policy	Threshold	Right for
Permissive	Any claim verifies	Lowest friction; legacy behaviour. Default for existing tenants.
Moderate	Score ≥ 60	Recommended balance — returning visitors on the same Wi-Fi / same browser typically pass.
Strict	Score ≥ 80	New tenants by default. Requires multiple corroborating signals or a direct trigger.
Regulated	Direct triggers only	Healthcare / finance / regulated industries — score-based path is disabled entirely.

Inbound caller-ID verification can be toggled separately under the same screen. Off by default for tenants where caller-ID spoofing is a concern.

Conflicting claims

If a session is already verified for one Person and the visitor types another Person's email or phone (e.g. an attacker, or a co-worker on a shared device), the new claim is rejected:

• The session keeps its existing verified identity.
• The conflicting claim is recorded as an audit event on the second Person's profile (Conflict — session was already verified for <other-person-id>).
• The AI prompt remains unchanged; the typed identifier is in the chat history but no second Person's profile is exposed.

You can review these on the per-Person Profile Identity Audit tab. The Person Profile card on the parent Person screen also shows an amber warning when any conflicting claims exist.

What this means for AI replies

• Returning verified visitor — AI greets them by name, references prior conversations and bookings, knows their CRM stage.
• Returning visitor whose verification couldn't be re-established (e.g. cleared all browser data, switched browsers) — AI sees their name and email but treats this session as a fresh interaction. They can re-verify the next time they fill a form / arrive via a CRM-tracked link / call from a known number.
• First-time visitor — AI sees only the current session's data: page they're on, traffic source, anything they've typed.
• Attacker who guesses someone's email — gets the same view as a first-time visitor under any non-permissive policy.