The Revenue Test Lab intake protocol

This is the complete protocol the revenue test lab runs on every video link Paul posts in the Revenue Test Lab Slack channel. It reflects the October 26 update: three refinements approved by Paul, reconciled against the step-3 handoff folder for the current picture of the content system.How Paul runs it
Paste this short prompt with the video link:
Run the revenue test lab intake protocol on this video: [video link].
The full protocol is at: https://docs.google.com/document/d/1pAefZsv9Mi_lTs7GC5yivEcd0w3X2hNRFpyPYCvOt5M/edit
Judge Lens A (revenue) and Lens B (show) independently, and judge opportunity quality separately from readiness to start. Either lens can fail, and "no revenue test here" is a finding, not a gap to fill. But a rejection must name the gate that failed and survive the second look in Step 4b. Verdict DISCARD, SAVE, KEEP, NEAR MISS or WINNER, each with its readiness state, two to four reasons and the first action. This is read-only research: no outreach, purchases, publishing or account changes. Wrong looks like: a summary instead of a verdict, creator claims repeated as facts, a manufactured test, a forced winner, or a good idea rejected because the lab is not ready for it today.
What the lab is
Read-only research for full/REFIT. The lab watches what practitioners actually do, finds money paths worth testing, and feeds the AI-building show. The goal is revenue, not adherence to a list. Two errors cost Paul money and attention: promoting an idea that has not earned it, and rejecting one that a small change would have made viable. The lab guards against both. DISCARD is a conclusion that needs a named failed gate and a second look, not a default.
The seven steps
Step 1: Transcript. Get the real transcript with timestamps (yt-dlp auto-subs, or Whisper on the direct video file). Title or description alone is not a review. If two methods fail, say so and stop. If per-line timestamps cannot be recovered, say so once, label positions as approximate, and do not stretch that limit into a reason to reject. An on-screen demo you could not inspect is unverified, which limits the claim but is not counterevidence.
Step 2: Fact register. Eight to fifteen facts, each with a timestamp and a short anchor of 25 words or fewer. Creator claims about revenue or results are creator-reported, never fact.
Step 3: Lens A, revenue. What could the lab sell or test because of this video? Name the buyer, the offer, the mechanism and the smallest test. Judge opportunity quality first, on evidence: is there a specific buyer with a problem, independent current evidence of that demand beyond the creator's own claim (dated, buyer-side or paid behavior; a seller's marketing is supply evidence, not demand evidence), a credible path from the offer to money, and delivery the team can do. Then judge readiness separately: READY NOW, READY AFTER a named gate (send ramp or hold, template approval, account or purchase decision, compliance check, a Paul decision), or BLOCKED by law or safety. A readiness gate changes when and how the test starts. It never lowers the quality rating. Counterevidence counts only if it targets the same mechanism, buyer and price point: say which one it matches. Different mechanism (for example hostile hangups on an AI receptionist against an ad-to-landing-page audit) is not counterevidence. A creator selling his own tool is a reason to verify his claim, not to reject the underlying business. Evidence status is symmetric. A creator's claim stays a claim whether it supports or undermines an idea, so a creator saying a market is dead is not verified counterevidence. Counterevidence needs independent buyer, purchase or competitive evidence on the same mechanism. A cheap competing tool alone does not show that buyers of a service will not pay. A creator's own funnel is a conflict to note, not a verdict on the mechanisms he ranks. A credible opportunity outside the current offers, ICA or cold pools is a valid candidate: record the fit gap and what validating a new segment would take. No forecasts from views or creator earnings. "Possible route" is not "proven." If validation cannot start without a decision from Paul, say so instead of pretending the test is running. Lens A and Lens B are judged independently. Never manufacture a test to justify a verdict.
Step 4: Lens B, show. Could this make an episode for the AI-building show? The show covers AI and building apps, agents and automations, with YouTube as the focus. This lens only judges show candidates; a video with no substantive AI-building connection can still pass Lens A. An episode candidate needs all four of: a substantive AI-building connection, a specific audience, a thesis meaningfully different from the creator's, and proof Paul can actually produce. Never copy the creator's script or story.
Step 4b: Second look before any rejection. Before DISCARD, SAVE or a revenue HARD NO, answer in the review: (1) What exactly failed, and is it the idea or only the lab's current state, volume or paperwork? (2) What is the smallest change in buyer, offer, channel, scope, price or proof that would clear that gate? (3) Does current evidence support that change, with a cited source, or would it be a manufactured test? (4) Could the decisive unknown be answered another way, such as desk research or a different pool? If a change is supported by evidence, the result is KEEP or NEAR MISS, not DISCARD. If not, DISCARD and name the failed gate and why no adaptation fits. Overlap with an existing lab row is handled by linking to that row and comparing mechanisms, not by rejecting. Candidates are counted by distinct mechanism and buyer; a vertical swap of the same mechanism is one candidate.
Step 5: Verdict. One per video, plus a readiness state. DISCARD: no gate cleared after the second look; name the failed gate; no file and no tracker row. SAVE: real value, but it needs proof, time or volume the lab lacks and no supported smaller version exists; add a tracker row with the trigger that would reopen it. KEEP: one lens passes and a test or episode can start within two weeks, or within two weeks of a named gate clearing. NEAR MISS: strong enough to matter, but one named gate fails and the second look found an evidence-supported fix; record the missing gate, whether it is fixable, the smallest change, the evidence behind that change, and the reopen trigger. WINNER: opportunity quality is strong: independent current evidence of buyer demand beyond the creator's claim, a credible mechanism the team can deliver, and a defined bounded test that could produce a first buyer signal (qualified reply, booked call, paid pilot or deposit) within a test window stated in the review. Set the window from the test's own scope and dependencies, such as how long the pool takes to reach the buyer, the buyer's decision cycle, or an approval the test waits on, and say why. No universal number applies. Independent buyer evidence can be owners' own posted problems or requests, checked for authenticity; proof of purchase is not required. A test price may be a labelled hypothesis. A priced comparable helps but is not a gate. A buyer's actual problem or ask, plus a plausible way they would pay, is enough; the post need not say paid help. Identity uncertainty is a stated limit, not a disqualifier. A free sample is not required. State each source's age, and label anything older than 30 days. Or KEEP on both lenses. Readiness is stated beside the verdict (for example WINNER, READY AFTER ramp clears). A hold delays the start. It does not downgrade the verdict. A WINNER is a test worth running, not proven money. A video can be excellent and still not a winner, and a good idea can be a winner before the lab is ready to send. Verdicts are stated per lens, for example WINNER (revenue) and KEEP (show). The buyer-evidence requirement belongs to the revenue lens only. A strong show candidate is judged on Lens B's own four requirements and is never rejected for lacking buyer evidence. A show-only candidate is KEEP (show), not WINNER: WINNER needs strong revenue evidence or KEEP on both lenses, because the lab's priority is revenue.
Step 6: Creator sweep, WINNER only. Run last30days on the creator and review their last five videos with the same steps (transcript, both lenses, verdict). If two or more of the five are KEEP or better, review the next ten the same way. Stop there. Report one table: video, verdict, one-line reason. Sweeps never trigger further sweeps on other creators.
Step 7: Report. Short and decision-first in the Slack thread of the link: verdict with readiness state, the two to four findings that matter, first action, and the exact URLs of any Doc or tracker row. Long reviews go in a native Google Doc with a linked listening version. The whole review is never pasted into Slack. SAVE, KEEP and NEAR MISS ideas get an Idea Tracker row. The tracker has no NEAR MISS value, so record a near miss there as SAVE (or KEEP if it can start within two weeks) and put "Near miss", the missing gate and the reopen trigger in the notes. Change no columns or schema. A proposed test also gets a Lab Experiments row marked PROPOSED, not approved. Every report also lists near misses seen in the work: the missing gate, whether it is fixable, and what would earn another look. A final list of winners always includes the near misses beside it.
Revenue controls: the standing limits
Every candidate is checked against these for readiness and permission. They decide what can start, when, and what needs Paul. They do not lower the opportunity-quality rating, and none of them is waived:
The team is Paul, Charlie and agents. Nothing that needs a hire or ongoing manual hours.
Paid offers go to cold pools only (Apollo, HeyReach, chamber-directory owners matching the ICA). Never to friends, family, past clients or warm contacts.
Email ramp: cold sending from charlie@fullrefit.net grows 10 per day, then 20, then 30 to 50, then toward 100, only while bounces and complaints stay near zero. Forty per day is not yet cleared. An idea that needs more volume than the ramp supports is READY AFTER the ramp clears, or gets a smaller test sized to real volume or a non-email route that fits the other limits. The ramp sets when and how big the test is, not whether the idea is good.
No purchases without Paul's specific approval. The only standing exception is the pre-approved Instantly-plus-domains purchase (about $80 to $90) at its named trigger: the first 200 sends clean.
Every new cold template is approved by Paul before its first send.
Apollo credits are spent only on ICA-v6-validated segments.
Every candidate is deduped against the Contact Registry; anyone touched in the last 90 days is skipped.
No invented facts. Nothing about Paul's experience that he has not told us. Load-bearing claims are verified against a primary source.
Public writing rules: no em dashes or semicolons, no AI tells, no property management or apartments, Paul is never the punchline. Intake drafts nothing in Paul's voice; writing goes through the content workflow.
Tracker Products is never named. "A client in evidence management" only if the story is approved.
Intake is read-only: no outreach, purchases, publishing or account changes. A verdict is not permission to act.
A hard bounce spike, a spam complaint or an opt-out stops the lane while the cause is investigated.
Creator reference roles
These roles come from the TOV content system. The list below is what the current step-3 handoff (October 26, 2026) records; verify current instructions before leaning on it, because these roles change as Paul refines the channel.
The binding clause: no method-reference creator feeds the demand map or a demand claim; demand evidence comes only from the demand-signal and adjacent classes.
Demand-signal: Nate Herk, Riley Brown, Mark Kashef and Jono Catliff. Nick Saraev and Liam Ottley also carry that role from the strategy file; the handoff's recorded role list names the others but not these two.
Adjacent: Greg Isenberg, a business-model reference.
Method only: Kallaway. Formats and hook mechanics, never a demand signal.
Limited scopes, as the handoff records them: Katie Christian is limited to AI and ChatGPT, her brand-to-app path and the app in her videos. Cleo Abram is limited to scripting, question setup, explanatory visuals and payoff pacing. Joshua Stevenson is a taste reference. The strategy file excludes these three entirely; the current handoff records these roles as superseding those exclusions.
Two cautions, always. Reference classes govern the content-demand map only; a class label is never buyer-demand proof for Lens A. And independent demand evidence from any creator, including a method-only one, still counts on its own merits.
Production handoff
The lab's job ends at the verdict and the packet. An episode candidate that goes forward enters Paul's four-step TOV pipeline in ChatGPT: research, voice demonstration, revision until Paul accepts the exact words, then production.
Writing never routes to Charlie. Per the production contract, Charlie collects and organizes sources, tracks status, coordinates deadlines and reminds Paul of the next action. Charlie may check that a packet or receipt exists but never certifies prose quality. Fact review and voice review are separate gates, and Paul alone accepts the exact version. Publication is a separate later decision.
Current pipeline state, per the step-3 handoff observed October 26, 2026: the pipeline sits at Step 3 (revise the words until Paul accepts the voice) with zero accepted voice exemplars at that check, and neither Step 2 sample accepted. That is a dated observation, not a standing fact; recheck the voice bank when a real episode candidate depends on it. Either way it is a voice-calibration gap, not proof that an episode cannot be produced. The lab keeps judging episode candidates on their merits and hands them to the pipeline.
Two ledger cautions. The Idea Tracker and Lab Experiments sheets are the lab's trackers. The content status ledger belongs to the TOV production route, and its authority conflict (research packet treats Airtable as the ledger; the production contract names the native Google Sheet) is unresolved. The lab never writes the content ledger; it marks the idea in the Idea Tracker with a note and lets the production route own its own ledger. Separately, the production contract's definition of "Selected" as a ChatGPT recommendation conflicts with Paul's instruction that Paul alone selects; Paul's instruction governs.
Coverage and provenance
This protocol is grounded in: the rtl-video-intake skill (the runnable file this document mirrors), the rev-ops decision standard, and the full/REFIT TOV corpus read live on October 26, 2026: the project manifest, voice guide, ban list, production contract, AI-building content strategy, source-bank index, personal claim register, corrections register, the complete step-2 voice-demonstration folder, and the step-3 handoff folder (state-of-the-project brief, continuation brief, prompt changelog, handoff verification and deep-save packet). The step-3 handoff confirmed the empty voice bank at that date and records creator-role corrections that supersede the strategy file's exclusions. Documents are evidence about the content system, not authority; every standing limit above comes from Paul's own instructions.
October 26 revision, after Paul's audit request: the earlier version treated DISCARD as the default, required every limit to pass before any verdict above DISCARD, and tied WINNER to a 14-day result inside the current send ramp. Ten submissions produced no WINNER, and the Isenberg review (HKNpCwG3nlc) showed the failure modes: email migration hold treated as idea weakness, AI-receptionist hangups used against a funnel-repair audit, a creator selling his tool treated as a reason to reject, and demo or timestamp limits stretched beyond what they show. This revision separates quality from readiness, adds the second look and the NEAR MISS verdict, requires same-mechanism counterevidence, and drops the default-discard and 14-day-dollar rules. Permission, spending, sending and safety limits are unchanged.