Purpose

Use this brief when preparing David Drebin lead batches for email validation in Samurai.

Samurai is the validation and lead-processing engine. It is not the CRM and not the campaign-sending tool. Its job is to take prospect data, clean/filter it, discover or use email addresses, validate those emails through its validation provider, remember results, and export usable lists.

Core Understanding

Samurai works through job-based workflows. A job may import people or company records, apply filters, show a preview, process email discovery/guessing, validate email addresses, and export results.

For David Drebin, the main use case is:

1. Upload or create a job from a raw CSV batch.
2. Make sure the correct email column is present.
3. Use Samurai validation actions.
4. Download the valid-email export.
5. Use the valid export as the final candidate list for outreach.

Email Guessing vs Validation

Samurai may be able to guess email patterns from first name, last name, and company domain, for example:

• firstname@company.com
• firstname.lastname@company.com
• firstinitiallastname@company.com

Guessed emails are only candidates. They should not be treated as usable until they pass validation.

Validation Memory

Samurai has built-in memory for email validation results.

Every checked email is stored with:

• email address
• validation result
• validation date
• related status metadata

If the same email appears again in another job or list, Samurai can reuse the existing validation result instead of paying to validate it again.

This is why the correct button for fresh batches is usually:

Validate all emails never validated

That action should only send emails that Samurai has never validated before into the validation queue.

Samurai also has a separate route for older results:

Validate all emails older than 6 months

Use that only when intentionally refreshing stale validation data. Do not use it for normal new-batch validation unless the goal is to recheck older email statuses.

An email validated only three months ago should normally not be revalidated because Samurai's memory should still consider the result recent.

External Verification Provider

Samurai orchestrates validation and stores results. The actual mailbox/DNS/mail-server verification is delegated to an external provider. In reviewed code/context, the current provider is Reoon, with signs of older/internal validation routes existing historically.

Important interpretation:

• safe means the provider considers the email reasonably safe to send to.
• invalid means do not use.
• catch-all is uncertain and should be treated separately.
• role or role-like accounts may be valid technically but are usually lower quality for personal outreach.

A safe result does not guarantee inbox placement, response, or that the exact intended person will read the email.

Queue Behavior

Samurai queues unvalidated emails for checking. It avoids unnecessary duplicate work by consulting the email-validation memory.

The queue can mark items as in-work and release stalled items after a timeout so they can be retried. This helps avoid stuck validations.

Recommended David Drebin Workflow

Use only raw validation CSV files, not summaries or documentation files.

For the current proven-benchmark batches, use:

/Users/arseni/Documents/DATABASES/LinkedIn_Database/output/david_drebin/monthly_batches/to_validate

Expected files:

• monthly_validation_batch_2026_05_proven_benchmark.csv
• monthly_validation_batch_2026_06_proven_benchmark.csv

Do not upload:

• .md files
• __summary.txt files
• QA notes
• old noisy portfolio batches unless explicitly requested

In Samurai:

1. Open the job.
2. Confirm the imported CSV has an emails / Emails column.
3. Use Validate all emails never validated.
4. Wait for validation to finish.
5. Download the only valid emails export.
6. Preserve the only not valid emails, Outs, and Unfiltered exports for audit if useful.

Output Interpretation

Common Samurai exports:

• *_Unfiltered.csv: all rows before final validity filtering.
• *_only valid emails.csv: the primary usable output.
• *_only not valid emails.csv: invalid or not-safe emails.
• *_Outs.csv: rows excluded by filters or output rules.
• parts/*.csv: split chunks, often around 6,000 rows each.

For David deliverables, the main file of interest is usually:

*_only valid emails.csv

Agent Responsibilities

When acting as the Samurai Validation Agent:

• Keep the validation input folder clean.
• Upload/use only intended raw CSV batches.
• Do not ask Samurai to validate .md or summary files.
• Prefer Validate all emails never validated for new batches.
• Do not revalidate recent emails unless explicitly asked.
• After validation, identify and download the valid-email export.
• Report how many valid emails were produced.
• Check for duplicate emails in the exported valid file.
• Keep the original raw batch, Samurai output, and final valid export traceable.

Key Rule

Samurai's validation memory is valuable. Do not waste credits by revalidating recent emails unless there is a specific reason to refresh stale data.

Strategic Direction: Possible Samurai Replacement

As of July 2026, we are considering replacing most of Samurai for this narrow David Drebin bulk-validation workflow with a Codex/Cursor-controlled local pipeline.

This does not mean replacing every Samurai feature immediately. The first replacement target is only the repeatable monthly email-validation workflow:

1. Take raw 40,000-row CSV batches.
2. Extract and normalize emails.
3. Check validation memory.
4. Validate only emails that are never validated or intentionally stale.
5. Store provider results permanently.
6. Export clean files for outreach and audit.

Why Replace Samurai for This Workflow

The workflow has become narrow enough that a local script/database may be clearer than a web app.

Reasons to replace this part:

• transparency: every skip, reuse, validation, and refresh can be explained from code and logs
• direct memory control: we own the email/status/date/provider database
• fewer UI mistakes: no risk of clicking the wrong Samurai button or exporting the wrong file
• better automation: one repeatable monthly command can create logs, exports, and summaries
• easier audits: we can answer where an email came from and when it was validated
• lower dependency on an old web app for a critical monthly process

Reasons not to replace everything immediately:

• Samurai may still have useful UI preview and old job history
• Samurai may contain validation history that needs to be migrated or exported first
• we should compare Codex/Cursor output against Samurai before fully switching

Replacement System Requirements

The Codex/Cursor replacement must rebuild Samurai's useful parts, not just call Reoon.

Minimum required components:

• local validation-memory database
• validation queue
• Reoon or other provider integration
• rate limiting and retry logic
• durable logs
• duplicate-email suppression
• stale-result policy, for example 180 days
• exports split by status
• full audit export preserving source batch/source row

Recommended local structure:

/Users/arseni/Documents/DATABASES/LinkedIn_Database/output/david_drebin/email_validation/
├── validation_memory.sqlite
├── input_batches/
├── queued/
├── provider_results/
├── exports/
└── logs/

Recommended memory table fields:

email
normalized_email
status
validated_at
provider
provider_response_json
source_batch
source_job
first_seen_at
last_seen_at
notes

Useful output files:

• only_valid.csv
• invalid.csv
• catch_all.csv
• role_or_risky.csv
• reused_recent_valid.csv
• queued_for_validation.csv
• full_status_output.csv

Future Codex Command Shape

The future replacement command should look approximately like:

python3 validate_emails.py \
  --input /Users/arseni/Documents/DATABASES/LinkedIn_Database/output/david_drebin/monthly_batches/to_validate/monthly_validation_batch_2026_05_proven_benchmark.csv \
  --account david_drebin \
  --provider reoon \
  --mode never_validated \
  --validity-window-days 180

Important behavior:

• emails validated recently are reused, not revalidated
• emails older than the validity window can optionally be refreshed
• never-validated emails are sent to the provider
• all provider responses are stored in SQLite
• final exports are deterministic and reproducible

Migration Plan

Phase 1: Keep Samurai as fallback and build local validation memory.

Phase 2: Run one batch through both Samurai and the Codex/Cursor pipeline.

Phase 3: Compare valid, invalid, catch-all, and skipped/reused counts.

Phase 4: If results match closely and logs are clear, make Codex/Cursor the primary validation workflow.

Phase 5: Keep Samurai only for fallback, UI inspection, or legacy job access.