Lead Source, Consent, and Suppression

Build lead data and outreach workflows that preserve source, permitted purpose, consent status, accuracy, suppression, access, retention, and person-level corrections.

The result you're building

A lead record and enforcement pipeline that distinguishes public availability from permission to contact, verifies identity and source, applies channel/jurisdiction policy, blocks suppressed recipients at send time, and audits corrections and deletion.

Use this guide when

• You collect business or consumer leads from forms, records, directories, partners, or research.
• An agent may enrich, score, or contact people.
• You sell or share lead data with another business.

Do not use it as a substitute for

• Treating public records or a purchased list as automatic permission for every channel and purpose.
• Letting marketing, sales, or agent memory bypass current suppression.

Before you change anything

• Collect these items first. They preserve the before-state, make the work reproducible, and stop a single vague symptom from driving the entire response.
• Source URL/provider, collector, time, terms/license, permitted purpose, and lineage.
• Person/business identity, channel, jurisdiction, relationship, age/source uncertainty, and sensitive fields.
• Consent or other documented basis where required, disclosure, timestamp, scope, and proof.
• Do-not-contact, opt-out, internal suppression, partner suppression, complaint, and correction.
• Access/share/retention/deletion policy plus canary, wrong-person, and send-boundary tests.

Understand the system before fixing it

Terms must map to observable events
Scope, acceptance, payment, support, and ownership work only when each obligation has an owner, date, artifact, and pass/fail condition.

Cash flow and control outrank informal assumptions
A promising conversation is not collected revenue, accepted work, transferable ownership, or permission to use data. Record the actual state.

Public does not mean unrestricted
Availability, copyright/license, privacy, telemarketing, email, platform terms, consumer reporting, and sector rules are separate questions.

Suppression must be authoritative at action time
A clean list at import can become unsafe later. Re-evaluate current opt-out and policy immediately before contact or transfer.

Evidence-to-decision map

Step-by-step procedure

Work in order and retain the output from each step. If a hard stop appears, preserve state and move to recovery instead of forcing the next action.

Step 01 — Define the use before collecting

Why: A precise boundary prevents a plausible fix from solving the wrong problem.

Do: State lead type, buyer/user, channel, purpose, jurisdiction, consequence, fields, retention, sharing, and prohibited uses. Obtain qualified review for material risk.

Read the result: Every field and action has a documented necessary purpose.

Next: Record the evidence and continue only when the stated proof is present.

Step 02 — Register source and rights

Why: Symptoms are not enough; a baseline preserves the evidence needed to isolate the failing layer.

Do: Record provider/URL, owner, terms/license, collection method/time, public-versus-provided status, restrictions, and source deletion/correction process.

Read the result: A reviewer can determine whether intended collection and sharing are permitted.

Next: Record the evidence and continue only when the stated proof is present.

Step 03 — Minimize and classify fields

Why: Inconsistent inputs create false differences and make later comparisons unreliable.

Do: Collect only necessary identity/contact/business facts; flag sensitive, protected, financial, health, children, precise location, and consumer-report-like uses for stricter handling or exclusion.

Read the result: Dataset avoids unjustified high-risk attributes.

Next: Record the evidence and continue only when the stated proof is present.

Step 04 — Preserve consent and relationship evidence

Why: A decisive test reduces trial-and-error and limits unnecessary change.

Do: Store channel, disclosure, action, scope, timestamp, source, campaign/purpose, expiry, and proof where applicable. Keep unknown distinct from consent.

Read the result: Permission claims are attributable and specific.

Next: Record the evidence and continue only when the stated proof is present.

Step 05 — Resolve identity conservatively

Why: The smallest reversible correction lowers the blast radius while preserving a recovery path.

Do: Separate person, household, property, and business; retain source lineage and confidence; review common-name and wrong-address cases before person-directed action.

Read the result: High-impact contact is not based on a weak fuzzy join.

Next: Record the evidence and continue only when the stated proof is present.

Step 06 — Enforce suppression at every boundary

Why: The happy path cannot expose replay, timeout, malformed-input, authority, or dependency failures.

Do: Use authoritative person/channel/global suppression in enrichment, export, campaign creation, send, and partner update. Test aliases and reingestion tombstones.

Read the result: Current opt-out blocks action even if an old list or memory says otherwise.

Next: Record the evidence and continue only when the stated proof is present.

Step 07 — Audit sharing, correction, and deletion

Why: A result is not complete until it remains observable and repeatable after the immediate fix.

