Lead Source, Consent, and Suppression

The result you are building

Finished Result:

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.

Stop Before Proceeding:

Stop collection, sale, enrichment, or outreach when source rights, purpose, identity, jurisdiction, channel rules, or current suppression cannot be established. Obtain qualified privacy/marketing counsel for the actual use.

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

Start with the row that most closely matches the evidence. The first test isolates a layer; it is not permission to
make every available change.

   Evidence              Likely layer     First decisive check              What the result means

   Opted-out person      Suppression      Trace identity and policy at      List-time filtering or stale memory bypassed current status.
   receives message      enforcement      send boundary

   Wrong homeowner       Entity           Compare source parcel/person      Name/address join lacks sufficient identity evidence.
   matched               resolution       and contact provenance

   Partner cannot        Provenance       Trace every field to source and   Data was transferred without lineage or contract controls.
   explain source                         permitted use

   Lead is old and       Freshness        Compare observed time and         Record age exceeds the purpose's accuracy requirement.
   inaccurate                             authoritative recheck

   Consumer asks         Lifecycle        Trace source, derivatives,        Deletion/correction does not propagate or reingestion lacks
   deletion but data                      exports, partners, and backups    tombstone.
   returns

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.

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.

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.

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.

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.

Procedure continued 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.

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.

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.

Decision rule SHIP / AUTOMATE GATE Proceed only when every required acceptance check is supported by direct evidence, rollback is available, and the remaining risk is explicitly owned. Unknown is not a 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

Starting Problem:

A mortgage lead file uses public property records, then adds a phone number from an unverified source and sells it to callers without source/consent fields.

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.

Proof Of Completion:

Every delivered field has source and permitted use; uncertain contacts are excluded; current suppression blocks export/send; buyer obligations and corrections are auditable.

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 What happened What it usually means Next safe move

Opted-out person receives List-time filtering or stale memory Trace identity and policy at send boundary message bypassed current status.

Wrong homeowner matched Name/address join lacks sufficient Compare source parcel/person and contact provenance identity evidence.

Partner cannot explain source Data was transferred without lineage or Trace every field to source and permitted use contract controls.

Lead is old and inaccurate Record age exceeds the purpose's Compare observed time and authoritative recheck accuracy requirement.

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
       Field                           Type                    Requirement

       target                          object                  Versioned environment, resource, identity, or workflow being evaluated.

       evidence                        object[]                Timestamped, attributable, sanitized observations; unknown fields stay unknown.

       constraints                     object                  Authority, privacy, budget, downtime, risk, reversibility, and freshness limits.

       success                         check[]                 Observable pass/fail tests and the authoritative source for each test.

    Returned output
       Field                           Type                    Requirement

       diagnosis                       object                  Likely layer, supporting and conflicting evidence, alternatives, and confidence.

       plan                            step[]                  Ordered bounded actions with owner, risk, expected proof, and stop condition.

       verification                    check[]                 Observed pass/fail/unknown results, not inferred success from command exit alone.

       handoff                         object                  Sanitized evidence record, recovery state, remaining risk, and next review trigger.

    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