6
tables live in the GTM Engine workbook
This is the engine that feeds your outreach. It starts as a wide TAM funnel and narrows through a stack of tables that each filter harder than the last, so the list that reaches you isn't a guess. It's the people who own the motion, each behind a validation check and a human approval gate before anything sends.
Before the individual tables, here's the shape. Clay's power isn't any single table. It's that each table takes the output of the one before it and narrows it, eight hops deep, until what's left is only the contacts that survived every filter. A person doesn't hand-build a list. The engine surfaces it and keeps it current.
This is a head start, not a finished product. The core of the engine is built and validated on the Star Ratings new-logo motion. The outer layers are designed and next to stand up. Nothing has touched a prospect.
Each rung is a Clay table. Each arrow is a real column, a write or a lookup, that carries rows into the next table only if they pass that table's filter. The funnel narrows on purpose.
Click any layer to open its detail: the purpose, what feeds it, what it writes to, and the columns that do the work.
Source tables land the raw universe so a re-import never clobbers enrichment downstream. The CMS table is live: the public 2026 Star Ratings universe, filtered to the plans that are actually in window, below 4.0 stars. The customer-exclusion wire is next, pending the flagged customer file from Naveen, so the same filter can also drop anyone who's already ours. The Install-Base import is designed, not built; it waits on Salesforce access and will seed the back-office motion. Only rows that pass the window filter get written up into Accounts.
This is the hub. Every account gets a fit score, an intent score, and a letter grade from those two. Grade is the gate: only accounts above the grade line push down into Contacts, and where that line sits is a dial the team sets, not something hardcoded in. This is where "who's worth our breath" gets decided.
This is what keeps the list alive instead of a dead snapshot. Each signal is one column that fires a point value when a trigger hits: Stars language in an SEC filing, an earnings-call mention, a new quality leader, a claims backlog. Those points flow back into the Accounts intent score and can lift an account's grade or, for the strongest triggers, fire it straight toward outreach. It's also what removes accounts that fixed their own Stars and don't need us anymore.
This is the payoff table and the one that's most complete. Accounts push in, then a people-find pulls the right personas by title, a persona-key formula classifies each into the buying committee, and an email waterfall finds an address that ZeroBounce then validates. Anything without a valid mailbox can't pass the send gate. Three tags get stamped at creation and never change: engine-sourced, source motion, and sourced date. Those three are how the engine's contribution gets proven later. Honest state: all 137 rows have been through ZeroBounce on the canonical email field; around 106 carry a deliverable email, and the invalid or email-less rows stay visible but gated.
Message Gen writes a personalized variant per contact from the account's why-now and the right product angle. It's fenced by small reference tables: a Verified Metrics library so the copy can only use approved numbers, a Product-Angle map that routes a title to Queue Optimizer or Back Office Optimizer, and the locked ICP rubric. Those three are built; a fourth, the variant library for testing, comes with the generation column. That column is the next to wire, and the deeper personalization runs through Claude, not templates in Clay.
Nothing sends from Clay directly. Every row that reaches here runs a critic check first. Today the critic checks email validity; the scope, claims, and length checks land with Message Gen. Then it waits on a human checkbox. That gate is built and every single row is held. This is the "human before send" rule made physical.
On approval, this hands the verified email and approved copy to the sequencer and writes the source tags onto the Salesforce record. A parallel deliverability monitor watches warmup, inbox rotation, and bounce rate, and it gates the whole thing: the sender stays off until inbox health is green. This is the layer that stops spray-and-burn.
A reverse webhook writes reply and meeting status back onto the contact row, and the attribution table reads those tags to compute the two-motion funnel: enriched, sent, opened, replied, qualified, met. Because the source tags were stamped at creation, we can see what the engine surfaced without arguing about it after the fact. It's a shared scoreboard the team defines together, not a credit claim.
The last table turns everything above it into a daily view per rep: the A and B accounts with a fresh signal, their committee, the why-now line, and the suggested product angle, filtered to that rep's territory. This is what a seller opens each morning. It's the point of the whole engine, a human working a short, sharp list instead of researching from scratch.
When we say a table "feeds" another, this is the actual mechanism. There's no magic, just three kinds of columns chained together, hop after hop, and that chaining is where the depth comes from.
Sends rows from one table into the next, filtered first so only the right rows go, only Grade A accounts, only valid-email contacts. This is the arrow that narrows the funnel at each hop.
Reads a value from another table by a join key. It's how a signal writes intent back onto an account, and how Message Gen pulls only an approved stat from the Verified Metrics table.
Gates every enrichment: only-run-if-empty, only-if-in-window, only-if-in-ICP. This is what makes it cheap enough to run continuously instead of burning the budget in a week.
The cleanest way to hold the whole system in your head: Clay handles facts, Claude handles words and judgment. Clay never writes a sentence a prospect reads. Claude never touches a row of data directly. Everything they exchange passes through the table, where it stays visible and gated.
Deterministic, per-row work. It runs the same way every time, costs credits when it enriches, and its output is always a value in a column you can audit.
Judgment work, packaged as skills you run yourselves. They're tools in your hands, not requests you file with Dallas. Each one takes the row Clay assembled, the who, the title, the why-now, the product angle, and turns it into something a person would actually send, fenced by the Value Repository so only approved claims appear.
Two things worth making concrete: the spend guardrails, and why connecting to Salesforce closes the gap between the outreach work and what leadership sees.
credits used of the 5,000-credit allocation to build and validate the whole Stars list.
The point of wiring Clay to Salesforce is that once a contact is surfaced, it becomes an account and contact in Salesforce automatically, with source tags attached. No one re-creates it. No gap between the outreach work and what execs can see.
The engine's job is to hand you a clean, current list and get out of your way. Here's what each of you touches, and the two things we'll lock in when we meet.