cocottetech/@platform/codebase/@features/prospecting/docs/cross-provider-graph.brief.md

cross-provider-graph.brief

Subfeature of: prospecting Code-name: prospect-graph Specialist: specialist-graph-resolver Status: P5, ships first (independent of warm-intros).

Problem

Each provider's specialist-prospect-resolver builds context from their own inbox alone. The same prospect who ghosted provider A and converted with provider B teaches nobody. Inbound qualification is repeated work across the network — most of it could be skipped if the network shared what it already knew, with consent.

Solution

A dynamically-generated cross-provider profile for every consented prospect-subject. The graph never merges prospect rows across providers (that boundary stays hard per Y §Y4), but it computes a shared subject-key — derived from identifier_hash and photo-hash matches already produced by specialist-prospect-resolver — and lets each provider's copilot query "what does the consented network know about this subject?"

Pooled signal returned per subject (all consented, all auditable):

• Outcomes histogram — ghost / no-show / converted / blocked, weighted by recency and provider-trust.
• Qualification fingerprint — feature vector summarizing how the subject communicates (response latency, message-length distribution, vocabulary markers), without leaking message content.
• Safety flags — N-provider-coop peer-attested reports re-surfaced on the subject (existing primitive).
• Funnel velocity hints — typical touchpoint-count and elapsed time from first message to outcome, anonymised across contributing providers.

States

1. No consented contributors. Graph returns provider-local data only; subfeature is a no-op.
2. Sparse contributors (2–10). Graph returns signal with explicit "low-confidence" badge; copilot uses as hint, not authority.
3. Dense contributors (50+ in same category/region). Graph returns confident signal; auto-qualify and warm-intros condition on it.
4. Subject opt-out. A prospect-subject can revoke consent through any consented provider; their subject-key is tombstoned and historical contributions are no longer surfaced.
5. Provider opt-out. A provider can leave the graph; their historical contributions are retained as anonymised aggregates but no longer attributable.

Constraints

• Subject-key, not row-merge. Subject-keys are derived from already-hashed identifiers; the graph never sees raw PII. Provider rows remain isolated per Y §Y4.
• Person-level consent gates contribution AND query. Both sides of the exchange are recorded.
• Anonymised aggregates only. Counts, distributions, and feature vectors — never quoted messages, never per-provider attribution unless the contributing provider explicitly opted into attributed signal for that subject.
• GDPR / Icelandic DPA compliant. Subject erasure must purge contributions; provider erasure must anonymise. See I-audit-trust-replay.brief.md for audit primitives.

Related docs

• prospecting.brief.md (parent)
• cross-provider-graph.contract.md (this subfeature's AI interface)
• cross-provider-graph.screen.md (low-priority web FE)
• @features/ai-copilot/docs/specialist-prospect-resolver.contract.md (produces the hashes the graph keys on)
• @features/ai-copilot/docs/N-provider-coop.brief.md (safety-flag primitive)
• @features/ai-copilot/docs/Y-cross-org-marketplace.brief.md §Y4 (no-auto-merge rule)
• @features/ai-copilot/docs/_engineering-surface-metrics.md (touchpoint schema + anonymous invariant)