Written specification · August 2026

List building and enrichment specification

The exact pipeline I use to turn a directory scale source into a clean, deduplicated and verified list of target accounts, and why the step order is the whole game: filter before you enrich, so every credit you spend lands on a row that survives to the export.

Yinka A. · Engineer behind Maikaza · All proof

The pipeline, in execution order

SOURCE          pull wide from the ICP source (directory, Apollo search, web set)
   |
NORMALIZE       casing, domains without www, phone and geo formats, title synonyms
   |
DEDUPE          stable keys BEFORE enrichment:
                company  = root domain + normalized name
                person   = email when present, else name + company key
                location = one firm with three branches is ONE partner record
   |
FILTER TO ICP   drop out of scope rows NOW, while they are still cheap
   |
ENRICH          waterfall only on survivors:
                Apollo first, Clearbit style fallback second,
                each field records WHICH provider filled it
   |
VERIFY          email verification pass; catch alls and role accounts flagged,
                hard bounces removed, verification status kept as a column
   |
QA GATE         sampling review against acceptance thresholds (below)
   |
DELIVER         live Clay table + CSV + Google Sheet, column dictionary included

Table design

Column groups in the delivered table
Column group	Fields	Source
Identity	Company, root domain, person, normalized title, seniority	Source plus normalization
Firmographic	Employee band, industry, location by city, region and country	Enrichment waterfall
Contact	Verified email, verification status, LinkedIn URL, phone where licensed	Waterfall plus verifier
Provenance	Source of each enriched field, enrichment date, dedupe key	Generated
ICP flags	Match results, inclusion reason, exclusion reason for near misses	Filter logic

Provenance columns matter more than they look. When a field is wrong you know which provider to stop trusting, and when the list is refreshed next quarter the table runs again instead of being rebuilt.

Acceptance thresholds I hold the list to

Zero duplicate company keys and zero duplicate person keys in the export.
Every row carries a verified or flagged email status; hard bounces do not ship.
Titles normalized to a controlled vocabulary, so filters and mail merge work.
Every enriched field traceable to its provider.
A random sample check documented before handover, with the sample and its results shared.

Where the same discipline already runs

pg-importer is a public repository with 17 automated tests that applies the same rules to Excel and CSV imports into PostgreSQL: files are staged, only rows that changed are updated, and a file already imported is skipped unless the run is forced. List hygiene is not a Clay feature; it is a working method that Clay makes fast.

Specification written in August 2026; the pg-importer reference was added in September 2026. Criteria for any project plug into the filter and ICP flag stages without changing the architecture.

Start here

Start with one real finding.

Send me your company domain, and I will send back one specific problem with its evidence, free.

Ask for a free finding See all proof

Or write to admin@maikaza.com