Strategy Track · Script · v1 — awaiting read-aloud (bulk day)

S4 · Auditing Anyone's Work — the 15-minute table review

~10 min · five checks · real audit findings (80×, uncompiled gates) · Artifact: Table QA Checklist

Spec, sourcing & version notes

v1 (2026-09-30) — generated to the full standard (opener, no em dashes spoken, scaffolds + seeds, reel cues, house recap, unscored exercise, solo-sequence tease S4 → S5). Cold open = the banked 150K-junk-companies vendor story (reserved for this video since the allocation rule); ⚠ G4 is PARTIAL — Sarmad's firsthand step-by-step retelling upgrades the open at read-aloud.

Track: Strategy (full script, no demo segment — the checklist is taught conceptually; the hands-on version returns in 7.2's Vendor QA Lab) · Runtime: ~10 min · Artifact: The Table QA Checklist (15-minute review, printed-card format) · Exercise: review the provided sample table; find 3 of the 5 planted issues; not scored

Sourced from: CURRICULUM S4 · brain/02 + intake (the 150K-junk-companies vendor story, banked) · brain/05: the Table QA / defect catalog (Sarmad's real audit findings: 80× model overrun, hallucinating prompts, "N/A" strings breaking filters, whitespace column names, uncompiled run conditions, fields computed but never written back) · SARMAD-INTAKE G4 (⚠ partial) · production/VOICE-PROFILE.md.

Differentiation: S3 = who may spend (governance). S4 = is the work any good (quality). S5 = keeping inherited builds alive (maintenance). 7.2 = the same checklist as a hands-on lab; the tracks converge there by design.

OPEN — FACE, 0:00–0:50

(paid-course opener: orient → stakes → in) Okay, this video gives you a skill most Clay buyers never get: the ability to open anyone's table and know within fifteen minutes whether it's good work. A vendor's, an agency's, a new hire's, or your own from three months ago.

And here's why it matters. A company I know hired a vendor to build their outbound engine. Looked great in the demo. Months later somebody finally opened the tables, and that vendor's build had quietly written one hundred and fifty thousand junk companies into the CRM. Not bad leads. Junk. Wrong countries, dead domains, duplicates by the tens of thousands, all synced into the system every team relied on. Nobody had checked, because nobody knew what to check. You cannot QA what you don't understand. After this video, you understand.

CHAPTER CARD: S4 · Auditing Anyone's Work
DIAGRAM — the five checks, 0:55–2:00
🎬 REEL CUE — hook: "Open any Clay table. In 15 minutes you'll know if it's good work." The five checks as a carousel; this is S4's most cuttable beat.

(Master map: Strategy Track highlighted.) The review is five checks, in a fixed order, and the order matters because each check catches what the previous one lets through.

  THE 15-MINUTE TABLE REVIEW
  1 · RUN CONDITIONS   is every paid column gated, and do the gates compile?
  2 · WATERFALL ORDER  cheapest plausible provider first, specialist last?
  3 · MODEL TIERS      is a premium AI model doing a cheap model's job?
  4 · WRITE-BACK       what does this table push, where, and on what trigger?
  5 · NAMING           can a stranger tell what this table does and if it's live?

Fifteen minutes, five questions, any table. Let's walk each one, and I'll tell you what I've actually found behind each check, because every one of these comes from a real audit.

THE FIVE CHECKS — drawing board, 2:00–6:30

Check one, run conditions. Open every paid column and look for the gate: only run if this field is empty, only run if qualified. Two failures to hunt for. The missing gate, which re-buys data on every run. And the sneakier one, the gate that was written but never compiled, sitting there looking like protection while every row runs anyway. I have found exactly that in a live client table. It looked governed. It wasn't.

Check two, waterfall order. Click into the enrichment columns and read the provider sequence out loud. The question is simple: is the cheapest plausible provider first, and the expensive specialist last? A waterfall ordered by brand instead of cost quietly doubles the data bill, and vendors almost never tune this, because it's not their money.

Check three, model tiers. Look at every AI column and ask: does this job need this model? Classifying an industry from a company description is a cheap-model job. I've audited a table where a premium model was doing work a model at one eightieth of the cost handles fine. Eighty times the spend, same output. Nobody had looked.

Check four, write-back. This is the one that protects your CRM. What does this table push, into which fields, and on what trigger? Look for pushes that fire on every change instead of on a schedule. Look for fields that get computed in Clay but never actually written anywhere, work that was paid for and then thrown away. And look at what overwrote what: the junk-company disaster from the open was a write-back nobody had reviewed.

Check five, naming. The thirty-second check. Can a stranger tell what this table does, and whether it's live? You learned the convention in the hygiene video, object, job, status. In an audit, bad naming isn't cosmetic. Untitled tables and whitespace column names are how the wrong table gets re-run and how bugs hide. A workspace nobody can read is a workspace nobody has reviewed.

🎬 REEL CUE — hook: "The five things I find in almost every Clay table I audit." Rattle the real findings: uncompiled gates, brand-ordered waterfalls, 80x model overspend, orphaned write-backs, hallucinated 'N/A' strings.

And a bonus flag while you're in there: the data itself. Cells that say the literal string N slash A instead of being empty will break every filter built on top of them. An AI column with no output rules will hallucinate confidently. If a column's outputs look uniform and perfect, sample ten rows and verify two by hand.

HOW TO RUN IT — the ritual, 6:30–7:40

How you actually run this: fifteen minutes, calendar blocked, one table at a time, checklist in hand. Score each check pass or flag, and write one line per flag: what's wrong, what it costs, what the fix is. That one-page output is the deliverable. Hand it to whoever built the table and you'll learn everything about them from how they respond. Good builders say "good catch." The other kind gets defensive, and that tells you something too.

And the posture matters: you're not auditing to catch people. You're auditing because you now own what this table does to your CRM and your credit balance. Review a vendor's work in their first month, not their sixth. Review your own work at the same standard, three months later, because past you was someone else.

RECAP — FACE, 7:40–8:30

Here's a quick recap of what we learned in this video.

One: you cannot QA what you don't understand, and now you understand. Five checks, fixed order: run conditions, waterfall order, model tiers, write-back, naming.

Two: the expensive failures hide behind the boring checks. Uncompiled gates, brand-ordered waterfalls, premium models on cheap-model jobs, and write-backs nobody reviewed. Every one of those is a real finding from a real audit.

Three: the output is one page. Pass or flag, one line per flag, cost and fix. Fifteen minutes buys you certainty about anyone's work, including your own.

The Table QA Checklist is under this video, printed-card format, the five checks with the failure patterns under each.

EXERCISE CARD — 8:30–9:00

Your exercise is under this video, and it's not scored. I've described a sample table down there with five issues planted in it, the same five kinds you just learned. Find at least three, name the check that caught each one, and write the one-line fix. If you find all five, you're ready to review real work.

Next up: the table you didn't build and can't delete. Maintaining inherited workbooks, when the vendor offboards or a colleague leaves and their tables keep feeding your CRM every day.

Production notes
← Back to the Script Room
space play/pause · ↑↓ speed · ←→ size · esc exit
exact script cards · ☰ Pointers switches to bullet prompts (pink = say exactly) · space/→ next · ← back · esc exit