What does a YELLOW classification cap?

No more than 2 YELLOW leads per 60 sends per mailbox. This bounds risk while still letting slightly-risky leads through when the sender is strong.

Can I override a RED classification?

No. RED means validation or health signals indicate the send would damage reputation. Manual override would bypass the core protection guarantee. If a RED is a false positive, resolve the underlying signal (re-validate the lead, recover the mailbox) and the lead will reclassify.

Execution Gate

Intelligent gate logic that determines whether a lead can be processed, with failure classification and retry strategies

What is the Execution Gate?

Before a lead is sent to a campaign, it passes through our **two-stage protection system**. The gate performs safety checks to ensure both lead quality and infrastructure health.

Stage 1: Ingestion Gate (Lead Quality)

Happens immediately when a lead is received (via API or Clay webhook). If a lead fails here, it is never stored as a valid lead.

⛔ Immediate Blocks

• Disposable Domains: (e.g., mailinator.com, tempmail.org)
• Role-Based Emails: (e.g., admin@, support@, info@)
• Suspicious TLDs: (e.g., .xyz, .tk)

Stage 2: Execution Gate (Infrastructure)

Happens asynchronously before sending. Ensures your sending infrastructure is healthy.

Gate Checks (in order)

1. Campaign exists — Is the target campaign configured?
2. Campaign active — Is the campaign currently running?
3. Mailbox available — Are there healthy mailboxes?
4. Domain healthy — Is the domain in good standing?
5. Risk acceptable — Is the hard risk score below threshold?

Failure Classification

Not all failures are equal. We classify gate failures into 4 types, each with different retry logic:

HEALTH_ISSUE

Mailbox or domain has exceeded bounce thresholds

Retryable: No

Deferrable: No

Action: Block until manual recovery

SYNC_ISSUE

Missing campaign or configuration data

Retryable: No

Deferrable: Yes

Action: Hold lead, retry after sync

INFRA_ISSUE

API timeout or connectivity problems

Retryable: Yes

Deferrable: No

Action: Retry with exponential backoff

SOFT_WARNING

High velocity but no bounce issues

Retryable: N/A

Deferrable: N/A

Action: Allow, log for monitoring

Mode-Based Behavior

The gate's behavior changes based on system mode:

Mode	Check Result	Gate Behavior
OBSERVE	Any	✅ Allow all, log results
SUGGEST	Failed	⚠️ Log recommendation, allow
ENFORCE	Failed	🛑 Block execution

Example Gate Flow

Lead arrives (API/Clay) → Ingestion Gate (Stage 1)
1. Is disposable domain? → NO
2. Is role-based email? → NO
Result: ✅ SAVED (Status: HELD)

Lead scheduled for sending → Execution Gate (Stage 2)

1. Campaign exists? → YES
2. Campaign active? → YES
3. Mailboxes available? → YES (3 healthy mailboxes found)
4. Domain healthy? → YES (domain in 'active' state)
5. Hard risk score acceptable? → YES (avgHardScore: 35, threshold: 60)

Result: ✅ ALLOWED
Action: Lead sent to campaign

Lead arrives → Execute Gate Checks

1. Campaign exists? → YES
2. Campaign active? → YES
3. Mailboxes available? → NO (all 3 mailboxes paused)
4. Domain healthy? → N/A
5. Hard risk score acceptable? → N/A

Result: 🛑 BLOCKED
Failure Type: HEALTH_ISSUE
Reason: "No healthy mailboxes available. 3 paused due to bounce threshold."
Retryable: false
Deferrable: false

Lead States

Leads transition through states based on gate results:

held→

Lead received from Clay, waiting for gate check

active→

Passed gate, sent to campaign

paused→

Gate blocked (HEALTH_ISSUE), manual intervention required

completed→

Outreach finished, no longer monitored

🎯 Key Insight

The execution gate is the last line of defense before leads enter production campaigns. By classifying failures and providing intelligent retry logic, we protect infrastructure while maximizing throughput.