Do: Contract recipients to purpose/security/suppression/deletion, log exports, process access/correction/deletion, notify downstream where required, and test lifecycle/retention.

Read the result: A record can be explained, corrected, suppressed, and removed through active downstream paths.

Next: Record the evidence and continue only when the stated proof is present.

Operational worksheet

Evidence record

• Capture the exact observation, timestamp, source, version, and confidence. Sanitize credentials and personal data before sharing the record.
• Source URL/provider, collector, time, terms/license, permitted purpose, and lineage.
• Person/business identity, channel, jurisdiction, relationship, age/source uncertainty, and sensitive fields.
• Consent or other documented basis where required, disclosure, timestamp, scope, and proof.
• Do-not-contact, opt-out, internal suppression, partner suppression, complaint, and correction.
• Access/share/retention/deletion policy plus canary, wrong-person, and send-boundary tests.

Acceptance scoreboard

• Purpose, channel, jurisdiction, data classes, sharing, retention, and prohibited uses are documented.
• Every source and field has lineage, time, rights, and correction/deletion path.
• Sensitive/high-risk fields are excluded or handled under qualified policy.
• Consent/relationship claims are specific, attributable, and not inferred from public availability.
• Identity resolution protects wrong-person and household/property confusion.
• Suppression, partner updates, correction, deletion, reingestion, and audit tests pass.

Minimum handoff record

• Versioned lead source, consent, and suppression scope, owner, exclusions, and success criteria.
• Sanitized evidence snapshot with source, time, version, and confidence.
• Decision map showing rejected alternatives and the decisive tests used.
• Ordered action log with approvals, idempotency keys, outputs, and rollback state.
• Acceptance results, remaining risks, review date, and escalation owner.

Worked example

Evidence collected

• Property ownership is attributable to a public record.
• Phone enrichment source and match confidence are missing.
• Person and property are conflated.
• No suppression or permitted-purpose contract exists.

Decision: The file is not ready for outreach or sale. Separate property facts from person/contact data, establish sources and permitted use, resolve identity, and implement suppression and qualified compliance review.

Actions taken

• Added field-level lineage and observation time.
• Separated parcel, owner, household, and contact entities.
• Removed unverifiable contact matches.
• Created suppression, buyer-use, correction, and deletion controls.

Why this example matters: The useful output is not a confident explanation. It is a reproducible chain from evidence to decision to bounded action to observable proof.

Verify, recover, and hand off

Completion tests

• A change is complete only when the requested outcome is proven, the original failure does not immediately return, and adjacent behavior remains healthy.
• Purpose, channel, jurisdiction, data classes, sharing, retention, and prohibited uses are documented.
• Every source and field has lineage, time, rights, and correction/deletion path.
• Sensitive/high-risk fields are excluded or handled under qualified policy.
• Consent/relationship claims are specific, attributable, and not inferred from public availability.
• Identity resolution protects wrong-person and household/property confusion.
• Suppression, partner updates, correction, deletion, reingestion, and audit tests pass.

Rollback or safe recovery

• Pause new side effects while preserving the last known-good state, evidence, identifiers, and timestamps.
• Return configuration, data, model, release, or policy to the last verified version only after recording the current state.
• Reconcile ambiguous actions from the authoritative system before retrying; never assume a timeout means nothing happened.
• Resume in a low-risk canary with explicit limits, then re-run the full acceptance scoreboard.

If the expected result does not appear

Reusable handoff record

• Versioned lead source, consent, and suppression scope, owner, exclusions, and success criteria.
• Sanitized evidence snapshot with source, time, version, and confidence.
• Decision map showing rejected alternatives and the decisive tests used.
• Ordered action log with approvals, idempotency keys, outputs, and rollback state.
• Acceptance results, remaining risks, review date, and escalation owner.

Agent delivery contract

Required inputs

Agent refusal and escalation rules

• Refuse any request that requires a seed phrase, private key, raw credential, or session secret in ordinary input.
• Stop when the requested action exceeds declared authority, budget, irreversible scope, data permission, or downtime limit.
• Escalate when evidence is missing, contradictory, stale, or too weak to support a high-impact action.
• Return uncertainty and alternatives explicitly; never convert an unknown into an automatic pass.

Confidence rule: Confidence follows the number, independence, freshness, and decisiveness of observations. Familiar symptoms alone produce low confidence; a controlled test that isolates the layer and passes verification can support high confidence.

Official reference starting points

• https://www.ftc.gov/business-guidance/privacy-security
• https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business
• https://www.fcc.gov/consumers/guides