# Waterfall Enrichment Cost Auditor

> Reorders your enrichment waterfall by cost-per-incremental-hit and finds the providers billing for rows already filled. Never spends a credit.

- Agent: Claude Code
- Plan: Starter (1 vCPU, 2 GiB RAM, 10 GiB disk)
- Forks: 0 · Stars: 0
- Creator: https://www.jurniti.com/creator-ca0ff2
- Tags: claude-code, clay, enrichment, gtm, lead-gen, outbound
- Requires config (you provide): ANTHROPIC_API_KEY
- Skills: waterfall-enrichment

**To fork:** open https://www.jurniti.com/templates/waterfall-enrichment-cost-auditor and use the Fork action — it starts a Stripe Checkout for a new VM seeded with this template's persist disk (same flat plan price, no fork fee).

## README

# 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.