§045 min read · Last updated 2026-06-04

Core intersect

Suppression check → dedup → Chainlog anchor. No lead proceeds to personalization without proof of ingestion timestamp and a suppression-clean status.

Intersect is the cheapest stage in the pipeline and the most consequential. It is what turns raw signals into eligible leads, and it is the step where the audit trail is established. Everything downstream — the LLM call, the AgentGate decision, the dispatch — runs against the chainlog_event_id that intersect writes.

Order of operations

  1. Suppression check. Email and domain matched against the tenant suppression list. Hits are dropped with a Chainlog event recording the suppression reference.
  2. Dedup. The (company, target_product) tuple is matched against the leads table. Hits update the existing lead row with the new signal pointer instead of creating a duplicate.
  3. Fit score. Deterministic scoring against a per-tenant rubric. Below threshold, the lead is dropped with a Chainlog event recording the score and the rubric version.
  4. Jurisdiction inference. The recipient jurisdiction is derived from the signal (domain TLD, company HQ from enrichment, explicit override). This is what PHI Gateway uses to route the LLM call.
  5. Chainlog anchor. A lead.admitted event is written with the lead id, all source signal ids, the fit_score, the jurisdiction, and the rubric version.

Why suppression goes first

Suppression is a hard gate. We check it before anything else because the cost of a wrong drop here (zero — we did nothing) is negligible, while the cost of admitting a suppressed contact is reputational and regulatory. Every other check assumes the row is suppression-clean.

Evaluate the runtime

Two free MCP tools surface this pipeline inside Cursor or Claude Desktop — no key required.

Install MCP →