About this template
Your 50% provider is being paid to re-find contacts the 70% one already found
Everyone orders an enrichment waterfall by hit rate. So the 70% provider goes first, and nobody notices that the one behind it is billing for rows that were already filled.
The bill is real. The incremental value isn't.
Order by cost-per-incremental-hit, not hit rate
incremental_hits(step_n) = rows step_n filled that steps 1..n-1 left empty
effective_cpl(step_n) = credits_spent(step_n) / incremental_hits(step_n)
Every provider line in the report shows raw hit rate and incremental hit rate. The gap between those two numbers is the thing that changes your mind.
Correct waterfalls front-load cheap-and-broad, even when its absolute hit rate looks unimpressive — because every row it fills is a row the expensive provider never gets billed for.
Overlap is the finding
When two providers fill the same rows, one of them is paid for nothing at its current position. You get a pairwise overlap matrix, and above 80% overlap the recommendation is to drop the more expensive one entirely — not reorder it.
Verification runs once, at the end
It's a separate cost. Verifying the same address three times because three providers returned it is pure waste, and the report flags it if your export shows it happening.
What comes back
First line is one number: credits paid for rows an earlier provider had already filled.
Then current vs proposed order side by side with effective CPL each, drop candidates with their overlap percentage and against which provider, the verification flag, and projected saving per 1,000 rows with the arithmetic shown.
What you supply
Your own Claude Code login, plus a table export with the per-provider columns intact (Clay: export with the enrichment columns).
A single merged email column can't be audited — it says so and stops rather than
guessing.
No provider keys. The export is the input, which is exactly why no credits can be spent.
The guard is a file, not a promise
~/waterfall/policy/WATERFALL-RULES.md carries NEVER_RUN_CREDITS, the
incremental formula, the overlap rule and your own provider costs. The skill reads
it before every audit. The whole point is to stop spending credits you didn't need
to spend, so it cannot spend one.
Where this stops
It reads exports and drafts a configuration. It does not call providers, run a Clay table, or spend a credit.
It won't read hit rate as quality — it sees fill rates, not whether the email is correct, and a high hit rate on bad data is worse than a low one. And it won't tell you a dropped provider is safe to cancel, because it may cover a segment this export doesn't contain.
Verified on build: the skill, the working tree, the NEVER_RUN_CREDITS guard, the
incremental formula, the overlap rule and the verify-once rule are present on a
fresh fork. Running it on your own export is yours to do.