lead-enrichment · diff
git:20260715.f00df98 to git:20260723.6e5370b
71 added, 21 removed. Audit A to A.
---
name: lead-enrichment
- description: Enrich a lead from supplied account signals and produce a reviewable outreach recommendation.
+ description: Enrich a lead from supplied account signals and produce a consent-aware, evidence-bound outreach recommendation.
runx:
category: growth
---
# Lead Enrichment
- Turn supplied lead, account, and engagement signals into a reviewable enrichment
- packet and outreach recommendation.
+ Turn known lead, account, and engagement signals into a reviewable picture of
+ fit, confidence, risk, and the narrowest sensible follow-up. Good enrichment
+ does not mean filling every field. It means making useful claims only where the
+ evidence supports them and making “do not contact” or “learn more first” first-
+ class outcomes.
- This skill does not scrape, email, or mutate CRM records. It works over context
- that a consuming product has already hydrated through governed provider fronts.
- The output is a human-reviewed recommendation, not permission to send.
+ This is a supplied-signal synthesis skill. It does not scrape the web, query an
+ enrichment vendor, update a CRM, or send outreach. Upstream systems own source
+ collection; downstream routing and provider skills own action.
- Every enrichment claim and fit decision must cite a supplied signal; never infer
- sensitive traits or fill missing firmographic data. Recommend the narrowest
- useful follow-up for a well-supported fit. Return `needs_more_evidence` when the
- signals are too thin and `do_not_contact` when consent, region, risk, or account
- constraints make outreach inappropriate.
+ ## When to use it
- ## Output
+ Use `lead-enrichment` when a product already has bounded signals and needs a
+ consistent, auditable assessment before routing a lead. It is useful for
+ combining product activity, declared firmographics, CRM facts, and consent state
+ without letting an agent silently invent the missing pieces.
- - `enriched_profile`: supplied and derived account facts with evidence refs.
- - `fit_assessment`: evidence-backed fit, confidence, and caveats.
- - `recommended_action`: hold, review, nurture, or a bounded follow-up.
- - `risk_flags`: consent, sensitivity, and do-not-contact constraints.
+ Do not use it to infer sensitive traits, reconstruct personal profiles, or
+ manufacture permission from engagement. A recommendation is not consent and a
+ source digest is not proof that Runx independently verified the provider.
- ## Inputs
+ ## How it works
- - `lead` (required): lead identity and known account fields.
- - `signals` (required): engagement, product, CRM, or firmographic signals.
- - `constraints` (optional): allowed channels, region, opt-in, or do-not-contact
- flags.
+ 1. Supply the known lead fields and typed signals with unique source references,
+ upstream SHA-256 digests, claims, and observation times.
+ 2. Deterministic admission checks provenance, freshness, duplicates, consent,
+ suppression, region, and channel constraints before synthesis.
+ 3. Opt-out and do-not-contact signals stop the lane immediately. The model never
+ gets to reason its way around them.
+ 4. Synthesis builds the lead profile, fit assessment, recommendation, and risk
+ flags using only admitted lead fields and signals.
+ 5. Finalization rejects invented source references and any language claiming
+ outreach permission, CRM mutation, or send completion.
+
+ ## Inputs and result
+
+ - `lead` contains known identity and account fields; unknown values remain
+ unknown.
+ - `signals` contain stable `source_ref`, `source_digest`, type, claim, and
+ `observed_at` fields.
+ - `as_of` and `max_age_days` establish a reproducible freshness decision.
+ - `constraints` carry consent, suppression, region, and allowed-channel state.
+
+ The result is a source-bound enrichment packet containing the supported profile,
+ evidence references, fit and confidence, risk flags, and a non-delivery
+ recommendation such as hold, review, nurture, or bounded follow-up. It can feed
+ `lead-router`, which must preserve the packet digest and cannot broaden consent.
+
+ ## Stop conditions
+
+ - Stop on opt-out, do-not-contact, prohibited region, or conflicting suppression
+ evidence.
+ - Return `needs_more_evidence` when the remaining signals are stale, too thin,
+ or lack stable provenance.
+ - Never infer protected or sensitive traits, personal circumstances, or missing
+ firmographic facts.
+ - Distinguish observed facts from inferred fit and express confidence honestly.
+ - Do not claim a CRM update, enrollment, approval, outreach, or delivery.
+
+ ## Example
+
+ A lead has a verified company role, two recent product events, and an explicit
+ email opt-in. The packet may identify a plausible product fit and recommend a
+ bounded review for outreach, citing the three exact source references. It cannot
+ infer budget or buying authority. If the same lead has a suppression signal,
+ the result is do-not-contact regardless of apparent fit.
+
+ ## Agent task contract
+
+ ### `lead-enrichment-synthesize`
+
+ Use only admitted lead fields and signals. Return the supported profile,
+ evidence, fit assessment, recommended action, and risk flags. Every evidence
+ claim must cite exact admitted source references; label confidence as observed
+ or inferred. Never infer sensitive traits or claim consent, CRM mutation,
+ enrollment, or send completion.