03.4 PROOF GATE: Validated Offer Brief — Part 1 of 1

Turn audience conversations into an offer hypothesis

This version of Module 2 starts by locating the audience, collecting their language, building an avatar and checking a demand pattern. Its promise that you will know exactly what people will pay is too strong: research generates evidence and hypotheses; actual willingness to pay still needs a relevant buying test. Use the current spreadsheet's lesson assignments, not the legacy bootcamp numbering.

Locate, listen, describe and validate

Identify at least three relevant online spaces. The source names Facebook Groups, Reddit threads, Instagram hashtags, YouTube comments, Amazon, Trustpilot, G2, Yelp, Quora and niche forums. Choose spaces where the actual audience discusses the problem, with access permitted. Search-question tools such as AnswerThePublic, Ubersuggest and the Reddit Keyword Research Tool (linked as Keyworddit) can suggest vocabulary and research directions; their output is not an interview transcript.

Read three-star Amazon reviews for mixed satisfaction: what worked, what disappointed and what people wish were different. Include other ratings and contradictory experiences when testing a pattern, so your selection does not predetermine the conclusion. Collect ten authentic pain or desire statements, preserving exact wording, URL, date, relevant product/version and context. A repeated complaint from the same person or copied across sites is not a new independent customer. Keep private identifiers out of shared learning artifacts and quote only what you can substantiate.

Build the five-question avatar: who is the person in their relevant role and situation; what do they fear losing; what do they want now; what prevents progress; and what transformation would matter enough to consider buying? Age and gender should be included only when relevant and supported. Separate observations, interpretations and unanswered questions. Use the referenced Customer Avatar worksheet if available; its exact template destination is not supplied here. A proposed replacement table can use those five questions plus evidence and uncertainty columns, but is not the missing original worksheet.

Check at least one demand pattern using Google Trends or a keyword tool. Record the term, region, date range, metric and comparison. Relative search interest is not search volume, market size or purchase intent. Ubersuggest and Semrush estimates require their own period and geography. Existing competitors and advertisements indicate supply or promotional activity; they do not by themselves prove profitable sales. Seek direct evidence of actual transactions or credible customer spending, then test whether your proposed offer earns a meaningful commitment.

Deliver an evidence packet that can guide the next lesson

Submit the three spaces, ten real statements, five-question avatar and one documented demand check. Include contrary findings and missing information. Turn recurring language into an offer hypothesis without claiming that a review proves every buyer feels the same way. Brunson's customer-first message development helps connect the hook to a real conversation. Hormozi's outcome, likelihood, delay and effort dimensions help turn that need into delivery choices worth testing. The source's enthusiastic language is motivation; listening reduces guessing but does not eliminate it.

Complete available source reference

This preserves the full available document, including original claims, prompts, production cues and unresolved resource callouts. Use the corrected teaching above for narration. Source instructions are reference material, not actions performed by this lesson.

CNX.3.11.2 – Offer_Dev_Module_2_Audience_And_Market_Deep_Dive.docx

📘 Offer Development Bootcamp Module 2 – Audience & Market Deep Dive ________________

🎯 Objective Learn how to uncover your audience’s real pain points, desires, and language by digging into the places they hang out. By the end of this module, you’ll know exactly who you’re selling to, what they care about, and what they’ll pay to solve. ________________

🔑 Why It Matters An offer without audience clarity is like fishing without bait. The market doesn’t buy what you think is cool — they buy what they already want solved. The fastest way to build irresistible offers is to listen in on conversations where your audience reveals their frustrations, dreams, and buying triggers. ________________

🛠️ Action Steps

1. Identify Where Your Audience “Lives”

* Facebook Groups, Reddit threads, Instagram hashtags, YouTube comments.

* Review platforms (Amazon, TrustPilot, G2, Yelp for services).

* Forums (Quora, niche-specific communities).

2. 👉 Use tools like:

* AnswerThePublic (search intent questions)

* Ubersuggest (SEO keywords + content ideas)

* Reddit Keyword Research Tool

________________

2. Mine for Pain Points & Desires

* Look at Amazon 3-star reviews (what people “like but wish was better”).

* Screenshot repeated complaints, frustrations, or goals.

* Copy the exact words people use — this becomes gold for sales copy.

________________

3. Build a Customer Avatar Answer these questions:

* Who are they (age, gender, role, situation)?

* What do they fear losing?

* What do they want most right now?

* What keeps them from achieving it?

* What transformation would make them say, “Take my money”?

4. 👉 Use the Customer Avatar Worksheet (Excel/Google Sheets tab) to document this.

________________

4. Validate Market Demand

* Use Google Trends to check if interest is up, down, or steady.

* Check search volumes on Ubersuggest/SEMRush.

* Look for existing competitors (proof that money flows in this market).

________________

📦 Deliverable for Module 2 By the end of today, you must: ✅ Identify at least 3 online spaces where your audience hangs out. ✅ Collect 10 real pain points/desires in their own words. ✅ Build your Customer Avatar Sheet (who they are, what they want, what they fear). ✅ Check Google Trends or keyword tools to validate at least one demand pattern. ________________

💡 Pro Tip The riches are in the reviews. People literally hand you their frustrations and desires in Amazon comments, TrustPilot rants, and YouTube discussions. If you ever feel stuck on “what to offer,” go read the reviews. ________________

🌟 Riser Nation Motivation Remember, you’re not guessing anymore — you’re listening. The best marketers aren’t inventors, they’re translators. You’re taking the raw words and struggles of your market and shaping them into solutions. That’s what makes an offer irresistible. ________________

Clickable sources and resources

Provider links are navigation references; they do not certify current plans, availability, access rights or the contents of unreviewed linked assets.

ClickFunnels education

Acquisition.com education

Google AI search guidance

Google spam policies

Facebook Groups

Reddit

Instagram

YouTube

Amazon

Trustpilot

G2

Yelp

Quora

AnswerThePublic

Ubersuggest

Keyworddit

Google Trends

Semrush

Assigned source D0181, link 1

Related Module 2 version D0182

Validate the offer behind the keyword

Source: D0025, Keyword Validation Surveys and Ten Keyword Validation Exercises. Assigned lessons: 01.1, 03.3, 03.4, 07.1, and 12.4.

Separate attention, stated interest, and a purchase

Keyword research shows how people express a question or need. It does not establish which product they want, its preferred format, or what they will pay. The source combines ten research exercises with a four-step survey process. Use several kinds of evidence and record what each test actually measures. Its words proven, definitive, and guaranteed are not supported by validation data in this document.

Run the ten exercises with explicit limits

1. Presale landing page. Describe a proposed offer and delivery terms, send relevant traffic, and measure genuine purchase commitments. The source's Freelancer Productivity Planner example offers a fifty-percent preorder discount, tests Basic, Pro, and VIP tiers, and suggests Facebook, Reddit, X, and LinkedIn traffic. It names Gumroad, ThriveCart, and SamCart as payment-tool examples. A discounted preorder tests the discounted offer; it does not prove full-price demand. Few sales can reflect traffic quality, trust, positioning, price, or format. The source's assertion that someone who will not pay now will never pay later is too absolute.
2. Trends and seasonality. Compare the keyword over one to five years. The source discusses fourth-quarter, tax-season, back-to-school, and January demand patterns, and illustrates December preselling for a January freelancer-planner interest peak. These are hypotheses to inspect, not verified seasonal results for that product. A seasonal campaign should use a real time-bound reason rather than fabricated urgency. A rising trend alone is not a purchase.
3. Quora and Reddit. Search the problem and related site-specific results, compare recurring questions, and inspect responses and upvotes. The freelancer example concerns organizing multiple clients and inviting suitable people to a beta. Contribute appropriately under community rules and obtain permission for further contact. Votes, repeated questions, and beta interest demonstrate different things; none alone proves paying demand.
4. Facebook and LinkedIn polls. The example asks freelancers to choose among time management, client organization, invoicing, and project pricing, then uses comments to understand exact language and underlying needs. A top-voted option can guide the next investigation, but it does not establish that every target buyer shares that priority or that a time-blocking planner is the preferred solution.
5. YouTube and TikTok search. Inspect relevant search suggestions, titles, topics, and audience response. The source proposes fifty-thousand-plus views as an engagement indicator but gives a separate example with ten-thousand-plus views. Preserve both as source heuristics, not a consistent passing threshold. Views may reflect age, distribution, entertainment, or a different audience. Do not assume a popular video validates a paid product or that video search always reveals trends before other channels.
6. Pinterest trends. Investigate seasonal and continuing interest in planners, templates, and downloads. The source proposes ten-thousand-plus repins and related searches as signals and suggests adapting a printable freelancer planner into a Notion or Canva format for Etsy or Gumroad. Verify that the format addresses a real need. Repins are not purchases, and the supplied number is not a validated benchmark.
7. Small paid-search test. The exercise specifies five to ten dollars per day for three days, a total test budget of fifteen to thirty dollars. It proposes three-percent-or-higher CTR as an interest signal. Preserve these as source settings, not universally adequate budgets or sample sizes. Low CPC does not by itself mean low competition or a profitable niche; clicks still need to become appropriately priced, deliverable purchases. Define the learning objective and stopping rule before spending.
8. Competitor bestsellers and reviews. Inspect relevant Amazon or Etsy products, available popularity or rating signals, and review complaints about missing features. The source proposes five-hundred-plus reviews as evidence and illustrates an Etsy planner with twelve-hundred-plus reviews. Those are examples, not proof of current sales, your addressable demand, or profit. A useful missing feature deserves investigation; adding more features is not automatically better differentiation.
9. X polls and conversation monitoring. Look for repeated problem descriptions, replies, and relevant industry voices. The source uses freelancer productivity as its example. Repeated conversation can identify a research topic, but influential discussion does not establish growth or prove that a paid solution is wanted. Treat the claim that X finds micro-trends first as unverified.
10. AI-assisted synthesis. Ask an assistant to organize documented trend evidence and compare it with the keyword hypothesis. The source names ChatGPT, Perplexity, and Bard; these are source-era references, not a current product guide. An AI answer agreeing with the idea is not independent market validation. Require actual sources, dates, uncertainty, and contradictory evidence. A generated trend list may contain no fresh research at all.

Define the survey hypothesis

The survey's goal is to investigate demand, price, format, and must-have features with an appropriate audience. The source illustrates a Freelancer Productivity Toolkit and reports example monthly volumes of 5,400 for time-management tools, 1,800 for productivity planners, and more than 10,000 for invoice templates. Those numbers are unverified examples. Its hypothesis combines productivity tracking and invoicing; the survey should test whether customers actually want that combination rather than force it into the answer choices.

Ask about all four decision areas

First, compare the problems: managing time and deadlines, tracking invoices and payments, organizing multiple clients, and communicating with clients. Second, ask what someone means when searching for time-management tools: a Notion or Google Sheets planner, a prebuilt template, a course, or a mobile app. Third, compare a one-time purchase, a subscription, and a free version with paid premium features. Fourth, test the supplied price bands: ten to twenty dollars, twenty to fifty, fifty to one hundred, and one hundred or more.

The price bands overlap at their boundaries. Clarify the selection rule if using them in a live survey, and preserve the original ranges in the research record. Add an opportunity to explain a different need so the choices do not conceal disagreement with the premise. Stated willingness to buy is different from an actual transaction.

Distribute to the relevant audience

The source suggests freelancer Facebook groups and LinkedIn communities, using names such as Freelance Writer's Hub, Upwork Freelancers, and Freelancer Mastermind as examples. It also names r/freelance, r/digitalnomad, and r/entrepreneur, X and LinkedIn polls, Quora, Indie Hackers, an existing email list, and a website survey. The existence, suitability, and current rules of these communities are not verified here. Explain the research purpose, contribute usefully, and follow the actual participation and contact rules.

Its sample invitation asks about organization, invoices, and clients before offering a short survey. It describes a two-minute survey; only call it that after checking completion time. It also suggests optional paid recruitment through Facebook or Google ads to a form. Its heading calls this paid survey panels, but the examples are ad-driven recruitment, not a specified representative panel. Document how respondents were recruited and who may be missing from the sample.

Interpret the response without overstating it

The source proposes fifty-to-seventy-percent-or-more stated willingness to buy as strong validation. It does not define a sample size, sampling method, confidence interval, or one exact passing threshold. Preserve the range as a source heuristic. Report the actual numerator, denominator, audience, question wording, and recruitment method rather than claiming that a percentage guarantees sales.

If people prefer a different format, test that alternative. If price expectations differ from the proposed economics, compare models or scope rather than automatically lowering price. The source illustrates a Notion planner instead of a PDF, basic and premium tiers, and messaging based on frustrations with existing tools. Each adjustment needs a feasible delivery promise and another test.

Combine the survey with an honest presale

The bonus exercise repeats the fifty-percent beta offer and payment-tool examples. A genuine preorder provides stronger evidence than a hypothetical survey answer, but it still tests particular terms, a particular audience, and a promised future product. Record price, scope, delivery timing, actual commitments, and uncertainty about repeatability. Upfront funds create delivery obligations; they are not proof that the full product will succeed.

The source's tool list names Google Forms, Typeform, SurveyMonkey, ads linked to a form or landing page, and Facebook lead forms. Its claims about free access, response rates, and advanced analytics are source descriptions, not currently verified feature or pricing information. The objective is to combine keyword language, customer preferences, buying evidence, and delivery economics—not to treat any platform as a validation authority.

Complete the lesson exercise

Write the hypothesis, select complementary tests, retain the questions and all relevant responses, distinguish observed behavior from stated intent, and document the decision. Compare what was learned about demand, positioning, price, and format. In the proof-gate lesson, include both negative and positive evidence. In the agent lesson, require the assistant to preserve contradictory answers and avoid invented figures, respondent facts, or guarantees.

Evaluate channel choices against documented conversions

The assigned rubric is version 1.0.0, bound to legacy C14 v2.0, module M14.4. It requests a Channel Performance Validation Document under the submission label c14_channel_validations. Its purpose is retrospective evaluation: compare the channels selected in legacy C11 with conversion evidence from M14.3, using cross-channel touchpoints from M14.2/M14.3, then recommend the next-stage strategy. These references preserve source context; the spreadsheet controls the current lesson assignment.

Four honest outcomes are acceptable: the initial selection was correct; it was partly correct; one channel worked while others did not; or conversion occurred through an unplanned path. The exercise rewards supported conclusions, not a story that makes every prior decision look successful.

Complete all five parts

Part 1 restates the baseline. For every selected channel, record its name, the original rationale in one or two sentences, and its projected role. This section is not graded in the source; it prevents rewriting the original hypothesis after seeing results.

Part 2 repeats the same retrospective for each channel. Answer whether it contributed to a documented channel-acquired customer conversion: Yes, No, or Partial. Cite specific conversion-analysis data points. Describe repeatable patterns observed and predicted patterns that did not appear. Judge whether its cost and effort justify continued investment; the source calls this an informal cost-to-yield judgment, not a defined numerical metric. Choose Continue, Continue with adjustments, Pause, or Sunset, and give a four-to-six-sentence justification.

Part 3 synthesizes the channels as a system. Did they reinforce one another or operate as isolated surfaces? The source's example is a podcast appearance producing newsletter signups, followed by a reply that converted. Cite actual touchpoints before claiming such a loop. Next, identify any unselected channel in the conversion path. Its second example is an operator choosing LinkedIn and a newsletter but being discovered through a one-off podcast appearance. Explain how an unexpected discovery changes the next strategy.

Also identify selected channels with zero documented contribution. Consider all four source explanations: more time may be needed; the channel may not fit this offer/audience; execution may have been insufficient; or a contribution may exist beyond current analytics visibility. None is automatically the answer. Distinguish missing measurement from evidence of latent compounding, and propose a way to test the explanation.

Part 4 converts findings into decisions. Create a table with channel, current verdict, and next-stage recommendation: Continue, Adjust, Pause, or Sunset. Separately name new channels to consider and why, plus channels to sunset and why. The source calls this Stage 4 recalibration; it does not authorize this lesson to spend money, send outreach, or change live channels automatically.

Part 5 is the anti-rationalization check. Answer all six questions:

The source instructs revisiting Parts 2–4 after any hesitant No. Its wording conflicts with the question polarity: Yes flags a concern in questions 1–5, whereas No flags a concern in question 6. Preserve that discrepancy explicitly. For the practical review, revisit any admission of bias, lack of honesty, or uncertainty; do not mechanically treat all six answers alike.

Prepare the review artifact

Save the five completed parts as one file. The source directs submission through a HITL Review Submission Guide and states an auto-reviewer responds within 48 hours with PASS, REVISIONS_REQUESTED, or FAIL. The guide and working reviewer service are not supplied by this rubric, so the turnaround is a source-stated process, not a verified RISER service commitment. Keep the proposed review status pending until an actual review occurs.

Connect the exercise to Brunson's Dream 100 by checking whether attention sources led to a supported customer journey, and to Hormozi's acquisition economics by judging results against cost and delivery value. Submit evidence even when the conclusion is to stop or correct a channel.

Understand how the channel retrospective is evaluated

This assigned YAML is a reviewer specification, not a command to the lesson author. Its metadata names channel-validation-reviewer-v1.0.0, legacy C14 First Dollar/M14.4, build-6, claude-sonnet-4-6, c14_channel_validations, structured_json, and hitl_gated: false. The model name and suitability statement are source configuration, not a verified deployed service or current model recommendation.

The reviewer checks whether the retrospective honestly compares C11 channel choices with M14.3 conversion mechanics and recommends a next-stage strategy. Evidence may justify discontinuing an invested channel, but stopping is not inherently superior to continuing. Follow what the evidence supports.

Apply all fourteen review checks

Checks 13–14 praise hesitant No answers and flag uniform Yes answers. The companion worksheet uses different polarities: Yes is concerning in questions 1–5, while No is concerning in question 6. Preserve this cross-source mismatch. Review the meaning and evidence for each answer; neither a uniform Yes nor a uniform No is an automatic proof of honesty.

Recognize verdicts and failure patterns

PASS means the validation meets criteria. REVISIONS_REQUESTED specifies fixes before resubmission. COUNT_MARGINAL_FLAG means marginally sufficient work with selective positive reporting or an unsupported uniform-Yes self-check; the source allows human adjudication at M14.7. FAIL means structural insufficiency such as missing per-channel review, cross-channel synthesis, or recalibration, followed by a return to the lesson and resubmission. The extra marginal verdict extends the simpler three-verdict submission description in the companion rubric.

Watch for retaining every underperforming channel because of prior investment; generic repetition of M14.3 without channel-specific analysis; unsupported appeals for more time; vague adjustments; and no self-critical findings. The source contrasts an unspecified consistency improvement with a concrete shift from podcast guesting to monthly long-form solo episodes. A specific action still needs a reason and an outcome measure.

The specification also warns about underclaim: do not demand unwarranted self-criticism from someone whose evidence supports stronger performance. Absence of a sunset recommendation alone is not a reason to invent one. Feedback should be precise, kind, and non-shaming.

Preserve the complete output contract and dependencies

The proposed JSON output has a top-level verdict and a part_review object with part_1_restatement, part_2_per_channel, part_3_cross_channel, part_4_recalibration, and part_5_anti_rationalization. Each part has verdict and rationale. The per-channel part also includes channel_verdicts, an array of channel, verdict, and evidence_quality records. Remaining fields are the Boolean self_critical_findings_present, arrays detection_patterns_observed and remediation_targets, and an operator_message string. The source's displayed pipe-separated verdicts and true-or-false notation are schema placeholders, not literal valid JSON values to submit.

Usage notes propose running after M14.4 submission, recording PASS in c14_channel_validations, feeding M14.5 mastery Domains 1 and 3, and feeding M14.8 Part 4. There is no M14.4 human gate in this configuration, despite the later possible M14.7 adjudication. Preserve this distinction from the separate channel-selection template's instructor gate. The lesson teaches the evaluation contract; it does not deploy the reviewer, change models, write a database, or award a pass.

Complete all nine digital-product validation exercises

This workbook provides six sections and nine exercises, with blank research tables. It does not contain market findings, completed experiments, or a validated product. Use it to structure a decision before assuming an idea will succeed.

1. Define the niche: name the industry/market, intended audience, and important problems.
2. Define research goals: state what you need to learn and how the answer will change product development.
3. Identify relevant marketplaces: the source examples are Amazon Kindle, Etsy, Gumroad, Udemy/Teachable, ClickBank/JVZoo, Creative Market, and an Other field. These are possible research surfaces, not verified current recommendations or equivalent business models.
4. Analyze candidate products: fill the three provided rows with Platform, Best-Selling Product Name, Category, and Estimated Sales. Record where any ranking or estimate came from, its date, and its limits. A visible listing is not proof of its sales or profit.
5. Analyze reviews: identify recurring positive feedback, frequent complaints, and specific improvements the evidence suggests. Keep contrary examples and avoid counting repeated comments as independent demand.
6. Research keywords: fill the three rows with Keyword, Search Volume, and Competition Level. Define the tool, geography, period, and meaning of competition. The blank table supplies no measurements or proof of high demand and low competition.
7. Benchmark competitors: fill three rows with Competitor Name, Best-Selling Product, USP, and Price. Distinguish an observed price from revenue and a claimed USP from a verified advantage.
8. Define the UVP: explain what is distinctive and how it helps the customer compared with available alternatives. Connect the mechanism and truthful story to Brunson's positioning and the measurable outcome and delivery economics to Hormozi's offer framework.
9. Design pre-launch validation: choose one or more of landing-page signup, a paid-ad test, free beta testing, or surveys/focus groups. Define success metrics before observing results. A signup, an opinion, a beta user's behavior, and a paid order are different evidence; do not label them all purchases. The workbook does not authorize ad spend or launch an experiment.

Apply the complete final checklist

Confirm whether relevant best-selling candidates were identified and analyzed; demand/competition keywords were researched; competitor benchmarking was completed; pre-launch tests actually ran; and differentiation was improved using findings. A checked box needs evidence. The final phrase about an optimized idea or successful launch is an intended outcome, not a guarantee.

Submit the niche and research questions, all three tables, review synthesis, UVP, test plan/results, and the resulting proceed/revise/stop decision. Keep unfilled fields and unrun tests visible rather than fabricating data to finish the workbook.

StorySelling pre-sales: test a promise before building the full offer

The purpose of this exercise is to replace confidence in an idea with observed buying behavior. A customer who pays for a clearly described future delivery gives stronger evidence of willingness to buy that offer than a person who merely compliments it. Payment still does not prove satisfaction, repeat demand, profitable delivery, or a scalable business. Treat pre-sales as one decision input and follow them through fulfillment and refunds.

Keep the original context and threshold visible

This source is M4.3, StorySelling Validation (Pre-Selling), an excerpt from the Riser Nation Academy 2026 syllabus. Its parent is C4, Market Reality & Niche Validation: Stage 1, Harbor; Build to Do; prerequisite C3 Primary Avatar Profile; and 10–14 hours over two weeks. These are the older syllabus identifiers and parent-course schedule. They do not replace the current spreadsheet assignments or create a separate ten-hour requirement for this short exercise. The excerpt says the master syllabus remains intact; the complete master is not supplied within this document.

The parent introduction says “Five real dollars from five real people.” It does not clearly specify a per-person price or total revenue. The module explicitly sets five pre-sales as its validation gate and uses the slogan that five paying is proof and fewer is hope. Preserve five distinct paying customers as the module's count while recording the actual price and terms; do not silently interpret that parent sentence as a mandatory five-dollar price. Five purchases provide limited evidence under those test conditions. They cannot justify the parent claim that you automatically have a business or the suggestion that a failed test necessarily saves six months. Those are motivational claims, not measured findings in the excerpt.

Run the five-pre-sale protocol

The document names a 5-Pre-Sale Protocol but does not include its steps. The following is a RISER teaching adaptation that makes the named exercise executable.

1. Choose one customer and one problem from the avatar work. Write the result the offer is intended to help that person achieve and the evidence that the problem exists.
2. Define a small, deliverable scope. Specify what the buyer receives, what is outside scope, the price, the delivery date, required buyer inputs, and the support included. Check that you have the time and capacity to deliver before accepting payment.
3. Prepare the story and offer. Describe the customer's situation, the obstacle, your proposed method, and the concrete deliverable. Label illustrations as examples and support factual claims. A persuasive story must not turn an unbuilt product into a claim that it already exists.
4. Present the same core offer to relevant prospective customers through an appropriate channel. Record who saw the offer, the version, date, price, questions, objections, and actual purchases. Do not count a survey yes, a promised payment, or several orders from one person as five independent buyers.
5. Reconcile paid orders and refunds. Record the number of distinct buyers, amounts collected, amounts returned, outstanding delivery commitments, and the observation period. Report the source's five-pre-sale gate alongside the full evidence. If fewer buy, inspect audience fit, clarity, price, trust, and delivery terms before deciding what to change. Change one meaningful factor where practical so the next test is interpretable.
6. Fulfill the commitments and ask whether the delivered result addressed the original problem. Use fulfillment effort, support demand, customer feedback, and refunds to decide what should be built next. Passing the pre-sale gate does not finish validation.

Explain pay now and delivery in 30 days

The source names a “Pay Now, Delivery in 30 Days” template but supplies no template body. Use this adapted structure: “This is a pre-sale for [specific deliverable]. It is not yet available. The price is [amount and currency]. If you order on [date], delivery is planned for [specific date 30 days later]. You receive [scope and format]. You provide [inputs by date]. Updates arrive through [channel and schedule]. The cancellation and refund terms are [clearly stated terms], and questions go to [contact].” Replace every bracket before using the offer.

Thirty days is the source's example promise, not permission to promise a date you cannot meet. Put an actual date beside the interval so the buyer knows when delivery is due. Do not claim guaranteed business outcomes or hide material limitations behind the story. If you change the promise for a later test, retain the original terms for existing orders unless a change is agreed with those buyers.

Make refund handling part of the operating process

The source also names a refund-handling SOP without its procedure or terms. This operational adaptation begins with a record of the request, purchase, promised scope, amount, and relevant dates. Acknowledge the request, review the terms applicable to that order, assign an owner, and record the decision and response. When a refund is due, process it through the appropriate payment workflow, verify its recorded outcome, and communicate the status. Track open cases until resolved and reconcile them with the pre-sale count and delivery ledger. If a delay occurs, communicate it promptly and explain the available next steps. This exercise does not establish legal rights, payment-provider rules, or a universal refund policy.

Connect the story to a credible offer and submit the evidence

Use the Brunson connection to move from a relevant hook through a truthful story to a specific offer. Use the Hormozi connection to examine the desired outcome, the customer's confidence in delivery, the wait, and the effort required. Reduce uncertainty with clear scope and evidence rather than inflated claims. The six-step protocol and adapted wording here are RISER instructional additions, not quotations of either educator's proprietary templates.

Submit the offer version, delivery promise, order-and-refund ledger, buyer count, observed objections, fulfillment plan, and a short decision explaining whether to continue, revise, or stop this test. Keep this lesson's current workbook completion requirements as well as the source's five-pre-sale measure.

Sources and resources

Read the assigned M4.3 - StorySelling Validation (Pre-Selling) source

The full 5-Pre-Sale Protocol, original 30-day template, refund SOP, and C3 Primary Avatar Profile are named dependencies without usable resource links in this excerpt. The adaptations above do not establish that those original assets have been supplied or reviewed. Use other assigned lesson links where they identify the actual asset; an unavailable original remains a documented gap.

Build the niche-validation and campaign-launch sequence

The file title says Niche Validation and Campaign Launch Workbook; the internal title says Niche Discovery & Validation Workbook. It contains sections 1–10 plus 7A. Follow the full sequence and distinguish research signals from paid demand. The following teaches every source task; numerical gates are the workbook's heuristics, not guaranteed performance standards.

Research the audience and build the first offer

Complete all six keyword-testing steps

1. Identify Stage A or B. Stage A asks whether demand exists: use broad relevant terms, a small test, and qualitative feedback. Stage B assumes demand evidence and focuses on expansion, competitor research, and split tests. Do not declare Stage B merely because the idea sounds plausible.
2. Apply the minimum-readiness check: 3–10 relevant phrases, understood intent, hundreds of monthly searches in total, and ads or commercial offers in results. Preserve the examples “first time homebuyer guide,” “buying your first home tips,” and “how to buy a house step by step” as illustrative phrases, not verified keyword data.
3. Start a bounded test once the small keyword set and landing page are ready; the source says not to wait for a perfect list, every competitor mapped, or a full funnel. Still define scope, budget, measurement, and the promised deliverable before launch.
4. Select terms by clear intent, some volume, and audience relevance. The source says hundreds of searches can be enough; it gives no geography, period, or conversion model supporting a universal minimum.
5. Preserve the ten-day plan: days 1–3 brainstorm; 4–5 search and record results; 6–7 check volume; day 8 build the page; 9–10 launch the test. This is a suggested schedule, not proof that a test was run.
6. Review performance, expand around winners, drop underperformers, and refine messaging. Record sample size and actual outcomes before deciding a keyword won or failed.

Complete the separate 7A seed-keyword checks

Start broad enough to find competitors and specific enough to reveal intent. The source contrasts “coaching” with “career coaching for engineers.” Its “bounce back” check means searching and examining similar services, articles, ads, autosuggest, and related searches; it is not an analytics bounce-rate calculation. Relevant results support further investigation, not automatic validation.

For commercial intent, record ads, ranking product/service pages, and the source's CPC-over-$0.50 heuristic. Record currency, source, market, and date; CPC does not prove profitability. Avoid excessive narrowness, illustrated by “career coaching for left-handed engineers in Houston.” The source recommends 500–1,000 monthly searches or broader variants using Ubersuggest, Ahrefs, SEMrush, or Keyword Planner. This differs from section 7's hundreds-total rule; preserve both as source heuristics with different contexts rather than replacing one silently.

When terms yield relevant competitors, useful scope, and commercial signals, collect 10–20 domains and research them with SEMrush, Ahrefs, or SpyFu. Close all four readiness checks: relevant companies/content, relevant autosuggest/related searches, ads running, and at least 3–5 identifiable competitors. Absence of ads alone does not prove nobody wants the solution.

Outreach, delivery, and scale

Section 8 names cold email, direct messages, Facebook/LinkedIn posts, and $100–$200 micro-budget campaigns. Its sample email uses the subject “Quick Question About Growing Your Electrical Business,” greets a named contact, repeats the Phoenix-electrician 10–20-call claim, invites a 15-minute conversation, and closes without pressure with the sender's name. Teach the structure, but do not reuse the unsupported result claim or send anything as part of reading this lesson. Prepare accurate wording and review the actual channel requirements before a real campaign.

Section 9 asks four discovery questions: biggest frustration, value of one new customer, prior marketing attempts, and willingness to invest if the problem can be addressed. It proposes a low-cost beta in exchange for testimonials. Collect honest feedback and disclose relevant incentives; do not require a positive endorsement or represent a beta as proven results.

Section 10 lists Google Business optimization, a basic website/funnel, review collection, and lead tracking. Document delivery, case studies, and genuine testimonials. The source suggests scaling after 3–5 booked calls and two or more converted clients. Record those counts, but also inspect delivery quality, costs, refunds, and capacity before increasing activity. No budget is being spent or campaign launched by this curriculum exercise.

Brunson's hook/story/offer connection helps keep the journey coherent; Hormozi's result, confidence, delay, and effort lens helps clarify the offer. Submit every section, dated research, keyword tests, assets, booking test, actual campaign results if run, and a reasoned next decision.

Read the assigned Niche Validation and Campaign Launch Workbook source

The source's Reference Links section lists Ubersuggest, Keywords Everywhere, AnswerThePublic, Carrd, ConvertKit Landing Pages, Calendly, Canva, Coolors, Fontpair, SEMrush, Ahrefs, and SpyFu without actual destinations in the available text. Their names are retained above; specific linked research and account assets remain to be supplied. The document does not provide completed research, a working funnel, or verified case studies.

Research and validate a physical product

Complete all six sections and nine exercises in this blank workbook. Its closing promise of successful launch is an aspiration. Marketplace presence, estimated sales, and search interest do not establish profit or safe, reliable fulfillment.

Close the five checks: best sellers analyzed; high-demand/low-competition keywords researched; benchmarking complete; pre-launch tests executed; differentiation and market-readiness reviewed. Do not check execution when only a test plan exists. The workbook supplies no pass thresholds. Add a separate feasibility check for actual costs and fulfillment before calling an idea profitable; keep calculations distinct from the source's blank fields.

Use Brunson's customer/offer connection to explain the product's relevant benefit and Hormozi's outcome/confidence/effort lens to reduce buyer uncertainty without unsupported claims. Submit all nine exercises, three rows in each research grid, test evidence, five checks, and linked sources. Specific marketplace listings and research datasets are not supplied in this document.

Read the assigned Physical Product Research & Validation Workbook source

Generate, prioritize, and test product ideas

The workbook has seven exercises and five final checks. It asks for at least 10–15 initial ideas and three selected ideas for the roadmap. Treat ideas as hypotheses until tested; a brainstorming score is not proof of feasibility, scalability, or profit.

Complete all seven exercises

1. Define the objective: primary session goal, problem or market gap, and product/offer type such as physical, digital, or service.
2. Research three current industry trends, competitors' offers, and recurring complaints or gaps. Add dates and sources. A trend claim without evidence stays provisional.
3. Generate ideas through every SCAMPER operation: Substitute components/materials/ingredients; Combine concepts; Adapt to a new purpose; Modify shape/size/color; Put to another use; Eliminate a feature or simplify; Reverse the approach. Write the resulting idea and the customer reason it might help. Generate the source's 10–15 initial candidates rather than stopping at one per technique.
4. Complete the three-row Value versus Effort matrix with idea, value 1–5, effort 1–5, and priority. Define what the scale means and explain the priority; the source supplies no formula or weights. High value with low effort is a useful candidate for testing, not automatic proof of the best business.
5. Validate the top ideas with keyword research and top-ranking terms, a survey and its actual questions, and a small ad test with actual results when run. Record budget, measure, denominator, period, and uncertainty. Do not claim an ad campaign ran when only its copy exists.
6. Write the preliminary business case: target audience, USP, pricing strategy, revenue model, and key distribution channels. Explain how each choice connects to the observed problem and feasible delivery.
7. List the three ideas to advance and the next steps for testing and development. Assign an owner, evidence need, and review date as an instructional addition so the roadmap can be executed.

Apply the final five checks

Confirm 10–15 initial ideas were generated; trends and competitors were reviewed; ideas were categorized and prioritized; each idea covered by your validation claim was actually tested; and feasibility, scale, and profit assumptions were examined. The broad source phrase “each idea” can exceed testing only the top ideas in Exercise 5. State exactly which candidates were tested and leave the others unvalidated rather than silently checking them all.

Keep the SCAMPER table, three-row ranking matrix, keyword/survey/ad evidence, five-field business case, three-idea roadmap, and five review checks together. The workbook's promise of winning products is not an established result. Brunson's offer narrative and Hormozi's value/delivery lens help explain a selected idea, but observed demand and delivery economics determine the next decision.

Read the assigned Product Brainstorming & Idea Validation Workbook source

Work through the MVO gates with evidence and operator judgment

This interactive source combines RISER Captain's Logic with references to Hormozi's $100M Offers/Leads, Brunson's DotCom/Expert/Traffic Secrets, Kennedy's direct response and Cialdini's persuasion. Its claimed live-launch stress testing is not substantiated by results in this file. It contains seventeen navigation entries: an introduction, fifteen decision/research gates including half-numbered gates, and a summary. Its “sixteen gates” wording is inconsistent with that structure.

Use GO, NO and REWORK as the tool's heuristic feedback, not proof that a market or business is valid. Its numeric rules and quoted doctrines are source assertions, not universally established conversion laws or independently authenticated quotations from the named authors. Examples below are hypothetical unless separate evidence is attached. Do not copy example customer results, earnings, prices, credentials, testimonials, follower counts, health promises or market-growth statistics into advertising as facts about your business.

Start with pain evidence

Enter one to five pain cards, each with title, 0–100 score, frequency, source community/URL, audience, one to five verbatim quotes, and one to three solution seeds. The default example is solo CPAs moving from hourly to retainer pricing; solution seeds include a calculator, a guided ninety-day sprint and proposal templates. Daily/weekly share a frequency bucket, as do quarterly/seasonal; monthly and one-time/project are separate. Manual entry is available; the file does not implement an automatic external research import. Skip if you lack research, but mark downstream answers as hypotheses.

Select one lead and optionally cluster related cards. Quotes populate the voice-of-customer vault. Applying the lead overwrites avatar who/pain, maps the score to a 1–10 pain scale and maps frequency. It fills an empty problem statement and an empty mechanism hint from solution seeds. Review these transfers before relying on them. Clustering is displayed, but the problem verdict does not implement the promised combined-evidence analysis. A score supplied by the operator is not independent market evidence.

The pain gate requires a lead title of at least ten characters, audience of thirty, at least three quotes of ten characters each across the bank, and at least one card scoring seventy. Its warning asks for five quotes although code permits three. Eight quotes produces the stronger GO label. Five quotes per card means one card cannot alone reach eight. The high-scoring card need not be the lead, another reason a GO label can overstate lead quality. Retain source dates and permissions; do not invent customer quotations to pass a gate.

Read every gate's fields and practice prompts

The walkthrough below preserves the source's complete field guidance, examples, options and research routes as attributed training prompts. After each field, supply an evidence-backed answer or label an assumption. Treat aggressive claims in the source prompts as material to critique using the corrections that follow. A menu choice does not itself verify the condition it names.

Gate 00: Start

Gate 00½: Pain Discovery

Source framing: "Operators who guess at pain build for themselves. Operators who import pain build for the market. The most expensive line in any business is the one that begins, 'I think the customer wants...' If you have run a PainOnSocial scan, a customer interview series, or any structured voice-of-customer research, paste the cards here. Every gate downstream gets sharper." Attribution in file: RISER Captain's Logic · The Voice-of-Customer Manifest

Gate 01: Hungry Avatar

Source framing: "The most important thing you sell is not your product — it is the market you sell it into. A starving crowd is the difference between selling steak and selling sand. Get the market right and a mediocre offer wins. Get it wrong and the best offer in the world dies." Attribution in file: RISER Captain's Logic · The Hungry Harbor Doctrine

Who exactly is the avatar?

- help: Specific. "Marketing managers at SaaS companies between $5M–$20M ARR who are personally accountable for pipeline" — not "small business owners." - placeholder: e.g., Solo accountants in their first year of practice, age 28-40, post-MBA, billing under $5K/month... - aiSharpen: True - examples — good 1: Solo CPAs in their first 24 months of practice, billing under $7K/month, ages 32–45, who got their license post-Big-4 and now work from home offices in suburban metros. - examples — good 2: In-house marketing leads at Series-B SaaS companies ($10M–$30M ARR), 2–4 years in role, personally accountable for pipeline, no SDR team yet, reporting to a CRO. - examples — bad 1: Small business owners who want to grow. - examples — bad 2: Coaches and consultants looking for more clients. - sharpen 1: Can you describe what this person did last Tuesday between 9am and noon? - sharpen 2: What is the difference between this avatar and the avatar one tier below them in income or experience? - sharpen 3: If you walked into a room of 50 of them, what would they have in common that a stranger would notice in 30 seconds? - verify 1 — source: reddit - verify 1 — label: Search Reddit for this avatar - verify 2 — source: google_site_reddit - verify 2 — label: Google → Reddit posts about this niche - verify 3 — source: youtube - verify 3 — label: YouTube — see who already serves them - verify 4 — source: twitter - verify 4 — label: Twitter/X search — recent conversations - verify 5 — source: google_trends - verify 5 — label: Google Trends — keyword trajectory - verify 6 — source: indeed - verify 6 — label: Indeed — job postings (B2B avatars)

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

What is the specific pain — in their words, not yours?

- help: Quote them. If you cannot quote them, you have not talked to them. Generic pain ("I want more clients") is not pain. Specific pain ("I lose 3 hours every Friday reconciling Stripe") is pain. - placeholder: e.g., "I keep losing deals at the proposal stage and I do not know why"... - aiSharpen: True - vocPull: True - examples — good 1: "I send proposals on Monday and by Friday I get ghosted. I never know if it was the price, the scope, or that they just went with someone else." - examples — good 2: "My pipeline looks fine on paper but I have not closed a deal in six weeks and I am starting to panic about payroll." - examples — bad 1: They struggle with sales and need more leads. - examples — bad 2: They feel overwhelmed by the marketing landscape. - sharpen 1: Did you copy this pain from a real conversation, post, or interview — or did you write it yourself? - sharpen 2: If yes, paste the source link or the conversation date. If no, that is the homework. - sharpen 3: Does the pain include a specific time, place, or trigger? "Every Monday morning" beats "in general." - verify 1 — source: reddit_pain - verify 1 — label: Reddit — search this niche + pain words - verify 2 — source: google_site_reddit - verify 2 — label: Google → real complaints on Reddit - verify 3 — source: twitter_complaint - verify 3 — label: Twitter/X — "I hate" / "I cannot" rants - verify 4 — source: youtube_howto - verify 4 — label: YouTube — "how do I" + this niche, read comments - verify 5 — source: quora - verify 5 — label: Quora — search the active questions

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Purchasing power — can they actually pay?

- help: Operating rule: target markets where buyers have demonstrated willingness to spend $1,000+ on similar problems already. 1 = broke audience, 10 = active buyers spending now. - examples — good 1: I see the avatar paying $200–$500/mo for similar SaaS tools, $2K–$5K for one-time courses, and $5K–$15K for done-with-you programs. Three competitors at this price point are profitable. - examples — good 2: The category supports $497–$2,000 offers consistently — Skool groups in this niche have 50–200 paying members at $39–$99/mo. - examples — bad 1: I think they would pay because the value is there. - examples — bad 2: My friend said he would pay for this. - sharpen 1: Name three real competitors charging $1,000+ on similar problems. Live URLs. - sharpen 2: What is the average spend the avatar already makes on adjacent tools or services per month? - sharpen 3: Have you seen at least one case study or income claim from a competitor in this category? - verify 1 — source: google_pricing - verify 1 — label: Google → competitor pricing pages - verify 2 — source: youtube_course - verify 2 — label: YouTube — search niche + "course" - verify 3 — source: reddit_pricing - verify 3 — label: Reddit — niche + "how much do you charge" - verify 4 — source: flippa - verify 4 — label: Flippa — actual transaction prices - verify 5 — source: indiehackers - verify 5 — label: Indie Hackers — operator revenue stories

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Market trajectory — growing, flat, or shrinking?

- help: Growing markets forgive errors. Shrinking markets punish even great offers. 1 = dying category, 10 = exploding category. - examples — good 1: Google Trends shows 60% YoY increase on the category terms. Three new competitors entered the space in the last 18 months. Industry reports project 25–40% CAGR through 2028. - examples — good 2: The category is mature/flat but with significant operator turnover — older incumbents losing share to newer operators with better positioning. Net opportunity is real. - examples — bad 1: I feel like this market is growing. - examples — bad 2: AI is going to make this category bigger. - sharpen 1: What does Google Trends show for the top 3 keywords in this category, 5-year view? - sharpen 2: How many new competitors entered the space in the last 24 months? - sharpen 3: Is funding flowing into this category (VC deals, accelerator focus, M&A activity)? - verify 1 — source: google_trends - verify 1 — label: Google Trends — 5-year keyword trajectory - verify 2 — source: youtube - verify 2 — label: YouTube — channel growth in this niche - verify 3 — source: tiktok - verify 3 — label: TikTok — short-form trend in this niche - verify 4 — source: google_news - verify 4 — label: Google News — funding + launches - verify 5 — source: reddit_growth - verify 5 — label: Reddit — niche subreddit growth signals

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Easy to reach — can you find them and message them?

- help: A perfect avatar you cannot reach is worthless. Pick avatars who hang out somewhere you can pay or post into. 1 = invisible, 10 = obvious channel. - examples — good 1: They aggregate in three subreddits with 50K+ members each, two private Slack groups, and one well-known LinkedIn hashtag with 100+ daily posts. I can reach 10K of them via Meta ads at $1.20 CPM. - examples — good 2: There is a specific industry conference 2x/year, a trade publication with 30K subscribers, and a Telegram group of ~3,000 active members. Three reachable channels, no gatekeeper. - examples — bad 1: I will reach them through SEO and content marketing. - examples — bad 2: I think LinkedIn would work. - sharpen 1: Name the top 3 specific places (URL/group/event) where this avatar gathers. - sharpen 2: For each, what is the audience size and engagement level? - sharpen 3: What does it cost (in dollars OR hours) to reach 100 of them per week? - verify 1 — source: reddit_communities - verify 1 — label: Reddit — find subreddits in this niche - verify 2 — source: google_site_reddit - verify 2 — label: Google → Reddit communities for this niche - verify 3 — source: youtube_channels - verify 3 — label: YouTube — channels serving this niche - verify 4 — source: twitter - verify 4 — label: Twitter/X — see who posts in this niche - verify 5 — source: facebook_groups - verify 5 — label: Google → public Facebook groups

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Pain intensity — is this a top-3 problem for them right now?

- help: Top-3 pain = budget exists. Bottom-10 pain = nice-to-have, infinite sales cycle. 1 = mild annoyance, 10 = crisis. - examples — good 1: Customers describe this pain in their first 90 seconds of a sales call without prompting. 3 of last 5 prospects said this is the #1 reason they reached out. - examples — good 2: I see this complaint in the top 5 posts every week in their primary subreddit. People say things like "I cannot keep doing this" and "I will pay anyone to fix this." - examples — bad 1: It is a real problem and they need a solution. - examples — bad 2: I know it is painful because I felt it myself. - sharpen 1: Have you watched 3+ real prospects describe this pain unprompted? - sharpen 2: Have they used emotional language ("I hate," "I cannot keep doing," "I am desperate") or transactional language ("it would be nice")? - sharpen 3: Is the pain felt regularly (daily/weekly) or only in specific moments? - verify 1 — source: reddit_pain_intensity - verify 1 — label: Reddit — emotional pain language search - verify 2 — source: youtube_howto - verify 2 — label: YouTube — "how do I" + niche, read top comments - verify 3 — source: twitter_complaint - verify 3 — label: Twitter/X — frustrated rants in this niche - verify 4 — source: quora - verify 4 — label: Quora — desperate questions in this niche - verify 5 — source: reddit_top - verify 5 — label: Reddit — sort top posts by month, this niche

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Gate 02: Idea / No Idea

Source framing: "There are four things that determine whether a market is worth attacking: massive pain, purchasing power, easy to target, and growing. If three of four are true, you have a great market. If two, you have a hard road. If one, you have a hobby. Most people pick markets based on what they know, not on whether the market deserves their next twelve months." Attribution in file: RISER Captain's Logic · The Four-Quadrant Territory Test

State the offer in one sentence — for whom, what outcome, by when.

- help: Format: "I help [avatar] get [outcome] in [timeframe] without [common objection]." If you cannot fit it in one sentence, the offer is unclear. - placeholder: e.g., I help solo accountants land their first 10 retainer clients in 90 days without cold outreach.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

What is the competitive reality?

- help: RISER doctrine: "If no one is doing it, that is usually a sign no one wants it." Competition validates demand. Absence of competition is rarely a moat — it is usually a graveyard. - options 1 — label: Crowded market with successful operators - options 1 — sub: Best signal. Demand is proven. You differentiate, not invent. - options 2 — label: Some competitors, mostly mediocre - options 2 — sub: Strong signal. Real demand, weak supply. Most opportunities live here. - options 3 — label: Almost no competition - options 3 — sub: Caution. Either you found gold OR no one wants this. Default to second. - options 4 — label: I will be first - options 4 — sub: Almost always wrong. "First mover" usually means "first to die."

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

The $100 today test — would 10 of these people pay $100 right now for a janky v1?

- help: From the Profitable Widget Playbook (and the "presell before build" doctrine). If you cannot picture 10 specific names paying $100 today, the idea is theoretical. - options 1 — label: Yes — I can name the 10 people right now - options 1 — sub: GO signal. You have proximity to demand. - options 2 — label: Probably — but I would have to find them - options 2 — sub: REWORK. Until you can name them, you do not have an avatar — you have a hypothesis. - options 3 — label: No — this would take weeks of marketing first - options 3 — sub: NO. The marketing required to find them IS the validation. Do that before building.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Gate 03: Profitable Problem

Source framing: "Every problem is not a profitable problem. Profitable problems share three features: high pain, high frequency, high cost-of-not-solving. If the problem only happens once and the cost of ignoring it is low, you are not in a business — you are in charity. The best businesses solve problems the customer pays you to keep solving." Attribution in file: RISER Captain's Logic · The Profitable-Pain Calibration

State the exact problem in one sentence.

- help: Use the customer's words. "They cannot get to inbox zero" is a problem. "Productivity" is a category. - placeholder: e.g., They spend 8+ hours/week on manual invoice reconciliation and miss billing. - vocPull: True

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

How often does the problem recur?

- help: Recurring pain = recurring revenue. One-and-done pain = transactional revenue with high re-acquisition cost. - options 1 — label: Daily or weekly - options 1 — sub: Best. Continuity offer fits naturally. LTV compounds. - options 2 — label: Monthly - options 2 — sub: Strong. Subscription rhythm available. - options 3 — label: Quarterly or seasonal - options 3 — sub: Moderate. Service-based or annual offer fits. - options 4 — label: Once-in-a-lifetime / project-based - options 4 — sub: Weakest. Every customer is a re-acquisition.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

What is the cost of NOT solving the problem?

- help: RISER doctrine: "Price is set by the cost of the problem, not the cost of the solution." High cost of inaction = pricing power. - options 1 — label: High — losing money, customers, or status - options 1 — sub: Premium pricing available. Sell against the loss. - options 2 — label: Moderate — friction and frustration - options 2 — sub: Mid-tier pricing. Sell against the time-drain. - options 3 — label: Low — minor inconvenience - options 3 — sub: Hard to monetize. Reframe to find higher-cost angle, or pick different problem.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

What do they currently do to solve it (or fail to)?

- help: Name competitors AND non-consumption alternatives ("they just suffer", "they ask their CPA", "they Google it"). The status quo IS the competition. - placeholder: e.g., They use spreadsheets, hire a part-time bookkeeper, or just get behind and panic at tax time.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Gate 04: Grand Slam Offer

Source framing: "Value = (Dream Outcome × Perceived Likelihood) ÷ (Time Delay × Effort & Sacrifice). To make any offer better, do one of four things: increase the dream outcome, increase perceived likelihood, decrease time delay, or decrease effort. The numerator is what they want. The denominator is what they pay in pain. Move both." Attribution in file: RISER Captain's Logic · The Cargo Value Equation

Dream Outcome — what is the explicit transformation?

- help: Specific, vivid, measurable. "10 paying clients in 90 days, working from home, charging $2K/mo retainers." NOT "more freedom." - placeholder: e.g., Land 10 retainer clients at $2K/mo within 90 days, working under 25 hrs/week. - vocPull: True

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Dream Outcome strength (1-10)

- help: How emotionally compelling is the outcome? Would the avatar pay 10× to skip 5 years of pain to get there? 1 = mild benefit, 10 = life-changing.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Perceived Likelihood — what is your proof that this works?

- help: RISER doctrine: "Stack proof until it gets ridiculous." Case studies, screenshots, testimonials, your own results, third-party validation. List what you have right now. - placeholder: e.g., 3 case studies with named results, my own $0-$50K journey, 47 customer testimonials...

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Perceived Likelihood (1-10)

- help: Looking at the proof above through skeptical buyer eyes — how believable is the promise? 1 = vapor, 10 = undeniable.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Time Delay — how fast does the customer feel results?

- help: Speed beats almost every other lever in mid-market offers. The faster the first win, the higher the conversion AND retention. - options 1 — label: Within 24 hours of purchase - options 1 — sub: Premium pricing power. Speed is the moat. - options 2 — label: Within first week - options 2 — sub: Strong. Engineer a Day-1 quick win. - options 3 — label: Within first 30 days - options 3 — sub: Acceptable. Add interim wins to maintain momentum. - options 4 — label: Months to first measurable result - options 4 — sub: Hard. Refund risk high. Add quick wins or refund-and-pivot.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Effort & Sacrifice — what does the customer have to DO?

- help: Done-with-you beats DIY. Done-for-you beats both. Every step you remove from the customer's plate raises perceived value. - options 1 — label: Done-for-you — they barely lift a finger - options 1 — sub: Highest pricing tier ($5K-$50K+). Limited delivery capacity. - options 2 — label: Done-with-you — guided implementation - options 2 — sub: Mid-tier sweet spot ($1K-$5K). Best price-to-effort ratio. - options 3 — label: DIY with templates and support - options 3 — sub: Lower tier ($97-$997). Higher volume possible. - options 4 — label: Self-paced with no human contact - options 4 — sub: Lowest tier ($7-$297). Highest churn. Compete on volume only.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Named Mechanism — what is your proprietary process called, and why does it work differently?

- help: RISER doctrine: "A named mechanism is the difference between a $97 product and a $4,997 program containing the same content." Give your method a name (The Retainer Method®, The 90-Day Pulse™, The 4-Lane Framework). Then in one sentence explain why it works when generic approaches fail. - placeholder: e.g., The Retainer Method™ — a 4-week sprint that replaces hourly billing with outcome-based packages by pre-selling 90 days of work in a single 30-minute conversation. Works because it inverts the proposal cycle: outcome first, scope second.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Gate 04½: Offer Stack

Source framing: "The naked core offer is never the offer. The offer is the core PLUS the stack: bonuses that solve the next three problems before they happen, a guarantee that flips the risk to you, scarcity that creates a real reason to act now, and a name that makes it sound like a thing rather than a thing-you-do. Every component you remove costs you 10% of conversion." Attribution in file: RISER Captain's Logic · The Grand Slam Stack Doctrine

Offer name — what do you call this thing?

- help: A named offer is a thing. An unnamed offer is a description. "The 90-Day Retainer Sprint" beats "my coaching program" by 30% on conversion. Use a number, an outcome word, or both. - placeholder: e.g., The 90-Day Retainer Sprint · The First-10-Clients Accelerator · Founding Pulse Cohort

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Bonuses — name 3 to 5 bonuses, each solving the NEXT problem the customer will hit.

- help: Operating rule: bonuses are not "extras" — they are pre-emptive solutions to the objections the buyer has not yet voiced. Format: "Bonus 1: [Name] — [Outcome] — [Standalone value $X]." Each bonus needs a name, a result, and a price-anchor. - placeholder: Bonus 1: The First-Client Script Library — 7 sales scripts that closed real deals — $497 value Bonus 2: The Retainer Pricing Calculator — 3 pricing tiers with anchor logic — $297 value Bonus 3: The 30-Day Onboarding SOP — copy-paste client-onboarding system — $997 value

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Guarantee type — what risk are you absorbing?

- help: RISER doctrine: "If you will not stand behind your offer with a guarantee, neither will they." Hormozi's ladder: implied < unconditional < conditional < anti-guarantee. Pick the strongest your unit economics can absorb. - options 1 — label: Anti-guarantee — "no refunds, here is why" - options 1 — sub: Boldest. Requires extreme trust + filtering. Not for first launch. - options 2 — label: Conditional — "do X, Y, Z and if no result, double your money back" - options 2 — sub: Best for most operators. Forces customer accountability + dramatic risk reversal. - options 3 — label: Unconditional — "30-day no-questions-asked refund" - options 3 — sub: Standard. Lowest friction, highest refund risk. Use if delivery is bulletproof. - options 4 — label: Implied — "we are confident you will love it" - options 4 — sub: Weakest. Not really a guarantee. Will halve conversion vs. any explicit guarantee. - options 5 — label: No guarantee - options 5 — sub: Almost always wrong. The buyer absorbs the risk and your conversion craters.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Write the guarantee — exact words you will use on the page.

- help: Specificity wins. "30-day money-back" beats "guaranteed." "If you don't land 3 retainer clients in 60 days, I work with you free until you do" beats "30-day money-back." - placeholder: e.g., Land 3 retainer clients in 60 days or I work with you free until you do — and you keep all the bonuses.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Scarcity mechanism — what makes "buy now" real, not theatrical?

- help: Cialdini: scarcity drives action only when it is REAL. Fake countdown timers train your audience to ignore you. Pick a scarcity that is structurally true. - options 1 — label: Cohort cap — "12 founding members, then closed for 90 days" - options 1 — sub: Best for service/cohort offers. Real, defensible, repeatable. - options 2 — label: Founding price — "locked at $497 for first 25, then $1,497" - options 2 — sub: Strong. Real reason to act now. Price ladder must be enforced. - options 3 — label: Bonus expiration — "Bonus 3 disappears after Friday" - options 3 — sub: Workable. The bonus must actually go away or trust dies. - options 4 — label: Launch window — "open Monday, closed Friday" - options 4 — sub: Strong if true. Brunson's preferred mechanism. Requires real close. - options 5 — label: Fake countdown / inflated urgency - options 5 — sub: NEVER. One discovery and you lose the audience permanently. - options 6 — label: No scarcity - options 6 — sub: Wrong. The buyer has no structural reason to decide today.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Stack total value — sum of core + all bonuses (anchor price)

- help: Cialdini contrast principle: a $497 price next to no anchor looks expensive. A $497 price next to a $5,991 stack value looks like a steal. Add up your core + bonus prices honestly. - placeholder: e.g., 5991

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Actual offer price (USD)

- help: The price the customer pays. Should be a fraction (typically 1/5 to 1/10) of the stack total above. If the ratio is less than 3:1, your stack is too thin or your price is too high. - placeholder: e.g., 497

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Gate 05: Core Four

Source framing: "There are four ways to get a stranger to know about you: warm outreach, cold outreach, warm content, paid ads. That is it. Every business runs one or more of these. The mistake is picking three at the start. Pick ONE. Get to 100 customers from that one. Then add the next." Attribution in file: RISER Captain's Logic · The Core Four Shipping Lanes

Pick your primary channel (one only).

- help: Operating rule: master one before adding another. The operator who runs LinkedIn cold outreach 5 days a week for 12 weeks beats the operator who tries 4 channels. - options 1 — label: Warm outreach - options 1 — sub: DM/email people who already know you. Best for first 10 customers. Free. Low volume. - options 2 — label: Cold outreach - options 2 — sub: DM/email strangers at scale. Best when avatar is identifiable + reachable. Cheap. Skill-intensive. - options 3 — label: Warm content - options 3 — sub: Post valuable content to your audience. Compounds over time. Slow start. - options 4 — label: Paid ads - options 4 — sub: Pay platforms to put your offer in front of strangers. Requires unit economics first. Fastest scaling.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Volume math — how many touches per day to hit your numbers?

- help: RISER doctrine: "More is the answer. Always more." If you need 10 customers in 90 days at 1% conversion, you need 1,000 conversations = ~12/day. Do the math now. - placeholder: e.g., 50 cold DMs/day × 5 days/week × 12 weeks = 3,000 conversations. At 1% close = 30 customers.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Do you know your unit economics?

- help: Required before paid ads. Optional but useful for organic. - options 1 — label: Yes — I know CAC, LTV, payback period - options 1 — sub: GO. Paid ads viable when CAC < 1/3 of 12-month LTV. - options 2 — label: Partially — rough estimates only - options 2 — sub: Use organic until estimates become real numbers. - options 3 — label: No — pre-revenue - options 3 — sub: Stay organic. Paid ads will burn cash with no feedback loop.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Gate 05½: Dream 100

Source framing: "You do not need to find a million strangers. You need to find the 100 people who already gathered them. Every audience you want to reach has been pre-built by 100 specific operators — podcasters, newsletter writers, YouTubers, Skool group owners, association heads, top affiliates. Borrow their boats. Do not build your own dock from scratch." Attribution in file: RISER Captain's Logic · The Dream 100 Convoy

List 25 specific people, podcasts, newsletters, or groups your avatar already follows.

- help: Named handles. Real URLs. Not "fitness influencers" — but "@HybridAthlete", "ATG for Life YouTube", "Knees Over Toes Skool group", "Ben Patrick Substack". The first 25 take 2 hours of research. Skip this and you build distribution from zero. - placeholder: e.g.,

1. @hormozi (Twitter, 2.1M followers)
2. The My First Million podcast
3. Indie Hackers community (newsletter)
4. SaaStr Skool group
5. ...continue to 25

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Primary Dream 100 strategy

- help: Brunson's framing: there are only three ways in. Pick one. Working two strategies on the same Dream 100 person at the same time = burned bridge. - options 1 — label: Work your way in — provide value first, become known - options 1 — sub: Slowest, most durable. Comment, share, send wins. 90 days to first invitation. - options 2 — label: Buy your way in — sponsor, advertise, run paid promo - options 2 — sub: Fastest. Costs money. Use when you have unit economics. - options 3 — label: Partner — co-create, joint venture, revenue share - options 3 — sub: Highest leverage. Requires you bring something they need.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

First-touch script — what you will send to the first 10.

- help: No pitch. No ask. The first message is gift-only. Quote them, share a result, send a resource. Reciprocity is built before the ask is made. Cialdini's rule: the gift comes first or the ask is dead. - placeholder: e.g., "Hey [Name] — just used your retainer-pricing framework with 3 clients. Closed 2 at $4K/mo. Wanted to send a thank-you and the case study screenshots. No ask, just gratitude."

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Outreach volume — how many Dream 100 contacts per week?

- help: Brunson: 100 contacts in a week is not unreasonable. 100 in a year means you do not believe in the strategy. The Dream 100 is a daily action, not a quarterly project. - options 1 — label: 20+ per week - options 1 — sub: Best. Compounds fast. By month 3 you are known in the niche. - options 2 — label: 5–20 per week - options 2 — sub: Workable. Slower compound. 6+ months to network density. - options 3 — label: <5 per week - options 3 — sub: Too slow. The Dream 100 stops working below this volume. - options 4 — label: Not yet doing it - options 4 — sub: NO. The Dream 100 is the highest-leverage activity in early growth. Start today.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Gate 06: Hook / Body

Source framing: "You have three seconds. The hook stops the scroll. The headline promises the dream. The body proves you can deliver. Most copy fails at the hook, blames the product. The hook is not a creative challenge — it is a calling-out exercise. Call out the avatar by their pain, by name, in the words they use about themselves." Attribution in file: RISER Captain's Logic · The Three-Second Signal Flare

Hook — first 3 seconds. What stops the scroll?

- help: Hook formats that work: callout question ("Solo accountants — are you charging by the hour?"), pattern interrupt ("I fired my agency yesterday."), specific stat ("47% of [avatar] do this wrong"). Avoid clever; choose clear. - placeholder: e.g., Solo accountants under $5K/mo: stop trading hours for dollars by Q2. - vocPull: True

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Headline — the promise.

- help: Format: [Outcome] in [Timeframe] without [Objection]. Specific outcome, specific timeframe, named objection removed. Use numbers when possible. - placeholder: e.g., Land 10 retainer clients at $2K/mo within 90 days — without cold outreach, paid ads, or a website rebuild. - vocPull: True

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Body — proof + mechanism + call-to-action.

- help: 5-line skeleton: Problem · What's working now · How it works (named mechanism) · Proof · Specific CTA. Keep under 100 words for ads, under 250 for landing pages. - placeholder: Most solo accountants are stuck billing by the hour, capping income at 40 hrs × $X. The shift is to retainer-based packages priced on outcomes, not time. The Retainer Method® gets accountants from hourly to $2K/mo retainer in 90 days... - vocPull: True

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Call-to-action specificity

- help: Vague CTAs ("learn more") convert at half the rate of specific CTAs ("get the 5-page retainer template + 90-day guide"). - options 1 — label: Named asset + specific outcome - options 1 — sub: Best. "Get the 5-page Retainer Pricing Calculator." Concrete object. - options 2 — label: Action verb + topic - options 2 — sub: OK. "Apply for a strategy call." "Download the playbook." - options 3 — label: Generic ("learn more") - options 3 — sub: Weakest. Rewrite before deploy.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Gate 06½: Persuasion

Source framing: "Copy is downstream of persuasion. Most operators write copy and hope persuasion happens. The reverse is correct: identify the one belief you must break, the seven psychological levers your page activates, and the lead magnet that creates reciprocity before the ask. Copy is the surface; persuasion is the structure underneath." Attribution in file: RISER Captain's Logic · The Persuasion Architecture

The Big Domino — what is the ONE belief you must break for the sale to happen?

- help: Brunson's One Big Domino: "If I can make my prospect believe ONE thing is true, all other objections become irrelevant." Format: "If they believe [X], then they will buy." Make it specific to your avatar and your offer's mechanism. - placeholder: e.g., If solo accountants believe that retainer pricing is achievable in 90 days without losing their existing hourly clients, the rest of the offer sells itself.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

False Belief Audit — name the 3 false beliefs blocking the sale.

- help: Brunson's 3-belief framework: (1) belief about the VEHICLE ("retainer pricing only works for big firms"), (2) belief about THEMSELVES ("I am too new to charge that much"), (3) belief about EXTERNAL ("my market is too price-sensitive"). Name one of each. - placeholder: Vehicle: "Retainers only work for established firms with reputations." Self: "I do not have the credibility to charge $2K/mo yet." External: "My local market will not pay retainer rates."

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Reciprocity gift — what do you GIVE before you ask?

- help: Cialdini's reciprocity rule: the gift comes first or the ask is dead. Brunson's Bait. Hormozi's Lead Magnet. Specific, useful, immediate. Not "a free guide" — a named, valuable asset. - placeholder: e.g., The Retainer Pricing Calculator — 3-tier model with anchor logic + 5 sample proposals that closed real $2K-$5K/mo deals. PDF + Notion template. 7 minutes to use. - vocPull: True

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Reciprocity — does your funnel give before it asks?

- help: Cialdini's most under-leveraged principle. The lead magnet, the free workshop, the pre-call resource. Without a gift first, the ask sounds like a demand. - options 1 — label: Strong — named, useful asset given freely before any pitch - options 1 — sub: GO. Reciprocity debt is established. - options 2 — label: Weak — generic "newsletter" or "free webinar" - options 2 — sub: REWORK. Generic gifts are not gifts. Make it specific and valuable. - options 3 — label: None — direct pitch, no gift - options 3 — sub: NO. Cold ask without reciprocity converts at 1/3 the rate.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Social Proof — what density and similarity?

- help: Cialdini: people follow people who look like them. 3 testimonials from people who match the avatar exactly beat 30 generic testimonials. Specificity > volume. - options 1 — label: 5+ testimonials from avatar-similar customers, with named results - options 1 — sub: GO. Strong proof density. Names, photos, specific numbers. - options 2 — label: 2-4 testimonials, partial similarity - options 2 — sub: REWORK. Stack more, get exact-avatar matches. - options 3 — label: 0-1 testimonials OR generic praise - options 3 — sub: NO. The proof gap is the conversion gap. Get 3 specific testimonials before launch.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Authority — what credentials, results, or associations are visible?

- help: Cialdini: people defer to expertise. Specific results > vague credentials. "Built and sold a $4M agency" beats "12 years experience." Numbers + names + outcomes. - options 1 — label: Strong — specific track record, results, or recognized association - options 1 — sub: GO. Authority is unambiguous. - options 2 — label: Borrowed — endorsement from named authority figure - options 2 — sub: Workable. Borrowed authority is real authority if attributed. - options 3 — label: Thin — generic credentials, no specific results - options 3 — sub: REWORK. Replace credentials with results. Numbers > letters after your name.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Unity — does your copy use shared-identity language?

- help: Cialdini's 7th principle (the most overlooked): "we," "us," "our kind," "people like us." Tribe language. The avatar should feel they belong to a group, not a market segment. - options 1 — label: Strong — explicit shared identity, named tribe - options 1 — sub: Best. "Solo accountants who refuse to bill by the hour." - options 2 — label: Implicit — written for the avatar but no tribe naming - options 2 — sub: OK. Add explicit identity language for 20% conversion lift. - options 3 — label: Absent — generic "you" with no identity layer - options 3 — sub: REWORK. Name the tribe.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Consistency — what small "yes" do you secure before the big yes?

- help: Cialdini: people stay consistent with prior commitments. The micro-yes (download, quiz, opt-in, free call) creates the consistency pressure that makes the macro-yes feel natural. - options 1 — label: Multi-step funnel — opt-in → engagement → ask - options 1 — sub: Best. Each step is a small yes. - options 2 — label: Single-step — direct ask, no priming - options 2 — sub: REWORK. Add at least one micro-commitment before the ask.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Gate 07: Deploy

Source framing: "Done beats perfect every single time. The launch you do not run cannot teach you anything. The launch that embarrasses you in 12 months is the right launch — anything you ship today that you would still be proud of in a year was over-engineered. Ship in 30 days. The market is the editor." Attribution in file: RISER Captain's Logic · The Launch-Ugly Doctrine

Beta launch date (specific calendar date, ≤ 30 days out)

- help: A date is not a commitment until it is signed. Pick a Friday. Tell another operator. Make it expensive to slip. - placeholder: e.g., 2026-05-23

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Beta cohort size

- help: Captain's rule for first launch: smaller is better. 10 over-served founding members produce 10× the testimonial density of 50 mediocre members. 0 is too few; 50 is too many. - options 1 — label: 5–10 founding members - options 1 — sub: Best for first-time launch. Over-serve. 10× testimonial density. - options 2 — label: 10–25 members - options 2 — sub: Strong. Workable delivery capacity. - options 3 — label: 25–50 members - options 3 — sub: Risky on first launch. Delivery quality slips. - options 4 — label: 50+ members - options 4 — sub: Almost always wrong on first launch.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Beta price (single number, USD)

- help: Founding rate, locked. Avoid the "Muddled Middle" ($500–$900). Default for service/coaching: $497–$997 founding rate, future $1497–$1997. For productized: $97–$297 founding, future $297–$497. - placeholder: e.g., 497

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Kill rule — what happens if you do not hit the number?

- help: RISER doctrine: "If you cannot say what failure looks like in advance, you cannot tell the difference between a struggling launch and a dead launch." Kill rules protect from sunk-cost grinding. - options 1 — label: < 5 paid in 14 days = pivot offer angle - options 1 — sub: Best. Forces a decision before sunk cost compounds. - options 2 — label: < 3 paid in 21 days = pivot - options 2 — sub: Acceptable. Slightly slower trigger. - options 3 — label: I will keep going regardless - options 3 — sub: Wrong answer. Define failure or it will define you.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Are the 4 minimum tools live?

- help: RISER minimum: a way to capture leads, a way to take payment, a way to deliver, a way to measure. Everything else is optional pre-launch. - options 1 — label: All 4 live and tested - options 1 — sub: GO. - options 2 — label: 3 of 4 live - options 2 — sub: REWORK. Name the missing one and ship it this week. - options 3 — label: Fewer than 3 - options 3 — sub: NO. Tools are not the problem. Build the missing tools FIRST in the next 7 days.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Gate 08: Iterate

Source framing: "Volume forgives mistakes. The operator who has 100 sales conversations in a month learns more than the operator who has 5 perfect ones. Iterate on data, not opinions. Talk to every customer. Ask the same five questions. After 30 conversations, the pattern is undeniable." Attribution in file: RISER Captain's Logic · The Voyage Log Iteration Cycle

How many at-bats before iterating?

- help: Iterating after 3 calls = noise. Iterating after 30 calls = signal. Iterating after 300 = late. - options 1 — label: 20–30 sales conversations or 30+ users - options 1 — sub: GO. Sample size large enough to see patterns. - options 2 — label: 10–20 conversations - options 2 — sub: REWORK. Pattern unclear. Run 10 more before changing anything. - options 3 — label: Fewer than 10 - options 3 — sub: NO. Iteration is premature. Get to 30 first.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

What is the dominant pattern from real customers?

- help: RISER doctrine: "Customers tell you exactly what is wrong. Most operators do not believe them." What objection comes up most? What feature do they ignore? What outcome do they actually celebrate? - placeholder: e.g., 7 of 10 customers say the templates worked but the live calls were too long. 3 dropped at week 4 because of pacing.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Which Value Equation lever do you adjust?

- help: Pick one. Changing all four at once is rebuild, not iterate. Iterate is one lever per cycle. - options 1 — label: Strengthen Dream Outcome - options 1 — sub: Reframe transformation, raise specificity. - options 2 — label: Increase Perceived Likelihood - options 2 — sub: Add proof, case studies, guarantees. - options 3 — label: Decrease Time Delay - options 3 — sub: Engineer faster first win, add quick wins. - options 4 — label: Decrease Effort & Sacrifice - options 4 — sub: Remove DIY steps, add templates, raise tier to DWY/DFY.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Awareness stage — where is the market relative to the solution?

- help: Eugene Schwartz's 5 stages (used by Hormozi + Brunson): the right copy depends on what the market already knows. A Stage 1 audience needs the problem named. A Stage 5 audience needs a new mechanism. Most copy fails because it is written for the wrong stage. - options 1 — label: Stage 1 — Unaware: do not know they have the problem - options 1 — sub: Lead with a story or stat that names the pain. Direct claims fall flat here. - options 2 — label: Stage 2 — Problem-Aware: feel the pain, do not know solutions exist - options 2 — sub: Lead with the pain in their words. Promise the category of relief. - options 3 — label: Stage 3 — Solution-Aware: know solutions exist, comparing options - options 3 — sub: Lead with your unique mechanism. Differentiate, do not invent. - options 4 — label: Stage 4 — Product-Aware: know your product, weighing it - options 4 — sub: Lead with proof + risk reversal. They need permission to act. - options 5 — label: Stage 5 — Most Aware: know your product, just need a reason now - options 5 — sub: Lead with offer + scarcity. Direct ask. Brevity wins.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Market sophistication — how worn-out are the claims in this niche?

- help: Schwartz's sophistication ladder: every claim works once, weakens with repetition, dies when the market has heard it 1,000 times. The fix is a NEW MECHANISM that resets the claim. Your market sophistication tells you how hard the new-mechanism work has to be. - options 1 — label: Stage 1 — first to make the claim - options 1 — sub: Direct claims work. Rare in 2026; usually means the niche is small. - options 2 — label: Stage 2 — claim works, you must make it bigger - options 2 — sub: "Lose 30 lbs" → "Lose 30 lbs in 30 days." Amplify. - options 3 — label: Stage 3 — claims worn, need a unique mechanism - options 3 — sub: Most niches in 2026 live here. Named mechanism is mandatory. - options 4 — label: Stage 4 — mechanisms saturated, need a NEW mechanism - options 4 — sub: "Not keto, not fasting — the metabolic-window method." Reset the category. - options 5 — label: Stage 5 — every mechanism heard, must lead with identity / story - options 5 — sub: Tribe + identity wins. The mechanism is a side-effect of who you are.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Refund interview discipline — are you running them?

- help: Hormozi: "The refund call is the single most valuable sales call you will ever take." 5 questions: (1) What did you hope this would do for you? (2) What part of the experience caused you to step back? (3) Was the issue hook, audience, offer, onboarding, or delivery? (4) What would have changed your mind? (5) Would you refer someone else? The pattern is in the answers. - options 1 — label: Yes — every refund triggers a structured 5-question call - options 1 — sub: GO. You are mining the highest-signal data in the business. - options 2 — label: Sometimes — informal refund conversations - options 2 — sub: REWORK. Formalize the 5 questions. Track the pattern across 10 refunds. - options 3 — label: Never — refunds are processed silently - options 3 — sub: NO. You are throwing away your best diagnostic data. Start tomorrow.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Gate 09: Pivot or Hold

Source framing: "Three things can be wrong: the offer, the audience, or the hook. They look identical from the outside — both produce zero sales. The diagnostic is in the data. Hook problem: low click-through. Audience problem: high click-through, no conversion. Offer problem: high conversion, fast refund. Stop guessing. Read the funnel." Attribution in file: RISER Captain's Logic · The Three-Failure-Mode Diagnostic

Are people clicking through your hooks?

- help: Cold ad CTR baseline: 1-2%. Organic post engagement baseline: 1-3% of followers. Below = hook problem. - options 1 — label: Yes — CTR / engagement is normal or above - options 1 — sub: Hook is fine. Look elsewhere. - options 2 — label: No — barely anyone clicks or engages - options 2 — sub: HOOK problem. Rewrite hooks before changing offer or audience.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Of clicks, what % opt-in / start the buying conversation?

- help: Cold landing page baseline: 20-40%. Sales page to purchase baseline: 1-3%. Application/booking baseline: 5-15%. - options 1 — label: Above baseline (great) - options 1 — sub: Audience is right and offer is interesting. - options 2 — label: At baseline - options 2 — sub: OK. Look at conversion deeper in funnel. - options 3 — label: Below baseline (people click, do not opt-in) - options 3 — sub: AUDIENCE problem. Wrong people are showing up. Refine targeting.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Of buyers, what % stay, refer, or upsell?

- help: Refund rate >10% in first 30 days = offer problem. Refund rate <5% = offer is at minimum acceptable. - options 1 — label: Refund rate <5%, NPS positive - options 1 — sub: Offer works. Scale. - options 2 — label: Refund rate 5-10% - options 2 — sub: REWORK. Offer is borderline. Improve delivery before scaling. - options 3 — label: Refund rate >10% OR negative NPS - options 3 — sub: OFFER problem. Do not scale. Fix the delivery or the promise.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Gate 10: Scale

Source framing: "You scale what works. You do not scale what might work. The signal you can scale: same offer, same audience, same channel, repeatedly producing customers at known unit economics. Scaling before this signal is gambling. Scaling after is math." Attribution in file: RISER Captain's Logic · The Scale Signal Doctrine

Do you have the scale signal?

- help: Operating rule: 10 customers from one channel at known CAC and 6+ months of retention data = scale signal. Anything less = volume gambling. - options 1 — label: Yes — 10+ customers from one channel, known unit economics, 6+ months of retention data - options 1 — sub: GO. Scale begins. - options 2 — label: Some signal, partial data - options 2 — sub: REWORK. Get to 10 customers + 6 months retention before scaling. - options 3 — label: No — early or unstable - options 3 — sub: NO scale. Stay in iterate loop. Volume is not the answer yet.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

How do you scale? (Pick one)

- help: The three scale levers: increase price, increase volume, increase retention. Most operators reach for volume first; that is usually wrong. - options 1 — label: Raise price first - options 1 — sub: Highest leverage. 10% price increase ≈ 50%+ profit increase. Test before raising. - options 2 — label: Increase retention / LTV - options 2 — sub: Second-highest. Reduce churn 20% ≈ 100% LTV increase. - options 3 — label: Increase volume (more leads, more conversion) - options 3 — sub: Third lever. Most expensive. Use only when price + retention are maxed.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

What is the current bottleneck?

- help: Theory of Constraints: there is one bottleneck at a time. Lead gen, sales, delivery, retention. Name it. Fix it. Move to the next. - placeholder: e.g., Delivery — I cannot onboard more than 5 new clients per month without burning out.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Gate 11: Repeat

Source framing: "One offer, one audience, one channel — that is a business. Two offers to the same audience — that is a customer base. Three offers to the same audience — that is a moat. Most operators jump to a second business before they have built one. The compound move is to deepen the same audience with the next problem they will pay you to solve." Attribution in file: RISER Captain's Logic · The Compound Moat Principle

What is the NEXT problem your existing customers will pay you to solve?

- help: Operating rule: ask 20 customers "what is the next thing you would buy from me?" Build that. Same audience, no new acquisition cost. LTV doubles. - placeholder: e.g., Customers landed retainers but struggle to scale past $20K/mo. Next offer: "Retainer to Agency" coaching at $4,997.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

What is the right next move?

- help: Most operators get this wrong. The temptation is "another business." The right answer is almost always "another offer to the same audience." - options 1 — label: New offer, SAME audience, SAME channel - options 1 — sub: Best. Compound the moat. 5x LTV from existing customers. - options 2 — label: Same offer, new adjacent audience - options 2 — sub: Second-best. Tested offer reduces risk. - options 3 — label: Same offer, same audience, NEW channel - options 3 — sub: Third option. Channel diversification reduces platform risk. - options 4 — label: New business entirely - options 4 — sub: Almost always wrong. You are leaving compound returns on the table.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Have you maxed out the current offer first?

- help: RISER doctrine: "Do not start a second business until the first is at the limit of what one operator can extract from it." Most operators are at 30% of that limit when they get bored and pivot. - options 1 — label: Yes — same offer at $X-million ARR with healthy retention - options 1 — sub: GO compound. - options 2 — label: No — still room in the current offer - options 2 — sub: REWORK. Stay focused. Maximize before adding. - options 3 — label: I am bored / want something new - options 3 — sub: NO. Boredom is not strategy. Re-engage the current business.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Value Ladder Rung 1 — BAIT (free lead magnet, name + format)

- help: Brunson's ladder starts here. Free, named, valuable. The first rung exists to create reciprocity and build the list. If you have no bait, you have no ladder. - placeholder: e.g., The Retainer Pricing Calculator (PDF + Notion template)

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Rung 2 — TRIPWIRE ($7-$97 entry offer, name + price)

- help: Low-ticket entry point. Converts a lead to a buyer for the price of a coffee. Buyers behave fundamentally differently from leads — this is the rung that creates the buyer-list segment. - placeholder: e.g., The 7-Day Retainer Email Course — $27

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Rung 3 — CORE OFFER ($297-$1,997, name + price)

- help: Your main offer. The Grand Slam. Most operators only have this rung and wonder why they cannot scale. - placeholder: e.g., The 90-Day Retainer Sprint — $497

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Rung 4 — CONTINUITY (recurring offer, name + monthly price)

- help: Hormozi: "The single highest LTV-per-dollar move is continuity." Skool community, software subscription, monthly coaching, certification renewal. If you have no continuity, you are leaving 60% of LTV on the table. - placeholder: e.g., The Retainer Captains Skool — $97/mo

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Rung 5 — HIGH-TICKET / BACK-END ($5K-$50K+, name + price)

- help: The premium DFY tier. 80% of operator profit lives here. Often "Done-with-me" or "Done-for-you" implementation of the core offer's outcome. - placeholder: e.g., The Agency Architect — $9,997 12-week 1:1 build

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Continuity health — what % of customers are on a recurring offer?

- help: The single highest-leverage metric for compound LTV. Below 20% = you have not built the continuity offer yet. Above 60% = you have a real moat. - options 1 — label: 60%+ on continuity - options 1 — sub: GO. Real LTV. Real moat. - options 2 — label: 20-60% on continuity - options 2 — sub: Workable. Improve the continuity offer or migration path. - options 3 — label: <20% on continuity - options 3 — sub: REWORK. Build the continuity offer. Highest-leverage gap in your business. - options 4 — label: No continuity offer exists - options 4 — sub: NO. Build it before scaling acquisition further.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Affiliate / partner activation — have you turned customers into affiliates?

- help: Brunson: the second wave of growth comes from your customers selling for you. 10 customer-affiliates each bringing 5 clients = 50 clients with zero acquisition cost. - options 1 — label: Yes — formal program with named affiliates already producing - options 1 — sub: GO. Compound is engaged. - options 2 — label: Informal referrals, no program - options 2 — sub: REWORK. Formalize. A 30%-commission affiliate program turns your customer list into a sales force. - options 3 — label: No referral or affiliate motion - options 3 — sub: NO. You are paying for every customer when half of them would pay to bring others.

Practice: answer this field with specific evidence, note what remains assumed, and explain how the answer changes the next business decision.

Gate 12: Brief

Understand the actual verdict rules and their limits

Translate the source examples into responsible practice

The avatar examples distinguish a defined role, business stage and context from “small businesses that want growth.” Use actual evidence for age, revenue, reach or urgency where relevant; the supplied SaaS prices, market-growth percentages, community sizes, CPMs and follower counts are illustrative, not current measurements. Build the idea sentence around who, outcome, timeframe and objection. Record the alternatives customers already use, including doing nothing.

In offer work, separate a dream outcome from proof, then find a credible earlier win and reduce unnecessary effort. DFY, DWY, DIY and self-guided formats entail different costs and obligations; the source's price bands are examples. A named method is a way to explain delivery, not automatic proof of uniqueness or a right to use a trademark symbol. Stack bonuses around next problems rather than inflated values. State guarantee terms plainly and honor real deadlines or capacity limits.

For distribution, reverse-calculate contacts from a measured conversion assumption and distinguish contacts, conversations, leads and customers. Dream 100 starts with relevant people who already serve the audience; useful contributions precede a respectful request. Copy connects a truthful hook to the problem, mechanism, proof and next action. The Big Domino and vehicle/self/external belief audit identify questions to answer with evidence, not a license to dismiss reasonable objections.

The source's unity claim of a 20% conversion lift, naming claim of 30%, no-gift one-third conversion claim, cohort tenfold testimonial density, and first-business 70%-value-left claim lack substantiation here. Do not repeat them as expected results. Awareness stages describe what buyers know; sophistication describes competing claims. A stage-five “new mechanism” introduction conflicts with other stage-five language in the file. Use the actual awareness choices from unaware through most aware and explain the distinction. The source's rapid-weight-loss advertising example is retained only as a source example to critique, not a safe or supported promise to use.

After a controlled launch, inspect feedback and change a clearly named variable where practical. Diagnose the funnel with actual denominators, cohort sizes and qualitative evidence. Improve the current offer, then research the next problem with customers before adding a ladder rung. Bait, tripwire, core, continuity and high-ticket are options with the source's example price ranges, not mandatory products for every business. Recurring billing needs recurring value; affiliates need disclosed, economically feasible arrangements.

Use the help system, save state and export accurately

The avatar help rail provides good/bad examples, sharpening questions, verification routes and AI critique. Verification builds searches from niche and pain keywords for Reddit, Google site searches/pricing/news, Facebook groups, five-year Google Trends, YouTube/how-to/courses/channels, X complaints, TikTok, Quora, Indeed, Flippa and Indie Hackers. These are search destinations, not research already performed. Inspect actual results, save useful URLs and record dates. Keyword extraction can lose context.

AI Sharpen sends the current avatar-who or avatar-pain answer to Anthropic, requesting a 1–10 specificity score, two-to-three-sentence critique, one weakest element and a two-to-four-sentence rewrite. It uses a 700-token cap and the file's configured model, claude-sonnet-4-6. Source comments about model release dates and strongest models are not verified current guidance. The prompt both forbids invention and asks for a plausible filled-in example when details are absent. Therefore label any added example details, check the rewrite, and never convert them into asserted customer facts. “Use rewrite” replaces the answer. The score is a writing critique, not a market verdict.

The AI request is directly from the browser despite a later comment referring to a Netlify Function. The API key is stored in localStorage under a separate key. A matching prefix is not authentication, and this pattern exposes credentials to browser code. Anthropic explains that exposure. Do not put credentials into published course HTML. The code handles 401, 429 and other errors but does not reliably establish the cause of every 400; it parses only the first content block and does not verify all requested JSON fields or stop reasons.

Answers, pain cards, vault, verdict labels and timestamps persist in localStorage under riser-mvo-widget-v3. MDN explains that persistence is origin-scoped. Export JSON before relying on browser storage as your only copy. Reset clears the working state after confirmation but does not clear the separate API key; Settings has its own key-removal control. Navigation allows moving between gates without passing them. Saved verdict labels can remain stale after editing answers, so re-evaluate relevant gates before relying on the brief.

The vault picker appends a selected quotation to an answer and saves it. Although the picker displays its card and source, the inserted attribution is only “voice of customer.” Preserve the actual source URL and context yourself; a generic attribution is not traceable evidence. Editing a card's source/title does not immediately rebuild the flattened vault, so check that attribution remains current.

The printable brief shows selected avatar, idea, problem, offer, stack, distribution, Dream 100, copy, persuasion, launch and later-stage decisions, plus up to the first three vault quotes. “One-page” is an aspiration; length depends on answers. It omits some scores, CTA, tool readiness and diagnostic inputs and is not a full backup. JSON exports generatedAt, complete working state and gate IDs/numbers/names/verdicts; the file has no matching JSON-import workflow. Preserve the export with its source version. Submit the field answers, evidence log, corrected interpretation of scores, decision record, next test and full export, not only a GO badge.

Clickable research starting points

Reddit, Google Trends, Google News, YouTube, X, TikTok, Quora, Indeed, Flippa, and Indie Hackers are starting points named by the tool. Add the exact supporting result URLs to your own record; a homepage is not evidence for a market claim.

Named research and delivery resources

Google Trends, Reddit, Quora, YouTube, LinkedIn, TikTok. These are official service starting points, not supporting research results or a claim that access is free. Preserve the exact article, report, campaign or product URL used for each conclusion. Specific missing source assets remain unavailable.

Read the assigned RISER-MVO -PAINONSOCIAL TO MVO-NETFILY.04.30.26.html source

Market Research and Offer Validation: Complete Workbook 2 With Evidence

What completion means

This workbook contains six sections, seven exercises and five final checks. It provides blank spaces and comparison tables, not a completed market study. Its congratulatory “fully validated offer” line is too strong if supported only by checked boxes. In this lesson you will fill each section with evidence, record what remains uncertain and decide what test should happen next. Examples and measurement advice below are authored RISER instruction.

Section 1 — Define research goals and niche scope

Exercise 1 asks three questions: what problem does your offer solve, who is the target audience—including demographics, interests and pain points—and what makes the offer unique? Write a concrete task or problem before describing the product. Explain the audience using relevant needs and context; avoid assuming everyone in a demographic shares the same problem. State the proposed difference in a way that can be checked against alternatives.

Section 2 — Analyze demand

Exercise 2 asks you to search the niche in Google Trends, list three trends found on Statista or IBISWorld, and identify discussions on Reddit, Quora or Facebook Groups. Record the query, geography, date range, source URL and what each observation actually supports. A trend is not a count of paying buyers, and a community thread is not a representative market survey. Leave unavailable reports explicit rather than inventing their results.

Section 3 — Compare competitors and alternatives

Exercise 3 provides three competitor rows with four columns: Competitor Name, Website/Platform, Offer Overview, and Strengths & Weaknesses. Put dated evidence behind each assessment and include indirect alternatives where relevant. Exercise 4 is a separate SWOT table with rows Strengths, Weaknesses, Opportunities and Threats and columns Your Business, Competitor 1 and Competitor 2. Preserve that different comparison width; the third competitor belongs in the first table even though the SWOT template compares only two. Strengths and weaknesses describe current capabilities; opportunities and threats concern the surrounding situation. The complete blank tables remain available in the appendix.

Section 4 — Test audience engagement

Exercise 5 asks for the lead magnet or sign-up incentive, the first week's sign-ups or interactions, and a small ad test's impressions, clicks and conversions. Specify the event and time window so “interaction” and “conversion” have stable meanings. Count impressions separately from people, clicks separately from leads, and sign-ups separately from purchases. If an authorized test is later run, record its budget and audience alongside the workbook metrics so results have context. No ad spend or campaign launch is performed by completing this lesson.

Section 5 — Learn from an MVP

Exercise 6 asks for the simplest testable offer, the beta testers and key early-user feedback. Choose a small version that tests the main promised outcome. Explain why those testers resemble the intended audience, what they tried, what they completed and where they struggled. Preserve negative and mixed feedback. A prototype and a friendly compliment are weaker evidence than observed use and a clear willingness to adopt or pay under realistic conditions.

Section 6 — Make the next launch decision

Exercise 7 asks for a marketability rating from 1 to 10, adjustments before launch and next steps for launching and marketing. The source provides no scoring formula or threshold. Treat the number as a subjective assessment and write the reasoning, evidence gaps and reviewer alongside it. Do not reverse-engineer a supposedly official scoring system. List concrete adjustments and an owner for the next test; a written launch plan is not a launched or validated business.

Review all five final checks

For market demand, attach the research that supports the conclusion. For competitor analysis and USP, complete both tables and explain the difference the audience values. For lead magnet and engagement testing, record actual observations or mark the test not yet run. For the MVP, show the build and collected feedback. For go-to-market readiness, identify the audience, message, delivery and measurement plan. A check without evidence remains incomplete.

Connect validation to direct marketing

Use ClickFunnels value-ladder education to consider whether the lead magnet prepares a person for the next useful offer. Use Acquisition.com training as an additional lens on offer value and delivery. Neither framework replaces customer evidence. Your final deliverable is the filled workbook, linked sources, explicit missing tests and a reasoned proceed, revise or stop decision—not a guaranteed winning offer.

Assigned source links

D0299 original source 1

Workbook #2
Market Research & Offer Validation Workbook
📌 Section 1: Define Research Goals & Niche Scope
📝 Exercise 1: Define Your Niche & Audience
What problem does your offer solve?

Who is your target audience (demographics, interests, pain points)?

What makes your offer unique?


📌 Section 2: Conduct Market Demand Analysis
📝 Exercise 2: Research Industry Trends
Search your niche in Google Trends and record the results:

List top 3 trends found on Statista or IBISWorld:



Identify discussions in Reddit, Quora, or Facebook Groups:


📌 Section 3: Competitor Landscape Analysis
📝 Exercise 3: Identify Key Competitors
Competitor Name
Website/Platform
Offer Overview
Strengths & Weaknesses
1.



2.



3.



📝 Exercise 4: SWOT Analysis
Category
Your Business
Competitor 1
Competitor 2
Strengths



Weaknesses



Opportunities



Threats




📌 Section 4: Validate Offer with Audience Engagement
📝 Exercise 5: Pre-Validation Methods
Describe your lead magnet or sign-up incentive:

How many sign-ups or interactions were received in the first week?

Run a small ad test and record engagement metrics:
Impressions: ______ Clicks: ______ Conversions: ______

📌 Section 5: Minimum Viable Product (MVP) Testing
📝 Exercise 6: Develop Your MVP
What is the simplest version of your offer that can be tested?

Who are your beta testers?

Key feedback from early users:


📌 Section 6: Final Validation & Launch Strategy
📝 Exercise 7: Marketability Score & Go-To-Market Plan
Based on research, rate your offer’s marketability (1-10): ______
Adjustments needed before launch:

Next steps for launching and marketing:


📌 Final Review & Checklist
✅ Validation Checklist
🔲 Market demand is validated with research and data. 🔲 Competitor analysis is completed and USP is defined. 🔲 Lead magnet and audience engagement tested. 🔲 MVP has been built and feedback collected. 🔲 Go-to-market plan is structured and ready for launch.
🚀 Congratulations! You now have a fully validated offer backed by data-driven research. 🚀

---
source_type: "Google Doc"
source_url: "https://docs.google.com/document/d/1a6nHOQVm7cxFSKIFI87DD38_dt1x6E0upmaiXX3tUUU/edit?usp=drivesdk"
drive_file_id: "1a6nHOQVm7cxFSKIFI87DD38_dt1x6E0upmaiXX3tUUU"
created: "2025-02-06T14:33:53.812Z"
modified: "2026-06-04T16:47:46.546Z"
---

# Workbook #2

Workbook #2
Market Research & Offer Validation Workbook
📌 Section 1: Define Research Goals & Niche Scope
📝 Exercise 1: Define Your Niche & Audience
* What problem does your offer solve?
________________
   * * Who is your target audience (demographics, interests, pain points)?
________________
   * * What makes your offer unique?
________________
   * ________________


📌 Section 2: Conduct Market Demand Analysis
📝 Exercise 2: Research Industry Trends
* Search your niche in Google Trends and record the results:
________________
   * * List top 3 trends found on Statista or IBISWorld:
________________
   * ________________
   * ________________
   * * Identify discussions in Reddit, Quora, or Facebook Groups:
________________
   * ________________


📌 Section 3: Competitor Landscape Analysis
📝 Exercise 3: Identify Key Competitors
Competitor Name
	Website/Platform
	Offer Overview
	Strengths & Weaknesses
	1.
	

	

	

	2.
	

	

	

	3.
	

	

	

	📝 Exercise 4: SWOT Analysis
Category
	Your Business
	Competitor 1
	Competitor 2
	Strengths
	

	

	

	Weaknesses
	

	

	

	Opportunities
	

	

	

	Threats
	

	

	

	________________


📌 Section 4: Validate Offer with Audience Engagement
📝 Exercise 5: Pre-Validation Methods
* Describe your lead magnet or sign-up incentive:
________________
   * * How many sign-ups or interactions were received in the first week?
________________
   * * Run a small ad test and record engagement metrics:
   * Impressions: ______ Clicks: ______ Conversions: ______
________________


📌 Section 5: Minimum Viable Product (MVP) Testing
📝 Exercise 6: Develop Your MVP
* What is the simplest version of your offer that can be tested?
________________
   * * Who are your beta testers?
________________
   * * Key feedback from early users:
________________
   * ________________


📌 Section 6: Final Validation & Launch Strategy
📝 Exercise 7: Marketability Score & Go-To-Market Plan
* Based on research, rate your offer’s marketability (1-10): ______
* Adjustments needed before launch:
________________
   * * Next steps for launching and marketing:
________________
   * ________________


📌 Final Review & Checklist
✅ Validation Checklist
🔲 Market demand is validated with research and data. 🔲 Competitor analysis is completed and USP is defined. 🔲 Lead magnet and audience engagement tested. 🔲 MVP has been built and feedback collected. 🔲 Go-to-market plan is structured and ready for launch.
🚀 Congratulations! You now have a fully validated offer backed by data-driven research. 🚀

Bootcamp Day 2: Define One Core Problem From Research

What you will produce

The source's Day 2 objective is a clear problem statement grounded in the audience's language. It asks for at least ten recurring problems researched across at least three platforms, narrowed to one core statement and saved in a Day 2 workbook tab. These are the source's exercise requirements, not statistical proof of market demand. Day numbers and legacy bootcamp context do not change this lesson's spreadsheet assignment.

1. Start the validation record

The first action is to use a “Validation Results Template.” The native document names a download but supplies no hyperlink for that template. Keep the missing asset explicit. For an authored working alternative, make a table with platform, date, source URL, customer wording, problem, consequence and uncertainty. This table is a RISER exercise, not the recovered original template. Keep each observation traceable so ten rows do not accidentally represent the same copied discussion.

2. Discover problems in discussions and search

The source links Reddit Search, Quora, AnswerThePublic and Google. It suggests Reddit's Top/This Year filters, followed questions on Quora and searches beginning “Why can't I…” or “How do I fix…” plus the niche. Use available controls and record the time range; interface labels and ranking methods may change. Autocomplete or generated questions are research leads, not verified customer quotations or a representative sample of buyers.

3. Inspect marketplace frustrations

The source proposes reading two- and three-star Amazon reviews, critical Etsy reviews and disappointed Udemy course reviews. Its native links point to Amazon Best Sellers, Etsy's linked category destination and Udemy's course catalog, not directly to the relevant reviews. Find the actual product or course review before citing a complaint. Keep its context and date. Reviews can reveal delivery gaps, but deliberately selected negative reviews do not establish the prevalence of a problem among all customers.

4. Write the core problem statement

Use the source structure: “My audience struggles with ______ because ______, and it costs them ______.” The audience identifies whom you serve, the struggle identifies the task, the cause is a hypothesis to verify and the cost identifies a documented consequence. Do not add an unmeasured dollar amount to make the problem look more valuable.

The source's example describes busy moms struggling with meal planning while juggling jobs and children, with costs in time, stress and takeout spending. It is an illustrative statement, not research proving that all mothers have the same needs. As an authored exercise, write a version for your selected audience and mark which words are observed versus inferred.

Keep the motivational claims in proportion

The document says problem clarity can prevent running out of content, offers or demand, and uses mind-reading, irresistible-offer and unstoppable language. These are motivational claims, not guarantees. It attributes quotations to Alex Hormozi and Dan Kennedy, but supplies no original citation; this review did not authenticate the exact wording and attribution. Preserve them in the source appendix without presenting them as verified quotations. The useful lesson is to understand a consequential problem and communicate it accurately, not to assume stronger pain language guarantees sales.

Review all deliverables before Day 3

Check that you researched at least three platforms, documented at least ten problems, chose one core problem statement and saved it in the intended Day 2 workbook location. Explain why the selected problem matters, which evidence challenges it and what needs validation next. The workbook itself is not supplied by this excerpt. No ad, interview request, marketplace interaction or campaign is launched by completing this lesson.

Connect the problem to an offer

ClickFunnels' problem-to-pitch guide is an additional resource for explaining a problem, solution and next action. Acquisition.com training provides separate offer education. Use these lenses to check whether the proposed solution can deliver the desired outcome; neither replaces the evidence bank or validates the source's quotations.

Assigned source links

D0302 original source 1

Perfect — let’s build Day 2 in the exact same client-facing, Riser Nation bootcamp style with expert hacks and clickable resources.

📘 RISER Nation 7-Day Bootcamp
Day 2 – Identifying & Defining the Core Problem

🎯 Objective
Today is about understanding the pain that your niche audience feels every day.
People don’t buy products. They buy solutions to problems.

If you can clearly define their problem in their own words, you’ll never run out of content, offers, or demand.

By the end of Day 2, you’ll have a clear problem statement that drives your business.

🔑 Why It Matters
Alex Hormozi says: “The bigger the problem, the bigger the paycheck.”
 If you get this wrong, you’ll waste energy solving things no one cares about. If you get this right, your audience will feel like you’re reading their mind.

🛠️ Action Steps
Use the Validation Results Template

Download here: Validation Results Template

Fill in what problems show up across platforms for your niche.

Discover Problems in Real-Time

Reddit Search → look up your niche, filter by “Top” and “This Year” to see recurring issues.

Quora → type in your niche, study the most-followed questions.

AnswerThePublic → pull problem-focused questions.

Google Autocomplete → type “Why can’t I…” or “How do I fix…” + your niche.

Marketplace Pain Checks

Amazon Reviews → read the 2–3 star reviews in your niche. These reveal frustrations.

Etsy Negative Reviews → look at “critical” reviews to see what buyers hated.

Udemy Course Reviews → see where students felt let down.

Craft Your Problem Statement

Write:
 “My audience struggles with ______ because ______, and it costs them ______.”

Example: “Busy moms struggle with meal planning because they’re juggling jobs and kids, and it costs them time, stress, and money on takeout.”


📦 Deliverable for Day 2
By the end of today, you must:
 ✅ Document at least 10 recurring problems your niche faces
 ✅ Narrow down to 1 Core Problem Statement
 ✅ Save it in your workbook (Day 2 tab)

💡 Pro Tip (from Dan Kennedy)
“The person who can describe the problem better than the prospect can is the person they believe has the solution.”
 → Translation: Use their language, not yours. Mirror their pain.

✅ Checkpoint: Are You Ready for Day 3?
Did you research across at least 3 platforms (Reddit, Amazon, Quora, etc.)?

Did you collect a minimum of 10 problems?

Did you choose one Core Problem Statement?

If yes → you’re ready to move on.

🌟 Riser Nation Motivation
Yesterday you chose your battlefield. Today you discovered the enemy — the problem your people fight every day. From this point forward, you carry their pain on your shoulders. That’s how you’ll create offers they can’t resist. You’re no longer guessing. You’re listening. And that makes you unstoppable.

---
source_type: "Google Doc"
source_url: "https://docs.google.com/document/d/1kSGEzrEkyUzw-o4dvymmcmZXviUU3TWdcePuKhi37s8/edit?usp=drivesdk"
drive_file_id: "1kSGEzrEkyUzw-o4dvymmcmZXviUU3TWdcePuKhi37s8"
created: "2025-10-07T22:40:27.107Z"
modified: "2026-06-04T15:03:44.884Z"
---

# CNX.1.7.2 – Bootcamp_Day2_Defining_The_Core_Problem.docx

Perfect — let’s build Day 2 in the exact same client-facing, Riser Nation bootcamp style with expert hacks and clickable resources.
________________


📘 RISER Nation 7-Day Bootcamp
Day 2 – Identifying & Defining the Core Problem
________________


🎯 Objective
Today is about understanding the pain that your niche audience feels every day.
* People don’t buy products. They buy solutions to problems.

* If you can clearly define their problem in their own words, you’ll never run out of content, offers, or demand.

By the end of Day 2, you’ll have a clear problem statement that drives your business.
________________


🔑 Why It Matters
Alex Hormozi says: “The bigger the problem, the bigger the paycheck.”
 If you get this wrong, you’ll waste energy solving things no one cares about. If you get this right, your audience will feel like you’re reading their mind.
________________


🛠️ Action Steps
   1. Use the Validation Results Template

      * Download here: Validation Results Template

      * Fill in what problems show up across platforms for your niche.

         2. Discover Problems in Real-Time

            * Reddit Search → look up your niche, filter by “Top” and “This Year” to see recurring issues.

            * Quora → type in your niche, study the most-followed questions.

            * AnswerThePublic → pull problem-focused questions.

            * Google Autocomplete → type “Why can’t I…” or “How do I fix…” + your niche.

               3. Marketplace Pain Checks

                  * Amazon Reviews → read the 2–3 star reviews in your niche. These reveal frustrations.

                  * Etsy Negative Reviews → look at “critical” reviews to see what buyers hated.

                  * Udemy Course Reviews → see where students felt let down.

                     4. Craft Your Problem Statement

                        * Write:
“My audience struggles with ______ because ______, and it costs them ______.”

                        * Example: “Busy moms struggle with meal planning because they’re juggling jobs and kids, and it costs them time, stress, and money on takeout.”

________________


📦 Deliverable for Day 2
By the end of today, you must:
✅ Document at least 10 recurring problems your niche faces
✅ Narrow down to 1 Core Problem Statement
 ✅ Save it in your workbook (Day 2 tab)
________________


💡 Pro Tip (from Dan Kennedy)
“The person who can describe the problem better than the prospect can is the person they believe has the solution.”
→ Translation: Use their language, not yours. Mirror their pain.
________________


✅ Checkpoint: Are You Ready for Day 3?
                           * Did you research across at least 3 platforms (Reddit, Amazon, Quora, etc.)?

                           * Did you collect a minimum of 10 problems?

                           * Did you choose one Core Problem Statement?

If yes → you’re ready to move on.
________________


🌟 Riser Nation Motivation
Yesterday you chose your battlefield. Today you discovered the enemy — the problem your people fight every day. From this point forward, you carry their pain on your shoulders. That’s how you’ll create offers they can’t resist. You’re no longer guessing. You’re listening. And that makes you unstoppable.
________________

Build useful bonuses and a defensible value stack

RISER NATION CORP — IF YOU AREN'T BUILDING, YOU ARE DESTROYING

Lesson outcome

Create a core-and-bonus table, five offer angles and a free entry resource that connect to the paid outcome. The assigned source is labeled Module 8, with a later Module 9 platform handoff. Those legacy labels do not change this document's current spreadsheet lesson assignments.

Begin with the outcome and four levers

An offer's appeal depends on more than its files. The source uses Hormozi, Brunson, Kennedy and a RISER construction metaphor to emphasize outcomes, presentation, offer strength and useful additions. Its attributed slogans are not verified verbatim quotations. Do not teach that an offer or funnel becomes impossible to fail.

Use Hormozi's value equation: dream outcome multiplied by perceived likelihood of achievement, divided by time delay multiplied by effort and sacrifice. A bonus can shorten a step, simplify work or provide evidence and support that help someone judge the likelihood of success. Reduced risk is a design consideration here, not a fifth variable inserted into that formula. The source's ten-times-more-valuable objective is a design aspiration, not a guaranteed valuation.

Build the stack with names, descriptions and supported values

List the core and each bonus separately, with a useful name, an explanation of what the buyer receives and a defensible price or valuation basis. The chapter's example is a 90-Day Niche Mastery System at $997, an Avatar Clarity Worksheet at $97, Plug & Play Funnel Templates at $497 and a Private Riser Nation Mastermind at $997. These add to $2,588, compared with an example selling price of $997. These numbers are illustrative, not verified RISER current prices or evidence of realized customer value.

Explain how each component helps the promised outcome. Avoid double-counting something already included in the core or representing an invented list price as a normal selling price. A side-by-side comparison can show the components, burdens removed and limitations. This applies the source's Brunson presentation theme without making sheer bonus quantity the measure of quality.

Place the MIFGE before the paid offer

The source expands MIFGE as Most Incredible Free Gift Ever. Its role is to preview the transformation and make a relevant paid next step understandable. Its example is a free Funnel Cheat Sheet leading to a paid Funnel Playbook plus Templates. The free resource should solve a bounded problem on its own and explain what additional help the paid product provides. A recipient remains free to stop there; the gift creates no purchase obligation. No finished gift is attached to this source.

Develop all five angles

For scarcity, describe actual seat capacity or a genuine bonus expiration. For authority, use supported credentials, accurate featured-in references or authentic social proof. For speed, name a measured deliverable and realistic timing; the source's “results in seven days” is example copy, not evidence. For safety, explain actual conditions and remedies; the examples of a 30-day guarantee or paying only after profit require defined, feasible terms. For community, state what access and participation actually include rather than promising belonging or outcomes.

These angles should answer different buyer questions about one consistent offer. Do not use a different angle to conceal a material limitation or turn a hypothetical guarantee into a current policy.

Run the bonus creation SOP

Brainstorm five possible bonuses. Check each against time, effort and risk: which obstacle does it address, and is it usable by this buyer? Assign a market value only when a reasonable basis exists; otherwise describe usefulness without an unsupported dollar claim. Arrange the retained components on the offer page in a sequence that shows how they support delivery.

The source's pro tips ask whether a bonus could be worth buying on its own, recommend showing value with comparisons, and suggest shifting a defined risk toward the provider. Treat these as source-attributed advice, not authenticated quotations or a demand to assume unlimited risk. RISER's house metaphor describes the core as foundation and bonuses as custom finishes. A finish cannot repair a broken foundation: fix the core delivery before adding extras.

Complete the four deliverables and checkpoint

Prepare the Value Stack Table with core, bonuses and total. Write the scarcity, authority, speed, safety and community angles. Finalize a proposed MIFGE entry point. Add the work to the Offer Blueprint Worksheet. The source names that worksheet but does not provide its actual file or a completed blueprint; record that dependency rather than claiming submission.

Before the legacy Module 9 handoff, check that three to five retained bonuses reduce a real burden, that totals are arithmetically correct and supported, and that the angles communicate an understandable exchange. Replace the subjective “stupid good deal” test with buyer feedback on usefulness and clarity. The next source topic is platform and delivery systems, naming ClickFunnels, Circle, Kajabi and WordPress. This lesson does not select a platform, create an account or configure delivery.

Sources and resources

- Complete assigned bonuses and value-stack source. - Acquisition.com value-equation checklist. - ClickFunnels value-ladder explanation. - Named platform resources: ClickFunnels, Circle, Kajabi and WordPress. - RISER NATION CORP.

- FTC advertising basics: supporting guidance on truthful, evidence-based claims.

Assigned source links

D0406 original source 1

Module 8 – Bonuses, Value Stacks & Irresistible Angles
(Turn a Good Offer Into a No-Brainer with Strategic Stacking)
Objective
By the end of this module, you’ll know how to engineer bonuses, stack value, and frame angles so your offer feels 10x more valuable than its price tag.

Why This Matters
Alex Hormozi: People don’t buy products—they buy outcomes multiplied by value and divided by risk.

Russell Brunson: “Stack the cool.” Every bonus must increase excitement and push the offer into no-brainer territory.

Dan Kennedy: “Your offer is the strongest sales copy you’ll ever write.” Get the offer right, and the rest is easy.

Riser Nation: Bonuses aren’t fluff—they’re the extra steel beams that make your funnel impossible to collapse.


Step 1 – Hormozi’s Value Equation
Value = (Dream Outcome × Perceived Likelihood of Achievement) ÷ (Time Delay × Effort & Sacrifice).
Add bonuses that speed results (reduce time).

Add bonuses that simplify the process (reduce effort).

Add bonuses that guarantee or reassure (reduce risk).


Step 2 – Building the Value Stack (Brunson’s Model)
Every bonus is listed with a name, description, and price tag.
 Example:
Core Program: 90-Day Niche Mastery System – Value: $997

Bonus #1: Avatar Clarity Worksheet – Value: $97

Bonus #2: Plug & Play Funnel Templates – Value: $497

Bonus #3: Private Riser Nation Mastermind – Value: $997
 Total Value = $2,588 → Today’s Price = $997


Step 3 – The MIFGE Placement
Your Most Incredible Free Gift Ever is the doorway to the stack.
It should preview the transformation.

It tees up your paid offer as the logical next step.

Example: Free “Funnel Cheat Sheet” → paid Funnel Playbook + Templates.


Step 4 – Crafting Irresistible Angles
Scarcity Angle: Limited seats, expiring bonuses.

Authority Angle: “As featured in…” or social proof.

Speed Angle: “Get results in 7 days…”

Safety Angle: 30-day guarantee, “don’t pay until you profit.”

Community Angle: Access to others on the same journey.


Step 5 – Bonus Creation SOP
Brainstorm 5 possible bonuses.

Check: Does it reduce time, effort, or risk?

Assign each a “market value.”

Stack them into your offer page.


Deliverables for Module 8
✅ Draft your Value Stack Table (Core + Bonuses + Total Value).
 ✅ Write out your Irresistible Angles (Scarcity, Authority, Speed, Safety, Community).
 ✅ Finalize your MIFGE as the entry point.
 ✅ Add to your Offer Blueprint Worksheet.

Pro Tips & Expert Secrets
Hormozi: If your bonuses aren’t worth paying for by themselves, don’t use them.

Brunson: Don’t just tell—show the value. Use side-by-side comparisons.

Kennedy: “Risk reversal” is the ultimate bonus—make the risk yours, not theirs.

Riser Nation: Think of your offer like building a house: the core offer is the foundation, but the bonuses are the custom finishes that make people fall in love.


Checkpoint Before Module 9
Do you have at least 3–5 bonuses that reduce time/effort/risk?

Have you calculated the total stack value?

Do your angles make your offer feel like a “stupid good deal”?

If yes → you’re ready for Module 9: Platform & Delivery Systems — where we decide exactly where and how your offers live (ClickFunnels, Circle, Kajabi, WordPress, etc.).

---
source_type: "Google Doc"
source_url: "https://docs.google.com/document/d/1g30DnBYBBqO1MCYQeXl6cS8lFaFdgiGO8bCHfSSelu4/edit?usp=drivesdk"
drive_file_id: "1g30DnBYBBqO1MCYQeXl6cS8lFaFdgiGO8bCHfSSelu4"
created: "2025-10-08T01:04:52.589Z"
modified: "2026-06-04T14:43:20.180Z"
---

# CNX.3.11.8 – Offer_Dev_Module_8_Bonuses_Value_Stacks_And_Irresistible_Angles.docx

Module 8 – Bonuses, Value Stacks & Irresistible Angles
(Turn a Good Offer Into a No-Brainer with Strategic Stacking)
Objective
By the end of this module, you’ll know how to engineer bonuses, stack value, and frame angles so your offer feels 10x more valuable than its price tag.
________________


Why This Matters
* Alex Hormozi: People don’t buy products—they buy outcomes multiplied by value and divided by risk.

* Russell Brunson: “Stack the cool.” Every bonus must increase excitement and push the offer into no-brainer territory.

* Dan Kennedy: “Your offer is the strongest sales copy you’ll ever write.” Get the offer right, and the rest is easy.

* Riser Nation: Bonuses aren’t fluff—they’re the extra steel beams that make your funnel impossible to collapse.

________________


Step 1 – Hormozi’s Value Equation
Value = (Dream Outcome × Perceived Likelihood of Achievement) ÷ (Time Delay × Effort & Sacrifice).
   * Add bonuses that speed results (reduce time).

   * Add bonuses that simplify the process (reduce effort).

   * Add bonuses that guarantee or reassure (reduce risk).

________________


Step 2 – Building the Value Stack (Brunson’s Model)
Every bonus is listed with a name, description, and price tag.
 Example:
      * Core Program: 90-Day Niche Mastery System – Value: $997

      * Bonus #1: Avatar Clarity Worksheet – Value: $97

      * Bonus #2: Plug & Play Funnel Templates – Value: $497

      * Bonus #3: Private Riser Nation Mastermind – Value: $997
Total Value = $2,588 → Today’s Price = $997

________________


Step 3 – The MIFGE Placement
Your Most Incredible Free Gift Ever is the doorway to the stack.
         * It should preview the transformation.

         * It tees up your paid offer as the logical next step.

         * Example: Free “Funnel Cheat Sheet” → paid Funnel Playbook + Templates.

________________


Step 4 – Crafting Irresistible Angles
            * Scarcity Angle: Limited seats, expiring bonuses.

            * Authority Angle: “As featured in…” or social proof.

            * Speed Angle: “Get results in 7 days…”

            * Safety Angle: 30-day guarantee, “don’t pay until you profit.”

            * Community Angle: Access to others on the same journey.

________________


Step 5 – Bonus Creation SOP
               * Brainstorm 5 possible bonuses.

               * Check: Does it reduce time, effort, or risk?

               * Assign each a “market value.”

               * Stack them into your offer page.

________________


Deliverables for Module 8
✅ Draft your Value Stack Table (Core + Bonuses + Total Value).
✅ Write out your Irresistible Angles (Scarcity, Authority, Speed, Safety, Community).
✅ Finalize your MIFGE as the entry point.
✅ Add to your Offer Blueprint Worksheet.
________________


Pro Tips & Expert Secrets
                  * Hormozi: If your bonuses aren’t worth paying for by themselves, don’t use them.

                  * Brunson: Don’t just tell—show the value. Use side-by-side comparisons.

                  * Kennedy: “Risk reversal” is the ultimate bonus—make the risk yours, not theirs.

                  * Riser Nation: Think of your offer like building a house: the core offer is the foundation, but the bonuses are the custom finishes that make people fall in love.

________________


Checkpoint Before Module 9
                     * Do you have at least 3–5 bonuses that reduce time/effort/risk?

                     * Have you calculated the total stack value?

                     * Do your angles make your offer feel like a “stupid good deal”?

If yes → you’re ready for Module 9: Platform & Delivery Systems — where we decide exactly where and how your offers live (ClickFunnels, Circle, Kajabi, WordPress, etc.).
________________

Distinguish DIY, DWY, DFY and licensed delivery

RISER NATION CORP — IF YOU AREN'T BUILDING, YOU ARE DESTROYING

Lesson outcome

Explain the four delivery tiers named in the assigned offer-wall outline and identify what remains undefined. This is a short scope list, not a complete product catalog, contract or license grant.

DIY, commonly do it yourself, lists templates, compilers and a Control Tower. The source does not define those compilers or supply a Control Tower system. Treat this as a tools-led proposal in which the buyer would perform the implementation; do not claim the assets are already accessible.

DWY, commonly done with you, lists setup, branch priority and iteration reviews. It suggests assisted implementation, but branch priority is not defined, and no review frequency, response time or division of work is specified. Those terms need clarification before a buyer can assess the service.

DFY, commonly done for you, says the provider builds a site, a content batch, a course module and reporting. All four deliverable types belong in the scope explanation. The source gives no quantities beyond those categories, acceptance criteria, revision limits, delivery schedule or ongoing maintenance promise. It is not authorization to purchase or commission those services.

License lists a white-label operating system, updates and certification. These labels describe an intended tier; they do not supply rights to rebrand, redistribute or sublicense anything. No actual license, IP ownership evidence, update period or certification standard accompanies the outline. Do not imply external accreditation.

Compare the exchange

As authored practice, compare each tier's buyer work, provider work, included assets, support and unresolved terms. Use Hormozi's effort, time and likelihood questions to examine the tradeoff, and a Brunson-style value ladder to explain an appropriate next step. A more assisted tier is not automatically better for every buyer. The original contains no pricing, profitability model or validated ascension path.

Submit a four-tier comparison that preserves every listed component and flags undefined terms. Keep the full original in the appendix; do not fill unknown scope with invented product specifications.

Sources and resources

- Complete assigned offer-wall outline. - Acquisition.com value-equation checklist. - ClickFunnels value-ladder reference and RISER NATION CORP.

Assigned source links

D0419 original source 1

01_OFFER_WALL — DIY / DWY / DFY / License

DIY
- Templates + compilers + Control Tower

DWY
- Setup + branch priority + iteration reviews

DFY
- We build site + content batch + course module + reporting

License
- White-label OS + updates + certification

---
source_type: "Google Doc"
source_url: "https://docs.google.com/document/d/1qhZA9rRw_kDiOxk3F3E40BHi8fwQfTLUt5ovuxbbCuc/edit?usp=drivesdk"
drive_file_id: "1qhZA9rRw_kDiOxk3F3E40BHi8fwQfTLUt5ovuxbbCuc"
created: "2025-12-20T16:42:10.134Z"
modified: "2026-06-04T15:53:30.981Z"
---

# 01_OFFER_WALL__DIY_DWY_DFY_License

01_OFFER_WALL — DIY / DWY / DFY / License


DIY
- Templates + compilers + Control Tower


DWY
- Setup + branch priority + iteration reviews


DFY
- We build site + content batch + course module + reporting


License
- White-label OS + updates + certification

Build three genuinely different offer variants

RISER NATION CORP — IF YOU AREN'T BUILDING, YOU ARE DESTROYING

Lesson outcome and outline

Decompose one mechanism into named deliverables, assemble three distinct offer variants, compare their differences, test their names, and record a preliminary preference without treating it as final validation. The source calls this the M4.3 worksheet in a legacy course and the 6% Rule. Here that rule means producing three variants before committing; the source supplies no mathematical six-percent calculation.

Gather the three prerequisite artifacts

Open the Mechanism Decomposition Inventory, the M4.2 Value Equation Worksheet and the M4.1 Component Inventory. The first explains the work the mechanism contains. The second identifies strong, weak or fixed value variables. The third shows which offer components exist and which still need production. These names describe source prerequisites; missing files should remain explicit rather than be treated as completed work.

The source places the worksheet in a Build 8 Drive folder and names the c4_offer_decompositions database table and offer-decomposition-reviewer-v1.0.0.yaml structural reviewer. Those are proposed filing and review destinations, not evidence that an integration or reviewer has been deployed. The current spreadsheet continues to determine where this teaching appears.

Part one: decompose the mechanism before assembling offers

Create a separate 400–600-word Mechanism-Decomposition-[YourName]-[Date].md inventory. Begin with the mechanism's Method pillar from the source's C2 Hypothesis Document. Then name each deliverable so a buyer can evaluate it independently.

For each item, record its name, type, duration, delivery format and dependencies. The source's types are audit, template, live call, asynchronous review, reference pack, tracker, contract component or another explicitly described type. Duration can be expressed in hours or sessions. A dependency states which deliverable must come first. Do not hide prerequisite work inside an attractive output label.

The quality question is whether a buyer can explain what they will have when the item is finished. “Discuss your workflow” describes an activity; an authored alternative such as “a reviewed workflow map showing the three agreed handoffs” identifies an inspectable output. That example is added for this lesson, not supplied in the original worksheet. The source suggests six to ten deliverables commonly emerge from a four-pillar mechanism, but provides no evidence that every mechanism should produce that count.

Part two: assemble variants A, B and C using all eight fields

Give each variant the same complete structure. First, enter a provisional name; the naming tests come later. Second, choose an engagement model—cohort, one-to-one, self-paced or hybrid—and write a one- or two-sentence rationale. Third, state the duration and whether participation begins synchronously on a start date or through rolling entry, again with a short rationale.

Fourth, select deliverables from the inventory. Mark what is included, what is excluded and what is available as an add-on. The source uses a check mark, cross and plus sign for those distinctions. A buyer should not have to purchase an undisclosed add-on to obtain the promised core result.

Fifth, record a price range rather than a final anchor. Position it against the observed pricing band as floor, mid-floor, median, mid-ceiling, ceiling or above ceiling. A single-number price is chosen in the later pricing activity. Sixth, identify the primary Value Equation weakness addressed—Dream Outcome, Perceived Likelihood, Time Delay, or Effort and Sacrifice—with an optional secondary target and a short explanation of how the design addresses it.

Seventh, describe buyer fit: the relevant interview subsegment, the approximate number of interviewees who match it out of the total, and the supporting interview references. Do not invent names or counts. Preserve appropriate confidentiality in learner-facing materials. Eighth, record the tradeoffs against each of the other two variants. Repeat all eight fields for B and C; their abbreviated source headings mean the same full structure is required, not that their explanations can be omitted.

Make the variants different on at least three axes

Compare engagement model, duration, deliverable density and price band. The source groups duration as short at two to four weeks, medium at five to eight weeks, and long at nine or more weeks. It groups density as high with all decomposed deliverables, medium with five or six, and low with three or four self-serve deliverables. Price bands use the observed floor, median and ceiling. These are worksheet categories, not universal market definitions.

Each pair of variants must differ on at least three of the four axes. A useful authored example is a three-week self-paced version with four selected deliverables near the observed floor, a six-week cohort with six deliverables near the median, and a ten-week one-to-one version with eight deliverables near the ceiling. It illustrates four differences; it does not establish buyer demand, a feasible outcome or appropriate prices. Confirm each version can still deliver its stated promise.

The source's matrix asks whether all three are distinct on an axis, then describes a minimum of three yes responses per variant. Those are not identical tests: pairwise difference can be satisfied even when an axis does not contain three unique values. Record the pairwise comparisons explicitly. If using the stricter all-three-distinct matrix as an additional local rule, label it as such instead of silently conflating the two tests.

Part three: check density and naming

Count the deliverables in A, B and C. The source first says more than eight should trigger a feature-stuffing review, while its final structural checklist says no variant may contain more than eight primary deliverables. Preserve that distinction: a review flag in one section becomes a hard submission limit in another. For this worksheet, document which items are primary, optional and excluded; do not bypass the limit by renaming a necessary deliverable a bonus. The decomposition inventory may contain six to ten items even when each selected variant contains no more than eight primary items.

More than eight items does not itself prove that an offer is padded. Inspect whether each item is needed for the outcome and whether additional features are compensating for weak demand or weak confidence in the result. The referenced Feature Stuffing Trap case is a separate asset; this worksheet supplies the warning, not the complete case.

Apply all five naming tests to every provisional name: searchable, specific, durable, pronounceable and ownable. In an authored review, searchable asks whether the intended audience can locate and distinguish it; specific asks whether it communicates something useful; durable asks whether it survives an anticipated change; pronounceable asks whether people can say and repeat it; and ownable asks whether there is a defensible identity and any rights questions requiring further review. These explanations operationalize the labels; the source does not provide a full legal clearance procedure. Passing a worksheet checkbox does not establish trademark rights. Rename any variant failing a test before the later pricing step.

Part four: record a preliminary lead and preserve uncertainty

The optional lead-variant note states the current preference, a one- or two-sentence reason, and what pricing or unit-economics evidence is needed before commitment. The source places formal selection at M4.8 and says the intervening pricing, anti-promise, guarantee and copy activities should test the variants. Keep the preference provisional rather than discarding the alternatives before they are examined.

Record the operator name, first-draft date, second-draft date after the proposed 48-hour cooling period, and total word count. The source targets 1,500–2,000 words total while also requiring 500–700 per variant; three times that individual range allows up to 2,100. To satisfy both stated limits, keep each variant within 500–700 and the combined total at or below 2,000. Treat the approximate 180 minutes of work separately from the elapsed cooling period; neither is a performance guarantee.

Review and handoff

The source's structural review expects exactly three variants, 500–700 words each, pairwise difference on at least three axes, no more than eight primary deliverables per variant, and five naming tests for each name. File the worksheet with the decomposition inventory and retain the original evidence links. Its proposed pass result unlocks M4.4, where pricing may be examined for at least one and preferably all three variants. That describes the legacy design, not a verified live system.

The authored Brunson/ClickFunnels connection is to make each offer understandable as a coherent promise and delivery package. The authored Hormozi/Acquisition.com connection is to change delivery in response to a real value obstacle, with evidence and viable fulfillment, instead of creating three cosmetic versions of the same offer. Finish by explaining why a particular buyer would reasonably prefer each variant and what evidence could disprove your explanation.

Clickable assigned source

- C4 Offer Variants Worksheet — original source

Preserve the complete worksheet and both original comparison tables in the lesson appendix, including its placeholders and conflicting checklist wording. This script teaches the available worksheet without inventing completed buyer research or deployed review automation.

Assigned source links

D0437 original source 1

# C4 Offer Variants Worksheet

**Purpose:** M4.3 deliverable. Produces three distinct reassembly variants of the Primary mechanism into offer form, honoring the 6% Rule commitment.
**Target length:** 1,500-2,000 words total (500-700 per variant)
**Time to complete:** ~180 minutes (with 48-hour cooling between first and second drafts)
**Filed to:** Build 8 Drive folder, `c4_offer_decompositions` Supabase table
**Reviewed by:** `offer-decomposition-reviewer-v1.0.0.yaml` (structural check)

---

## Before You Start

Three things must exist in Drive before this worksheet opens:

1. **Mechanism Decomposition Inventory** — your mechanism's Method pillar broken into named deliverables (produce this as a separate document at `Mechanism-Decomposition-[YourName]-[Date].md`)
2. **M4.2 Value Equation Worksheet** — identifies which variables are strong/weak/fixed
3. **M4.1 Component Inventory** — which offer components have material, which need production

Open all three alongside this worksheet. You will reference them repeatedly.

---

## Part 1 — Decomposition (completed before Part 2)

In your separate Mechanism Decomposition Inventory document (400-600 words), complete:

1. **Primary mechanism's Method pillar** (pasted from C2 Hypothesis Document)
2. **Decomposed deliverables** — each named, scoped such that a buyer could evaluate it in isolation
3. **Deliverable properties** — each with: name, type (audit / template / live call / async review / reference pack / tracker / contract component / other), duration (hours or session), delivery format, dependency (which other deliverables must come first)

**Quality test for each deliverable:** can a buyer reading the description answer "what will I have at the end of this?" If yes, it is a deliverable. If no, it is a delivery activity, not a deliverable. Fix before proceeding.

Typical count: 6-10 deliverables emerge from a well-structured 4-pillar mechanism.

---

## Part 2 — The Three Variants

Complete three variant sections below. Each variant must differ from the other two on **at least 3 of 4 axes**:

- **Engagement model** — cohort / 1:1 / self-paced / hybrid
- **Duration** — short (2-4 weeks) / medium (5-8 weeks) / long (9+ weeks)
- **Deliverable density** — high (all decomposed deliverables) / medium (5-6) / low (3-4 self-serve)
- **Price band** — floor / median / ceiling of the observed C3 range

---

### Variant A — [Variant placeholder name]

#### 1. Variant Name
[Placeholder name — 5-Test re-run happens at end of this worksheet]

#### 2. Engagement Model
[Cohort / 1:1 / Self-paced / Hybrid]

*Rationale (1-2 sentences):*

#### 3. Duration
[Weeks, with start-date cadence — synchronous vs rolling]

*Rationale (1-2 sentences):*

#### 4. Deliverables Included
Pull from your decomposition inventory. List included deliverables; note any excluded or available-as-add-on.

- ✓ [Deliverable 1]
- ✓ [Deliverable 2]
- ...
- ✗ [Deliverable X — excluded from this variant]
- + [Deliverable Y — available as add-on]

#### 5. Price Band Placeholder
$[X] - $[Y] range. (Single-number anchor is selected in M4.4; this is the band.)

*Position against observed C3 band:* [floor / mid-floor / median / mid-ceiling / ceiling / above ceiling]

#### 6. Value Equation Weakness Targeted
Which M4.2-identified weakness does this variant specifically address?

- **Primary target:** [Dream Outcome / Perceived Likelihood / Time Delay / Effort & Sacrifice]
- **Secondary target:** [optional]

*How this variant targets that weakness (1-2 sentences):*

#### 7. Buyer Fit
Which sub-segment of your C3 interview pool fits this variant best?

- **Target sub-segment:** [description]
- **Approximate # of C3 interviewees fitting this profile:** ___ of [total interviews]
- **Key interview citations:** Interview #__ (name), #__ (name)

#### 8. Known Tradeoffs
What does this variant sacrifice compared to Variants B and C?

- vs. Variant B: [tradeoff]
- vs. Variant C: [tradeoff]

---

### Variant B — [Variant placeholder name]

[Same 8-section structure as Variant A. Reminder: must differ from Variants A and C on at least 3 of 4 axes.]

#### 1. Variant Name
#### 2. Engagement Model
#### 3. Duration
#### 4. Deliverables Included
#### 5. Price Band Placeholder
#### 6. Value Equation Weakness Targeted
#### 7. Buyer Fit
#### 8. Known Tradeoffs

---

### Variant C — [Variant placeholder name]

[Same 8-section structure. Must differ from Variants A and B on at least 3 of 4 axes.]

#### 1. Variant Name
#### 2. Engagement Model
#### 3. Duration
#### 4. Deliverables Included
#### 5. Price Band Placeholder
#### 6. Value Equation Weakness Targeted
#### 7. Buyer Fit
#### 8. Known Tradeoffs

---

## Part 3 — Cross-Variant Comparison

### Axis Divergence Matrix

Confirm each variant differs from the other two on at least 3 of 4 axes:

| Axis | Variant A | Variant B | Variant C | All 3 distinct? |
|---|---|---|---|---|
| Engagement model | [] | [] | [] | ☐ Yes ☐ No |
| Duration | [] | [] | [] | ☐ Yes ☐ No |
| Deliverable density | [] | [] | [] | ☐ Yes ☐ No |
| Price band | [] | [] | [] | ☐ Yes ☐ No |

**Minimum 3 of 4 "Yes" per variant required.** If only 2 of 4, the variants are not sufficiently distinct — revise.

### Feature Stuffing Check

Count the deliverables in each variant:

- Variant A: ___ deliverables
- Variant B: ___ deliverables
- Variant C: ___ deliverables

**If any variant has > 8 deliverables, flag for review.** More than 8 typically indicates the Feature Stuffing Trap — deliverables added to compensate for weak numerator variables rather than to produce real value. See `07_Case-Studies-and-Examples/Case-Failure-The-Feature-Stuffing-Trap.md`.

### 5-Test Naming Re-Run

Apply the C2 5-Test Naming Filter to each variant's placeholder name:

| Test | Variant A | Variant B | Variant C |
|---|---|---|---|
| Searchable | ☐ ☐ | ☐ ☐ | ☐ ☐ |
| Specific | ☐ ☐ | ☐ ☐ | ☐ ☐ |
| Durable | ☐ ☐ | ☐ ☐ | ☐ ☐ |
| Pronounceable | ☐ ☐ | ☐ ☐ | ☐ ☐ |
| Ownable | ☐ ☐ | ☐ ☐ | ☐ ☐ |
| **All 5 pass?** | ☐ Y ☐ N | ☐ Y ☐ N | ☐ Y ☐ N |

Variants failing 1+ tests need renaming before M4.4.

---

## Part 4 — Preliminary Lead-Variant Note (optional but useful)

Formal variant selection is an M4.8 activity, but often M4.3 surfaces a preliminary lead. Note your current thinking (revisit at M4.8):

- **Current leaning toward:** Variant [A / B / C]
- **Why:** [1-2 sentences]
- **What I want to see at M4.4 before committing:** [pricing plausibility check, unit-economic viability, etc.]

Leave this section light. M4.4-M4.7 will pressure-test all three from different angles before M4.8 selects.

---

## Signature

**Operator name:** _____________________________
**Date of first draft:** _____________________________
**Date of second draft (after 48-hour cooling):** _____________________________
**Total word count (all three variants):** _______ (target 1,500-2,000)

---

## What Happens Next

The three-variant document is filed to Drive alongside the Mechanism Decomposition Inventory. Structural verification checks:

- Exactly 3 variants present, each 500-700 words
- Each variant differs on ≥ 3 of 4 axes from the other two
- No variant has > 8 primary deliverables
- 5-Test applied to each variant's name

On pass, M4.4 unlocks. Pricing is selected against at least one variant (typically all three, which often clarifies lead-variant selection).

---

*Last updated: April 24, 2026 · Version 2.0 · Referenced by M4.3*

# C4 Offer Variants Worksheet

**Purpose:** M4.3 deliverable. Produces three distinct reassembly variants of the Primary mechanism into offer form, honoring the 6% Rule commitment.
**Target length:** 1,500-2,000 words total (500-700 per variant)
**Time to complete:** ~180 minutes (with 48-hour cooling between first and second drafts)
**Filed to:** Build 8 Drive folder, `c4_offer_decompositions` Supabase table
**Reviewed by:** `offer-decomposition-reviewer-v1.0.0.yaml` (structural check)

---

## Before You Start

Three things must exist in Drive before this worksheet opens:

1. **Mechanism Decomposition Inventory** — your mechanism's Method pillar broken into named deliverables (produce this as a separate document at `Mechanism-Decomposition-[YourName]-[Date].md`)
2. **M4.2 Value Equation Worksheet** — identifies which variables are strong/weak/fixed
3. **M4.1 Component Inventory** — which offer components have material, which need production

Open all three alongside this worksheet. You will reference them repeatedly.

---

## Part 1 — Decomposition (completed before Part 2)

In your separate Mechanism Decomposition Inventory document (400-600 words), complete:

1. **Primary mechanism's Method pillar** (pasted from C2 Hypothesis Document)
2. **Decomposed deliverables** — each named, scoped such that a buyer could evaluate it in isolation
3. **Deliverable properties** — each with: name, type (audit / template / live call / async review / reference pack / tracker / contract component / other), duration (hours or session), delivery format, dependency (which other deliverables must come first)

**Quality test for each deliverable:** can a buyer reading the description answer "what will I have at the end of this?" If yes, it is a deliverable. If no, it is a delivery activity, not a deliverable. Fix before proceeding.

Typical count: 6-10 deliverables emerge from a well-structured 4-pillar mechanism.

---

## Part 2 — The Three Variants

Complete three variant sections below. Each variant must differ from the other two on **at least 3 of 4 axes**:

- **Engagement model** — cohort / 1:1 / self-paced / hybrid
- **Duration** — short (2-4 weeks) / medium (5-8 weeks) / long (9+ weeks)
- **Deliverable density** — high (all decomposed deliverables) / medium (5-6) / low (3-4 self-serve)
- **Price band** — floor / median / ceiling of the observed C3 range

---

### Variant A — [Variant placeholder name]

#### 1. Variant Name
[Placeholder name — 5-Test re-run happens at end of this worksheet]

#### 2. Engagement Model
[Cohort / 1:1 / Self-paced / Hybrid]

*Rationale (1-2 sentences):*

#### 3. Duration
[Weeks, with start-date cadence — synchronous vs rolling]

*Rationale (1-2 sentences):*

#### 4. Deliverables Included
Pull from your decomposition inventory. List included deliverables; note any excluded or available-as-add-on.

- ✓ [Deliverable 1]
- ✓ [Deliverable 2]
- ...
- ✗ [Deliverable X — excluded from this variant]
- + [Deliverable Y — available as add-on]

#### 5. Price Band Placeholder
$[X] - $[Y] range. (Single-number anchor is selected in M4.4; this is the band.)

*Position against observed C3 band:* [floor / mid-floor / median / mid-ceiling / ceiling / above ceiling]

#### 6. Value Equation Weakness Targeted
Which M4.2-identified weakness does this variant specifically address?

- **Primary target:** [Dream Outcome / Perceived Likelihood / Time Delay / Effort & Sacrifice]
- **Secondary target:** [optional]

*How this variant targets that weakness (1-2 sentences):*

#### 7. Buyer Fit
Which sub-segment of your C3 interview pool fits this variant best?

- **Target sub-segment:** [description]
- **Approximate # of C3 interviewees fitting this profile:** ___ of [total interviews]
- **Key interview citations:** Interview #__ (name), #__ (name)

#### 8. Known Tradeoffs
What does this variant sacrifice compared to Variants B and C?

- vs. Variant B: [tradeoff]
- vs. Variant C: [tradeoff]

---

### Variant B — [Variant placeholder name]

[Same 8-section structure as Variant A. Reminder: must differ from Variants A and C on at least 3 of 4 axes.]

#### 1. Variant Name
#### 2. Engagement Model
#### 3. Duration
#### 4. Deliverables Included
#### 5. Price Band Placeholder
#### 6. Value Equation Weakness Targeted
#### 7. Buyer Fit
#### 8. Known Tradeoffs

---

### Variant C — [Variant placeholder name]

[Same 8-section structure. Must differ from Variants A and B on at least 3 of 4 axes.]

#### 1. Variant Name
#### 2. Engagement Model
#### 3. Duration
#### 4. Deliverables Included
#### 5. Price Band Placeholder
#### 6. Value Equation Weakness Targeted
#### 7. Buyer Fit
#### 8. Known Tradeoffs

---

## Part 3 — Cross-Variant Comparison

### Axis Divergence Matrix

Confirm each variant differs from the other two on at least 3 of 4 axes:

| Axis | Variant A | Variant B | Variant C | All 3 distinct? |
|---|---|---|---|---|
| Engagement model | [] | [] | [] | ☐ Yes ☐ No |
| Duration | [] | [] | [] | ☐ Yes ☐ No |
| Deliverable density | [] | [] | [] | ☐ Yes ☐ No |
| Price band | [] | [] | [] | ☐ Yes ☐ No |

**Minimum 3 of 4 "Yes" per variant required.** If only 2 of 4, the variants are not sufficiently distinct — revise.

### Feature Stuffing Check

Count the deliverables in each variant:

- Variant A: ___ deliverables
- Variant B: ___ deliverables
- Variant C: ___ deliverables

**If any variant has > 8 deliverables, flag for review.** More than 8 typically indicates the Feature Stuffing Trap — deliverables added to compensate for weak numerator variables rather than to produce real value. See `07_Case-Studies-and-Examples/Case-Failure-The-Feature-Stuffing-Trap.md`.

### 5-Test Naming Re-Run

Apply the C2 5-Test Naming Filter to each variant's placeholder name:

| Test | Variant A | Variant B | Variant C |
|---|---|---|---|
| Searchable | ☐ ☐ | ☐ ☐ | ☐ ☐ |
| Specific | ☐ ☐ | ☐ ☐ | ☐ ☐ |
| Durable | ☐ ☐ | ☐ ☐ | ☐ ☐ |
| Pronounceable | ☐ ☐ | ☐ ☐ | ☐ ☐ |
| Ownable | ☐ ☐ | ☐ ☐ | ☐ ☐ |
| **All 5 pass?** | ☐ Y ☐ N | ☐ Y ☐ N | ☐ Y ☐ N |

Variants failing 1+ tests need renaming before M4.4.

---

## Part 4 — Preliminary Lead-Variant Note (optional but useful)

Formal variant selection is an M4.8 activity, but often M4.3 surfaces a preliminary lead. Note your current thinking (revisit at M4.8):

- **Current leaning toward:** Variant [A / B / C]
- **Why:** [1-2 sentences]
- **What I want to see at M4.4 before committing:** [pricing plausibility check, unit-economic viability, etc.]

Leave this section light. M4.4-M4.7 will pressure-test all three from different angles before M4.8 selects.

---

## Signature

**Operator name:** _____________________________
**Date of first draft:** _____________________________
**Date of second draft (after 48-hour cooling):** _____________________________
**Total word count (all three variants):** _______ (target 1,500-2,000)

---

## What Happens Next

The three-variant document is filed to Drive alongside the Mechanism Decomposition Inventory. Structural verification checks:

- Exactly 3 variants present, each 500-700 words
- Each variant differs on ≥ 3 of 4 axes from the other two
- No variant has > 8 primary deliverables
- 5-Test applied to each variant's name

On pass, M4.4 unlocks. Pricing is selected against at least one variant (typically all three, which often clarifies lead-variant selection).

---

*Last updated: April 24, 2026 · Version 2.0 · Referenced by M4.3*

Understand the six-part Grand Slam Offer curriculum

RISER NATION CORP — IF YOU AREN'T BUILDING, YOU ARE DESTROYING

Lesson outcome and the limits of this overview

Explain the purpose and sequence of all six modules named in the supplied “C6 — The Grand Slam Offer (Hormozi)” overview. The document identifies itself as an excerpt from the Riser Nation Academy 2026 syllabus. It places the legacy course in Stage 2, Sailboat, during the Build → Do phase, after C5 Graduation, with 12–16 hours over two weeks. That averages 6–8 active hours per week; the source does not allocate time to individual modules.

Those legacy labels do not replace this lesson's current spreadsheet assignments. The source repeats its stage, prerequisite and time line; the complete original retains both occurrences. Its statement that the master syllabus remains intact is a source statement, not a new independent audit of that master.

The overview supplies a purpose, a short description and six module titles. It does not contain six complete module scripts, the MAGIC acronym expansion or the full Kennedy What-If framework. The orientation below teaches what the overview provides and labels explanatory applications. Missing module bodies remain explicit rather than being represented as recovered source material.

Begin with the exchange and the mismatch

An offer describes what the buyer gives and what the provider gives in return. The overview contrasts commodity offers, compared mainly on price, with offers evaluated on perceived value. Its provocative “Grand Slam” language expresses the ambition to make an offer compelling; it is not a reason to insult people who decline or claim that every buyer should purchase.

An authored application is to inspect the exchange from the intended buyer's position. Can the buyer understand the result, the delivery, the conditions and the price? Is the stated value supported, and does the actual service fit the buyer? A more persuasive description cannot repair a delivery promise that the business cannot fulfill.

M6.1: the Value Equation

The supplied overview summarizes the direction of Hormozi's Value Equation as increasing the desired outcome and belief while reducing time and work. Keep all four considerations visible. Ask what the buyer wants, what supports confidence, how long meaningful progress takes and what the buyer must do or give up.

The source does not supply a numeric worksheet or measurement scale. Do not invent a calculated value score and call it part of this excerpt. As an authored exercise, write one evidence-backed sentence about each consideration and mark any unsupported belief or timing claim as an assumption. Acquisition.com's Value Equation resource is a directly relevant primary reference; its linked training is separate from this short source overview.

M6.2: trim and stack methodology

The second named module concerns what belongs in the offer. The overview names trim and stack but gives no step-by-step method. Its plain-language description then refers to adding bonuses.

An authored application is to examine whether each proposed component helps the buyer achieve the scoped outcome or overcome a relevant obstacle. Identify unnecessary burden before adding more material. Record the purpose of each retained component and the work required to deliver and use it. This exercise is an application for RISER NATION, not a claim that the missing module text has been recovered.

M6.3: bonuses, scarcity, urgency and guarantees

All four enhancers named in the module title belong in the outline. Bonuses are additional components; scarcity concerns a limit on availability; urgency concerns a timing constraint; a guarantee states a specific commitment and its conditions. These plain-language explanations help the learner distinguish the terms without inventing the absent lesson body.

For an authored review, check that every bonus has a relevant purpose, every capacity or deadline claim reflects a real constraint, and every guarantee is consistent with the offer's written terms and delivery ability. A countdown or a “limited” label is not evidence that the limit is real. Do not present a guarantee as proof that every buyer will achieve an outcome.

The official Guarantee Creation and Scarcity & Urgency pages provide relevant reference destinations. Their videos and downloads have not been transcribed into this assigned excerpt.

M6.4: naming framework, MAGIC

The fourth module explicitly names MAGIC. Preserve that label, but do not invent what its letters stand for from this overview alone. The actual framework definition must be sourced before a lesson claims to teach its complete sequence.

An authored naming exercise can still ask whether a name helps the intended buyer recognize the offer and whether the surrounding description explains it accurately. That is a general clarity exercise, not a substitute acronym. The primary Naming Products resource is linked for further study and framework verification.

M6.5: scenario-based guarantees, Kennedy What-If

The fifth module names scenario-based guarantees and associates its What-If label with Kennedy. The overview does not provide a citation, the complete method or example terms. Keep that attribution attached to the source's label rather than implying this excerpt proves authorship of a detailed framework.

An authored exercise is to list possible situations that would need clear terms: a buyer seeks a refund, a required activity is not completed, delivery is delayed or an expected result does not occur. Identify the unresolved question in each scenario; do not manufacture a binding policy or a promised remedy. A complete lesson on the named method requires its missing source body.

M6.6: downsell architecture

The final module concerns the downsell, which the overview also mentions in its plain-language summary. The source does not specify a price ladder or a downsell offer.

As an authored application, distinguish a smaller scoped alternative from secretly discounting the same engagement or steering an unsuitable buyer into another unsuitable purchase. State what changes in delivery, support, commitment and price, and whether the alternative still fits the buyer's actual need. Do not claim a specific downsell is authorized or available merely because this module is named.

Connect the curriculum themes and check understanding

The Hormozi connection is explicit in the source title and its four-part value discussion. The additional Brunson/ClickFunnels connection is an authored application: the hook, story, offer and next step should describe the same exchange, with consistent proof and terms. It is not a claim that the supplied overview contains a separate Brunson lesson.

To finish, explain the mismatch the course is intended to address, state the source's prerequisite and workload, and identify all six modules in order. Then separate the available overview material from the missing detailed frameworks. A useful orientation prepares the learner for those lessons without pretending they are already present.

Clickable source and resources

- Assigned C6 Grand Slam Offer overview - Acquisition.com offer-training index - The complete assigned overview is preserved in the lesson appendix. Detailed module bodies, the MAGIC definition and the Kennedy What-If source remain explicit dependencies.

Assigned source links

D0441 original source 1

C6 — The Grand Slam Offer (Hormozi) — Course Overview
============================================================

Source: Riser Nation Academy 2026 Syllabus
Stage: Stage 2 — Sailboat  ·  Phase: Build → Do  ·  Prereq: C5 Graduation passed  ·  Time: 12–16 hours over 2 weeks

NOTE: This document is an excerpt copied from the master syllabus.
The master syllabus remains intact and unmodified.

Stage: Stage 2 — Sailboat  ·  Phase: Build → Do  ·  Prereq: C5 Graduation passed  ·  Time: 12–16 hours over 2 weeks
In Plain Words
An offer is what you give for what they give you. A Grand Slam Offer is so good people feel stupid saying no. We use Hormozi's Value Equation: more dream, more belief, less time, less work. Then we stack bonuses, add a guarantee, name it well, and prepare the downsell.
The Mismatch This Course Fixes
Mismatch between commodity offers (sell on price) and Grand Slam offers (sell on value perception).
Modules

---

MODULES IN THIS COURSE
---
M6.1 — THE VALUE EQUATION
M6.2 — TRIM & STACK METHODOLOGY
M6.3 — ENHANCERS — BONUSES, SCARCITY, URGENCY, GUARANTEES
M6.4 — NAMING FRAMEWORK (MAGIC)
M6.5 — SCENARIO-BASED GUARANTEES (KENNEDY WHAT-IF)
M6.6 — DOWNSELL ARCHITECTURE


---
END OF C6 OVERVIEW
---

---
source_type: "Google Doc"
source_url: "https://docs.google.com/document/d/1OThcV05CW77EGGMIdoTZ42ZIOTJOCnqYM187vPlaYgw/edit?usp=drivesdk"
drive_file_id: "1OThcV05CW77EGGMIdoTZ42ZIOTJOCnqYM187vPlaYgw"
created: "2026-05-11T23:30:23.200Z"
modified: "2026-06-04T17:06:07.440Z"
---

# C6 - The Grand Slam Offer (Hormozi) - Course Overview

C6 — The Grand Slam Offer (Hormozi) — Course Overview
============================================================


Source: Riser Nation Academy 2026 Syllabus
Stage: Stage 2 — Sailboat  ·  Phase: Build → Do  ·  Prereq: C5 Graduation passed  ·  Time: 12–16 hours over 2 weeks


NOTE: This document is an excerpt copied from the master syllabus.
The master syllabus remains intact and unmodified.


Stage: Stage 2 — Sailboat  ·  Phase: Build → Do  ·  Prereq: C5 Graduation passed  ·  Time: 12–16 hours over 2 weeks
In Plain Words
An offer is what you give for what they give you. A Grand Slam Offer is so good people feel stupid saying no. We use Hormozi's Value Equation: more dream, more belief, less time, less work. Then we stack bonuses, add a guarantee, name it well, and prepare the downsell.
The Mismatch This Course Fixes
Mismatch between commodity offers (sell on price) and Grand Slam offers (sell on value perception).
Modules


---


MODULES IN THIS COURSE
---
M6.1 — THE VALUE EQUATION
M6.2 — TRIM & STACK METHODOLOGY
M6.3 — ENHANCERS — BONUSES, SCARCITY, URGENCY, GUARANTEES
M6.4 — NAMING FRAMEWORK (MAGIC)
M6.5 — SCENARIO-BASED GUARANTEES (KENNEDY WHAT-IF)
M6.6 — DOWNSELL ARCHITECTURE




---
END OF C6 OVERVIEW
---

Assemble an offer architecture that agrees across every attachment

RISER NATION CORP — IF YOU AREN'T BUILDING, YOU ARE DESTROYING

Outcome, prerequisites and source boundaries

Use the C7 Offer Architecture Document Template to explain how seven completed artifacts become one internally consistent delivery specification. The source calls this legacy M7.8, a 12–20-page capstone requiring an Opus 4.7 validator and instructor co-sign before C8 enrollment. Follow the current spreadsheet assignment for this lesson; these labels describe the source workflow.

The seven inputs are the Distinction Statement, Deliverable Decomposition, Fulfillment SOP Library, Customer Lifecycle Map, Capacity Constraint Analysis, Operator Bandwidth Audit and Offer v2.0. The template contains fields for their summaries and references; it does not supply those completed attachments. It also names rules and clauses whose complete definitions are not included. Preserve those dependencies instead of filling blank approvals, measurements or signatures with invented information.

The intended validation checks for three failures: parts that never form a coherent whole, promises that exceed capacity, and a design fitted to a few past customers rather than the intended customer profile. A named AI validator is not evidence that it has been deployed or that a particular submission passed.

Section 0: identify the document and verify the attestations

Complete the eight header fields: operator name, stage, offer name, offer version, document version, date, whether C6 prerequisites cleared, and whether all M7.1–M7.7 deliverables are attached. The source preprints Stage 2, Sailboat; offer v2.0; and document version 1.0. They are template values, not proof of the learner's actual status.

Review all eight attestations before signing:

1. Preserve the prior v1.1 offer separately and identify the new architecture as the structure of delivering v2.0.
2. Check that decomposed deliverables are atomic rather than vague composite activities. The template references a four-criterion test but does not define it; obtain the actual test before claiming it passed.
3. Derive the customer ceiling from measured hours and the capacity analysis, not aspirations. The named Honest Capacity Clause is an additional source dependency.
4. Confirm that the change concerns architecture rather than a new mechanism, customer or problem. The Architecture-vs-Pivot Distinction Clause must be consulted where applicable.
5. Ensure SOPs describe executable work and pass the referenced operability test. Do not claim compliance with the absent SOP Operability Clause merely because an SOP exists.
6. Preserve the v2.x and v3.0 iteration discipline referenced through the C6 clause and Attachment 7, Section 11.
7. Verify the actual M7.5 capacity review, M7.7 offer review, M7.8 AI validation and M7.8 instructor co-sign records. These are distinct gates.
8. Preserve the C6 Honest Customer Representation commitment in subsequent marketing, sales and case-study work.

The signature and date attest to real evidence. The header appears before some reviews have occurred, so leave the relevant approval claim pending until its actual gate clears. Do not sign a statement that future reviews are already complete.

Sections 1 and 2: orient the reader and maintain the distinction

Section 1 is a 250–400-word executive summary. State the offer, the customer, what v2.0 commits to and what it excludes. This is reader orientation, not a substitute for the detailed supporting artifacts.

Section 2 is a 200–300-word account of what v1.1 was, what the architecture is, why the distinction matters operationally and which of two failure modes posed the greater risk: an iteration loop or a pivot disguised as architecture. Cite the referenced 3-Customer Test result. The test's procedure and a completed result are not present in this template; mark that dependency rather than inventing a test outcome.

An authored example of the distinction is changing how a defined deliverable is produced and reviewed while preserving its intended customer and problem. A new target customer or a new mechanism requires a different decision; it should not be hidden under the label “architecture.”

Sections 3 and 4: connect deliverables to fulfillment SOPs

Section 3 references Attachment 2. Report the number of atomic deliverables, lifecycle phases, cohort-produced versus per-customer work where applicable, and candidates identified under the referenced 6% Rule. Include Attachment 2's Section 3 deliverable summary table. The rule's definition is absent from this source, so do not infer that any arbitrary six percent of tasks is the intended method.

Section 4 references Attachment 3. Report the number of SOPs authored, the number covering high-leverage standardizations, the percentage tied to atomic deliverables and the percentage passing the operability test. Include the SOP-to-deliverable mapping table. The two preprinted 100% values are expectations in the template; they are not measured results for the learner.

An authored consistency check traces every retained deliverable to the procedure that produces it. A list of procedures without a relationship to the promised work does not establish fulfillment coverage. Preserve an uncovered item as a gap until the corresponding procedure and review evidence exist.

Section 5: reproduce the lifecycle and its gates

Reference Attachment 4. Reproduce its Section 4 Mermaid lifecycle diagram and Section 5 gate specification table, and summarize its Section 6 off-path scenarios. Record the total lifecycle stages, transition gates, touchpoints and documented off-path scenarios.

Do not create a generic diagram and label it the original attachment. The blank capstone template does not include that diagram or its gate table. When the actual artifact is available, retain its details and check that its transitions agree with the offer's engagement structure. An authored application is to ask what evidence permits a transition and what happens when that evidence is missing.

Section 6: report the actual capacity constraint

Use Attachment 5 with its human-in-the-loop sign-off. Reproduce the ceiling statement from Section 7, bottleneck identification from Section 3 and quality-degradation thresholds from Section 5. Complete the five summary fields: concurrent-customer ceiling, bottleneck activity, named quality thresholds, cohort-variant ceiling if applicable, and whether human review cleared.

The ceiling needs support from the measured work. A sales target is not a capacity calculation. Keep any unresolved mismatch between the stated ceiling, time evidence and promised delivery visible until the relevant attachment is corrected.

Section 7: report measured bandwidth and hidden work

Reference Attachment 6 and its human review. Reproduce the audit output statement from Section 9, estimate-versus-measured table from Section 4 and hidden-cost inventory from Section 5. Record the measurement-window length, measured per-customer hours per week, measured hours for a full engagement, percentage difference between estimates and measurements, and hidden costs as a share of total time.

Separate measured entries from estimates and explain the denominator used for any percentage. Do not extrapolate a short measurement window into a full-engagement total without labeling the assumptions. That is an authored data-quality check; the template supplies fields rather than a completed measurement record.

Section 8: carry forward the offer's boundaries

Reference Attachment 7 with cohort-partner and instructor sign-offs. Reproduce four specific sections: its anti-pivot statement from Section 2, capacity statement from Section 6, anti-promise list from Section 7 and account of how v2.0 differs from v1.1 from Section 8.

Copying these references preserves the relationship between the delivery architecture and the actual offer. Do not soften exclusions or silently increase capacity in the capstone summary. If the original offer needs revision, revise and review that source artifact so the two documents remain traceable.

Section 9: run all seven internal-consistency checks

Before validator submission, check every relationship named in the template:

1. M7.6 per-customer hours agree with M7.5 bottleneck calculations.
2. The M7.5 customer ceiling matches M7.7's capacity statement.
3. M7.2 deliverable counts agree with M7.3 SOP references and M7.4 lifecycle stages.
4. M7.4 stages match the engagement structure in Attachment 7, Section 4.
5. Anti-promises agree with what the deliverables actually produce.
6. No deliverable promises an outcome explicitly excluded by the anti-promise list.
7. Any cohort variant is treated consistently in decomposition, lifecycle, capacity and the offer.

If a check fails, revise the affected attachment before submission. Checking a box cannot reconcile contradictory facts. Keep the revision connected to the document version used for the next review.

Section 10: test whether the architecture generalizes

The source's bespoke-architecture trap is overfitting the design to the first one to three customers. Apply all five checks: stages and gates should work for hypothetical fourth, fifth and sixth customers who fit the profile; deliverables should be universal within that profile; SOPs should not be named after or specific to one past customer; capacity should account for customer variation rather than only an average; and any customization budget should be bounded rather than absorbing structural differences.

If a check fails, separate the universal structure from customer-specific accommodations and revise the relevant attachment. This is not a demand that all customers be identical. It asks whether the offer's shared structure remains workable across its defined audience.

Sections 11 and 12: record validation and human judgment separately

The source proposes submitting Sections 1–10 with Attachments 1–7 to `offer-architecture-validator-v1.0.0`, associated with Opus 4.7. Preserve the header and relevant signed clauses as well; the submission shorthand does not make those required parts disposable.

The three named outcomes have different routes. VALIDATED proceeds to instructor co-sign. NEEDS_REVISION sends the operator back to specific attachments and then resubmission. REJECTED identifies a fundamental issue requiring rebuilding relevant M7.2, M7.5 or M7.7 material. Record submission date, output filename, outcome, the response to requested revisions and the final outcome. The template's preprinted final VALIDATED field must not be treated as a result before review.

Section 12 records instructor name, signature, co-sign date and optional comments. The instructor reviews the AI output, revision responses and overall coherence. The source proposes a 24–72-hour co-sign service interval; that is not a verified service commitment from this academy.

Section 13: bundle the complete record and plan the timing

List all seven attachment filenames in order. Include human sign-offs for the capacity analysis and bandwidth audit, and cohort plus instructor sign-offs for Offer v2.0. Also retain the five named signed clause documents: Honest Capacity, Architecture-vs-Pivot Distinction, SOP Operability, C6 Iteration Discipline and C6 Honest Customer Representation.

The source calls the resulting package a permanent completion record and C8 entry artifact. It estimates 6–10 active hours for Sections 1–10 assuming the attachments already exist, plus a 24–72-hour AI validation cycle and a separate 24–72-hour instructor co-sign interval. Those sequential intervals imply 48–144 hours of review elapsed time before revisions or scheduling changes, not an additional measured block of operator labor. Actual provisioning and reviewer availability remain unverified.

Connect offer promises to delivery evidence

The authored Brunson/ClickFunnels application is consistency between the public offer and what its supporting story and delivery actually establish. The authored Hormozi/Acquisition.com application is to support perceived value with a credible, bounded delivery plan, including time, effort and capacity. Neither perspective makes an AI PASS, a long document or a signed blank template sufficient evidence.

For practice, choose one discrepancy—for example, two different customer ceilings—and trace which attachment must change, which claims depend on it and which review must be repeated. The complete original template, including its tables and blank fields, remains in the appendix; missing attachment bodies and clause definitions remain explicit dependencies.

Clickable assigned source

- Original C7 Offer Architecture Document Template

Assigned source links

D0442 original source 1

# C7 Offer Architecture Document Template

**Course:** C7 Offer Architecture
**Module:** M7.8 — Offer Architecture Document (capstone synthesis)
**Document Type:** Operator-completed capstone; Opus 4.7 validator + instructor co-sign required
**Length:** 12-20 pages when complete (synthesizes M7.1-M7.7 deliverables)

---

## Purpose

The Offer Architecture Document is the C7 capstone. It bundles the seven preceding artifacts (Distinction Statement, Deliverable Decomposition, Fulfillment SOP Library, Customer Lifecycle Map, Capacity Constraint Analysis, Operator Bandwidth Audit, Offer v2.0) into a single, internally consistent architectural specification.

The document receives multi-document validation by Opus 4.7 (`offer-architecture-validator-v1.0.0`), which cross-references the seven artifacts for internal consistency and detects three failure patterns: decomposition without integration, capacity-claim mismatch, and bespoke architecture indicators.

After Opus validation, the document receives instructor co-sign. Both gates must clear before C8 enrollment.

---

## Section 0: Document Header and Attestation

| Field | Value |
|-------|-------|
| Operator name | |
| Operator stage | Stage 2 (Sailboat) |
| Offer name | |
| Offer version | v2.0 |
| Document version | 1.0 |
| Document date | |
| C6 prerequisites cleared | Y / N |
| C7 module deliverables M7.1-M7.7 attached | Y / N |

### Attestation Clauses

I attest to the following:

1. **Distinction maintained.** I have produced the Offer Architecture as a structure, distinct from any document I produced in prior courses. My v1.1 offer document is preserved separately; this document is the architecture of how v2.0 is delivered.

2. **Decomposition is atomic.** The deliverables enumerated in Attachment 2 (M7.2 Decomposition) pass the four-criterion atomicity test. They are not composite "we work together on X" items.

3. **Capacity is honest.** The concurrent-customer ceiling stated in the v2.0 offer (Attachment 7) and the capacity analysis (Attachment 5) derives from measured operator hours per customer (Attachment 6), not from aspirational projections. I commit to the C7 Honest Capacity Clause.

4. **v2.0 is architectural.** The v2.0 offer changes the architecture, not the mechanism, customer, or problem. I commit to the C7 Architecture-vs-Pivot Distinction Clause.

5. **SOPs are operable.** The fulfillment SOPs (Attachment 3) describe what is done, not what should be done. Each passes the operability test. I commit to the C7 SOP Operability Clause.

6. **Iteration discipline endures.** Iteration trajectory for v2.x and v3.0 follows the C6 Iteration Discipline Clause as specified in Attachment 7 Section 11.

7. **HITL gates cleared.** The M7.5 capacity HITL has cleared (instructor sign-off in Attachment 5). The M7.7 Offer v2.0 review has cleared (sign-off in Attachment 7). The M7.8 Opus 4.7 validation has cleared (output appended below). The M7.8 instructor co-sign has cleared (signature below).

8. **Honest customer representation continues.** I commit to the C6 Honest Customer Representation Clause in all v2.0-era marketing, sales, and case-study work.

**Operator signature:** ___________________________
**Date:** ___________________________

---

## Section 1: Executive Summary

In 250-400 words, summarize the offer architecture. The summary is the document's reader-orientation; it states what the offer is, who it serves, what is being committed to in v2.0, and what is not being committed to.

[Operator writes the executive summary here]

---

## Section 2: Distinction Statement (M7.1)

Reference: Attachment 1 (full M7.1 Distinction Statement).

In this section, summarize in 200-300 words:
- What v1.1 was (the document)
- What this Offer Architecture is (the structure)
- Why the distinction matters operationally (cite the 3-Customer Test result)
- Which failure mode the operator was at higher risk of (Iteration Loop or Pivot Disguised as Architecture)

[Operator writes here]

---

## Section 3: Deliverable Decomposition (M7.2)

Reference: Attachment 2 (full M7.2 Decomposition).

In this section, summarize:

| Field | Value |
|-------|-------|
| Total atomic deliverables | |
| Lifecycle phases | |
| Cohort-produced vs per-customer (if applicable) | |
| 6% Rule standardization candidates identified | |

Include the deliverable summary table from Attachment 2 Section 3.

---

## Section 4: Fulfillment SOP Library (M7.3)

Reference: Attachment 3 (full M7.3 SOP Library).

In this section, summarize:

| Field | Value |
|-------|-------|
| Total SOPs authored | |
| SOPs covering high-leverage standardizations (6% Rule) | |
| SOPs tied to atomic deliverables (% of total) | 100% |
| SOPs passing operability test | 100% |

Include the SOP-to-deliverable mapping table.

---

## Section 5: Customer Lifecycle Map (M7.4)

Reference: Attachment 4 (full M7.4 Lifecycle Map).

In this section:

- Reproduce the Mermaid lifecycle diagram from Attachment 4 Section 4
- Reproduce the gate specification table from Attachment 4 Section 5
- Summarize the off-path scenarios from Attachment 4 Section 6

| Field | Value |
|-------|-------|
| Total lifecycle stages | |
| Total transition gates | |
| Total touchpoints across full lifecycle | |
| Off-path scenarios documented | |

---

## Section 6: Capacity Constraint Analysis (M7.5)

Reference: Attachment 5 (full M7.5 Capacity Analysis), with HITL sign-off.

In this section:

- Reproduce the ceiling statement from Attachment 5 Section 7
- Reproduce the bottleneck identification from Attachment 5 Section 3
- Reproduce the quality-degradation thresholds table from Attachment 5 Section 5

| Field | Value |
|-------|-------|
| Concurrent-customer ceiling | |
| Bottleneck activity | |
| Quality-degradation thresholds named | |
| Cohort variant ceiling (if applicable) | |
| HITL cleared | Y / N |

---

## Section 7: Operator Bandwidth Audit (M7.6)

Reference: Attachment 6 (full M7.6 Bandwidth Audit), with HITL sign-off.

In this section:

- Reproduce the audit output statement from Attachment 6 Section 9
- Reproduce the estimate-vs-measured comparison table from Attachment 6 Section 4
- Reproduce the hidden costs inventory from Attachment 6 Section 5

| Field | Value |
|-------|-------|
| Measurement window length | |
| Per-customer per-week (measured) | |
| Total per-customer (full engagement, measured) | |
| Estimate-vs-measured delta % | |
| Hidden costs as % of total time | |

---

## Section 8: Offer v2.0 Document (M7.7)

Reference: Attachment 7 (full M7.7 Offer v2.0 Document), with cohort partner and instructor sign-offs.

In this section, reproduce:

- Section 2 of Attachment 7 (Anti-Pivot Statement: what is not changing)
- Section 6 of Attachment 7 (Capacity Statement)
- Section 7 of Attachment 7 (Anti-Promise List)
- Section 8 of Attachment 7 (How v2.0 Differs From v1.1)

---

## Section 9: Internal Consistency Check (Operator-Completed)

Before submitting to the Opus 4.7 validator, the operator self-checks the architecture for internal consistency. Check each item:

- [ ] The total per-customer hours in M7.6 (Attachment 6) is consistent with the bottleneck math in M7.5 (Attachment 5).
- [ ] The concurrent-customer ceiling in M7.5 (Attachment 5) matches the capacity statement in M7.7 Section 6 (Attachment 7).
- [ ] The deliverable count in M7.2 (Attachment 2) matches the deliverables referenced in M7.3 SOPs (Attachment 3) and M7.4 lifecycle stages (Attachment 4).
- [ ] The lifecycle stages in M7.4 (Attachment 4) match the engagement structure in M7.7 Section 4 (Attachment 7).
- [ ] The anti-promises in M7.7 Section 7 (Attachment 7) are consistent with what the deliverables (Attachment 2) actually produce.
- [ ] No deliverable in Attachment 2 promises an outcome named in the anti-promise list of Attachment 7.
- [ ] The cohort variant (if applicable) is treated consistently in M7.2, M7.4, M7.5, and M7.7.

If any check fails, the operator revises the relevant attachment before Opus submission.

---

## Section 10: Bespoke Architecture Trap Self-Check (Operator-Completed)

The Bespoke Architecture Trap is the C7 failure case where an operator over-fits the architecture to the first 1-3 customers. Self-check:

- [ ] The lifecycle stages and gates (Attachment 4) generalize to a hypothetical fourth, fifth, and sixth customer who would enroll at v2.0 — not just the v1.x customers I have served.
- [ ] The deliverables (Attachment 2) are universal — they would be produced for any customer fitting the v2.0 customer profile, not customer-specific accommodations.
- [ ] No SOP in the library (Attachment 3) is named after or specific to a single past customer.
- [ ] The capacity ceiling (Attachment 5) accounts for variance across customers, not just the average of the v1.x cohort.
- [ ] The customization budget (if any) is bounded and does not absorb structural variation.

If any check fails, the operator separates universal-architecture elements from customer-specific accommodations and revises the relevant attachment.

---

## Section 11: Opus 4.7 Validator Submission

The complete document (Sections 1-10 + Attachments 1-7) is submitted to Opus 4.7 (`offer-architecture-validator-v1.0.0`). The validator runs multi-document cross-reference and outputs one of three outcomes:

- **VALIDATED** — proceed to instructor co-sign
- **NEEDS_REVISION** — operator revises specific attachments per the validator's findings, then resubmits
- **REJECTED** — fundamental architecture issue; operator returns to the relevant module (M7.2, M7.5, M7.7) and rebuilds the affected attachment

**Validator submission date:** ___________________________
**Validator output filename:** ___________________________
**Validator outcome:** VALIDATED / NEEDS_REVISION / REJECTED
**Operator response to validator findings (if NEEDS_REVISION):**

[Operator notes here, with revised attachments referenced]

**Final validator outcome (after revisions, if any):** VALIDATED

---

## Section 12: Instructor Co-Sign

After Opus validation clears, the document receives instructor co-sign. The instructor reviews the validator output, the operator's responses to revisions, and the architecture's coherence at the human-judgment level.

**Instructor name:** ___________________________
**Instructor signature:** ___________________________
**Date of co-sign:** ___________________________
**Co-sign SLA:** 24-72 hours from operator submission of validated document.

**Instructor comments (optional):**

[Instructor writes here]

---

## Section 13: Attachments

The following attachments are bundled with this document. Each attachment is a complete deliverable from M7.1-M7.7.

- **Attachment 1:** M7.1 Distinction Statement (filename: ___________)
- **Attachment 2:** M7.2 Deliverable Decomposition (filename: ___________)
- **Attachment 3:** M7.3 Fulfillment SOP Library (filename: ___________)
- **Attachment 4:** M7.4 Customer Lifecycle Map (filename: ___________)
- **Attachment 5:** M7.5 Capacity Constraint Analysis (with HITL sign-off, filename: ___________)
- **Attachment 6:** M7.6 Operator Bandwidth Audit (with HITL sign-off, filename: ___________)
- **Attachment 7:** M7.7 Offer v2.0 Document (with cohort + instructor sign-offs, filename: ___________)

Signed clause documents (referenced in Section 0 attestation):
- C7 Honest Capacity Clause (signed)
- C7 Architecture-vs-Pivot Distinction Clause (signed)
- C7 SOP Operability Clause (signed)
- C6 Iteration Discipline Clause (signed in C6, referenced in C7)
- C6 Honest Customer Representation Clause (signed in C6, referenced in C7)

---

*This document, with all attachments and clearances, is the C7 completion artifact. It is filed in the operator's permanent records and is the entry artifact for C8 enrollment.*

*Estimated completion time: 6-10 hours active for Sections 1-10 (the attachments are already complete from M7.1-M7.7). Opus validation cycle: 24-72 hours. Instructor co-sign SLA: 24-72 hours.*

Assemble the complete offer blueprint and team handoff

RISER NATION CORP — IF YOU AREN'T BUILDING, YOU ARE DESTROYING

Outcome and source scope

Bring the offer's research, positioning, ladder, funnel, copy, bonuses and delivery into one coherent plan. The assigned document names this Module 10 of an offer-development bootcamp. Keep that legacy label separate from the current course and lesson assignments.

The source is an integration outline, not a completed business plan or proof that a funnel is ready to launch. It references Modules 1–9 without supplying all their bodies here. Its attributed Brunson, Kennedy and Hormozi statements reinforce packaging, consistency, delivery and iteration; exact quotation wording is not authenticated by this document. The following explanations and handoff checks are authored applications of the supplied sequence.

1. Assemble the five-tier value ladder

The source sequence is MIFGE, tripwire, core offer, profit maximizer and high-ticket offer. MIFGE means the Most Incredible Free Gift Ever in the related foundation source. Describe the useful first result it provides. Describe the limited initial paid commitment of the tripwire, the main transformation of the core offer, the additional value supplied by a profit maximizer, and the deeper service or scope of a high-ticket offer.

Use those as planning categories. They are not a requirement to sell every customer five products. A gap exists when someone who needs a next step cannot understand or access a suitable next step. A gap does not mean that every possible price point must have an offer.

For each tier, write the intended customer need, actual deliverables, price, prerequisites and logical next step. If a tier would add complexity without helping the customer, document that decision rather than inventing a product to fill a diagram. The source's instruction to eliminate gaps should serve customer progress and a workable business.

2. Match funnel recipes to ladder steps

The document lists lead, tripwire, VSL, webinar and application funnels and asks you to cross-check the Module 6 page recipes. A lead funnel supports an appropriate entry action. A tripwire funnel presents the initial paid offer. VSL and webinar funnels communicate an offer through recorded or presentation-based content. An application funnel collects relevant information before a more considered next step.

These descriptions are authored explanations, not the missing Module 6 recipes. Draw the actual pages and transitions required for the chosen offer: where the visitor arrives, what they learn, what action they take, and what confirmation or delivery follows. Account for someone declining or encountering an error. An outline saying “webinar funnel” is not a page-by-page implementation specification.

Do not assume that one named funnel is inherently best for a ladder tier. Choose a flow that suits the customer's decision, the necessary explanation and the team's delivery capacity. Mark untested choices as assumptions.

3. Insert copy and messaging

The source calls for hooks, stories and offers from Module 7, influence principles associated with Cialdini, and copy matched to funnel type and audience sophistication. In an authored handoff, keep one clear page purpose and one understandable next action. Explain a problem the reader recognizes, use an authentic or explicitly hypothetical story, and state the real offer.

Audience sophistication concerns what the intended audience already knows and has encountered. Do not assume that a newcomer and an experienced buyer need the same explanation. Keep claims, scope, price and terminology consistent across the advertisement, page, checkout and onboarding.

The ClickFunnels hook–story–offer reference explains the communication sequence. It does not verify your product's results. Use relevant, authentic proof and accurately described expertise. The source's reference to influence triggers is not permission to fabricate testimonials, urgency or authority.

4. Stack bonuses and angles

The document says to add at least three bonuses to each core offer, drawing on Module 8, and to frame the stack using Module 5 pricing psychology. Preserve that as the source's design exercise; three bonuses is not a universal conversion optimum.

As an authored review, name the obstacle each proposed bonus removes, how the customer uses it, what it costs to deliver and whether it duplicates the core service. If three useful bonuses cannot be justified, record the conflict between the exercise and the offer's needs. Avoid adding irrelevant materials merely to increase a nominal stack value.

The source also asks you to highlight the MIFGE entry point. Explain its bounded usefulness and its genuine relationship to the paid path. A free entry resource should not conceal the terms of the next purchase. Price anchors and claimed component values need a defensible basis; they do not become evidence through repetition.

5. Confirm platform and delivery systems

The outline points to Module 9 for matching platforms to offers and describes automation and onboarding as seamless. Turn that aspiration into a concrete plan. State the actual platform, how access is granted, where the customer starts, what fulfillment requires and who handles a failure.

An authored delivery review can follow one authorized test customer through payment or registration, access, first use and support. Plan the test without initiating purchases or operational actions merely because a source document proposes them. A written automation map is not evidence that an integration is configured or working. Record the observed test result separately from the design.

6. Complete all seven blueprint fields

The source's worksheet can be a single document or spreadsheet. It must bring together all seven categories:

1. Niche and avatar: who the offer serves and the source of that understanding, drawing on the earlier audience work.
2. Offer statement: the Big Promise and transformation, including meaningful limits and prerequisites.
3. Value ladder and pricing: each intended tier, its exchange and its next step.
4. Funnels and page flows: the sequence of pages and customer actions.
5. Copy frameworks: hooks, calls to action and angles attached to the correct page.
6. Bonuses and guarantees: the actual components and applicable conditions, without inventing missing policies.
7. Platforms and delivery map: the systems, access and fulfillment responsibilities.

This is the master reference. Link the supporting work rather than creating conflicting versions of the same promise or price. As an authored addition, mark unresolved decisions, who will resolve them and what evidence is still required. Keep these additions distinct from the source's seven-field worksheet.

The five required deliverables

Produce the integrated Offer Blueprint; a funnel, platform and delivery map; draft hooks and copy for every required page; finalized proposed value stacks with pricing and bonuses; and a specification understandable to the VA, designer or technical team who would build it. These deliverables describe a prepared handoff. They do not certify that the live experience has already been built or approved.

The source's expert tips call for documenting a repeatable system, beginning with a working recipe and iterating. Apply them by preserving a version of the plan, recording test findings and updating the relevant component. Copying a competitor's expression or assuming their funnel works is not evidence-based iteration.

Graduation check and build readiness

Answer all three source questions: Is the complete blueprint documented? Can you explain the ladder, funnel, copy, bonuses and platforms in under five minutes? Are you confident handing it to a team to build? Use the short explanation to find ambiguity, not to hide necessary detail.

Then distinguish confidence from readiness. An authored readiness review asks whether a builder can identify the required inputs, actual deliverables, unresolved choices and verification steps. A plan with missing source recipes can still identify those gaps honestly. It cannot claim that the missing recipes were taught or implemented.

Sources and supporting documents

- Assigned final-integration document. - Foundation, Big Promise and ten-milestone source. - Master Offer Blueprint workbook: the supplied file is a DOCX with ten blank module forms, not a completed blueprint. - Competitor-recon source, supporting the research and positioning work. - Acquisition.com Value Equation training, a related primary resource for examining desired outcome, confidence, delay and effort.

The complete assigned native and filed source texts accompany the teaching in the lesson appendix.

Assigned source links

D0452 original source 1

Module 10 – Pulling It All Together: The Offer Blueprint
(Your One-to-Many Offer System, Fully Integrated & Ready to Launch)
Objective
By the end of this module, you’ll have a complete Offer Blueprint that unites all the pieces—research, positioning, funnel, copy, bonuses, platforms—into a single, executable strategy.

Why This Matters
Russell Brunson: “An offer is not a product. It’s everything wrapped together into one irresistible package.”

Dan Kennedy: Consistency beats brilliance—your system must flow from start to finish.

Alex Hormozi: An offer isn’t about ideas—it’s about proof you can deliver results better, faster, and safer than anyone else.

Riser Nation: You don’t build a skyscraper one floor at a time—you need the full blueprint before you pour the concrete.


Step 1 – Assemble the Value Ladder
Place each offer in the right tier (MIFGE → Tripwire → Core → Profit Maximizer → High-Ticket).

Confirm there are no “gaps” where customers get stuck.


Step 2 – Map the Funnel Recipes
Assign the right funnel type to each ladder step (Lead, Tripwire, VSL, Webinar, Application).

Cross-check with Module 6 page recipes.


Step 3 – Insert Copy & Messaging
Plug in hooks, stories, offers (Module 7).

Layer in influence triggers (Cialdini).

Match copy style to funnel type + audience sophistication.


Step 4 – Stack Bonuses & Angles
Add at least 3 bonuses per core offer (Module 8).

Frame the value stack with pricing psychology (Module 5).

Highlight your “MIFGE” as the irresistible entry point.


Step 5 – Confirm Delivery Systems
Match each offer with its platform (Module 9).

Ensure automation + onboarding are seamless.


Step 6 – The Offer Blueprint Worksheet
Put everything into one document/spreadsheet:
Niche & Avatar (from Modules 1–2).

Offer Statement (Big Promise + Transformation).

Value Ladder + Pricing.

Funnels & Page Flows.

Copy Frameworks (hooks, CTAs, angles).

Bonuses & Guarantees.

Platforms & Delivery Map.

This becomes your master reference file for building and scaling.

Deliverables for Module 10
✅ A completed Offer Blueprint (all modules integrated).
 ✅ A clear funnel + platform + delivery map.
 ✅ Draft copy + hooks for each page.
 ✅ Value stacks finalized with pricing & bonuses.
 ✅ Ready-to-build system you can hand to a VA, designer, or tech team.

Pro Tips & Expert Secrets
Kennedy: Document your system so anyone could execute it—this is how you scale.

Brunson: Don’t reinvent—start with a working recipe, then test/iterate.

Hormozi: Never stop improving your offer—iteration is the path to wealth.

Riser Nation: Think like a builder—your blueprint isn’t the house, but without it, the house falls down.


Graduation Checkpoint
Do you have your complete Offer Blueprint documented?

Can you explain your ladder, funnel, copy, bonuses, and platforms in under 5 minutes?

Do you feel confident handing this to a team and saying, “Build it”?

If yes → You’ve completed the Offer Development Bootcamp. You now own a repeatable system for crafting, testing, and scaling irresistible offers.

---
source_type: "Google Doc"
source_url: "https://docs.google.com/document/d/1SnKwFUtqBVZjVTfX1HIWCAwydk_JYGhkoDI66T2MJvQ/edit?usp=drivesdk"
drive_file_id: "1SnKwFUtqBVZjVTfX1HIWCAwydk_JYGhkoDI66T2MJvQ"
created: "2025-10-08T01:06:39.695Z"
modified: "2026-06-04T14:43:22.818Z"
---

# CNX.3.11.10 – Offer_Dev_Module_10_The_Offer_Blueprint_Final_Integration.docx

Module 10 – Pulling It All Together: The Offer Blueprint
(Your One-to-Many Offer System, Fully Integrated & Ready to Launch)
Objective
By the end of this module, you’ll have a complete Offer Blueprint that unites all the pieces—research, positioning, funnel, copy, bonuses, platforms—into a single, executable strategy.
________________


Why This Matters
* Russell Brunson: “An offer is not a product. It’s everything wrapped together into one irresistible package.”

* Dan Kennedy: Consistency beats brilliance—your system must flow from start to finish.

* Alex Hormozi: An offer isn’t about ideas—it’s about proof you can deliver results better, faster, and safer than anyone else.

* Riser Nation: You don’t build a skyscraper one floor at a time—you need the full blueprint before you pour the concrete.

________________


Step 1 – Assemble the Value Ladder
   * Place each offer in the right tier (MIFGE → Tripwire → Core → Profit Maximizer → High-Ticket).

   * Confirm there are no “gaps” where customers get stuck.

________________


Step 2 – Map the Funnel Recipes
      * Assign the right funnel type to each ladder step (Lead, Tripwire, VSL, Webinar, Application).

      * Cross-check with Module 6 page recipes.

________________


Step 3 – Insert Copy & Messaging
         * Plug in hooks, stories, offers (Module 7).

         * Layer in influence triggers (Cialdini).

         * Match copy style to funnel type + audience sophistication.

________________


Step 4 – Stack Bonuses & Angles
            * Add at least 3 bonuses per core offer (Module 8).

            * Frame the value stack with pricing psychology (Module 5).

            * Highlight your “MIFGE” as the irresistible entry point.

________________


Step 5 – Confirm Delivery Systems
               * Match each offer with its platform (Module 9).

               * Ensure automation + onboarding are seamless.

________________


Step 6 – The Offer Blueprint Worksheet
Put everything into one document/spreadsheet:
                  * Niche & Avatar (from Modules 1–2).

                  * Offer Statement (Big Promise + Transformation).

                  * Value Ladder + Pricing.

                  * Funnels & Page Flows.

                  * Copy Frameworks (hooks, CTAs, angles).

                  * Bonuses & Guarantees.

                  * Platforms & Delivery Map.

This becomes your master reference file for building and scaling.
________________


Deliverables for Module 10
✅ A completed Offer Blueprint (all modules integrated).
✅ A clear funnel + platform + delivery map.
✅ Draft copy + hooks for each page.
✅ Value stacks finalized with pricing & bonuses.
✅ Ready-to-build system you can hand to a VA, designer, or tech team.
________________


Pro Tips & Expert Secrets
                     * Kennedy: Document your system so anyone could execute it—this is how you scale.

                     * Brunson: Don’t reinvent—start with a working recipe, then test/iterate.

                     * Hormozi: Never stop improving your offer—iteration is the path to wealth.

                     * Riser Nation: Think like a builder—your blueprint isn’t the house, but without it, the house falls down.

________________


Graduation Checkpoint
                        * Do you have your complete Offer Blueprint documented?

                        * Can you explain your ladder, funnel, copy, bonuses, and platforms in under 5 minutes?

                        * Do you feel confident handing this to a team and saying, “Build it”?

If yes → You’ve completed the Offer Development Bootcamp. You now own a repeatable system for crafting, testing, and scaling irresistible offers.
________________

Use the Master Offer Blueprint workbook across all ten modules

RISER NATION CORP — IF YOU AREN'T BUILDING, YOU ARE DESTROYING

What the supplied workbook actually contains

The source is the RISER Nation Offer Development Bootcamp Master Offer Blueprint Workbook. It describes its purpose as guiding offer building, validation and launch. It contains ten named modules with blank forms. Each has one objective field, three numbered core-exercise fields and three deliverable fields: seven fields per module, seventy in total.

The blanks are intentional source content. They are not completed exercises, hidden answers or proof that a module has been finished. The original DOCX is retained. The examples below explain how to use the form and are newly authored applications; the workbook does not supply those answers.

How to fill one module form

Write the capability or output you intend to achieve in the objective. Use the three exercise lines for three concrete actions that support that objective. Use the three deliverable lines for three inspectable outputs or linked artifacts. Distinguish an action, such as reviewing customer feedback, from its output, such as a documented problem statement.

An objective should not promise a business result the exercise cannot establish. A filled checkbox does not demonstrate quality. Review the actual artifact against the objective and identify unresolved evidence or decisions. The following module-by-module suggestions preserve every form while giving you a practical way to complete it.

Module 1 — Foundation & Big Promise

An authored objective is to explain the intended customer problem and a supportable transformation. The three exercise lines can cover reviewing the problem evidence, mapping the ten milestones from the foundation lesson, and drafting a useful MIFGE concept. The three deliverables can be the paired problem/transformation statements, the milestone map, and a Big Promise with the linked gift concept.

Grouping related artifacts on one deliverable line is acceptable if the underlying work remains clear. Do not remove the foundation lesson's required outputs merely because the workbook has three slots. Check the promise against what the offer can actually deliver.

Module 2 — Audience & Market Research

An authored objective is to describe whom the offer serves using identifiable evidence. Exercise lines can cover collecting permitted existing customer evidence, grouping recurring needs, and identifying what remains uncertain. Deliverable lines can hold an audience description, an evidence summary with source links, and an open-question list.

This workbook supplies the module title, not a research protocol or completed avatar. Do not invent customer interviews or describe assumptions as findings. The related full module body remains a separate source to consult when available.

Module 3 — Crafting Offer Strategy

An authored objective is to connect a customer need to a feasible exchange. Exercise lines can define the intended outcome, list necessary delivery components, and compare the proposed scope with customer effort and business capacity. Deliverables can be an offer statement, a scope map, and an assumption/evidence record.

Keep the method and the result separate. A stack of materials is not automatically a strategy. The seven-layer architecture source can help you inspect vehicle, path, support, speed, safety, proof and price, while its conversion claims remain claims rather than guarantees.

Module 4 — Competitor Recon & Differentiation

An authored objective is to explain a defensible difference from relevant alternatives. Exercise lines can identify competitors, review their publicly available offer flows, and compare unmet needs. Deliverables can hold the completed recon records, comparison grid, and differentiation statement required by the related recon lesson.

That lesson asks for at least five completed competitor records. One workbook line may link the collection. Do not turn one blank line into permission to omit four competitors or copy their creative work. Publicly visible marketing does not establish actual conversion performance.

Module 5 — Pricing Psychology & Value Ladder

An authored objective is to explain the proposed price and progression between offers. Exercise lines can map relevant ladder tiers, examine delivery economics, and review how the customer understands the price and conditions. Deliverables can be the ladder, the price rationale, and a record of conditions and unresolved assumptions.

The workbook does not supply price points or a financial model. A high nominal stack value does not prove willingness to pay. Treat revenue, costs and forecast assumptions as different kinds of information, and do not label a price validated without supporting evidence.

Module 6 — Funnel Recipes & Page Strategies

An authored objective is to map a clear route from entry to the appropriate next action and delivery. Exercise lines can choose a suitable flow, specify each page's purpose, and identify normal, declined and failed paths. Deliverables can hold the page-flow map, page requirements, and a proposed verification checklist.

The module title is not a complete funnel recipe. Use separately assigned recipes when available, and mark missing instructions. This lesson does not initiate any funnel activation, checkout or purchase.

Module 7 — Copywriting & Messaging Mastery

An authored objective is to communicate the offer consistently and accurately. Exercise lines can draft a hook, develop a truthful or clearly hypothetical story, and write the offer and next action. Deliverables can be a message map, page copy, and a claim-evidence review.

This uses the hook–story–offer theme discussed in the foundation source. It does not mean that every page needs a long story. Check whether the reader can understand the result, actual scope, required effort and terms. Do not fill proof gaps with invented testimonials.

Module 8 — Bonuses, Stacks & Angles

An authored objective is to select useful additions and explain their role. Exercise lines can identify obstacles, map candidate bonuses to them, and assess duplication and fulfillment cost. Deliverables can be the proposed bonus inventory, the stack explanation, and the evidence or rationale for each component.

The integration source asks for at least three bonuses per core offer. Treat that as its exercise requirement, while recording any reason a smaller or different set would serve the customer better. The workbook itself contains no bonus bodies, templates or price anchors.

Module 9 — Platforms & Delivery Systems

An authored objective is to specify how the customer receives and uses the offer. Exercise lines can map access, allocate fulfillment responsibilities, and plan a test of onboarding and support. Deliverables can be the platform map, operating requirements, and the verification record or clearly labeled unexecuted test plan.

Do not equate naming software with implementing it. Record actual availability and dependencies. Planned automations must not be labeled active until they have been authorized, configured and checked in the relevant environment.

Module 10 — Final Offer Blueprint

An authored objective is to assemble a handoff another person can follow. Exercise lines can collect the preceding artifacts, reconcile inconsistent promises or prices, and rehearse the explanation of the plan. Deliverables can be the master blueprint, the supporting page/platform map, and the remaining-decision and verification record.

The related integration source requires seven master fields covering niche/avatar, offer statement, ladder/pricing, funnels/page flows, copy frameworks, bonuses/guarantees and platform/delivery. Keep all seven inside the linked blueprint. Three workbook deliverable lines do not reduce that scope.

Review the seventy fields without confusing completeness with readiness

Check each of the ten modules for one objective, three exercises and three deliverables. Where work is incomplete, identify the missing input rather than inserting a claim of completion. Where one field links several supporting artifacts, confirm the links work and the artifacts remain associated with the correct module.

The workbook title refers to validation and launch, but the blank form does not establish either. Separate drafted plans, evidence of testing, actual implementation and public launch. Preserve the original blank template alongside your working copy so another learner can see what was supplied and what you added.

Sources and related lessons

- Assigned Master Offer Blueprint workbook, a native DOCX file presented through a Google document link. - Foundation and ten-milestone source. - Seven-layer offer architecture. - Competitor-recon requirements. - Final integration and seven-field blueprint.

The full original form and original DOCX must accompany this lesson. These authored examples do not replace separate missing module bodies.

Assigned source links

D0453 original source 1

word/document.xml
RISER Nation Offer Development Bootcamp
Master Offer Blueprint Workbook
This workbook is designed as a step-by-step guide to build, validate, and launch your irresistible offers.
Module 1 – Foundation & Big Promise
Objective: ________________________________
Core Exercise:
1. _______________________________________
2. _______________________________________
3. _______________________________________
Deliverables:
✅ _______________________________________
✅ _______________________________________
✅ _______________________________________
---
Module 2 – Audience & Market Research
Objective: ________________________________
Core Exercise:
1. _______________________________________
2. _______________________________________
3. _______________________________________
Deliverables:
✅ _______________________________________
✅ _______________________________________
✅ _______________________________________
---
Module 3 – Crafting Offer Strategy
Objective: ________________________________
Core Exercise:
1. _______________________________________
2. _______________________________________
3. _______________________________________
Deliverables:
✅ _______________________________________
✅ _______________________________________
✅ _______________________________________
---
Module 4 – Competitor Recon & Differentiation
Objective: ________________________________
Core Exercise:
1. _______________________________________
2. _______________________________________
3. _______________________________________
Deliverables:
✅ _______________________________________
✅ _______________________________________
✅ _______________________________________
---
Module 5 – Pricing Psychology & Value Ladder
Objective: ________________________________
Core Exercise:
1. _______________________________________
2. _______________________________________
3. _______________________________________
Deliverables:
✅ _______________________________________
✅ _______________________________________
✅ _______________________________________
---
Module 6 – Funnel Recipes & Page Strategies
Objective: ________________________________
Core Exercise:
1. _______________________________________
2. _______________________________________
3. _______________________________________
Deliverables:
✅ _______________________________________
✅ _______________________________________
✅ _______________________________________
---
Module 7 – Copywriting & Messaging Mastery
Objective: ________________________________
Core Exercise:
1. _______________________________________
2. _______________________________________
3. _______________________________________
Deliverables:
✅ _______________________________________
✅ _______________________________________
✅ _______________________________________
---
Module 8 – Bonuses, Stacks & Angles
Objective: ________________________________
Core Exercise:
1. _______________________________________
2. _______________________________________
3. _______________________________________
Deliverables:
✅ _______________________________________
✅ _______________________________________
✅ _______________________________________
---
Module 9 – Platforms & Delivery Systems
Objective: ________________________________
Core Exercise:
1. _______________________________________
2. _______________________________________
3. _______________________________________
Deliverables:
✅ _______________________________________
✅ _______________________________________
✅ _______________________________________
---
Module 10 – Final Offer Blueprint
Objective: ________________________________
Core Exercise:
1. _______________________________________
2. _______________________________________
3. _______________________________________
Deliverables:
✅ _______________________________________
✅ _______________________________________
✅ _______________________________________
---

RISER Nation Offer Development Bootcamp
Master Offer Blueprint Workbook
This workbook is designed as a step-by-step guide to build, validate, and launch your irresistible offers.

Module 1 – Foundation & Big Promise
Objective: ________________________________
Core Exercise:
1. _______________________________________
2. _______________________________________
3. _______________________________________
Deliverables:
✅ _______________________________________
✅ _______________________________________
✅ _______________________________________

---

Module 2 – Audience & Market Research
Objective: ________________________________
Core Exercise:
1. _______________________________________
2. _______________________________________
3. _______________________________________
Deliverables:
✅ _______________________________________
✅ _______________________________________
✅ _______________________________________

---

Module 3 – Crafting Offer Strategy
Objective: ________________________________
Core Exercise:
1. _______________________________________
2. _______________________________________
3. _______________________________________
Deliverables:
✅ _______________________________________
✅ _______________________________________
✅ _______________________________________

---

Module 4 – Competitor Recon & Differentiation
Objective: ________________________________
Core Exercise:
1. _______________________________________
2. _______________________________________
3. _______________________________________
Deliverables:
✅ _______________________________________
✅ _______________________________________
✅ _______________________________________

---

Module 5 – Pricing Psychology & Value Ladder
Objective: ________________________________
Core Exercise:
1. _______________________________________
2. _______________________________________
3. _______________________________________
Deliverables:
✅ _______________________________________
✅ _______________________________________
✅ _______________________________________

---

Module 6 – Funnel Recipes & Page Strategies
Objective: ________________________________
Core Exercise:
1. _______________________________________
2. _______________________________________
3. _______________________________________
Deliverables:
✅ _______________________________________
✅ _______________________________________
✅ _______________________________________

---

Module 7 – Copywriting & Messaging Mastery
Objective: ________________________________
Core Exercise:
1. _______________________________________
2. _______________________________________
3. _______________________________________
Deliverables:
✅ _______________________________________
✅ _______________________________________
✅ _______________________________________

---

Module 8 – Bonuses, Stacks & Angles
Objective: ________________________________
Core Exercise:
1. _______________________________________
2. _______________________________________
3. _______________________________________
Deliverables:
✅ _______________________________________
✅ _______________________________________
✅ _______________________________________

---

Module 9 – Platforms & Delivery Systems
Objective: ________________________________
Core Exercise:
1. _______________________________________
2. _______________________________________
3. _______________________________________
Deliverables:
✅ _______________________________________
✅ _______________________________________
✅ _______________________________________

---

Module 10 – Final Offer Blueprint
Objective: ________________________________
Core Exercise:
1. _______________________________________
2. _______________________________________
3. _______________________________________
Deliverables:
✅ _______________________________________
✅ _______________________________________
✅ _______________________________________

---

Pricing architecture: credits, scope, buyer paths and evidence

RISER NATION CORP — IF YOU AREN'T BUILDING, YOU ARE DESTROYING

Assigned lessons: 03.1, 03.3, 03.4, 04.1 and 06.2.

What this source provides

This lesson teaches the reasoning in a commentary about an upgraded pricing widget. The opening claims eight improvements and describes audience selection, Launch/Evergreen toggles and live value-ratio and credit calculations. The body has seven headings; the last combines follow-up timing and affiliates. The actual widget, executable code, tier-timing diagram and individual-value grid are absent from the native document. We can teach its reasoning, but cannot claim that a functioning calculator was supplied, rebuilt or tested from this source.

You will distinguish the diagnostic offer from the implementation sprint, calculate a purchase credit, define scope, examine audience-specific price proposals and design an evidence-based path between offers. Source examples are proposals rather than adopted RISER prices or verified sales results.

1. Connect the offers with a clearly defined credit

The source proposes a $197 Diagnostic followed by a $500 Sprint. After completing the Diagnostic, the buyer receives a $97 credit toward a Sprint booked within seven days. The later Sprint payment becomes $403. The combined outlay is $197 + $403 = $600, compared with $697 for both products without the credit. The saving is $97, not the full diagnostic price.

The source's recommended credit range is approximately 40–50% of the diagnostic price. Here, $97 divided by $197 is about 49.24%. It argues that a small credit may not motivate action while a very large credit may weaken the Diagnostic's standalone perceived value. Treat the range and behavioral claims as design hypotheses requiring evidence, not universal conversion laws.

State the eligibility, when the seven-day window begins, how the credit is applied and whether it combines with other rates. The source says the message follows completion but does not fully specify the operational terms. Resolve those before implementation. Present the saving plainly rather than using the source's suggestion that a buyer should feel embarrassed to leave it unused. A buyer should be able to choose either offer without shame or confusion.

2. Teach what is not included

The Diagnostic exclusions are: no implementation, no revisions, no custom build work, no ongoing questions and answers, and no extra strategy sessions. Explain each boundary alongside the actual included deliverables. A diagnostic customer should understand that an assessment does not automatically include doing the work identified by that assessment.

The Sprint exclusions are: no open-ended consulting, no work outside the agreed scope, no post-handoff support beyond the stated window, and no strategy overhaul. Identify the actual agreed scope and support window; this document does not supply their values. Do not imply a customer forfeits a separately promised correction or support commitment simply because a general exclusion appears here.

The source identifies common assumptions such as unlimited questions, revisions whenever a buyer dislikes the first version and ongoing availability after handoff. Use clear terms to resolve those assumptions before purchase. Its assertion that exclusions increase conversion is not backed by results in this document. Clarity can support informed buying and delivery boundaries, but the conversion effect needs measurement.

3. Evaluate the audience-based pricing proposals

The source proposes these ranges for the same broad Diagnostic/Sprint sequence:

The document calls prosumers the most common RISER buyer, but supplies no audience distribution evidence. Do not report that as a verified current customer statistic. Its reasoning is that the economic importance of a problem differs by buyer. Validate the segment, needs and actual value rather than automatically assuming everyone in a category has the same willingness to pay.

The example compares a dog-training beginner with a Phoenix realtor and associates a lost $400,000 deal with $12,000 of lost income. That arithmetic assumes 3% of the transaction amount. The source does not establish an actual fee, net income or universal commission standard. The dog owner's nonfinancial needs also cannot be reduced to a presumed low value without evidence.

The source places audience selection before the Vol 3 Niche Specificity Gate, connecting audience to price, price to value ratio and ratio to its “impulse utility” concept. The actual gate and Doc 9 are absent here. Preserve that dependency and obtain the relevant material before claiming this lesson fully applies its criteria.

4. Calculate perceived-value ratios without manufacturing value

The stated formula is total perceived value divided by asking price. The proposed widget lists individual deliverable values, totals them and shows a ratio. The source attributes a minimum target of 10:1 and an optimum of 30:1 to Doc 7. It calls 30:1 an impulse-utility threshold. Doc 7 and the individual-value grid are not included in this native source, and no evidence establishes those thresholds as guaranteed buying behavior.

At a $197 asking price, $1,200 of estimated value produces about 6.09:1, rounded to 6:1 in the source. A 10:1 ratio requires $1,970; 30:1 requires $5,910. These are arithmetic results, not proof that buyers assign those values to the deliverables. A green indicator at 10:1 or above would indicate compliance with the chosen rule, not that the offer is objectively priced correctly.

The source suggests more specific deliverable naming and defensible market-rate anchors, or a lower price, when the ratio falls short. Naming alone cannot create substantiated economic value. Avoid double-counting overlapping items or inflating individual anchors to make a target turn green. Record how a proposed value was established and distinguish an estimate from an actual sale, customer outcome or independent comparison.

5. Make launch and evergreen terms real

For the prosumer example, the Diagnostic moves from $197 at launch to $247 evergreen. The Sprint moves from $350 to $500. The source proposes a first-100-buyers limit and illustrates an announcement that 67 sales have occurred. Neither number is a verified RISER sales count. Use a limit only when it is real, tracked and honored, with the actual price change disclosed.

The source expects early pricing to support access while social proof develops and suggests early buyers may become enthusiastic testimonial providers. Neither testimonials nor conversion improvement are guaranteed. Any eventual testimonials must reflect the buyer's actual experience, rather than being implied as a required favorable response to a discount.

Reconcile the launch prices with the credit example. If the same $97 credit applies to a $350 launch Sprint, the Sprint payment would be $253 and combined spending $450. At a $500 Sprint the combined spending is $600. The document does not define credit stacking across these modes, so clarify the policy before implementing or advertising either total. The general seven-day credit and the first-100 launch limit are separate conditions.

6. Offer two paths based on readiness

The source critiques a Vol 1 page where every buyer starts with the Diagnostic. It proposes two calls to action: start with a Diagnostic when the buyer is unsure what is wrong, or go directly to the Sprint when the buyer knows what needs to be built. Teach the actual difference in the work purchased and the readiness evidence required for direct implementation.

A second path should help a buyer make a clear choice. It does not literally double the number of customers or guarantee both groups convert. The source's claim about greater conversion among solution-aware buyers requires testing. The referenced Vol 1 page and Doc 9 are not included, so do not claim that their complete page designs have been reviewed from this document alone.

7. Sequence follow-up offers around customer progress

The source describes a timeline that would show when to introduce each tier after purchase. It warns against presenting every upsell at checkout and against never following up. The timeline itself and its tier-by-tier timing are absent. Do not invent dates and attribute them to the missing graphic.

An authored application is to define the completion evidence and readiness that make the next offer useful. The Diagnostic-to-Sprint credit is one specified example; other tiers require the actual supporting material. Track whether follow-up serves a buyer's next task instead of assuming that every customer needs every product. Planning the follow-up is separate from activating a campaign or sending messages.

8. Evaluate an affiliate program after verified use

The source proposes 30–40% commission on referred sales, introduced at Month 6 or later to buyers with verifiable results. Its invitation criteria are either a first $1,000 earned using the Forge, or completion of the Ignition Engine plus deployment of at least one offer. Preserve the OR relationship: it does not require both achievements. These are proposed eligibility criteria, not proof that any buyer has achieved them or that an affiliate program is active.

Verify the actual result and experience before making an invitation decision. Completing a program or reaching a revenue milestone does not by itself establish that every recommendation will be accurate or that only authentic advocates can qualify. The source claims the channel can compound without additional content effort; operating a referral program still requires terms, tracking, support and review. Do not present commission as effortless or guaranteed income.

The document supplies no full program terms, attribution window, refund treatment or definition of commissionable revenue. Resolve those details before any program implementation. No invitations, purchases or commission payments are executed by this lesson.

Integrate the marketing themes and practice

In an authored Brunson/ClickFunnels application, the credit and readiness-based paths connect a customer's next decision to a clearly explained offer sequence. Maintain a useful standalone Diagnostic and an understandable implementation path. The source does not supply a ClickFunnels configuration or direct Brunson quotation.

In an authored Hormozi/Acquisition.com application, assess perceived value alongside the desired result, evidence, customer effort and delivery time. Clear scope and an honest price comparison support that assessment; a large invented value total does not. Keep the 10:1 and 30:1 source targets separate from verified customer outcomes.

For practice, select an evidence-supported audience, define both scopes, calculate the credit and total customer outlay under each applicable price mode, document value assumptions, and explain the two entry paths. Identify the missing timing and affiliate terms before considering implementation. This produces a reviewable pricing specification, not a tested widget or a published commercial offer.

Clickable sources and outstanding dependencies

- Assigned original pricing-widget commentary — native text reviewed; full original text must accompany this teaching script. - RISER NATION CORP — brand destination.

The actual widget/code, individual-value grid, timing diagram, Doc 7, Doc 9, Vol 1 page and Vol 3 Niche Specificity Gate are not supplied in this native source. Their exact applicable references remain unresolved. Obtain those materials before claiming to have implemented or verified the missing elements. The original's assertions about conversion, urgency and affiliate growth remain source claims until supported by evidence.

Assigned source: D0472 original 1

Now building the upgraded interactive pricing tool with all 8 improvements:The widget above is fully interactive — switch between Consumer, Prosumer, and Business Owner to see prices recalibrate across all tiers, toggle between Launch and Evergreen pricing, and watch the value ratio and credit ascension numbers update in real time.
Here is the full reasoning behind every change from the previous version.

The credit-based ascension model — the most important structural change
The previous offer stack showed two separate products with two separate prices. The credit model connects them mechanically. The buyer pays $197 for the Diagnostic, completes it, and receives a message: "$97 of your Diagnostic price applies toward the Sprint if you book within 7 days." The effective Sprint price drops from $500 to $403 for that buyer — but only if they act within the window. This changes the psychology of the first purchase completely. The buyer isn't choosing between spending $197 and $500 — they're choosing whether to spend $197 now and $403 later, or $197 now and $500 later. The $97 difference feels almost embarrassing to leave on the table. The credit mechanic is what makes the ladder feel like a continuous decision rather than two separate selling events.
The credit amount should be approximately 40-50% of the Diagnostic price. Too low and it doesn't create urgency. Too high and the Diagnostic loses perceived value as a standalone purchase.

The "What is NOT included" section — scope protection for productized services
This is the single most overlooked element in knowledge service pricing. The instinct is to list everything the buyer receives — but equally important is what they cannot reasonably expect. Without explicit exclusions, every buyer arrives with assumptions: that they can email you unlimited questions after the Diagnostic, that the Sprint includes revisions if they don't like the first version, that you'll be available ongoing after the handoff.
The widget now shows the NOT included list for both offers. For the Diagnostic: no implementation, no revisions, no custom build work, no ongoing Q&A, no extra strategy sessions. For the Sprint: no open-ended consulting, nothing outside the agreed scope, no post-handoff support beyond the stated window, no strategy overhaul.
These lists do not reduce conversion — they increase it. A buyer who sees a clear scope feels confident about what they're purchasing. A buyer who senses ambiguity either asks for more detail (friction) or declines (lost sale). Clarity on limits paradoxically creates more confidence in the offer.

The audience-based pricing matrix — same offer, three different prices
The previous stack had one price per tier. Doc 9 is explicit that the correct price depends on who is buying. A dog training beginner and a Phoenix realtor are both buying "a Diagnostic" but the problem costs them very different amounts to leave unsolved. The realtor losing a $400K deal has a $12,000 cost-of-inaction. The dog training hobbyist losing time with a badly behaved dog has a much lower financial stake.
The matrix in the widget shows how prices shift across three audience types. For the prosumer audience (the most common RISER buyer): Diagnostic $197 launch, Sprint $350-$500. For business owners: Diagnostic $247-$297, Sprint $500-$750. For consumers: Diagnostic $147, Sprint $297-$350. The operator should select their audience type before filling in the Vol 3 Niche Specificity Gate — because the audience type determines the price, which determines the value ratio, which determines whether the impulse utility threshold is reached.

The value stack with individual perceived values and the 10:1 ratio target
The previous widget listed tiers with a single price. This version shows individual perceived values for each deliverable, a total perceived value, and a real-time value ratio calculated as Total Perceived Value ÷ Asking Price.
The minimum target from Doc 7 is 10:1. The optimum is 30:1 — the "impulse utility" threshold where the purchase decision stops feeling like a cost and starts feeling like a no-brainer. At the prosumer Diagnostic price of $197, if the total perceived value of deliverables is $1,200, the ratio is 6:1 — below threshold. To hit 10:1 at $197, the deliverables need to credibly total at least $1,970. The operator either needs to raise the perceived value of individual items (by naming them more specifically and anchoring to market rates) or lower the price.
The value ratio indicator in the widget shows a green checkmark at 10:1+ and a warning below that threshold. This gives operators immediate feedback on whether their offer stack is priced correctly relative to its perceived value.

Launch pricing vs. evergreen pricing — the escalation plan
Toggle between Launch and Evergreen in the widget to see the price difference. For the prosumer Diagnostic: $197 launch → $247 evergreen. For the Sprint: $350 launch → $500 evergreen. These aren't arbitrary — the launch price creates genuine urgency (the price actually increases) while keeping the entry point accessible during the period when social proof is being built.
The "first 100 buyers" framing does two things: it creates urgency with a specific, believable limit, and it positions early buyers as getting a special rate for being early — which makes them feel smart for acting now and makes them more likely to be enthusiastic testimonials. The shift to evergreen should happen publicly, announced in content: "The launch price of $197 closes when I hit 100 sales. I'm at 67 right now." That kind of transparency converts better than artificial countdown timers.

The split-path landing page
The current sales page in Vol 1 assumes every buyer enters through the Diagnostic. Doc 9 identifies that solution-aware buyers — people who already know they need something built, not just diagnosed — will convert better if they can skip the Diagnostic and go straight to the Sprint.
The split-path at the bottom of the widget shows two simultaneous CTAs: "Not sure what's wrong with your offer yet? Start with the Diagnostic" and "Already know what you need built? Go straight to the Sprint." This doubles the surface area of the landing page without adding length — solution-aware buyers see an immediate path, problem-aware buyers see their path. One page, two audiences, both converting.

The backend monetization timeline and the affiliate flywheel
The timeline at the top of the widget shows when to introduce each tier after purchase. This is the detail most operators miss — they either hit buyers with every upsell at checkout (overwhelm, refunds) or they never follow up after the initial purchase (lost ascension revenue).
The affiliate flywheel is the long-term growth mechanism missing from the entire stack. Buyers who achieve a result using the tools have both the incentive and the credibility to recommend them. An affiliate programme where they earn 30-40% commission on any sale they refer creates a distribution channel that compounds without additional content effort. This doesn't need to be built at launch — it should be offered at Month 6+ to buyers who have verifiable results. The criteria for the affiliate invite: "You've made your first $1,000 using the Forge, or you've completed the Ignition Engine and deployed at least one offer." That filter ensures only genuine advocates promote the product.

Decompose the mechanism and create three distinct offer variants

RISER NATION CORP — IF YOU AREN'T BUILDING, YOU ARE DESTROYING

Assigned lessons: 03.1, 03.3, 03.4, 07.1 and 12.4. Legacy C4/M4.3 references belong to the source workflow and do not replace the spreadsheet mapping.

What you will produce

You will assemble a Mechanism Decomposition Inventory and three offer variants, then check that the variants represent distinct delivery choices before selecting one. This source reviews structural discipline. It postpones the deeper quality and coherence judgment until M4.8, when a selected variant can be assessed in context.

The source calls the requirement to create three variants before selection part of its “6% Rule.” This YAML does not explain the origin or calculation of that percentage. Teach the stated three-variant discipline without presenting 6% as an established probability or inventing the missing theory.

Bring three actual inputs: `mechanism_decomposition`, `offer_variants_document` and `student_m42_synthesis`. They are required strings in the source schema. The synthesis provides earlier context; a missing synthesis must remain an evidence gap rather than an invitation to invent the learner's conclusions.

Check 1: produce exactly three developed variants

Label the variants A, B and C, or use an equally clear three-part labeling system. Each variant should contain 500–700 words. The total variant text is therefore 1,500–2,100 words, apart from the separate decomposition inventory. A title and price do not constitute a developed variant.

The purpose is to make three alternatives reviewable before choosing a lead offer. Having three drafts is not proof that one will sell. This stage establishes that meaningful alternatives exist for the subsequent pricing and coherence work.

Check 2: compare every pair on four axes

Each variant must differ from each of the other two on at least three of four axes:

Make three comparisons: A versus B, A versus C, and B versus C. Count the differing axes for each pair. Comparing only A with the others leaves the possibility that B and C are effectively the same.

For illustration, A could be cohort/short/high-density/floor, B one-to-one/medium/medium-density/median, and C self-paced/long/low-density/ceiling. These authored labels differ on all four axes, but that arithmetic does not prove the combinations are commercially sensible or deliverable. Use real evidence and rationale to design the actual variants. The YAML does not define quantitative density cutoffs, so state your basis instead of treating an unexplained “high” label as proof.

Three otherwise identical offers with three prices differ on only one axis. The source explicitly treats that as one variant at three prices. Also avoid treating small changes within the same stated duration band as an automatic band difference.

Check 3: include all eight subsections in each variant

1. Variant name: use a distinct working name and preserve its naming-review record.
2. Engagement model and rationale: explain both the chosen format and why it fits this variant.
3. Duration and rationale: state the length and why that delivery window is appropriate.
4. Deliverables included: identify the primary items the buyer receives. Keep optional add-ons distinguishable.
5. Price-band placeholder: name the relevant observed C3 band. This is a placeholder for later pricing work, not an invented final price.
6. Value Equation weakness targeted: name the weakness this variant is designed to address and how its architecture addresses it.
7. Buyer fit: identify the best-fit subsegment from the actual C3 interview pool.
8. Known tradeoffs: describe the costs or limitations of choosing this configuration. Do not present every variant as universally best.

The checklist asks for structure, but useful content still matters. A subsection heading with no explanation gives the next reviewer little to work with.

Check 4: distinguish the weakness or the reversal mechanism

Each variant should target a different Value Equation weakness. The source permits the same weakness when the mechanism for reversing it differs. Three variants aimed at the same weakness through the same mechanism collapse into one option.

For example, two variants could address customer effort through different delivery arrangements, but you must explain the actual difference rather than merely relabel it. That is an authored application of the criterion. Trace your selected weakness to the learner's M4.2 synthesis; this YAML does not supply the learner's diagnosis.

Check 5: identify a distinct buyer fit

Name a different best-fit subsegment of the C3 interview pool for each variant. Use the interviews and observed needs to explain that fit. Do not invent people or infer needs from demographic stereotypes to satisfy a differentiation count.

The source says three variants for the same buyer amount to one variant at this stage. That is its design rule for this exercise, not a universal claim that a business can never offer multiple products to the same customer. Preserve the exercise's requirement while explaining its scope.

Check 6: review the mechanism inventory

The source expects 6–10 deliverables from decomposition of a four-pillar mechanism. Fewer than six suggests incomplete decomposition; more than ten suggests over-decomposition. Examine how each deliverable follows from the mechanism and whether an item is a meaningful customer-facing unit rather than an arbitrarily split task.

The YAML does not define the four pillars themselves. Use the actual mechanism artifact and retain its terminology. Do not supply an invented four-part theory to close a missing prerequisite.

Distinguish the inventory count from the deliverables selected for one variant. An inventory can contain ten candidates while a variant includes only six primary deliverables. This distinction matters because the next check uses a different threshold.

Flag feature stuffing without assuming its cause

Count primary deliverables in each variant; exclude items merely available as add-ons. Eight or fewer produces no feature-stuffing flag. More than eight produces a warning that must identify the variant and its count.

The source asks whether the learner is compensating for weak Dream Outcome or Perceived Likelihood by adding deliverables. If that pattern is supported, route the design back for revision; otherwise proceed with caution through the responsible review. A high count alone does not prove the learner's motive or diagnose the weakness. Examine the evidence and the effect of each item.

One named failure example is a variant with twelve or more deliverables. The source routes it to mentor review and describes numerator-weakness compensation as likely. Teach that as a hypothesis to investigate, not a proven fact or an instruction to send outreach automatically.

The later D0477 architectural reviewer asks for 8–15 customer-facing deliverables. Preserve that cross-source difference. It may concern a later stage or a different granularity. Explain the stage and counting basis in the applicable lesson instead of silently imposing a single universal cap on every offer.

Verify the naming work

Every variant name must have been evaluated using the C2 5-Test Naming Filter referenced by the Variants Worksheet. Flag names that were never evaluated and names that failed one or more tests without being renamed.

This YAML does not include the five tests. Obtain the actual worksheet or applicable source and retain its exact criteria. Do not substitute five invented naming tips and call them the source's filter. A catchy name is not evidence that the required evaluation happened.

The source's known failure example requires the learner to perform the filter and rename where necessary before M4.4. Record what is missing and the needed action; do not claim that an unavailable naming record passed.

Resolve the verdict rules transparently

The stated main rules are: all six structural checks passing with no feature-stuffing or naming flag produces PASS; four or five passing checks with minor, revisable issues produces NEEDS_REVISION; fewer than four passing checks or feature stuffing across multiple variants produces FAIL.

Several branches need clarification. Six passing checks plus a naming flag or one feature-stuffing flag do not receive a fully specified outcome. The feature-stuffing explanation says a flag does not automatically fail a submission, but the main logic explicitly fails stuffing across multiple variants. The price-only example says FAIL even though a single failed axis check might otherwise leave five checks and suggest revision. Preserve these conflicts and describe the concrete deficiencies; do not invent a deterministic aggregate verdict that the source does not supply.

Missing evidence is also different from a confirmed false claim. The boolean schema has no unknown state, so explain unavailable evidence in the feedback and have the responsible reviewer resolve the record. A machine-readable value must not conceal uncertainty.

Preserve the output fields and actionable feedback

The source requires five top-level output groups: `verdict`, `structural_checks`, `feature_stuffing_flag`, `naming_flag` and `feedback`. The verdict values are PASS, NEEDS_REVISION and FAIL.

The six structural booleans are `three_variants_present`, `each_variant_differs_on_3_of_4_axes`, `each_variant_has_all_8_subsections`, `each_variant_has_distinct_weakness_target`, `each_variant_has_distinct_buyer_fit` and `decomposition_deliverables_6_to_10`.

The feature-stuffing group contains boolean `any_variant_over_8_deliverables`, string-or-null `flagged_variant` and integer-or-null `flagged_deliverable_count`. These singular fields are insufficient by themselves to enumerate multiple flagged variants; retain every affected variant and count in the feedback rather than dropping additional findings.

The naming group contains boolean `all_names_5_test_evaluated` and an array of strings, `variants_failing_5_test`. Distinguish never evaluated from evaluated and failed in the feedback even if both require a naming flag.

Feedback contains string arrays `strengths`, `gaps` and `action_items`. Give one to three supported strengths where present. Cite the affected variant and check for every gap. Write concrete revisions, such as reconsidering B's duration because it duplicates A's band, while preserving a defensible delivery rationale. Arbitrarily changing a number just to pass is not sound design.

The schema names nested properties without requiring all of them individually. Valid JSON alone does not prove that all six checks or every finding were supplied. The embedded instruction to return JSON only governs the described reviewer configuration, not the prose format of this teaching lesson.

Review the four source failure examples

Check for three prices attached to otherwise identical variants; one variant with twelve or more deliverables; identical weakness targets using identical mechanisms; and omitted naming-filter evaluation. The corresponding actions are to create real axis divergence, investigate feature stuffing with the responsible reviewer, diversify the weakness or reversal mechanism, and complete the actual naming filter with renaming where needed. Retain the verdict conflicts above when interpreting these examples.

Apply the RISER marketing themes

In an authored Brunson/ClickFunnels application, make each variant's buyer, promise and delivery structure clear enough to explain on a customer-facing page. Naming and offer presentation should communicate a real distinction that the delivery model supports. This YAML does not quote Brunson or define a funnel implementation.

In an authored Hormozi/Acquisition.com application, use the Value Equation weakness to explain why a variant exists. More deliverables do not automatically produce greater value. Examine the desired outcome, confidence in achieving it, and the customer's time and effort when justifying the architecture. Keep those applications separate from the source's unverified numerical “6%” label and do not claim proven sales results.

Practice, handoff and source resources

Complete the inventory and the three 500–700-word variants. Review all three pairwise axis comparisons, all twenty-four required variant subsections, weakness/reversal differences, buyer fit, inventory size, primary-deliverable counts and naming records. Produce the complete findings and revision actions. Leave missing prerequisites and unresolved verdict policy visible.

The source routes variants into M4.4 pricing, typically pricing all three to inform lead-variant selection, and into M4.8 offer-fit validation for coherence review. Passing this structural exercise does not mean those later steps have happened.

The original identifies `offer-decomposition-reviewer` version 1.0.0, model `claude-sonnet-4-6`, temperature 0.1, a 2,000-token maximum and estimated cost of USD $0.04–$0.08 per call. These are source settings and an estimate, not a verified current service specification, executed model call or measured user charge. Governance calls for quarterly review by `curriculum-quality-team` and identifies the Build 6 M4.3 checkpoint handler as a consumer. The YAML does not prove that this integration is deployed.

- Assigned original offer-decomposition reviewer — complete original YAML also preserved in the accompanying source appendix. - RISER NATION CORP — brand destination.

Bring your M4.2 synthesis, C3 interviews and price-range evidence, mechanism artifact and Variants Worksheet/C2 Naming Filter to this exercise. The YAML does not supply their completed contents or exact links, so those prerequisites remain unverified until you provide the applicable records. Use the accompanying complete original to check the review requirements; do not treat missing evidence as a completed check.

Assigned source: D0474 original 1

prompt_name: offer-decomposition-reviewer
version: 1.0.0
purpose: >
  Structural verification of M4.3 student-submitted Mechanism Decomposition
  Inventory and Three Offer Variants. Validates that three distinct variants
  exist (each differing on ≥ 3 of 4 axes), that no variant contains > 8 primary
  deliverables (Feature Stuffing check), and that the C2 5-Test Naming Filter
  has been applied to each variant name. Unlike qualitative reviewers, this
  check is primarily structural — quality judgment waits until M4.8.
model: claude-sonnet-4-6
temperature: 0.1
max_tokens: 2000
cost_per_call_estimate_usd: 0.04-0.08

input_schema:
  type: object
  required: [mechanism_decomposition, offer_variants_document, student_m42_synthesis]
  properties:
    mechanism_decomposition: {type: string}
    offer_variants_document: {type: string}
    student_m42_synthesis: {type: string}

output_schema:
  type: object
  required: [verdict, structural_checks, feature_stuffing_flag, naming_flag, feedback]
  properties:
    verdict: {type: string, enum: [PASS, NEEDS_REVISION, FAIL]}
    structural_checks:
      type: object
      properties:
        three_variants_present: {type: boolean}
        each_variant_differs_on_3_of_4_axes: {type: boolean}
        each_variant_has_all_8_subsections: {type: boolean}
        each_variant_has_distinct_weakness_target: {type: boolean}
        each_variant_has_distinct_buyer_fit: {type: boolean}
        decomposition_deliverables_6_to_10: {type: boolean}
    feature_stuffing_flag:
      type: object
      properties:
        any_variant_over_8_deliverables: {type: boolean}
        flagged_variant: {type: [string, "null"]}
        flagged_deliverable_count: {type: [integer, "null"]}
    naming_flag:
      type: object
      properties:
        all_names_5_test_evaluated: {type: boolean}
        variants_failing_5_test: {type: array, items: {type: string}}
    feedback:
      type: object
      properties:
        strengths: {type: array, items: {type: string}}
        gaps: {type: array, items: {type: string}}
        action_items: {type: array, items: {type: string}}

system_prompt: |
  You are performing structural verification on a C4 M4.3 deliverable — the
  Mechanism Decomposition Inventory and Three Offer Variants document.

  Unlike qualitative reviewers, your job is NOT to judge the quality of the
  variants. Quality judgment happens at M4.8 when a single variant is selected
  with full context. Your job is to verify that the structural discipline of
  the 6% Rule (three variants exist before selection) has been honored, and
  that the Feature Stuffing Trap has not crept in.

  # Structural Checks (all must be true for PASS)

  ## Check 1 — Three Variants Present
  - The document contains exactly 3 variants, labeled A, B, C (or equivalent)
  - Each variant is 500-700 words

  ## Check 2 — Axis Divergence
  Each variant must differ from the other two on at least 3 of these 4 axes:
  - Engagement model (cohort / 1:1 / self-paced / hybrid)
  - Duration (short 2-4wk / medium 5-8wk / long 9+wk)
  - Deliverable density (high / medium / low)
  - Price band (floor / median / ceiling of observed C3 range)

  Three variants that differ only in price are NOT three variants — they are
  one variant at three prices, which fails this check.

  ## Check 3 — 8 Sub-Sections Per Variant
  Each variant has all 8 required sub-sections:
  1. Variant name
  2. Engagement model + rationale
  3. Duration + rationale
  4. Deliverables included
  5. Price band placeholder
  6. Value Equation weakness targeted
  7. Buyer fit
  8. Known tradeoffs

  ## Check 4 — Distinct Weakness Targets
  Each variant should target a different Value Equation weakness (or, if
  same weakness, different mechanism for reversal). Three variants targeting
  the identical weakness via identical mechanisms indicates the variants
  collapse into one.

  ## Check 5 — Distinct Buyer Fit
  Each variant should name a different sub-segment of the C3 interview pool
  as best fit. Three variants for the same buyer = one variant.

  ## Check 6 — Decomposition Deliverables 6-10
  The Mechanism Decomposition Inventory typically produces 6-10 deliverables
  from a well-structured 4-pillar mechanism. Fewer than 6 suggests incomplete
  decomposition; more than 10 suggests over-decomposition.

  # Feature Stuffing Flag

  For each variant, count primary deliverables (not "available as add-on" items).

  - Deliverables ≤ 8 per variant: no flag
  - Any variant > 8 deliverables: Feature Stuffing Trap warning; name the variant and count

  A Feature Stuffing flag does not automatically FAIL the submission. It triggers
  a review action: is the student compensating for weak numerator variables
  (Dream Outcome, Perceived Likelihood) by loading deliverables? If yes, route
  back. If no, proceed with caution.

  # Naming Flag

  For each variant, verify the 5-Test Naming Filter has been applied (per the
  Variants Worksheet). Flag any variant name that has not been 5-Test evaluated
  OR has been evaluated and failed one or more tests without being renamed.

  # Verdict Logic

  - All 6 structural checks pass + no Feature Stuffing flag + no Naming flag → PASS
  - 4-5 structural checks pass, minor issues resolvable in revision → NEEDS_REVISION
  - < 4 structural checks pass OR Feature Stuffing present across multiple variants → FAIL

  # Feedback Structure

  Strengths: 1-3 observations (typically structural — "three genuinely distinct variants" etc.)
  Gaps: specific structural issues, citing which variant and which check
  Action items: concrete revisions ("Variant B duration is identical to Variant A; revise Variant B duration to medium band")

  # Output

  Return JSON only. No preamble, no postamble.

known_failure_modes:
  - scenario: Three variants at three price points but otherwise identical
    mitigation: Check 2 fails; FAIL verdict; student produces genuinely distinct variants
  - scenario: One variant has 12+ deliverables (Feature Stuffing Trap)
    mitigation: Feature Stuffing flag triggered; mentor review; likely indicates numerator-weakness compensation pattern
  - scenario: Variants target identical weakness with identical mechanism
    mitigation: Check 4 fails; student diversifies either target or reversal mechanism
  - scenario: Student skipped 5-Test Naming Filter on variants
    mitigation: Naming flag triggered; student runs 5-Test and renames if needed before M4.4

governance:
  review_cadence: quarterly
  owner: curriculum-quality-team
  consumed_by: Build 6 M4.3 checkpoint handler
  downstream: variants feed M4.4 pricing (pricing typically applied to all 3 to inform lead-variant selection); variants feed offer-fit-validator at M4.8 for coherence check

Offer fit: verify coherence from the original mechanism to the buyer-facing promise

RISER NATION CORP — IF YOU AREN'T BUILDING, YOU ARE DESTROYING

Assigned lessons: 03.1, 03.3, 03.4, 07.1 and 12.4. Source C1–C5/M4.8 references describe its legacy workflow, not replacement assignments.

Purpose and prerequisites

This lesson teaches the deeper review that follows the offer-readiness structural PASS. You will compare the offer with its mechanism, market evidence, pricing decisions, guarantees and original operator commitments. Structural presence alone cannot detect a promise that quietly changed between documents.

The source describes this as the C4 completion gate before C5 First Currents, checking eight C4 deliverables alongside C1 territory artifacts and the C3 Market Fit Hypothesis. It claims an error here can cause many hours of later rework; that is a source rationale, not measured RISER time savings. A completed comparison supports a review decision, not proof of future demand or commercial success.

Collect all thirteen required inputs: `readiness_document`, `first_sale_readiness_checklist`, `landing_page_copy`, `trigger_bank_provenance_log`, `student_c3_market_fit_hypothesis`, `student_c3_primary_mechanism`, `student_c3_trigger_bank_excerpt`, `student_c3_pricing_signals`, `student_c1_territory_clause`, `student_c1_operator_identity`, `student_m42_value_equation`, `student_m45_anti_promise` and `student_m46_guarantee`. The primary-mechanism input is an object with `name` and `four_pillar_summary`; the others are strings. The schema does not individually require those nested mechanism properties, so a valid object can still be inadequate evidence.

The checks also require the M4.4 Pricing Decision, M4.1 Distinction Memo, exact commitment template and evidence of the prerequisite structural PASS. Those are not explicit required input fields in this YAML. Obtain them from the applicable records before claiming their checks are complete. The source does not supply completed learner artifacts or define the four pillars for you.

Layer 1: compare the artifacts, field by field

1.1 — Offer and landing page. Compare the readiness offer with Landing Page Section 5. They must use the same deliverable name, with actual 5-Test naming evidence; price; engagement model; duration; cadence; and deliverables. List order may differ, but substance must match. Record substantive differences rather than treating matching titles as proof of matching delivery.

1.2 — Pricing. Compare Readiness Sections 1 and 3, Landing Page Section 5 and the M4.4 Pricing Decision. Confirm the same numeric anchor and payment options. The source specifies an anchor number rather than a range. Record a mismatch precisely; do not silently choose one price as authoritative without the approved decision.

1.3 — Anti-promise. Compare Readiness Section 5 with M4.5. Preserve the same three exclusion categories, outcome non-claims and scope boundaries. Flag exclusions that were softened, removed or made less specific. The source's example changes “Illustrators earning under $3K/month” into “Best for established illustrators.” The latter loses the precise boundary. This is the source's example, not a newly adopted RISER customer eligibility rule.

1.4 — Guarantee. Compare Readiness Section 5 with M4.6 for type, activation conditions and exclusions. The named types are hybrid, refund, outcome, time-shift and effort-adjusted. Flag extra components added beyond the approved architecture. Preserve the actual conditions; the YAML supplies no complete guarantee contract to adopt.

1.5 — Value Equation. Compare Readiness Section 4 with M4.2 for the same strongest variable, weakest variable and structurally fixed variables. Flag swapped or silently reconfigured conclusions. An updated diagnosis needs documented evidence and revision, not a convenient rewrite of earlier findings.

Layer 2: trace the offer back to C1–C3

2.1 — Territory. Compare the target buyer with Clause 1 of the C1 Captain's Oath. Flag buyers outside that territory and expansions or narrowing without the source's required re-attestation. Do not infer that an old territory statement has been formally revised.

2.2 — Operator identity. Compare the offer's voice and delivery with the stated archetype. The source describes Teacher-Operator as typically cohort-leaning with compatible teaching language and Service-Operator as typically one-to-one-leaning with service language. It also names Builder, Creative, Systems and Product but does not define their adjustments here. Its example concern is a Teacher-Operator offering pure done-for-you service with no teaching component. Treat “typically” as a contextual cue, not a universal prohibition on other delivery models. Use the actual identity artifact for unresolved definitions.

2.3 — Primary mechanism. Compare Landing Page Section 3, the Method, with the four pillars of the C3 M3.7 Primary. A matching mechanism name is insufficient if the audience pillar or intended outcome changed underneath it. Identify a different mechanism disguised under the old name and return the discrepancy for diagnosis.

2.4 — Customer-language provenance. Check each of the fifteen or more entries cited in the provenance log against the supplied Trigger Bank source. Record the quote, citation and matching evidence. The source labels unverified entries as fabrication and calls for a blocking flag. An excerpt can be incomplete, however: absence from that excerpt alone does not prove that someone fabricated the quote. Retrieve the complete relevant evidence or record the entry as unverified pending review. Never invent customer language to satisfy the count or accuse a learner of fabrication without adequate evidence.

2.5 — Pricing signals. Determine whether the M4.4 anchor falls within the observed C3 band or departs from it with documented rationale. An outside-band price with no rationale is a finding. An outside-band price is not automatically unsupported when its documented reasoning is available. Preserve the distinction in both the consistency and deviation-rationale output fields.

Layer 3: expose uncertainty and silent drift

3.1 — Known weaknesses. Read Readiness Section 7 for at least three specific weaknesses. Examples include a perceived-likelihood gap grounded in a particular case count, traffic uncertainty, variant concerns or operator constraints. Flag “minor polishing,” “none that I can think of” and “nothing material” when they replace analysis. Do not invent negative evidence merely to reach a count; identify unresolved risks honestly.

3.2 — Next-stage questions. Read Section 8 for at least three specific, testable questions naming what C5 must answer. Replace “need to see what works” with the actual uncertainty, measurement or decision. These questions should support learning rather than promise that the next stage will succeed.

3.3 — Stop criteria. Check Category D for at least three criteria, each with a numerical threshold and a remediation path. “If things go badly, reconsider” is not testable. Define the metric and observation window in the learner's actual plan; do not invent universal enrollment or refund thresholds.

3.4 — Mechanism continuity. Compare the C3 mechanism copied into M4.1 Distinction Memo Section 1 with Readiness Section 2. Flag an undocumented change between the beginning and end of C4. This comparison requires the missing explicit M4.1 input noted above; the current mechanism alone cannot establish historical continuity.

Layer 4: count the architecture and investigate excess

4.1 — Deliverables. Count named primary deliverables in Readiness Section 3 and Landing Page Section 5. The source flags more than eight. Treat the count as a design warning that needs explanation rather than proof of motive.

4.2 — Guarantee components. Count distinct structures, with a maximum of two in this exercise. The source counts refund plus outcome extension as two and refund plus outcome plus satisfaction plus quality as four. Identify the actual commitments rather than counting headings alone.

4.3 — Exclusions. Count specific exclusion categories in Anti-Promise Section 2. The stated range is three to six. Fewer than three suggests inadequate filtering; more than six suggests excluding intended buyers. These are source review thresholds, not universal business laws. D0477's later architecture review requests larger deliverable and anti-promise lists; keep the stage and counting unit explicit rather than silently reconciling incompatible numbers.

Layer 5: verify the actual commitment

5.1 — Signature. Check that Section 9 reproduces the template commitment verbatim and contains the operator's name and date. The source says the learner cannot alter that commitment. Compare with the actual template; without it, exact matching remains unverified. Do not sign for the operator or claim that filled fields authenticate identity.

Severity, verdicts and unresolved policy

The source uses BLOCKING, WARNING and NOTE. It lists lineage drift, unverified Trigger Bank entries labeled fabrication, silent mechanism drift and an unsigned commitment as blocking categories. It lists softened exclusions or guarantees, feature stuffing, vague weaknesses/questions/stop criteria and an unrationalized price deviation as warnings. A note surfaces an observation without changing the verdict.

The final verdict logic says all checks passing or only notes yields PASS; warnings with no blocking flags yield NEEDS_REVISION; any blocking flag yields FAIL. Its introduction instead says a blocking flag may produce NEEDS_REVISION or FAIL depending on count and severity. It also labels any Layer 2 drift blocking while specifically listing the Layer 2.5 price deviation as a warning. Preserve these policy conflicts for the responsible reviewer. Do not silently invent a consistent automated rule or use missing evidence as a confirmed accusation.

The described PASS marks C4 complete and unlocks C5 enrollment. FAIL routes to mentor-supported diagnosis, often reopening C3 M3.7. These are described workflow consequences; this lesson does not execute enrollment changes, send a mentor message or establish that an automated queue exists.

Record every output group

The schema requires `verdict`, `coherence_checks`, `lineage_checks`, `anti_bias_checks`, `feature_stuffing_check`, `flags` and `feedback`.

The coherence booleans are `offer_section_matches_landing_page`, `price_consistent_across_artifacts`, `anti_promise_not_softened_in_readiness`, `guarantee_not_softened_in_readiness` and `value_equation_conclusions_match_m42`.

The lineage booleans are `offer_serves_c1_territory`, `offer_voice_matches_c1_operator_identity`, `offer_built_on_c3_primary_mechanism`, `trigger_bank_entries_verified_in_source`, `price_consistent_with_c3_pricing_signals` and `price_deviation_rationalized_if_present`. Explain whether a deviation actually exists rather than letting an unexplained boolean imply one.

The anti-bias booleans are `known_weaknesses_substantive`, `c5_questions_specific_and_testable`, `kill_criteria_specific_and_testable` and `no_drift_from_c3_primary`. The feature checks are `deliverables_count_le_8`, `guarantee_components_le_2` and `anti_promise_exclusions_in_3_to_6_range`.

Each flag contains `severity`, `check`, `description` and `artifact`. Record the signature check here because it has no dedicated output group. Nested properties are not all required by the schema, and booleans do not represent unknown evidence; use explicit findings so a technically valid output cannot hide incomplete review.

Feedback contains string arrays `strengths`, `gaps` and `action_items`. Give two to four supported strengths where available, cite each gap by check number and artifact, and prescribe concrete corrections. For the source's softened illustrator exclusion, restoring the approved specific wording is actionable; “make it stronger” is not. Do not adopt the example's dollar threshold for unrelated offers.

Review all seven named failure modes

Check for subtle Primary-mechanism drift; anti-promise softening for marketing; guarantee expansion from two components to four or five; a Trigger Bank mismatch; “nothing material” weaknesses; vague stop criteria; and an unsigned commitment. The source respectively calls for mechanism diagnosis, restoring approved anti-promise language, restoring the guarantee structure, provenance review, substantive weaknesses, numerical criteria and actual signing/resubmission. Its “30-second fix” for a signature is an informal estimate, not a guaranteed processing time.

Apply the marketing themes and finish the exercise

An authored Brunson/ClickFunnels application is to keep the page's buyer, mechanism, promise and delivery description aligned with the actual offer. Persuasive language must not quietly erase exclusions or alter the mechanism. This YAML supplies no funnel implementation or direct Brunson quotation.

An authored Hormozi/Acquisition.com application is to support the Value Equation conclusions with evidence and a deliverable promise. Extra guarantees and deliverables do not automatically repair weak confidence in the outcome. Preserve the learner's actual diagnosis and capacity rather than inflating claims. The YAML is a review configuration, not empirical proof of financial results.

For practice, assemble the evidence, verify the prerequisite structural PASS, complete all eighteen numbered checks across five layers and produce the full review record. Retain unsupported inputs and severity ambiguities as open items. Obtain the responsible decision before treating later enrollment or completion as authorized.

Source identity and clickable resources

The original is `offer-fit-validator` version 1.0.0. It names `claude-opus-4-7`, temperature 0.1, maximum 4,000 tokens and estimated USD $0.30–$0.55 per call. It describes this as the highest per-call C4 cost, intended once per learner per course plus revisions. These are source configuration claims and estimates, not verified current model availability, executed calls or actual user billing.

Governance names quarterly review, owner `curriculum-quality-team`, automatic FAIL escalation to a mentor queue and consumption by the Build 6 C4 completion handler gating C5 First Currents. These configuration notes do not establish that the integration is deployed or working. The source's JSON-only instruction applies to its described reviewer, not to this educational prose.

- Assigned original offer-fit validator — complete original YAML also preserved in the accompanying source appendix. - RISER NATION CORP — brand destination.

Bring the thirteen inputs and the additional pricing decision, distinction memo, naming evidence, commitment template and prior PASS to your review. This YAML does not contain their completed contents or exact links. Those records remain unverified until the applicable evidence is available. Consult the accompanying complete original when tracing each check to its source.

Assigned source: D0475 original 1

prompt_name: offer-fit-validator
version: 1.0.0
purpose: >
  Deep coherence validation of M4.8 C4 course-completion artifacts. Performs
  offer-mechanism-market coherence check across all 8 C4 deliverables plus
  C1 territory artifacts plus C3 Market Fit Hypothesis. This is the highest-
  stakes prompt in C4 — blocks course completion until offer coherence is
  verified. The full C1-C3 lineage is checked; any drift between the offer
  and the validated Primary mechanism is flagged. Runs only after the
  offer-readiness-reviewer (Sonnet) has issued a structural PASS.
model: claude-opus-4-7
temperature: 0.1
max_tokens: 4000
cost_per_call_estimate_usd: 0.30-0.55

input_schema:
  type: object
  required:
    - readiness_document
    - first_sale_readiness_checklist
    - landing_page_copy
    - trigger_bank_provenance_log
    - student_c3_market_fit_hypothesis
    - student_c3_primary_mechanism
    - student_c3_trigger_bank_excerpt
    - student_c3_pricing_signals
    - student_c1_territory_clause
    - student_c1_operator_identity
    - student_m42_value_equation
    - student_m45_anti_promise
    - student_m46_guarantee
  properties:
    readiness_document: {type: string}
    first_sale_readiness_checklist: {type: string}
    landing_page_copy: {type: string}
    trigger_bank_provenance_log: {type: string}
    student_c3_market_fit_hypothesis: {type: string}
    student_c3_primary_mechanism:
      type: object
      properties:
        name: {type: string}
        four_pillar_summary: {type: string}
    student_c3_trigger_bank_excerpt: {type: string}
    student_c3_pricing_signals: {type: string}
    student_c1_territory_clause: {type: string}
    student_c1_operator_identity: {type: string}
    student_m42_value_equation: {type: string}
    student_m45_anti_promise: {type: string}
    student_m46_guarantee: {type: string}

output_schema:
  type: object
  required: [verdict, coherence_checks, lineage_checks, anti_bias_checks, feature_stuffing_check, flags, feedback]
  properties:
    verdict: {type: string, enum: [PASS, NEEDS_REVISION, FAIL]}
    coherence_checks:
      type: object
      properties:
        offer_section_matches_landing_page: {type: boolean}
        price_consistent_across_artifacts: {type: boolean}
        anti_promise_not_softened_in_readiness: {type: boolean}
        guarantee_not_softened_in_readiness: {type: boolean}
        value_equation_conclusions_match_m42: {type: boolean}
    lineage_checks:
      type: object
      properties:
        offer_serves_c1_territory: {type: boolean}
        offer_voice_matches_c1_operator_identity: {type: boolean}
        offer_built_on_c3_primary_mechanism: {type: boolean}
        trigger_bank_entries_verified_in_source: {type: boolean}
        price_consistent_with_c3_pricing_signals: {type: boolean}
        price_deviation_rationalized_if_present: {type: boolean}
    anti_bias_checks:
      type: object
      properties:
        known_weaknesses_substantive: {type: boolean}
        c5_questions_specific_and_testable: {type: boolean}
        kill_criteria_specific_and_testable: {type: boolean}
        no_drift_from_c3_primary: {type: boolean}
    feature_stuffing_check:
      type: object
      properties:
        deliverables_count_le_8: {type: boolean}
        guarantee_components_le_2: {type: boolean}
        anti_promise_exclusions_in_3_to_6_range: {type: boolean}
    flags:
      type: array
      items:
        type: object
        properties:
          severity: {type: string, enum: [BLOCKING, WARNING, NOTE]}
          check: {type: string}
          description: {type: string}
          artifact: {type: string}
    feedback:
      type: object
      properties:
        strengths: {type: array, items: {type: string}}
        gaps: {type: array, items: {type: string}}
        action_items: {type: array, items: {type: string}}

system_prompt: |
  You are the C4 course-completion gate — the highest-stakes reviewer in
  C4 Offer Ignition. A student reaches you only after the offer-readiness
  reviewer has issued structural PASS. Your job is to verify that the offer
  is coherent, lineage-consistent with C1-C3, honest about its weaknesses,
  and free of Feature Stuffing.

  You are checking whether the offer is ready to be presented to real buyers
  in C5 First Currents. A false PASS at your layer ships a miscalibrated
  offer into Stage 1 graduation and downstream Stage 2+ work — every hour
  of error at this gate saves tens of hours of Stage 2-4 rework.

  # Five-Layer Check

  Run five distinct check layers. Each layer has multiple subchecks. A single
  BLOCKING flag in any layer results in NEEDS_REVISION or FAIL — the verdict
  depends on severity and count.

  ## Layer 1 — Coherence Across Artifacts

  Check 1.1 — Offer Section of Readiness Document matches Landing Page Copy Offer Section (Section 5)
  - Same deliverable name (5-Test passed)
  - Same price
  - Same delivery structure (engagement model, duration, cadence)
  - Same deliverables list (order may differ; substance must match)
  - Drift flag: any substantive difference

  Check 1.2 — Price consistent across: Readiness Doc Section 1, Readiness Doc Section 3, Landing Page Copy Section 5, M4.4 Pricing Decision
  - Same anchor number (not ranges; the anchor is a number)
  - Same payment options
  - Drift flag: different numbers across artifacts

  Check 1.3 — Anti-Promise in Readiness Doc Section 5 matches M4.5 Anti-Promise Statement
  - Same three exclusion categories
  - Same outcome non-claims
  - Same scope boundaries
  - Softening flag: any exclusion softened, removed, or made less specific

  Check 1.4 — Guarantee in Readiness Doc Section 5 matches M4.6 Guarantee Architecture
  - Same type (hybrid/refund/outcome/time-shift/effort-adjusted)
  - Same activation conditions
  - Same exclusions
  - Stacking flag: additional guarantee components added beyond M4.6

  Check 1.5 — Value Equation Conclusions in Readiness Doc Section 4 match M4.2 synthesis
  - Same strongest variable
  - Same weakest variable
  - Same structurally fixed variables
  - Drift flag: strongest/weakest swapped or silently reconfigured

  ## Layer 2 — C1-C3 Lineage Integrity

  Check 2.1 — Offer serves C1 Captain's Oath Clause 1 territory
  - The target buyer named in the offer is within the stated territory
  - If territory has been expanded or narrowed without C1 re-attestation, flag
  - Drift flag: target buyer outside C1 territory

  Check 2.2 — Offer voice matches C1 Operator Identity archetype
  - Teacher-Operator → typically cohort-leaning delivery; teaching-vocabulary-compatible
  - Service-Operator → typically 1:1-leaning delivery; service-vocabulary-compatible
  - Builder/Creative/Systems/Product — per archetype adjustments
  - Mismatch flag: e.g., a Teacher-Operator's offer is structured as pure done-for-you service with no teaching component, indicating archetype drift

  Check 2.3 — Offer built on C3 Primary mechanism
  - Offer's Method section (Landing Page Section 3) describes the same 4 pillars as C3 M3.7 Primary
  - Subtle repositioning flag: the mechanism name is the same but the Method pillar has subtly changed (e.g., different audience pillar, altered outcome)
  - Drift flag: the offer is structurally a different mechanism dressed in the Primary's name

  Check 2.4 — Trigger Bank entries verified in source
  - For the 15+ entries cited in Provenance Log, verify against student_c3_trigger_bank_excerpt
  - Fabrication flag: any entry not verifiable in the source Trigger Bank (serious Integrity issue)

  Check 2.5 — Price consistent with C3 Pricing Signals
  - The anchor price in M4.4 sits within the observed C3 band OR deviates with documented rationale
  - Unrationalized deviation flag: price outside observed band with no M4.4 rationale

  ## Layer 3 — Anti-Bias Checks

  Check 3.1 — Known Weaknesses Section (S7 of Readiness Doc) is substantive
  - At least 3 specific weaknesses named
  - Each weakness is concrete (Perceived Likelihood gap with specific case count; traffic gap; variant concerns; operator concerns)
  - Whitewash flag: "minor polishing" / "none that I can think of" / "nothing material" language

  Check 3.2 — C5 Questions (S8) are specific and testable
  - At least 3 specific questions
  - Each question names a specific thing C5 must answer
  - Hand-wave flag: "I'll figure it out" / "need to see what works" language

  Check 3.3 — Kill Criteria (First-Sale Readiness Checklist Cat D) are specific and testable
  - At least 3 kill criteria
  - Each names a numerical threshold AND a remediation path
  - Vagueness flag: "if things go badly, reconsider" or similar

  Check 3.4 — No silent drift from C3 Primary
  - Cross-reference M4.1 Distinction Memo Section 1 (mechanism pasted from C3) against current Readiness Doc Section 2
  - Silent drift flag: the mechanism at M4.8 is subtly different from the mechanism at M4.1, without documented revision

  ## Layer 4 — Feature Stuffing

  Check 4.1 — Primary deliverables count ≤ 8
  - Count named deliverables in Readiness Doc Section 3 / Landing Page Section 5
  - Flag: count > 8 (typical Feature Stuffing signal)

  Check 4.2 — Guarantee components ≤ 2
  - Count distinct guarantee structures (refund + outcome extension = 2; refund + outcome + satisfaction + quality = 4)
  - Flag: count > 2 (Feature Stuffing signal)

  Check 4.3 — Anti-promise exclusions in 3-6 range
  - Count specific exclusion categories in Section 2 of Anti-Promise
  - Flag if < 3: under-excluding; offer is soft on filtering unfit buyers
  - Flag if > 6: over-excluding; likely filtering actual target buyers

  ## Layer 5 — Signature Block

  Check 5.1 — Section 9 commitment statement is reproduced and signed
  - Operator name filled in
  - Date present
  - The commitment language matches the template verbatim (student cannot alter the commitment)

  # Flag Severity

  - BLOCKING: stops PASS verdict. Categories include: any Layer 2 drift flag (lineage broken); Fabrication flag (Layer 2.4); silent drift (Layer 3.4); signature not signed (Layer 5).
  - WARNING: triggers NEEDS_REVISION. Categories: softening flags (1.3, 1.4); Feature Stuffing flags (Layer 4); whitewash/hand-wave flags (3.1, 3.2, 3.3); unrationalized deviation (2.5).
  - NOTE: does not change verdict; surfaces observation for student awareness.

  # Verdict Logic

  - All checks pass OR only NOTE-level flags → PASS (C4 complete; C5 enrollment unlocks)
  - WARNING flags present, no BLOCKING flags → NEEDS_REVISION (student addresses warnings and resubmits; typical outcome)
  - Any BLOCKING flag → FAIL (mentor-supported diagnosis; most commonly traces to C3 M3.7 that was waved through rather than made)

  # Feedback Structure

  Strengths: 2-4 specific observations about what the student did well. Coherence across artifacts is common strength; specific Trigger Bank discipline is another.

  Gaps: specific flags raised, cited by check number and artifact. "Check 1.3 — Anti-Promise Exclusion 2 softened from 'Illustrators earning under $3K/month' in M4.5 to 'Best for established illustrators' in Readiness Doc Section 5."

  Action items: concrete revision steps. "Revert Readiness Doc Section 5 Exclusion 2 to the specific $3K threshold stated in M4.5" is actionable. "Make your anti-promise stronger" is not.

  # Output

  Return JSON only. No preamble, no postamble. Be specific in flag descriptions — the student needs to know exactly what to fix.

known_failure_modes:
  - scenario: Student's Primary mechanism at M4.8 differs subtly from C3 M3.7
    mitigation: BLOCKING flag Check 2.3; typically traces to C3 M3.7 decision that was waved through; mentor escalation to reopen C3 M3.7 before resubmitting C4
  - scenario: Anti-promise softened between M4.5 and M4.8 for "marketing appropriateness"
    mitigation: WARNING flag Check 1.3; NEEDS_REVISION; student reverts to M4.5 language
  - scenario: Guarantee stacked from 2 components in M4.6 to 4-5 in Readiness Doc
    mitigation: WARNING flag Check 1.4 + Check 4.2; NEEDS_REVISION; student restores clean structure
  - scenario: Trigger Bank entry in Provenance Log does not match source
    mitigation: BLOCKING flag Check 2.4 (fabrication); serious integrity issue; mentor review
  - scenario: Known Weaknesses is "nothing material"
    mitigation: WARNING flag Check 3.1; NEEDS_REVISION; student writes specific weaknesses
  - scenario: Kill Criteria are "if things go badly, reconsider"
    mitigation: WARNING flag Check 3.3; NEEDS_REVISION; student adds numerical thresholds
  - scenario: Signature block not signed
    mitigation: BLOCKING flag Check 5.1; 30-second fix; student signs and resubmits

governance:
  review_cadence: quarterly
  owner: curriculum-quality-team
  escalation: FAIL verdicts route automatically to mentor queue for diagnosis
  consumed_by: Build 6 C4 course completion handler; gates C5 First Currents enrollment
  compute_notes: highest per-call cost in C4 at $0.30-0.55; acceptable at course-completion frequency (once per student per course, plus revisions)

Offer readiness: complete the evidence packet before the fit review

RISER NATION CORP — IF YOU AREN'T BUILDING, YOU ARE DESTROYING

Assigned lessons: 03.1, 03.4, 04.1, 07.1 and 12.4. Legacy C4/M4.8 references identify the source workflow, not replacements for these assignments.

What does this review establish?

This lesson teaches you to assemble and structurally review an Offer Readiness Document and First-Sale Readiness Checklist. You will identify missing sections, incomplete operational preparations and vague stop criteria before a separate reviewer assesses whether the offer fits its mechanism and market.

A complete packet makes a serious review possible. It does not prove market demand, delivery quality or a coherent offer. The source describes this stage as a pre-flight checklist before the deeper inspection. Its PASS routes the packet to a separate offer-fit validator. It does not authorize launch or certify that every claim is true.

The source expects two string inputs: `readiness_document` and `first_sale_readiness_checklist`. Collect the actual current documents. Do not fill missing evidence with invented approvals, signatures or infrastructure status.

Build all nine readiness-document sections

1. Executive Summary — 100–150 words in one paragraph. Give the reviewer a compact account of the offer. Use the paragraph to orient the review rather than substitute for the detailed sections below.
2. Mechanism Recap — 150–200 words. Include the four-pillar summary from the applicable mechanism work. This YAML does not define those four pillars; carry them forward from the actual assigned artifact rather than inventing a framework.
3. The Offer — 300–400 words. Name the deliverable, buyer, delivery arrangement and price. Presence of these elements passes a structural check, but their consistency with earlier work belongs to the separate fit review.
4. Value Equation Conclusions — 200–300 words. Identify the strongest and weakest variables, the variables treated as structurally fixed, and the module targeting recorded in the applicable synthesis. Here, fixed means constrained in the architecture, not necessarily repaired; the companion offer-fit review checks that those structurally fixed variables remain consistent with M4.2. Make the conclusions traceable to your actual analysis; the YAML does not supply your scores or findings.
5. Anti-Promise and Guarantee — 200–300 words. Reproduce the applicable M4.5/M4.6 material as the source requests. Check that you are using the actual approved versions and retain the distinction between what you commit to deliver and what you exclude.
6. Landing Page Copy Reference — 100–150 words. Identify the file, its word count, the Trigger Bank entry count and the peer-review status. A reference that only says “landing page done” leaves the reviewer without the required evidence.
7. Known Weaknesses — 200–300 words. Name substantive gaps. Discuss actual perceived-likelihood, traffic or offer-variant concerns where applicable, rather than writing “nothing major.” State what remains uncertain without inventing weaknesses merely to fill space.
8. C5 Questions — 100–200 words. Ask specific questions that the next stage must answer. Replace “I'll figure it out in C5” with the precise unresolved decision and the evidence needed to make it.
9. Signature Block — 50–100 words. Reproduce the required commitment and provide the operator's actual name and date. Obtain the operator's own completion; this lesson does not sign for you or authenticate identity.

The combined section targets total 1,600–2,300 words. Flag missing sections and sections substantially below their targets, as the source instructs. Length is a screening heuristic: enough words can still conceal poor reasoning, while a short section needs substantive review rather than automatic assumptions about the author's effort.

Category A: verify the artifacts and their provenance

Check all five artifact-completeness items. First, the seven prior C4 artifacts must be filed; the YAML does not list all seven names, so resolve them against the applicable curriculum records. Second, the landing page must contain at least fifteen verbatim Trigger Bank entries accompanied by a provenance log. Count the actual entries and retain where they came from; do not manufacture customer language. Third, verify the Anti-Promise Integrity Statement has actually been signed. Fourth, verify the Guarantee Honesty Clause has actually been signed. Fifth, confirm two peer reviews given and two received, with the resulting feedback incorporated.

A document labeled “complete” does not establish these facts. Record its location and the evidence supporting the checked item. In particular, receiving feedback and incorporating it are separate requirements.

Category B: verify operational readiness

Check five infrastructure items: an active payment processor; a capable qualifying form; email delivery capability for the Welcome Kit; a calendar slot for the first cohort at least four weeks away; and a ready delivery channel. Record the applicable evidence and unresolved defects.

The presence of an account, a form title or an email draft alone does not establish an operational path. Review whether the intended learner/customer journey can function. The source describes readiness checks; it does not direct this lesson to activate accounts, run charges, send messages or launch a cohort. Keep those actions separate from the review record.

Category C: prepare the operator

Check all five operator-readiness items. Block the actual weekly delivery time on the operator's calendar. Prepare an undersell contingency for enrollment below expectations and an oversell contingency for demand above delivery capacity. Prepare the first objection response and the pricing-discount conversation.

Teach the distinction between a prepared response and a promised outcome. A discount response should reflect the actual offer policy. An oversell plan should describe what happens when capacity is reached rather than assume more customers can always be accommodated. Record plans that exist and identify plans still needing work.

Category D: make stop criteria measurable

The source calls these “Kill Criteria.” Their purpose here is to make a stop-and-remediate decision testable. Name at least three criteria with specific numerical thresholds. Each must identify a metric, such as enrollment count, reply rate or refund rate, and a remediation path, such as returning to M4.3 or revisiting M4.2.

“If things go badly” cannot be checked consistently. An authored example of a better structure is: “At the end of the defined enrollment window, if paid enrollment is below our approved minimum of N, follow the documented cohort contingency and return to the named offer-review step.” Replace N with a justified number and supply the window; this is a template, not a threshold prescribed by the source. For a rate, define the denominator and observation period so reviewers know what was measured. The YAML requires numerical, metric-linked criteria but does not supply universal thresholds.

For each criterion, record the metric, threshold, measurement window and specific remediation. The window is an authored clarification that makes the prescribed numerical check usable. Count only distinct, testable criteria; three vague statements do not meet the requirement.

Apply the three structural flags

`signature_block_signed` asks whether Section 9 reproduces the commitment and contains the operator's name and date. A typed name is evidence of field completion, not independent signature authentication.

`c5_questions_specific` asks whether Section 8 contains actual questions, rather than a promise to decide later. A useful question names the uncertainty closely enough that someone can investigate it.

`known_weaknesses_substantive` asks whether Section 7 names real gaps. “None that I can think of” and “minor polishing needed” are the source's examples of insufficient treatment. Connect a concern to evidence and a next decision without pretending an unknown has already been resolved.

Understand the verdict rules and their gaps

The source assigns PASS when all nine sections are present, all four checklist categories are populated and all three structural flags are green. It assigns NEEDS_REVISION for one or two minor gaps, such as a thin weaknesses section or an incomplete checklist category. An unsigned signature block or more than two missing sections produces FAIL.

Do not mistake a populated category for proof that every item is complete. The source separately requires testable stop criteria and actual infrastructure readiness. Its verdict logic does not fully cover every combination: three minor issues with no missing sections, a populated category containing no valid numerical criteria, or one severe gap unrelated to a signature are not fully resolved by the brief aggregation rules. Record the actual findings and route ambiguity to the responsible curriculum reviewer. Do not invent an automatic approval rule to close the gap.

PASS advances to the fit review. It does not mean that this review has checked mechanism-market coherence. A structurally complete offer can still have drifted from M4.3/M4.4/M4.7.

Preserve the complete output structure

The source's output is an object with four required groups: `verdict`, `section_presence`, `checklist_completeness` and `structural_flags`. `feedback` is an additional, optional group in the schema, although the prose instructs the reviewer to supply useful feedback.

The verdict is PASS, NEEDS_REVISION or FAIL. The nine presence booleans are `s1_executive_summary`, `s2_mechanism_recap`, `s3_the_offer`, `s4_value_equation_conclusions`, `s5_anti_promise_and_guarantee`, `s6_landing_page_reference`, `s7_known_weaknesses`, `s8_c5_questions` and `s9_signature_block`.

The checklist group contains the booleans `cat_a_artifact_completeness`, `cat_b_infrastructure_readiness`, `cat_c_operator_readiness` and `cat_d_kill_criteria`, plus integer `kill_criteria_count` and boolean `kill_criteria_testable`. Preserve the three structural flags described above.

Feedback contains three arrays of strings: `strengths`, `gaps` and `action_items`. Give one or two real strengths where present, identify specific missing or weak sections/checklist items, and say what the learner must add before resubmission. The source requests JSON only from its configured reviewer; that embedded formatting instruction does not prevent this course from teaching the workflow in readable prose.

The schema does not mark every nested property as required and does not encode all word counts, numeric ranges or semantic criteria. JSON validation alone therefore cannot establish instructional completeness. Review both the record structure and the underlying evidence.

Work through all five known failure modes

An unsigned Section 9 produces FAIL and requires the learner to sign and resubmit. The source calls that thirty seconds of work; treat this as an informal estimate, not a service-time guarantee.

A Section 7 that says “nothing major” makes `known_weaknesses_substantive` false and requires revision into specific concerns, such as perceived likelihood, traffic or variant questions where those concerns actually apply.

Vague Category D criteria make `kill_criteria_testable` false and require numerical thresholds tied to metrics and remediation.

Offer drift in Section 3 is explicitly not caught by this structural layer. The separate offer-fit validator must assess consistency with earlier work. Do not report that this pre-screen performed that deeper review.

Infrastructure gaps in Category B require revision. A learner cannot substantiate first-sale readiness while the required payment or delivery infrastructure is unavailable.

Connect the readiness packet to RISER's marketing education

In an authored Brunson/ClickFunnels application, the packet connects the customer-facing page and its language to the qualifying, onboarding and delivery experience. Provenance for customer language and a usable next step matter more than a page merely looking finished. This source does not supply a ClickFunnels implementation or quote a Brunson framework.

In an authored Hormozi/Acquisition.com application, the Value Equation Conclusions and explicit weaknesses make the offer's claimed value reviewable. Identify what supports confidence in the outcome and what still creates delay or effort for the customer. Bound the guarantee and exclusions to what the operator can deliver. Do not turn a completed checklist into proof of a financial outcome.

Practice, governance and resources

Assemble the two input documents, review every section and all eighteen checklist items, and record the three flags. Write the output and concrete revision actions. Preserve missing linked artifacts as unresolved evidence. Obtain the operator's actual commitment and the responsible review decision before describing the packet as ready for the next gate.

The original identifies `offer-readiness-reviewer` version 1.0.0, model `claude-sonnet-4-6`, temperature 0.1 and maximum 2,000 tokens. Its stated per-call estimate is USD $0.04–$0.08. These are source configuration and cost estimates, not current verified product specifications, an actual model invocation or the user's measured bill. No embedded prompt is executed here.

Governance specifies quarterly review by `curriculum-quality-team`, consumption by the Build 6 M4.8 checkpoint handler and a downstream offer-fit-validator described as Opus 4.7. These are described workflow components, not proof that a deployed integration exists. Keep the handoff explicit and verify the separate fit review rather than equating the structural PASS with its completion.

- Assigned original offer-readiness reviewer — original YAML preserved byte-for-byte in the accompanying source appendix. - RISER NATION CORP — brand destination.

Bring the seven prior artifacts, Trigger Bank, M4.5/M4.6 clauses, landing page, peer reviews and completed checklist to your review. The YAML references them but does not supply their completed contents or exact links. Treat unavailable records as unresolved evidence. The accompanying complete original lets you trace the checklist requirements without mistaking them for proof that your own preparations are complete.

Assigned source: D0476 original 1

prompt_name: offer-readiness-reviewer
version: 1.0.0
purpose: >
  Structural validation of M4.8 student-submitted Offer Readiness Document and
  First-Sale Readiness Checklist. Verifies all 9 sections present, signature
  block signed, and Checklist complete across 4 categories including named
  Kill Criteria. This is a structural pre-screen; the Opus-powered offer-fit
  validator (separate prompt) performs the deep coherence check.
model: claude-sonnet-4-6
temperature: 0.1
max_tokens: 2000
cost_per_call_estimate_usd: 0.04-0.08

input_schema:
  type: object
  required: [readiness_document, first_sale_readiness_checklist]
  properties:
    readiness_document: {type: string}
    first_sale_readiness_checklist: {type: string}

output_schema:
  type: object
  required: [verdict, section_presence, checklist_completeness, structural_flags]
  properties:
    verdict: {type: string, enum: [PASS, NEEDS_REVISION, FAIL]}
    section_presence:
      type: object
      properties:
        s1_executive_summary: {type: boolean}
        s2_mechanism_recap: {type: boolean}
        s3_the_offer: {type: boolean}
        s4_value_equation_conclusions: {type: boolean}
        s5_anti_promise_and_guarantee: {type: boolean}
        s6_landing_page_reference: {type: boolean}
        s7_known_weaknesses: {type: boolean}
        s8_c5_questions: {type: boolean}
        s9_signature_block: {type: boolean}
    checklist_completeness:
      type: object
      properties:
        cat_a_artifact_completeness: {type: boolean}
        cat_b_infrastructure_readiness: {type: boolean}
        cat_c_operator_readiness: {type: boolean}
        cat_d_kill_criteria: {type: boolean}
        kill_criteria_count: {type: integer}
        kill_criteria_testable: {type: boolean}
    structural_flags:
      type: object
      properties:
        signature_block_signed: {type: boolean}
        c5_questions_specific: {type: boolean}
        known_weaknesses_substantive: {type: boolean}
    feedback:
      type: object
      properties:
        strengths: {type: array, items: {type: string}}
        gaps: {type: array, items: {type: string}}
        action_items: {type: array, items: {type: string}}

system_prompt: |
  You are performing structural pre-screen validation on a C4 M4.8 deliverable —
  the Offer Readiness Document and First-Sale Readiness Checklist.

  Your role is structural completeness only. The deep coherence check (does the
  offer actually fit the mechanism and market?) happens in the Opus-powered
  offer-fit-validator, which runs after your PASS verdict.

  Think of yourself as the pre-flight checklist before the flight inspection.
  If pieces are missing, stop the process here — the deeper reviewer should
  not be spun up until basic structure is in place.

  # Structural Checks

  ## Readiness Document Section Presence (all 9 required)

  1. Executive Summary (100-150 words; single paragraph)
  2. Mechanism Recap (150-200 words; includes 4-pillar summary)
  3. The Offer (300-400 words; named deliverable, buyer, delivery, price)
  4. Value Equation Conclusions (200-300 words; strongest, weakest, fixed, module targeting)
  5. Anti-Promise and Guarantee (200-300 words; pasted from M4.5/M4.6)
  6. Landing Page Copy Reference (100-150 words; file, word count, trigger bank count, peer review status)
  7. Known Weaknesses (200-300 words; substantive, not hand-waved)
  8. C5 Questions (100-200 words; specific questions)
  9. Signature Block (50-100 words; reproduced commitment + signed)

  Flag any missing section. Flag any section substantially below its word-count target (indicates hand-waving).

  ## First-Sale Readiness Checklist Completeness

  Four categories must all be populated:

  Category A — Artifact Completeness:
  - 7 prior C4 artifacts filed ✓
  - Landing page has ≥ 15 verbatim Trigger Bank entries with provenance log ✓
  - Anti-Promise Integrity Statement signed ✓
  - Guarantee Honesty Clause signed ✓
  - Peer reviews completed (2 given, 2 received, incorporated) ✓

  Category B — Infrastructure Readiness:
  - Payment processor active
  - Qualifying form capable
  - Email delivery capability for Welcome Kit
  - Calendar slot for first cohort (≥ 4 weeks out)
  - Delivery channel ready

  Category C — Operator Readiness:
  - Weekly calendar blocked for cohort delivery
  - Undersell contingency plan
  - Oversell contingency plan
  - First objection response prepared
  - Pricing discount conversation prepared

  Category D — Kill Criteria:
  - At least 3 named kill criteria with specific numerical thresholds
  - Each kill criterion references a specific metric (enrollment count, reply rate, refund rate, etc.)
  - Each kill criterion names the remediation path (return to M4.3, revisit M4.2, etc.)

  ## Structural Flags

  - signature_block_signed: is the Section 9 commitment statement reproduced AND the operator name + date filled in?
  - c5_questions_specific: does Section 8 name specific questions (not "I'll figure it out in C5")?
  - known_weaknesses_substantive: does Section 7 name specific gaps (not "none that I can think of" or "minor polishing needed")?

  # Verdict Logic

  - All 9 sections present + all 4 checklist categories populated + all structural flags green → PASS (triggers offer-fit-validator)
  - 1-2 minor gaps (e.g., Section 7 present but thin; one checklist category incomplete) → NEEDS_REVISION with specific guidance
  - Signature block not signed OR > 2 missing sections → FAIL

  # Feedback Structure

  Strengths: 1-2 observations if present (typically structural completeness-related)
  Gaps: specific sections or checklist items missing or weak
  Action items: what the student must add before resubmitting

  # Output

  Return JSON only. No preamble, no postamble.

known_failure_modes:
  - scenario: Student submits without signing Section 9 commitment block
    mitigation: FAIL; student signs and resubmits (30 seconds of work)
  - scenario: Section 7 Known Weaknesses reads "none that I can think of" or "nothing major"
    mitigation: known_weaknesses_substantive = false; NEEDS_REVISION; student writes specific Perceived Likelihood / traffic / variant concerns
  - scenario: Category D Kill Criteria are vague ("if things go badly")
    mitigation: kill_criteria_testable = false; NEEDS_REVISION; student rewrites with specific numerical thresholds
  - scenario: Section 3 offer description has drifted from M4.3/M4.4/M4.7
    mitigation: Not caught at this layer — Opus offer-fit-validator catches drift. This reviewer only checks presence, not consistency.
  - scenario: Checklist Category B infrastructure gaps (e.g., payment processor not live)
    mitigation: NEEDS_REVISION; student cannot submit first-sale-ready without operational infrastructure

governance:
  review_cadence: quarterly
  owner: curriculum-quality-team
  consumed_by: Build 6 M4.8 checkpoint handler; gates offer-fit-validator spin-up
  downstream: on PASS, offer-fit-validator (Opus 4.7) runs full coherence check

Offer v2.0: improve delivery architecture without concealing a pivot

RISER NATION CORP — IF YOU AREN'T BUILDING, YOU ARE DESTROYING

Assigned lessons: 03.1, 03.2, 03.4, 04.1 and 12.4. The source's C7/M7.7 labels are its legacy references; they do not replace the spreadsheet assignments.

Lesson outcome and opening

By the end of this lesson, you will be able to review a customer-facing Offer v2.0 document against its previous version, distinguish an architectural improvement from a change in business direction, and record specific revisions before treating the document as approved.

You can improve how you deliver an offer without changing whom you serve, what problem you solve or the mechanism that produces the result. That is the distinction this source asks you to protect. Architecture includes deliverables, standard operating procedures, the customer lifecycle and capacity. A new mechanism, customer or problem is a directional change that needs its own evaluation. Calling a document “v2.0” does not establish that its direction stayed the same.

For example, replacing scattered onboarding emails with a scheduled onboarding sequence may change delivery architecture. Switching from an offer for independent operators to an offer for enterprise teams changes the customer, even if the document retains its old title. These are authored teaching examples, not reported source outcomes.

Assemble the evidence before reviewing

Bring the proposed v2.0 document, the prior v1.1 document and relevant v1.x learning. Bring the M7.6 measurement record, customer feedback patterns, the M7.5 capacity analysis and the M7.2 decomposition referenced by the source. The assigned YAML does not include those completed artifacts. Missing evidence must be recorded as missing; a confident description cannot substitute for it.

Review the actual comparison, not just the author's declaration. The source identifies four especially common failures: a customer or mechanism pivot disguised as architecture; a missing or weak anti-promise list; capacity that disagrees with M7.5; and features that do not follow from v1.x learning. The checks below turn these into observable questions.

Walk through all thirteen sections

1. Offer header: identify the offer and explicitly designate version 2.0. A version label supports traceability; it is not an approval.
2. Anti-pivot statement: name the mechanism, customer and problem and explicitly state that each is unchanged. Explain the architectural changes separately so a reviewer can see the distinction.
3. Deliverable summary: list the source's required 8–15 customer-facing deliverables. Name what customers actually receive, rather than padding the count with internal tasks.
4. Engagement structure: state both cadence and engagement length. Customers need to know when delivery occurs and how long the relationship lasts.
5. Pricing: address whether pricing changed or stayed unchanged. If it changed, identify the supporting learning and resolve the pricing-review conflict discussed below.
6. Capacity statement: cite the concurrent-customer ceiling from M7.5 Section 7. Identify the bottleneck from M7.5 Section 3 and make the resulting delivery boundaries visible.
7. Anti-promise list: state specific outcome and scope exclusions. Include capacity boundaries here or in Section 6.
8. How v2.0 differs from v1.1: name each architectural change and trace it to a measurement or feedback pattern from v1.x. “Better service” is not a concrete change description.
9. Cohort variant: explain the evaluated cohort variant or explicitly record N/A. Silence leaves the reviewer unable to distinguish a deliberate decision from an omission.
10. Customer commitments: state what the customer must do for delivery to function. Make participation requirements understandable alongside your own delivery commitments.
11. Iteration trajectory: state the v2.0 deployment date, earliest v2.1 and v3.0 dates, and the conditions that would trigger v2.1.
12. Reviewer: prepare the reviewer information so the document is ready for review. Do not invent a reviewer or imply a review has occurred.
13. Sign-off: prepare the sign-off section and obtain the actual required review. A section ready to sign is different from documented cohort-partner sign-off.

Test whether the direction really stayed fixed

Check four things: the mechanism is explicitly named as unchanged; the customer is explicitly named as unchanged; the problem is explicitly named as unchanged; and the document visibly distinguishes architecture from a pivot. Compare each claim with the earlier offer. If the earlier version or its definition is missing, record partial or unconfirmed evidence instead of asserting that continuity has been proved.

Then test every architectural change against three evidence requirements. Each change must trace to v1.x evidence such as M7.6 measurement or a repeated customer-feedback pattern. It must not introduce a structure with no basis in that learning. It must remain bounded rather than accumulating “while we're at it” additions. Record the changed element, its prior state, its proposed state, the evidence and the expected delivery effect. That record is an authored method for making the source's traceability requirement usable.

A historical reference supports the reason for a change; it does not prove that the proposed change will work. A new idea without supporting learning may deserve a separately bounded experiment. Do not mislabel it as an already evidenced architectural improvement.

Write anti-promises that match the offer

The source requires at least three specific outcome anti-promises and at least three specific scope anti-promises. Outcome exclusions identify results you are not committing to produce. Scope exclusions identify work you will not supply. For example, “we do not guarantee a particular revenue result” is an outcome boundary; “we do not operate your advertising account” is a scope boundary. These examples need adaptation to the actual offer.

The source also requires capacity anti-promises and an anti-promise list at least as long as the deliverable list. Six minimum exclusions are therefore insufficient when you list eight or more deliverables unless additional substantive exclusions are supplied. Count meaningful boundaries, not repeated wording added to satisfy a quota. Make the capacity limits visible in Section 6 or Section 7.

There is a cross-source tension: D0474 flags more than eight primary deliverables as possible feature stuffing, while this later architectural reviewer requests 8–15 customer-facing deliverables. These may describe different stages or levels of detail. Identify that distinction explicitly in your own artifact and verify actual capacity. Do not silently turn either number into a universal offer-design rule.

Reconcile capacity before promising delivery

Match the concurrent-customer ceiling exactly to M7.5 Section 7 and the bottleneck activity to M7.5 Section 3. If the proposed ceiling differs, the reviewer needs a revised, supported capacity analysis; an attractive new number in the offer is insufficient.

Include the source's waitlist and 15% drift trigger in the capacity boundaries. Explain when additional customers must wait and what happens when the monitored measure drifts. The YAML names 15% but does not define its baseline, metric, measurement window or complete response procedure. Supply those definitions from the applicable capacity artifact or record them as unresolved. Do not invent an established measurement system or treat 15% as a universal research finding.

Review pricing and iteration dates without hiding conflicts

Pricing needs explicit treatment. The section checklist allows pricing to be changed or unchanged, while the output field asks whether a pricing revision was appropriately deferred. The failure list also flags changes not derived from v1.x evidence as likely pivot indicators. Those instructions do not fully define when an evidenced pricing change is acceptable. Record the price decision and supporting evidence, identify whether the change is in scope, and request clarification from the responsible reviewer where the rules disagree. Do not manufacture a deterministic verdict from an incomplete policy.

The iteration trajectory has four checks: a stated v2.0 deployment date; v2.1 no earlier than 60 days after deployment; v3.0 no earlier than six months after v2.0; and named conditions for v2.1. The dates are source curriculum rules intended to allow a measurement window, not universal release laws. Calculate calendar months as months rather than silently substituting 180 days. These review windows must not be used to postpone an urgent correction to a harmful error or broken delivery commitment; distinguish corrective maintenance from a planned major version.

Record the complete review output

The YAML specifies JSON with fifteen fields. Understand what each communicates before producing a review record:

The source supplies no formal JSON Schema and no complete rule for aggregating individual findings into APPROVED. A syntactically valid JSON object therefore cannot by itself establish a reliable approval. Keep evidence and unresolved criteria visible, and have the responsible reviewer resolve the recommendation. Address the operator as “you,” using precise language and direct explanations when a purported architectural change looks directional.

Check every named failure pattern

Before finishing, inspect all eight patterns: a missing or implicit anti-pivot statement; a changed mechanism, customer or problem framed as v2.0; fewer than three outcome and three scope anti-promises; a capacity ceiling inconsistent with M7.5; a pricing change unsupported by v1.x evidence; Section 8 changes untraced to learning; feature additions absent from the M7.2 decomposition; and a v3.0 date earlier than six months after v2.0. Write the precise location and needed correction for each finding rather than returning an unexplained negative verdict.

Apply the marketing themes responsibly

In a RISER application of Brunson/ClickFunnels education, the customer-facing promise and the delivery experience should remain connected as the offer evolves. Make the mechanism and buyer clear in the offer explanation and keep the revised delivery description consistent with the page and sales narrative. This is an authored integration; the YAML does not quote Brunson or establish a specific ClickFunnels configuration.

In a RISER application of Hormozi/Acquisition.com education, increasing perceived value must be supported by deliverability. Examine whether an architectural improvement reduces customer effort or delay, or strengthens the evidence that the promised result is achievable. Do not add unsupported guarantees or more deliverables merely to inflate the apparent value of the offer. The source's boundaries and capacity checks help turn that application into a concrete review.

Practice and completion standard

Take one real proposed architectural change. Show the old and new delivery arrangement, cite its v1.x evidence, confirm the mechanism/customer/problem comparison, and reconcile the capacity effect. Complete all thirteen sections and all fifteen review fields. Check the anti-promise counts, every named failure pattern, the pricing ambiguity and the iteration dates. Preserve missing evidence as an open item, then obtain actual reviewer and cohort-partner decisions where required.

Your result is a reviewable offer revision and an evidence-based recommendation. It is not an automatically launched offer, an authenticated signature or proof of market fit.

Source identity, operating limits and clickable resources

The original is `offer-v2-reviewer`, version 1.0.0, legacy module M7.7 in C7 Offer Architecture. Its declared role is Reviewer and its review type is Structured automated review. It names `claude-sonnet-4-6`, submission path `c7_offer_v2_documents`, JSON output and an expected response time of 5–12 minutes. These are source configuration labels and an estimate; this lesson does not establish that the model, database route or review service exists, and the time is not measured RISER runtime. No embedded prompt or model call is executed by this teaching script.

- Assigned original Offer v2.0 reviewer — complete original YAML; retain its exact bytes in the final source appendix. - RISER NATION CORP — brand destination.

Bring the completed v1.1, M7.2, M7.5 and M7.6 artifacts to your comparison. This YAML does not include their contents or exact links; they remain unverified prerequisites until the applicable records are available. Use the accompanying original source appendix to inspect the complete reviewer specification alongside this explanation.

Assigned source: D0477 original 1

name: offer-v2-reviewer
version: 1.0.0
module: M7.7
course: C7 Offer Architecture
model: claude-sonnet-4-6
role: Reviewer
review_type: Structured automated review

description: |
  Reviews student-submitted Offer v2.0 documents. Validates that the
  v2.0 release is architectural rather than directional (per the C7
  Architecture-vs-Pivot Distinction Clause), the anti-promise list is
  explicit and bounded, the capacity statement matches the M7.5 capacity
  analysis, and the v1.1-vs-v2.0 distinction is concrete.

system_prompt: |
  You are the Offer v2.0 Reviewer for C7 Module 7.7. You are reviewing
  a student-submitted Offer v2.0 document.

  The v2.0 document is the customer-facing successor to v1.1. The C7
  Architecture-vs-Pivot Distinction Clause requires that v2.0 changes
  the architecture (deliverables, SOPs, lifecycle, capacity) but NOT
  the mechanism, customer, or problem. Your role is to verify this
  distinction holds in the document.

  The most common failures are:
    1. v2.0 sneaks in a pivot under the architecture label (changes
       the customer or mechanism)
    2. Anti-promise list is missing or anemic
    3. Capacity statement is inconsistent with M7.5 analysis
    4. v2.0 introduces new features not derived from v1.x learning

  Output a structured response with these fields:
    - section_completeness: object with per-section pass/partial/fail
    - anti_pivot_statement_present: yes / partial / no
    - mechanism_unchanged_confirmed: yes / partial / no
    - customer_unchanged_confirmed: yes / partial / no
    - problem_unchanged_confirmed: yes / partial / no
    - architectural_changes_evidence_grounded: yes / partial / no (each change traces to v1.x learning)
    - anti_promise_list_quality: complete / partial / weak
    - anti_promise_findings: array of specific concerns
    - capacity_statement_consistent_with_M7.5: yes / partial / no
    - capacity_statement_findings: array of consistency concerns
    - pricing_revision_appropriately_deferred: yes / out_of_scope_addition_present / N/A
    - pivot_disguised_as_architecture_indicators: array of indicators detected
    - iteration_trajectory_named: yes / partial / no
    - cohort_partner_signoff: documented / not_documented
    - overall_recommendation: APPROVED / NEEDS_REVISION

  Tone: precise, focused on the architectural-vs-directional distinction.
  Address the operator as "you." Push back when changes look like a
  pivot disguised as architecture.

review_criteria:
  section_completeness:
    - Section 1 (Offer Header) is complete with v2.0 designation
    - Section 2 (Anti-Pivot Statement) explicitly states mechanism, customer, problem unchanged
    - Section 3 (Deliverable Summary) lists 8-15 customer-facing deliverables
    - Section 4 (Engagement Structure) named with cadence and length
    - Section 5 (Pricing) addressed (changed or unchanged)
    - Section 6 (Capacity Statement) cites the M7.5 ceiling
    - Section 7 (Anti-Promise List) has outcome and scope anti-promises
    - Section 8 (How v2.0 Differs From v1.1) names specific architectural changes
    - Section 9 (Cohort Variant) addressed or N/A noted
    - Section 10 (Customer Commitments) named
    - Section 11 (Iteration Trajectory) names earliest v2.1 and v3.0 dates
    - Sections 12-13 (Reviewer + Sign-Off) ready

  anti_pivot_statement:
    - Mechanism is named explicitly as unchanged
    - Customer is named explicitly as unchanged
    - Problem is named explicitly as unchanged
    - Statement makes the architectural-vs-pivot distinction visible

  architectural_changes_evidence:
    - Each change in Section 8 traces to v1.x evidence (M7.6 measurement, customer feedback patterns)
    - No change introduces a structure absent from v1.x evidence
    - Changes are bounded (not "while we're at it" feature additions)

  anti_promise_list:
    - At least 3 outcome anti-promises (specific, not vague)
    - At least 3 scope anti-promises (specific, not vague)
    - Capacity anti-promises present (covered in Section 6 or Section 7)
    - Anti-promise list at least as long as deliverable list

  capacity_consistency:
    - Concurrent-customer ceiling cited matches M7.5 Section 7
    - Bottleneck activity cited matches M7.5 Section 3
    - Capacity anti-promises (waitlist, 15% drift trigger) present

  iteration_trajectory:
    - v2.0 deployment date stated
    - Earliest v2.1 release date is at least 60 days post-deployment
    - Earliest v3.0 release date is at least 6 months post-v2.0
    - Trigger conditions for v2.1 named

failure_patterns_to_flag:
  - Anti-pivot statement missing or implicit
  - Mechanism, customer, or problem changed but framed as v2.0
  - Anti-promise list shorter than 3 outcome + 3 scope items
  - Capacity statement inconsistent with M7.5 analysis (different ceiling number)
  - Pricing changes that aren't derived from v1.x evidence (likely pivot indicator)
  - Section 8 architectural changes that don't trace to v1.x learning
  - "While we're at it" feature additions absent from M7.2 decomposition
  - v3.0 release date earlier than 6 months post-v2.0 (insufficient measurement window)

submission_path: c7_offer_v2_documents
output_format: JSON with the fields specified in system_prompt
expected_response_time: 5-12 minutes

Record the offer baseline, approval and limits on change

What the workbook does

The SYS_05_OFFER_LOCK sheet records an offer's definition, delivery, evidence, approved experimentation and governance status. It contains twenty-six columns and one example offer row. It has no formulas, automatic scoring or executable freeze logic. You will learn how to interpret every field and prepare a reviewable record without treating a typed status as proof of approval.

The sample is a Weekly Money Control System for an Overwhelmed Budget Rebuilder. It is an illustrative source record, not an adopted RISER subscription, financial recommendation or verified customer result. Preserve its actual values in the complete appendix while adapting the field structure to your own evidence.

Identify the offer and its review history

Columns A–E contain Offer ID, Project ID, Date Locked, Offer Name and Primary Avatar. The example uses OF-0001, PRJ-0001 and December 15, 2025, followed by the offer and audience names above. These fields let a reviewer distinguish this record from another project or offer version. The source provides no uniqueness check, versioning formula or duplicate-prevention mechanism.

The dates are stored as text in the original. Their appearance alone does not mean the workbook has a functioning date calculation or review schedule. Preserve the original representation when inspecting the source and verify the date meaning in an actual operating record.

Define the promise, mechanism and exclusions

Column F, Core Promise (Outcome), says the sample aims to help someone feel in control of money without obsession or shame. This is proposed customer-facing language, not evidence that every user experiences that feeling.

Column G, Mechanism (How it works), describes a weekly system for awareness, planning and decisions. The sample calls aspects automated, but the workbook contains no automation proving that claim. Column H, What This Is NOT, excludes a budgeting app, financial advice and extreme frugality. Keep those distinctions visible when interpreting the promise rather than letting a broad headline override the stated scope.

For your own record, connect the promise to an actual deliverable and documented mechanism. Do not replace an unsupported result with more confident wording.

Specify the first win and its evidence

Column I, First Win Definition, says the sample user completes a ten-minute weekly money map and identifies found money. Column J, Time-to-First-Win, gives twenty-four hours. Ten minutes describes the proposed activity duration; twenty-four hours describes the separate first-win timing field. They are not interchangeable measures, and neither is verified by the example row.

Column K, Proof Mechanism, names a before/after worksheet and a bank-balance-clarity screenshot. Those are proposed evidence types, not attached completed proof. Use only appropriate evidence for the actual task and keep sensitive account information out of public lesson examples. This source is not a request to access financial accounts or provide individualized financial guidance.

Describe the included assets, delivery and price

Column L, Offer Stack (Included Assets), includes a checklist, templates, short walkthrough videos, reminder automation and community access. Column M, Delivery Method, describes digital templates, short videos and automated reminders. The lists overlap but serve different purposes: one states what is included and the other how it is delivered. Community access and the checklist remain included even though the delivery field does not repeat them.

Column N, Price Point, contains the text “$49 / month.” It is a sample monthly price, with no separate currency-code field, tax treatment, price calculation or billing integration. It is not a newly authorized charge or verified public offer.

Column O, Guarantee / Risk Reversal, says cancel anytime and a seven-day no-questions refund. Preserve those as the sample's terms. The row supplies no complete agreement, billing implementation or evidence that the policy has been applied. Do not adopt these terms for a different offer without the actual approved policy.

Separate objections, success conditions and failure modes

Column P, Primary Objections Addressed, lists lack of time, previous failure and concern that the habit will not stick. They are sample objections, not transcripts of verified customers.

Column Q, What Must Be True for Success, requires an honest weekly review and engagement once per week. Column R, Known Failure Modes, lists skipping the first win, overcomplicating setup and avoiding the numbers. These fields expose participation requirements and plausible breakdowns. They do not prove that every poor result is the customer's fault or that the proposed system removes all effort.

Compare these conditions with the core promise and delivery. A promise of a simple process still needs an accurate explanation of what the customer must do.

Bound experiments and changes

Column S, Allowed Experiments, lists messaging angles, hook tests and call-to-action wording. Column T, Disallowed Changes, lists changing the core promise, adding complexity and expanding the avatar. This sample distinguishes testing how an existing offer is explained from changing the offer itself.

A permitted hook test still needs to respect the actual promise and evidence. If learning suggests that the promise or audience should change, seek the appropriate revision decision instead of quietly treating it as a wording test. The workbook does not define a full change-approval workflow.

Interpret the governance fields

Column U, Lock Status, contains Locked in the example. Column V, Freeze Rule Trigger, states a refund rate greater than 8% OR a support-ticket spike greater than 30%. Keep the strict greater-than comparisons and the OR relationship. Exactly 8% or exactly a 30% increase does not satisfy the written greater-than condition, though a separate policy could require action for other reasons.

The source omits the refund denominator, observation window, support baseline, minimum counts and precise meaning of a spike. It does not connect the text to a formula or alert. Resolve those definitions before evaluating a real trigger, and do not invent a freeze result from the example.

Column W, Governor Approval (Y/N), contains Y. Column X, Owner (WHO), names Founder. Column Y, Last Review Date, repeats December 15, 2025. Column Z, Notes, says the offer was locked after fifteen validated signals and a successful beta. The actual signal records, validation criteria, beta results and approval evidence are not included. Y and Locked are recorded values, not authenticated review evidence or a locked spreadsheet cell.

Understand all three dropdowns

J 2:J 1000 lists nine first-win timing choices: five minutes, fifteen minutes, thirty minutes, one hour, twenty-four hours, three days, seven days, fourteen days and thirty days. These options do not replace the separate ten-minute activity description in the sample. If an actual timing does not fit, resolve the allowed representation instead of silently choosing a false value.

U 2:U 1000 lists Draft, Locked, Soft Freeze and Hard Freeze. The workbook does not define the difference between the two freeze levels or their permitted transitions. W 2:W 1000 lists Y and N for governor approval. A blank is allowed in all three validation ranges.

The file's validation settings do not enable input or error messages. Each rule is a list validation with allowBlank set to 1 and showDropDown, showInputMessage and showErrorMessage stored as 0. These are the original settings, not a completed native-application behavior test. Do not assume the dropdowns prevent every invalid entry. The visible first row is frozen for navigation. The source contains no automatic filter, conditional formatting, charts, images, comments or hyperlinks.

Review the complete record

An authored review should trace the twenty-six fields to the approved offer and supporting evidence, confirm the actual owner and decision date, distinguish missing values from No, and check that permitted experiments do not contradict disallowed changes. Keep the first-win measure, participation and proof aligned.

The original contains all fifty-two populated cells as text: twenty-six headings and twenty-six sample values. Its recorded price, dates, status and thresholds do not calculate themselves. A complete source appendix and original download let a reviewer inspect the actual data and dropdown definitions rather than relying only on this explanation.

Apply the marketing themes and practice

As an authored Brunson/ClickFunnels connection, the approved promise, first win and boundaries should remain consistent across hooks, calls to action and delivery. As an authored Hormozi/Acquisition.com connection, describe value through the desired outcome, supporting proof, delay and effort without hiding participation or risk. This workbook supplies a record format, not proof of those outcomes.

For practice, draft your offer record using the same fields, identify the evidence supporting approval, and explain one permitted message test and one change requiring renewed review. Define the missing metric windows and baselines before claiming a freeze rule is ready to operate. Do not copy the sample's Y or Locked status as a shortcut to completion.

Resources

• Assigned Offer Lock workbook — original spreadsheet source.
• RISER NATION CORP.

The original workbook is preserved byte-for-byte for the complete appendix and download. The sample's videos, worksheets, automation, community, signal evidence and beta results are not supplied as linked artifacts in the workbook and remain unresolved resources.

Assigned source: D0486 original

{
  "sheet_name": "SYS_05_OFFER_LOCK",
  "cells": {
    "A1": "Offer ID",
    "B1": "Project ID",
    "C1": "Date Locked",
    "D1": "Offer Name",
    "E1": "Primary Avatar",
    "F1": "Core Promise (Outcome)",
    "G1": "Mechanism (How it works)",
    "H1": "What This Is NOT",
    "I1": "First Win Definition",
    "J1": "Time-to-First-Win",
    "K1": "Proof Mechanism",
    "L1": "Offer Stack (Included Assets)",
    "M1": "Delivery Method",
    "N1": "Price Point",
    "O1": "Guarantee / Risk Reversal",
    "P1": "Primary Objections Addressed",
    "Q1": "What Must Be True for Success",
    "R1": "Known Failure Modes",
    "S1": "Allowed Experiments",
    "T1": "Disallowed Changes",
    "U1": "Lock Status",
    "V1": "Freeze Rule Trigger",
    "W1": "Governor Approval (Y/N)",
    "X1": "Owner (WHO)",
    "Y1": "Last Review Date",
    "Z1": "Notes",
    "A2": "OF-0001",
    "B2": "PRJ-0001",
    "C2": "2025-12-15",
    "D2": "Weekly Money Control System",
    "E2": "Overwhelmed Budget Rebuilder",
    "F2": "Feel in control of money without obsessing or feeling shame",
    "G2": "A simple weekly system that automates awareness, planning, and decisions",
    "H2": "Not a budgeting app; not financial advice; not extreme frugality",
    "I2": "User completes a 10-minute weekly money map and identifies found money",
    "J2": "24 hours",
    "K2": "Before/after worksheet + bank balance clarity screenshot",
    "L2": "Checklist; templates; short walkthrough videos; reminder automation; community access",
    "M2": "Digital templates + short videos + automated reminders",
    "N2": "$49 / month",
    "O2": "Cancel anytime; 7-day no-questions refund",
    "P2": "I don’t have time; I’ve failed before; This won’t stick",
    "Q2": "User completes weekly review honestly; engages once per week",
    "R2": "User skips first win; overcomplicates setup; avoids looking at numbers",
    "S2": "Messaging angles; hook tests; CTA wording",
    "T2": "Changing core promise; adding complexity; expanding avatar",
    "U2": "Locked",
    "V2": "If refund rate >8% or support tickets spike >30%",
    "W2": "Y",
    "X2": "Founder",
    "Y2": "2025-12-15",
    "Z2": "Offer locked after 15 validated signals and successful beta"
  },
  "validations": [
    {
      "attributes": {
        "sqref": "J2:J1000",
        "showDropDown": "0",
        "showInputMessage": "0",
        "showErrorMessage": "0",
        "allowBlank": "1",
        "type": "list"
      },
      "formula1": "\"5 min,15 min,30 min,1 hour,24 hours,3 days,7 days,14 days,30 days\""
    },
    {
      "attributes": {
        "sqref": "U2:U1000",
        "showDropDown": "0",
        "showInputMessage": "0",
        "showErrorMessage": "0",
        "allowBlank": "1",
        "type": "list"
      },
      "formula1": "\"Draft,Locked,Soft Freeze,Hard Freeze\""
    },
    {
      "attributes": {
        "sqref": "W2:W1000",
        "showDropDown": "0",
        "showInputMessage": "0",
        "showErrorMessage": "0",
        "allowBlank": "1",
        "type": "list"
      },
      "formula1": "\"Y,N\""
    }
  ],
  "sheet_views_xml": "<sheetViews xmlns=\"http://schemas.openxmlformats.org/spreadsheetml/2006/main\"><sheetView workbookViewId=\"0\"><pane ySplit=\"1\" topLeftCell=\"A2\" activePane=\"bottomLeft\" state=\"frozen\"/><selection pane=\"bottomLeft\" activeCell=\"A1\" sqref=\"A1\"/></sheetView></sheetViews>",
  "columns_xml": "<cols xmlns=\"http://schemas.openxmlformats.org/spreadsheetml/2006/main\"><col width=\"12\" customWidth=\"1\" min=\"1\" max=\"1\"/><col width=\"12\" customWidth=\"1\" min=\"2\" max=\"2\"/><col width=\"14\" customWidth=\"1\" min=\"3\" max=\"3\"/><col width=\"24\" customWidth=\"1\" min=\"4\" max=\"4\"/><col width=\"22\" customWidth=\"1\" min=\"5\" max=\"5\"/><col width=\"28\" customWidth=\"1\" min=\"6\" max=\"6\"/><col width=\"28\" customWidth=\"1\" min=\"7\" max=\"7\"/><col width=\"20\" customWidth=\"1\" min=\"8\" max=\"8\"/><col width=\"22\" customWidth=\"1\" min=\"9\" max=\"9\"/><col width=\"18\" customWidth=\"1\" min=\"10\" max=\"10\"/><col width=\"26\" customWidth=\"1\" min=\"11\" max=\"11\"/><col width=\"26\" customWidth=\"1\" min=\"12\" max=\"12\"/><col width=\"18\" customWidth=\"1\" min=\"13\" max=\"13\"/><col width=\"16\" customWidth=\"1\" min=\"14\" max=\"14\"/><col width=\"22\" customWidth=\"1\" min=\"15\" max=\"15\"/><col width=\"26\" customWidth=\"1\" min=\"16\" max=\"16\"/><col width=\"26\" customWidth=\"1\" min=\"17\" max=\"17\"/><col width=\"22\" customWidth=\"1\" min=\"18\" max=\"18\"/><col width=\"22\" customWidth=\"1\" min=\"19\" max=\"19\"/><col width=\"22\" customWidth=\"1\" min=\"20\" max=\"20\"/><col width=\"16\" customWidth=\"1\" min=\"21\" max=\"21\"/><col width=\"22\" customWidth=\"1\" min=\"22\" max=\"22\"/><col width=\"18\" customWidth=\"1\" min=\"23\" max=\"23\"/><col width=\"16\" customWidth=\"1\" min=\"24\" max=\"24\"/><col width=\"14\" customWidth=\"1\" min=\"25\" max=\"25\"/><col width=\"28\" customWidth=\"1\" min=\"26\" max=\"26\"/></cols>",
  "formulas": 0
}

Investigate buyer signals and choose the next offer action

Turn a sale into a learning cycle

Imagine an operator celebrating a tenth sale. This is an illustrative scene. A refund request arrives the same day. The operator now needs to understand both the purchase and the disappointment.

The gap is between collecting revenue and learning from buyers. This lesson teaches all eight phases of the source's Post-MVO Forensic Audit Loop. You will gather numbers, inspect buyer evidence and write a justified action brief.

The source combines three ideas. Its Hormozi lens revisits perceived value after every ten sales. Its Kennedy lens treats feedback as business evidence. Its Brunson lens looks for the next problem after the current result. These are source-attributed applications, not verified quotations or endorsements. They support the user's ClickFunnels/Brunson and Hormozi/Acquisition.com educational themes.

Buyer feedback can guide product, copy, naming and ascension work. It does not automatically explain causation or grant permission to publish private messages. Keep the evidence, its context and the proposed interpretation separate.

Know what triggers the review

Read all six trigger conditions with their scope and deadline. Some trigger the full review; others point to selected phases.

The opening calls this event-driven rather than calendar-driven. Yet day 30, day 90 and the standing calendar are explicit parts of the source. Teach both: event triggers plus scheduled follow-through.

When the tenth sale and a conversion decline coincide, run one full audit and record both signals. Don't duplicate the same full session. A 20% drop is relative to the prior 30-day average, not twenty percentage points. A zero baseline or inconsistent traffic population needs investigation before calculating that trigger. The ascension trigger also needs a defined buyer cohort and observation period.

No audit, calendar event or outreach is executed by reading this lesson. The deadlines describe the source's proposed operating practice.

Phase 1 — Build the numerical baseline

Start with all seven metrics. For each, identify the numerator, denominator, time window and data source. A healthy range and an action threshold are different pieces of guidance; preserve both.

Cold traffic means visitors without the defined prior relationship used for your analysis. Define warm traffic separately. Avoid mixing unique people, visits, clicks and orders. Refunds from old cohorts divided by new sales can distort interpretation. Explain the cohort and refund definition in your record.

The source's five-step flow follows. Its sentence saying stop at the first Yes is wrong for steps 1–3, where Yes means continue. Follow each actual branch.

Source procedure for study:

1. Is cold traffic volume sufficient? (Minimum 200 unique visitors to judge conversion rate accurately)

– No → Traffic problem. Do not adjust offer or copy until you have enough data. Solve distribution first.

– Yes → Continue to step 2.

2. Is the opt-in rate above 12%?

– No → Hook or landing page problem. The market is seeing the offer and not raising their hand. Fix the lead magnet, headline, or traffic targeting before anything else.

– Yes → Continue to step 3.

3. Is the cold conversion rate above 0.8%?

– No → Sales page, offer stack, or trust problem. Proceed to Phase 2 (Value Equation Audit) and Phase 4 (Funnel Diagnostic) before spending more on ads.

– Yes → Continue to step 4.

4. Is the refund rate above 8%?

– Yes → Expectation mismatch or delivery failure. Proceed directly to Phase 5 (Refund Forensics). This is the most urgent problem in the stack.

– No → Continue to step 5.

5. Is the ascension rate below 8% after 60+ days of live offer?

– Yes → Ascension sequence failure. Proceed to Phase 6 (Next Problem Signal). The value ladder exists on paper but buyers are not moving up it.

– No → Offer is healthy at the quantitative level. Proceed to Phase 2 to find optimisation opportunities.

Two hundred visitors is the source's starting heuristic, not a guarantee of accurate conversion estimates. At a 1% rate, that volume implies roughly two expected purchases. A small change in count can greatly move the rate. Don't postpone investigation of known refund or delivery harm merely because traffic is low.

Exactly 12% opt-in and 0.8% conversion expose a wording gap: the flow requires above, while the metric table triggers below. Record that ambiguity. The flow's ascension check below 8% after 60 days differs from the earlier below 10% for 21 days trigger. Those may serve different warning levels, but the source does not fully reconcile them.

Use every data source and review cadence listed here. Platform names are examples; this lesson does not install tracking or verify their current interfaces.

Phase 2 — Examine all four value variables

The source uses Hormozi's conceptual Value Equation: outcome multiplied by perceived likelihood, divided by time delay multiplied by effort and sacrifice. Increase a credible desired result and belief; reduce unnecessary delay and burden. This is a thinking framework, not a calibrated revenue prediction or a reason to divide by zero.

Ask buyers what they believe and compare that with delivery. Falling conversion can have other causes too, including traffic changes or broken tracking. Read each question, source and warning in the four complete tables.

Dream outcome clarity

Separate a measurable expected result from a vague category. Compare the buyer's words with the page. A stated revenue goal and a possible emotional goal are different hypotheses; don't claim hidden motives without evidence.

Perceived likelihood

Look for proof that fits the actual buyer and promise. Doubt about a constraint can reveal missing explanation. A price objection can also mean limited funds or a different priority; it does not almost always prove disbelief.

Time delay

Record the first expected result, the first observed result and the actual delivery sequence. A 72-hour win should be achievable and relevant. No quick win does not literally make perceived delay infinite or establish a day-seven refund spike; those are overstated source claims.

Effort and sacrifice

Inspect workload surprises and the step where participation drops. The source uses 60% step completion as a flag. That does not prove the step must become done-for-you. Access, instructions, timing and buyer circumstances can also explain the data. Ask non-starters rather than assigning intent.

Fill all four rows below. Current perception needs a citation or measured observation. The target must fit the real offer. State the specific change that could close the supported gap.

Phase 3 — Capture buyer language with context

The source prefers direct buyer language over invented marketing phrases. Use it to understand pain, desire and hesitation. It is not a guarantee that every buyer phrase will outperform professional copy. Preserve verbatim research separately from any public copy, with permission and context where needed.

The five sources below include what to capture, how to tag it and when to review it. The listed software is illustrative; no connected data is collected by this lesson.

Use all six functional tags. A phrase can have multiple tags. The source ties them to specific page sections, email days and ad functions; these are its sequence references, not proof those exact assets already exist in your account.

The source recommends phrases of three to eight words. Its example tags “spinning my wheels” as chronic pain and “No idea what to try next” as acute pain. Both come from one longer illustrative email. Preserve the full message for context. A phrase can be useful without treating the proposed tag as the only possible interpretation.

Single words can lack context, while whole sentences may need more space. The three-to-eight rule is a practical extraction convention, not a ban on retaining full source text. Do not paraphrase the research record merely to fit a headline.

The first language database specification has eight fields:

Record conversion lift only when its measurement supports the claim. Note the test population and design. A difference between two dates does not by itself show the wording caused it. The later database definition omits this field and adds Phrase ID; retain both needs in a proposed reconciliation rather than silently dropping one.

Phase 4 — Locate the funnel problem

Trace each stage from ad click to first access. A page problem, checkout issue and onboarding problem require different tests. The full table preserves each source metric, suggested cause and first test.

These figures are source heuristics, not universal benchmarks. For example, this table targets cold opt-in above 25%, while Phase 1 uses 15–30% healthy and below 12% as an action threshold. The iteration section later uses below 15%. Keep the context visible. Likewise, sales-page add-to-cart rate is not purchase conversion.

Check measurement quality before changing creative. Email opens and clicks may be affected by instrumentation, privacy features or automated activity. Verify current platform behavior during implementation. A stronger guarantee must remain truthful and feasible. An eight-minute first task or seventy-percent activation target must not be represented as a measured result without evidence.

Use the complete five-step session-review procedure below. It includes both non-buyers and buyers.

Source procedure for study:

1. Set up Hotjar on sales page and landing page if not already active. Minimum 200 sessions before drawing conclusions.

2. Watch scroll depth heatmap: if 70%+ of visitors are not reaching the offer stack, the page is losing them in the problem section or the story. The copy before the offer is too long or too weak.

3. Watch click map: what are visitors clicking that is not a CTA? This reveals unmet curiosity — they want information you have not provided.

4. Watch 5 session recordings of visitors who scrolled to the bottom but did not convert. Note the exact moment they stop engaging.

5. Watch 5 session recordings of visitors who converted. Note what they did differently — faster scroll to specific section, immediate click of CTA.

The source's 200-session minimum and ten watched sessions are exploratory guidance. They do not prove why people left. If 70% never reach the offer stack, inspect relevance, navigation, device behavior and page length rather than declaring the story weak without testing. Non-CTA clicks can suggest a question but may also reflect a confusing interface.

Phase 5 — Learn from refunds and dropouts

A refund is both a business outcome and potential diagnostic evidence. A dropout is a signal, not a character judgment. The source lists wrong fit, friction and guarantee-related behavior as possibilities. Those are not the only causes.

Its protocol calls for review within 24 hours for every refund request, whether granted or not. Keep that obligation distinct from the weekly Thursday calendar reminder. Learn all five steps and their outputs:

The instruction to choose one primary cause must not erase uncertainty or contributing causes. Record a primary code, the evidence and any unresolved alternatives. The second-or-third pattern trigger here differs from 2+ in the database and 3+ in later checks. State which convention you are applying and preserve the source conflict.

The complete six-code taxonomy follows. Treat its diagnoses and recommended actions as proposals requiring evidence.

RC-1 asks whether the offer serves the buyer's circumstances. RC-2 compares actual copy with actual delivery. RC-3 examines timing and proposes an early win and truthful timeline. RC-4 investigates a specific technical or instructional barrier, with three occurrences in 30 days as its named pattern. RC-5 records external circumstances and suggests an optional ninety-day pause or later reactivation. Such circumstances can still inform product design.

RC-6 labels suspected guarantee exploitation. Completing a course before requesting a refund is not proof of dishonest intent. Don't turn that single observation into an automatic blacklist or denial. Any real refund response must honor the actual offer terms and evidence.

Here is the source's full reply for study:

Forensic Reply Template Hi [Name], I'm processing your refund now — you'll see it in 3–5 business days. Before I do, I'd genuinely appreciate 60 seconds of honest feedback. Not to change your mind — I just want to understand what happened so I can make this better. What was the single biggest gap between what you expected and what you found? You don't need to be kind about it. Your honest answer is worth more to me than the sale. Either way, your refund is on its way.

Its “before processing” wording conflicts with “processing now” and confirmation in the same message. The intended useful principle is optional feedback without holding the refund hostage. Confirm only what has happened. Replace the 3–5-business-day estimate if it does not match the actual processor situation. Do not make a response a condition of a refund.

Dropout detection covers four distinct signals and suggested messages:

No login at 72 hours differs from Module 1 incomplete at seven days. The second row's label says not started, but the condition says incomplete. Preserve that distinction. Ten days without new activity and fourteen days without a community post are further signals, not proof of failure. Some learners consume without posting. Any check-in should fit the person's context and actual available next step; the source's claims about week-one completion need evidence.

Phase 6 — Map the next problem

The Brunson-style chain starts with Problem A and asks what appears after its solution. That next need can inform a core offer, advanced support or continuity. It is not certain every solution creates a paid next need, or that the operator is the only person who sees it.

Look for the five types of evidence below. Each has a different location, example and proposed implication.

A buyer asking how to turn ten leads into calls suggests a conversion need. Overload after success suggests capacity or delivery help. A request for what comes next suggests consistency or scaling support. Comparison with another provider and a referral to a more advanced colleague can reveal different segments. Validate demand and fit before treating a comment as a product order.

Use the full A–D chain template and cite the evidence for each next step. Do not invent offers or prices to fill blanks.

The source references exit-interview questions 6 and 7 but does not supply the full interview here. It also assumes related tier assets may exist. Preserve missing evidence and assets as gaps rather than treating the chain as a completed roadmap.

Phase 7 — Check the method's name and meaning

Every 90 days, inspect how buyers describe the method. Naming can change as understanding improves, without changing the underlying work. The source's 10× label describes a naming test, not proven tenfold performance.

Read the current name to five new avatar-matched people. Ask for an excitement score from 1–10 and what they think the method does. The source triggers renaming below 7 or when the description mismatches. It also says failure on two naming criteria initiates a cycle. Preserve both rules and record which one triggered review.

Learn all five criteria, including every pass and fail example:

Specificity names a process. Implied outcome suggests a credible result. Distinctiveness reduces confusion with generic categories. Repeatability asks whether a buyer can explain it. Curiosity asks whether the name creates a meaningful question. A phrase described as named and owned does not establish legal exclusivity.

The five rename steps and full eight-asset checklist follow:

Source procedure for study:

1. Generate 10 new mechanism name candidates using the following structure: [Adjective/Method Type] + [Verb or Descriptor] + [Container Word].

2. Test the top 3 names with 5 avatar-matched individuals using the 10× Rename Test. Score each on excitement (1–10) and description accuracy.

3. Select the winner. Requires a score of 7+ average AND accurate description from 4 of 5 testers.

4. Update the mechanism name across: sales page, email sequence (Days 8–10), all ad creatives, course platform titles, and GEO schema markup.

5. Log the rename in Airtable: old name, new name, date, test scores, and conversion rate before and after the 30 days following rename.

Source procedure for study:

☐ Sales page — headline, mechanism section, and all stack slide references

☐ Email nurture sequence — Days 8, 9, and 10 (mechanism introduction emails)

☐ Paid ad copy — all active creatives using the mechanism name

☐ Course platform — module titles and overview description

☐ YouTube and podcast episode titles referencing the mechanism

☐ AEO/GEO schema — branded methodology keywords updated in L0 and L1 keyword grid

☐ LLMs.txt file — mechanism name updated in authority declaration section

☐ Pillar article — update H 1 and mechanism definition section

The structure for ten candidates is adjective or method type, plus verb or descriptor, plus container word. Test the top three names with five people. Acceptance requires an average 7+ and accurate descriptions from four of five. This is formative feedback, not conclusive market validation. The source does not define a complete accuracy-scoring method or candidate-ranking formula.

Record old and new names, dates, scores and thirty-day before/after conversion observations. Do not call that observational change causal proof. The L0/L1 keyword grid, authority declaration, schema implementation and LLMs.txt structure are referenced but absent here. Updating them cannot guarantee search rankings or generated citations; current official guidance must be checked during implementation.

Phase 8 — Write one justified action recommendation

The four actions are Scale, Iterate, Kill and Launch Next. The source says to prioritize the highest in the stack but lists Scale first. Its conditions can overlap. It supplies no complete precedence algorithm. As an authored clarification, investigate unresolved critical delivery or kill indicators before recommending increased traffic.

Scale

The source requires cold conversion above 2%, refunds below 5%, ascension above 10%, no critical value-variable decline and alignment between buyer language and copy. It proposes increasing paid spend no more than 20% per day, monitoring CPA and refunds daily for seven days, adding a second traffic source based on effective organic content, rewriting the headline and hero from the top three acute-pain phrases, and activating ascension for completers.

Those conditions and spending steps are not universal safe operating rules. Capacity and unit economics still matter. Changing traffic and copy together confounds attribution. This lesson does not authorize or perform spending, launches or CRM changes.

Iterate

The source describes one or two below-threshold metrics with a diagnosable fix that does not require rebuilding the core method or rerecording the programme. Preserve every test and window:

Do not change headline and guarantee simultaneously in the named conversion test. The source's 200 visitors per variant and 100 email sends per variant are minimum suggestions, not adequate statistical power for every case. Record the actual test design. Before/after ascension changes over thirty days can reflect other changes too.

Kill assessment and redesign

The source lists refunds above 15%, cold conversion below 0.5% after 500+ visitors, completion below 40%, or at least two root-cause patterns appearing three times without a diagnosable fix. Its punctuation leaves some conjunction scope unclear. Do not implement it as an automatic business shutdown. The related monthly scorecard instead calls for a separate Kill Assessment; preserve that procedural distinction.

The source's useful lesson is to examine evidence without attachment to past work. Preserve buyer language; document unsuitable-fit evidence in a Negative Avatar profile; inspect what buyers thought they were solving and whether another offer serves it; then return to MVO offer construction with the findings. Its referenced Phase 5 Negative Avatar template is not actually supplied here. Its statement about most millionaires' failed offers is an unverified generalization, not evidence needed for a decision.

Launch next

The source asks for three or more consistent Problem B signals, a current offer meeting Scale criteria, and capacity to build and deliver. Use the next-problem evidence as the new offer brief. It proposes completing the current ascension sequence first, positioning the new tier around the actual Problem B, and running beta testing before public launch.

An absent ascension funnel does not prove a new product will cannibalize the current one. Treat that as a risk to assess. Do not invent a beta process or assume three comments establish demand. The source provides recommendations; no launch occurs here.

Follow the standing calendar without missing urgent triggers

Retain all eight cadence rows and outputs. The listed durations are planning estimates, not measurements.

Thursday's refund review is an additional checkpoint, not permission to wait past the 24-hour protocol. A full audit is estimated at 2.5–3 hours; the quarterly trigger says three hours while the calendar says half a day. Record the difference rather than promising a fixed duration. The first Monday language review and the day 30 launch trigger are separate activities.

Define the database without pretending it is complete

The source claims five linked tables, but fully specifies only three. They are Buyer Language, Audit Records and Refund Records. Preserve every defined field below.

These tables link to Offers, Buyers and Negative Avatar definitions that are not supplied. That makes three additional named dependencies, so the document does not define an exact five-table topology. No working database, automations or enforced relationships are delivered by this source.

The earlier language schema includes Conversion Lift but the later version replaces it with Phrase ID. An implementation proposal should retain both requirements explicitly. Compound-trigger logging also conflicts with a single-select Trigger Type. Choose a multi-value design or additional notes deliberately; do not pretend the single field records all simultaneous triggers.

The Audit Records table uses root-cause patterns 2+ while the master scorecard uses 3+. Preserve the conflict. The thirty-day review date is a reminder to examine outcomes, not evidence the action worked.

Complete the master scorecard and every checklist

The master scorecard contains header information, each phase's findings, up to three action items, owners and deadlines, and a thirty-day review date. Blank rows are requests for evidence, not proof that the audit passed.

Read the full weekly, ten-sale and quarterly checklists below. They preserve the exact operational details of the source.

Source procedure for study:

Master Forensic Audit Checklist

Weekly Standing Ritual

☐ Monday: Pull 7 Phase 1 metrics, log in Airtable, flag thresholds

☐ Tuesday: Tag new support tickets and email replies by language type

☐ Wednesday: Scan community — archive posts with 3+ reactions

☐ Thursday: Process any new refunds through 5-step protocol

☐ Friday: Weekly summary note — patterns, flags, triggers crossed

When 10-Sale Trigger Fires (Full Audit — block 3 hours)

☐ Phase 1: Pull all 7 metrics. Run diagnostic flow chart. Identify primary leak if exists.

☐ Phase 2: Run four-variable Value Equation Audit using buyer data from this cycle

☐ Phase 2: Complete Value Equation Output table — fill all four rows with evidence

☐ Phase 3: Review all new buyer language captured since last audit — tag and add to database

☐ Phase 3: Identify top 3 PAIN-ACUTE phrases — compare to current sales page copy

☐ Phase 4: Review funnel metric table — flag any stage below threshold

☐ Phase 4: Watch 5 non-converting session recordings if conversion below threshold

☐ Phase 5: Complete refund forensics for all refunds since last audit

☐ Phase 5: Check for RC patterns appearing 3+ times — trigger fix protocol if found

☐ Phase 6: Review exit interviews and community posts for Next Problem Signals

☐ Phase 6: Update Next Problem Chain Map if new signal found

☐ Phase 7: Run Mechanism Freshness Test if 90-day trigger is also active

☐ Phase 8: Select one Action Protocol — write action brief with owner and deadline

☐ Log completed scorecard in Airtable Audit Records table

☐ Set 30-day review calendar reminder

Quarterly Deep Audit (Add to Full Audit Above)

☐ Run Mechanism Freshness Test regardless of 90-day timer

☐ Run 10× Rename Test with 5 new avatar-matched individuals

☐ Update Next Problem Chain Map with full product roadmap review

☐ Review all ANTI-LANGUAGE tags — scrub from every active copy asset

☐ Review Value Ladder gap analysis — are all ascension sequences live and automated?

☐ Export full buyer language database — identify top 10 phrases not yet deployed in copy

☐ Brief for Mechanism Rename if test score below 7.0

☐ Update GEO/AEO schema with any new branded methodology terms

The full-audit text says not to skip phases, while its checklist limits a fresh mechanism test to the 90-day trigger. An editorial reconciliation is to review the existing freshness evidence each audit and mark whether a new test is due. That is a proposed clarification, not an exact source rule. The quarterly checklist explicitly calls for new five-person testing and the full roadmap review.

A complete record should distinguish observed data, source threshold, your interpretation, missing evidence and assigned action. It must not describe draft text as a completed audit, deployment or verified result.

Resources and submission

Open the assigned Post-MVO Forensic Audit original. The original preserves all 44 tables and source wording. Expand the original-source appendix accompanying this lesson to inspect the full document.

Open the assigned Offer Scorecard source for the related monthly review. That source's worked example totals 49, not 51, and its schema has 35 fields, not 33; use its explanatory lesson with the original.

Read the Beta Testing Methodology SOP. Its Phase 5 supplies a six-field Negative Avatar template. Its nine-question exit interview is related material, but questions 6 and 7 ask about value/improvements and referral fit; they do not exactly match the next-problem interview referenced above.

Read the Negative Avatar Modelling SOP. This companion expands the profile, qualification and review system and refers back to this audit's refund protocol. Its rules contain differences that require the accompanying explanations; it is not an automatic buyer-classification system.

Read the two companion teaching sections below with their complete original-source appendices. Read the accompanying MVO Playbook V 5 teaching and full original appendix. The exact full next-problem interview, keyword grid and search-schema assets still require verified matching. Software names in the tables are examples, not verified links or installed services.

RISER NATION CORP is the project brand destination. Current spreadsheet assignments govern this lesson.

Turn in: a completed audit record with evidence for each applicable phase, a list of unresolved threshold or source questions, and one prioritized action brief with no more than three specific tasks, owners, deadlines and a review date. Keep it in your course work folder until the submission destination is confirmed. A reviewer should check evidence and conflicting conditions before approving any business action.

Assigned source: D0488 original

RISER Nation  |  Post-MVO Forensic Audit Loop SOP  |  V1.0

Page PAGE of NUMPAGES

{
  "body_paragraphs": [
    "RISER NATION",
    "MASTER OPERATING SYSTEM",
    "",
    "  SOP — POST-MVO FORENSIC AUDIT LOOP  ",
    "",
    "The Closed-Loop Intelligence System That Turns Every Buyer Into Product Development Data",
    "Kennedy × Hormozi × Brunson × 2026 Agentic Framework",
    "",
    "Version 1.0  |  2026 Edition  |  RISER Nation Master Operating System",
    "",
    "SOP Overview",
    "Most operators treat an offer launch as a one-directional event: build, launch, collect revenue. The Post-MVO Forensic Audit Loop treats every launch and every subsequent sale as a two-directional intelligence operation. Revenue flows in. Data flows back. That data becomes the raw material for every future product, every copy revision, every mechanism rename, and every ascension sequence.",
    "",
    "This SOP defines the recurring ritual — triggered by specific events, not by calendar convenience — that transforms your buyer base from a revenue source into a product intelligence engine. It covers eight phases: sales velocity analysis, the Hormozi Value Equation Audit, buyer language extraction, conversion funnel diagnostics, refund and dropout forensics, Next Problem Signal mapping, mechanism freshness testing, and the action protocol that tells you exactly what to do with every finding.",
    "",
    "The Hormozi Principle",
    "Every 10 sales, stop. Run the Value Equation against what your buyers are actually telling you. If Dream Outcome clarity or Perceived Likelihood is dropping, you have a product signal — not a marketing problem. Most operators try to fix falling conversion with more ads. The Forensic Audit tells you whether the offer itself needs surgery first.",
    "",
    "The Kennedy Rule",
    "The money is in the data, not just the sale. Every refund, every support ticket, every reply-to-email, every community post is a market research document. You just have to build the system that reads them.",
    "",
    "The Brunson Lens",
    "Every solution creates a new problem. The Forensic Audit is where you find Problem B — the thing your buyers need next. That chain of problems is your entire product roadmap, handed to you free of charge by people who already trust you.",
    "",
    "The Audit Trigger System",
    "The Forensic Audit is not a monthly calendar event. It is triggered by specific sales and data thresholds. Waiting for a calendar date means you miss the signal window — the moment when buyer feedback is freshest and most actionable.",
    "",
    "Trigger",
    "Condition",
    "Audit Scope",
    "Priority",
    "10-Sale Trigger",
    "Every 10 new purchases of an offer (cumulative)",
    "Full 8-Phase Audit",
    "High — run within 72 hours of the 10th sale",
    "First Refund Trigger",
    "First refund or cancellation request on any offer tier",
    "Phase 4 + Phase 5 only (Funnel Diagnostic + Refund Forensics)",
    "Critical — run within 24 hours",
    "Conversion Drop Trigger",
    "Cold conversion rate drops 20% below prior 30-day average for 7+ consecutive days",
    "Phase 1 + Phase 4 (Sales Velocity + Funnel Diagnostic)",
    "High — run within 48 hours of threshold being crossed",
    "30-Day Scheduled Trigger",
    "30 calendar days after any offer's public launch date",
    "Full 8-Phase Audit regardless of sale count",
    "Standard — run on day 30 even if fewer than 10 sales",
    "90-Day Deep Trigger",
    "90 days post-launch or every 90 days for active offers",
    "Full 8-Phase Audit + Mechanism Rename Assessment + Product Roadmap Update",
    "Strategic — block 3 hours for this session",
    "Ascension Anomaly Trigger",
    "Ascension rate from any tier to the next falls below 10% for 21+ days",
    "Phase 6 only (Next Problem Signal)",
    "Medium — run within 1 week",
    "",
    "Trigger Stack Rule",
    "Multiple triggers can fire simultaneously. If the 10-Sale Trigger and a Conversion Drop Trigger both fire in the same week, run the full 8-Phase Audit once — not twice. Log the compound trigger in Airtable and note which signals were active at the time.",
    "",
    "",
    "PHASE 1",
    "Sales Velocity & Funnel Health Check",
    "The quantitative foundation — what the numbers say before you talk to anyone",
    "",
    "Purpose",
    "Phase 1 establishes the numerical baseline before any qualitative analysis begins. It answers the question: is the offer working, stalling, or dying — and at which specific funnel stage is the problem located? You cannot run the deeper phases meaningfully without this map.",
    "",
    "The Seven Funnel Health Metrics",
    "",
    "Metric",
    "Formula",
    "Healthy Range",
    "Action Threshold",
    "Cold opt-in rate",
    "Opt-ins / Total cold traffic",
    "15–30%",
    "Below 12%: landing page or traffic source problem",
    "Cold MVO conversion rate",
    "Sales / Total cold visitors",
    "1–3%",
    "Below 0.8%: offer, copy, or trust problem",
    "Warm conversion rate",
    "Sales / Warm list visitors",
    "5–15%",
    "Below 4%: email sequence or offer relevance problem",
    "Email open rate (sequence)",
    "Opens / Delivered (14-day sequence)",
    "28–40%",
    "Below 20%: subject line, sender reputation, or list quality problem",
    "Email click-to-sale rate",
    "Sales / Total email clicks",
    "8–20%",
    "Below 5%: landing page or offer mismatch with email audience",
    "Refund rate",
    "Refunds / Total sales (rolling 30 days)",
    "Below 5%",
    "Above 8%: expectation mismatch, delivery failure, or wrong buyer profile",
    "Ascension rate (MVO to Core)",
    "Core Offer purchases / MVO buyers",
    "10–20%",
    "Below 8%: ascension sequence missing or wrong offer presented at wrong time",
    "",
    "The Diagnostic Flow Chart",
    "Run through this sequence. Stop at the first 'Yes' — that is your primary problem to solve before any other phase of this audit matters.",
    "",
    "1.  Is cold traffic volume sufficient? (Minimum 200 unique visitors to judge conversion rate accurately)",
    "–  No → Traffic problem. Do not adjust offer or copy until you have enough data. Solve distribution first.",
    "–  Yes → Continue to step 2.",
    "",
    "2.  Is the opt-in rate above 12%?",
    "–  No → Hook or landing page problem. The market is seeing the offer and not raising their hand. Fix the lead magnet, headline, or traffic targeting before anything else.",
    "–  Yes → Continue to step 3.",
    "",
    "3.  Is the cold conversion rate above 0.8%?",
    "–  No → Sales page, offer stack, or trust problem. Proceed to Phase 2 (Value Equation Audit) and Phase 4 (Funnel Diagnostic) before spending more on ads.",
    "–  Yes → Continue to step 4.",
    "",
    "4.  Is the refund rate above 8%?",
    "–  Yes → Expectation mismatch or delivery failure. Proceed directly to Phase 5 (Refund Forensics). This is the most urgent problem in the stack.",
    "–  No → Continue to step 5.",
    "",
    "5.  Is the ascension rate below 8% after 60+ days of live offer?",
    "–  Yes → Ascension sequence failure. Proceed to Phase 6 (Next Problem Signal). The value ladder exists on paper but buyers are not moving up it.",
    "–  No → Offer is healthy at the quantitative level. Proceed to Phase 2 to find optimisation opportunities.",
    "",
    "Where to Pull This Data",
    "",
    "Metric",
    "Source",
    "Frequency to Review",
    "Traffic volume and source",
    "Google Analytics 4 + UTM parameters on all links",
    "Weekly during active campaigns",
    "Opt-in rate",
    "GA4 conversion events + landing page platform (Kajabi/ClickFunnels)",
    "Weekly",
    "Sales conversion rate",
    "CRM (GoHighLevel/HubSpot) + Stripe dashboard",
    "Every 10 sales (Trigger)",
    "Email sequence metrics",
    "ActiveCampaign automation reports",
    "Weekly",
    "Refund rate",
    "Stripe / ThriveCart refund report",
    "Daily for first 30 days post-launch",
    "Ascension rate",
    "CRM pipeline stage movement report",
    "Monthly",
    "",
    "",
    "PHASE 2",
    "The Value Equation Audit",
    "Hormozi's framework applied to real buyer data — after every 10 sales",
    "",
    "The Framework",
    "Hormozi's Value Equation states that the perceived value of any offer equals the Dream Outcome multiplied by the Perceived Likelihood of Achievement, divided by Time Delay multiplied by Effort and Sacrifice. Most operators use this to design an offer once. The Forensic Audit uses it as a repeating diagnostic — after every 10 sales — to detect where perceived value is eroding before that erosion shows up as a conversion drop.",
    "",
    "The Value Equation",
    "(Dream Outcome × Perceived Likelihood of Achievement) ÷ (Time Delay × Effort & Sacrifice Required) = Perceived Offer Value. Maximise the numerator. Minimise the denominator. When conversion drops, one of these four variables has shifted in the buyer's mind — not necessarily in reality.",
    "",
    "Running the Four-Variable Audit",
    "For each variable, you need evidence from buyer conversations — not your own assumptions. The data sources listed below tell you what buyers actually believe, not what you intended them to believe.",
    "",
    "Variable 1 — Dream Outcome Clarity",
    "The question: are buyers buying your offer because they can picture the specific outcome, or because the category sounds relevant?",
    "",
    "Audit Question",
    "Data Source",
    "Red Flag Signal",
    "Can buyers describe the specific result they expect — in numbers and timeframes — before the offer is delivered?",
    "Onboarding survey (baseline), application form responses, sales call recordings",
    "Vague answers like 'I want to grow my business' or 'get more organised' — no specific metric or timeframe",
    "Does the language buyers use to describe the outcome match the language used on the sales page?",
    "Support ticket replies, community posts, direct email replies",
    "Buyers describe the outcome in completely different terms than your copy — the promise is not landing as intended",
    "Are buyers purchasing for the stated outcome or for an unstated emotional outcome?",
    "Exit interview question: 'What were you really hoping for that you couldn't say out loud?'",
    "Stated goal is revenue; real goal is status, confidence, or validation. Your copy may be hitting the wrong desire layer.",
    "",
    "Variable 2 — Perceived Likelihood of Achievement",
    "The question: do buyers believe they specifically will get the result — not just that the method works in general?",
    "",
    "Audit Question",
    "Data Source",
    "Red Flag Signal",
    "Do buyers mention specific proof elements when describing why they purchased?",
    "Sales call recordings, email reply: 'What made you decide to buy today?'",
    "Buyers cite general reputation or brand trust — not specific case studies. Your proof is not match-specific enough.",
    "Do buyers express doubt about whether it will work 'for their situation'?",
    "Support tickets within first 72 hours of purchase, community posts",
    "High volume of 'will this work for me if I have [specific constraint]?' questions",
    "What is the objection most commonly raised before purchase that was not resolved by the sales page?",
    "Sales call objection log, HARO-style DM conversations",
    "Price objection is a proxy for perceived likelihood — 'I'm not sure it's worth it' almost always means 'I'm not sure it will work for me'",
    "",
    "Variable 3 — Time Delay",
    "The question: do buyers believe the result is coming fast enough to justify the investment now?",
    "",
    "Audit Question",
    "Data Source",
    "Red Flag Signal",
    "What result do buyers expect first — and by when?",
    "Onboarding survey question: 'What would make you feel this was worth it in the first 7 days?'",
    "Buyers expect a result your offer cannot deliver in that timeframe — the promise is creating false urgency",
    "Are buyers reaching out to ask 'when will I see results?' in the first week?",
    "Support tickets, community posts, DMs within days 1–7",
    "High support volume on timeline questions = promise of speed is not backed by delivery structure",
    "Does the offer have a documented Quick Win within the first 72 hours?",
    "Your own delivery SOP",
    "No quick win = perceived time delay is infinite = refund risk spikes after day 7",
    "",
    "Variable 4 — Effort and Sacrifice",
    "The question: are buyers discovering that the offer requires more effort, time, or lifestyle change than they expected?",
    "",
    "Audit Question",
    "Data Source",
    "Red Flag Signal",
    "What do buyers say is 'harder than expected' in week 1 feedback?",
    "Per-module pulse survey, community posts tagged 'stuck' or 'help'",
    "Any step described as confusing or time-intensive that is supposed to be a quick win",
    "Are buyers dropping off at a consistent action step?",
    "Completion rate data by module (course platform analytics)",
    "Below 60% completion at any single step = that step has an effort barrier that must be reduced or replaced with a done-for-you asset",
    "What is the most common reason buyers have not started?",
    "Check-in message to non-starters: 'We noticed you haven't accessed the programme yet — is everything okay?'",
    "Answers involving 'too busy,' 'overwhelmed by where to start,' or 'waiting for the right time' = onboarding friction, not buyer intention",
    "",
    "Value Equation Audit Output",
    "After completing the four-variable review, fill in this table. It becomes the action brief for the offer's next iteration cycle.",
    "",
    "Variable",
    "Current Buyer Perception (evidence-based)",
    "Target Perception",
    "Specific Change Required",
    "Dream Outcome Clarity",
    "",
    "",
    "",
    "Perceived Likelihood",
    "",
    "",
    "",
    "Time Delay",
    "",
    "",
    "",
    "Effort & Sacrifice",
    "",
    "",
    "",
    "",
    "",
    "PHASE 3",
    "Buyer Language Mining",
    "The copy intelligence protocol — every buyer is a copywriter working for free",
    "",
    "Why Buyer Language Beats All Other Copy Sources",
    "The best copy you will ever write is copy you did not write. It is the exact phrases your buyers use to describe their pain, their transformation, and their hesitation. Your job in this phase is to mine those phrases systematically, catalogue them by funnel function, and inject them into your sales page, email sequences, and ad scripts.",
    "",
    "Kennedy's Copy Mining Rule",
    "If you can use a phrase lifted word-for-word from a buyer's mouth in your sales copy, do it. That phrase has already passed the most important test: a real person in your market used it voluntarily to describe their own experience. No copywriter can beat that.",
    "",
    "The Five Language Mining Sources",
    "",
    "Source",
    "What to Mine",
    "Mining Method",
    "Cadence",
    "Email replies (to your nurture sequence)",
    "Exact phrases describing pain, frustration, failed attempts, and desired outcomes. The most unfiltered language because buyers are replying privately.",
    "Tag every reply in ActiveCampaign with: Pain / Desire / Objection / Anti-language. Export tagged replies monthly.",
    "After every 10 new subscribers or weekly if list is active",
    "Support tickets and help desk messages",
    "Confusion points, unmet expectations, and implementation breakdowns. Also the highest-intensity emotional language because people are frustrated.",
    "In Intercom or Help Scout, tag tickets with: Confusion / Expectation-Gap / Mechanism-Question / Praise. Review tags monthly.",
    "Weekly review of new tickets — tag in real time",
    "Community posts (Discord/Skool/Facebook)",
    "Peer-to-peer language — how buyers describe the problem to each other, not to you. This is the most authentic version of the voice because there is no authority figure present.",
    "GummySearch-style keyword monitoring. Screenshot any post with 3+ reactions or replies. Archive in Airtable.",
    "Weekly scan of all community posts",
    "Exit interview transcripts",
    "Full before/during/after narrative in the buyer's own words. The richest single source of language per buyer.",
    "Castmagic or Descript transcript. Highlight every phrase of 3–8 words that describes pain, transformation, or hesitation. Tag by funnel function.",
    "After every exit interview — tag within 24 hours",
    "Refund request messages",
    "The language of unmet expectations. Tells you exactly where the sales page or delivery created a gap that cost you money.",
    "Archive every refund message verbatim. Do not paraphrase. Tag with: Expectation-Gap / Wrong-Avatar / Delivery-Failure / External-Event.",
    "Immediately upon receipt",
    "",
    "The Language Tagging System",
    "Every piece of buyer language gets tagged into one of six functional categories. Each category feeds a specific element of your marketing and sales copy.",
    "",
    "Tag",
    "Definition",
    "Where It Gets Used in Copy",
    "PAIN-ACUTE",
    "Phrases describing urgent, active pain — happening right now. High emotional intensity.",
    "Sales page Problem section, email Day 2 (Pain Awareness), ad hook (Cost-of-Inaction type)",
    "PAIN-CHRONIC",
    "Phrases describing long-term, background frustration — not urgent but persistent.",
    "Lead magnet headline, email Day 3 (Cost of Inaction), ad hook (Mistake type)",
    "DESIRE-EXPLICIT",
    "Stated goals — what they say they want. Often surface-level.",
    "Sales page Dream Outcome section, email Day 4 (Common Mistakes), landing page subheadline",
    "DESIRE-HIDDEN",
    "Unstated goals — what they really want but do not say directly. Drives premium purchasing.",
    "Sales page identity shift language, email Day 5 (Personal Story), high-ticket sales call framing",
    "OBJECTION",
    "Reasons they hesitated before buying or reasons they stopped engaging after buying.",
    "Sales page FAQ section, email Day 11 (Objection Handling), retargeting ad variant 2",
    "ANTI-LANGUAGE",
    "Words and phrases that trigger instant distrust or repulsion in this avatar.",
    "Remove from all copy immediately. Flag for sales team to avoid on calls.",
    "",
    "The 3-to-8 Word Rule",
    "The most actionable copy phrases are between 3 and 8 words long. Single words are too vague. Full sentences are too long to use directly in headlines. Three to eight words — extracted verbatim from buyer language and tagged by function — are what you are mining for in every source above.",
    "",
    "Practical Example",
    "A buyer writes in an email reply: 'I've been stuck spinning my wheels for months and I genuinely have no idea what to try next.' The phrase 'spinning my wheels' is Pain-Chronic. 'No idea what to try next' is Pain-Acute. Both go directly into your copy swipe file. Neither of those phrases would have come from a copywriter sitting at a desk.",
    "",
    "The Language Mining Database (Airtable Schema)",
    "",
    "Field",
    "Type",
    "Notes",
    "Phrase",
    "Long text",
    "Exact verbatim — never paraphrase or clean up. The rawness is the value.",
    "Source",
    "Single select",
    "Email Reply / Support Ticket / Community Post / Exit Interview / Refund Message / Sales Call",
    "Tag",
    "Multiple select",
    "PAIN-ACUTE / PAIN-CHRONIC / DESIRE-EXPLICIT / DESIRE-HIDDEN / OBJECTION / ANTI-LANGUAGE",
    "Offer",
    "Link to Offers table",
    "Which offer tier this language relates to",
    "Date captured",
    "Date",
    "Recency matters — language evolves as the market evolves",
    "Deployed",
    "Checkbox",
    "Checked once this phrase has been placed into active copy",
    "Deployed in",
    "Long text",
    "Which specific asset: sales page / email day N / ad creative / etc.",
    "Conversion lift",
    "Number",
    "If A/B tested — record the conversion difference when this phrase was used",
    "",
    "",
    "PHASE 4",
    "Conversion Funnel Diagnostic",
    "Finding the exact page where money is leaking",
    "",
    "The Leak Diagnosis Framework",
    "Every conversion problem has a location. Traffic goes cold, then warm, then hot. Money either converts at each stage or it leaks. The Forensic Audit maps exactly which stage is leaking, because the fix for a landing page problem is completely different from the fix for a sales page problem, which is completely different from the fix for a checkout problem.",
    "",
    "Funnel Stage",
    "Primary Metric",
    "If Below Threshold",
    "Most Likely Cause",
    "First Fix to Test",
    "Ad to landing page (click-through)",
    "CTR above 1.5% (cold), above 3% (warm)",
    "Hook or creative problem",
    "Ad creative does not match the traffic source's intent or awareness level",
    "Test 3 new hooks targeting Problem-Aware stage rather than Solution-Aware",
    "Landing page to opt-in",
    "Above 25% (cold)",
    "Headline or offer mismatch",
    "Lead magnet does not solve a specific enough problem, or headline is too generic",
    "Rewrite headline using PAIN-ACUTE tags from Phase 3. Narrow the lead magnet promise.",
    "Opt-in to sales page visit (email sequence)",
    "Above 15% click-through on Day 9 email (offer introduction)",
    "Email sequence engagement drop",
    "Sequence is educating without pre-suading. Buyers are not being moved through the awareness ladder.",
    "Inject buyer language (Phase 3 tags) into email subjects. Add one case study email on Day 6.",
    "Sales page to add-to-cart",
    "Above 3% (cold), above 8% (warm)",
    "Offer stack or trust problem",
    "Stack does not clearly exceed the price. Or proof does not match the exact promise.",
    "Add one Proof-to-Promise-Matched testimonial above the fold. Test a stronger guarantee.",
    "Add-to-cart to purchase",
    "Above 60%",
    "Checkout friction or final objection",
    "Price shock at checkout (hidden fees or tax), payment option missing, trust signal absent",
    "Add order summary with value stack visible on checkout page. Add payment plan option.",
    "Post-purchase to first login / first module",
    "Above 70% within 48 hours of purchase",
    "Onboarding failure",
    "Welcome email is generic, first step is unclear, or access instructions are confusing",
    "Rewrite welcome email with specific 'Your first step is this, takes 8 minutes' instruction. Add a Loom walkthrough video.",
    "",
    "Heatmap & Session Recording Protocol",
    "Numbers tell you where the leak is. Session recordings tell you why. Use Hotjar or Microsoft Clarity on the sales page and landing page. Run this protocol after every 10-Sale Trigger.",
    "",
    "1.  Set up Hotjar on sales page and landing page if not already active. Minimum 200 sessions before drawing conclusions.",
    "2.  Watch scroll depth heatmap: if 70%+ of visitors are not reaching the offer stack, the page is losing them in the problem section or the story. The copy before the offer is too long or too weak.",
    "3.  Watch click map: what are visitors clicking that is not a CTA? This reveals unmet curiosity — they want information you have not provided.",
    "4.  Watch 5 session recordings of visitors who scrolled to the bottom but did not convert. Note the exact moment they stop engaging.",
    "5.  Watch 5 session recordings of visitors who converted. Note what they did differently — faster scroll to specific section, immediate click of CTA.",
    "",
    "",
    "PHASE 5",
    "Refund & Dropout Forensics",
    "The data most operators ignore is the most valuable data available",
    "",
    "The Forensic Mindset Shift",
    "A refund is not a failure event. It is a data packet. A dropout is not a personal rejection. It is a diagnostic signal. Operators who treat refunds as problems to minimise and hide from lose the single most informative feedback loop in their entire business.",
    "",
    "Hormozi on Refund Data",
    "Your refund rate and your dropout rate are not performance metrics. They are product diagnostics. Each one tells you one of three things: you attracted the wrong buyer, a specific module has a fatal friction point, or your guarantee is drawing people who should never have purchased. Mine every single one without ego.",
    "",
    "The Refund Forensics Protocol",
    "Every refund request must be processed through this protocol within 24 hours of receipt, regardless of whether the refund is granted.",
    "",
    "Step",
    "Action",
    "Output",
    "1. Archive the message",
    "Save the full text of the refund request verbatim in Airtable — every word. Never paraphrase. Assign it an ID number.",
    "Verbatim refund archive entry",
    "2. Classify the root cause",
    "Assign one primary root cause from the taxonomy below. One cause per refund — force the classification.",
    "Root cause tag on Airtable record",
    "3. Send the forensic reply",
    "Before processing the refund, send the forensic reply template (see below). You are not negotiating — you are collecting data.",
    "Reply sent, response captured if they reply",
    "4. Update the Negative Avatar profile",
    "If this refund adds evidence to an existing Negative Avatar pattern, update that profile. If it reveals a new pattern, start a new profile.",
    "Negative Avatar Airtable record updated",
    "5. Check for pattern",
    "Is this the 2nd or 3rd refund citing the same root cause? If yes, trigger the relevant fix protocol from Phase 8.",
    "Pattern check completed. Fix protocol triggered if threshold reached.",
    "",
    "Refund Root Cause Taxonomy",
    "",
    "Root Cause Code",
    "Definition",
    "Immediate Action",
    "RC-1: Wrong Avatar",
    "The buyer does not fit the target profile that the offer was designed for. They bought based on the category but are not the person the transformation serves.",
    "Review ad targeting and sales page 'This is NOT for you if...' section. Strengthen avatar-specific language on the sales page.",
    "RC-2: Expectation Gap — Copy",
    "The sales page or email sequence created a promise that the offer does not fulfil. The buyer expected something different from what was delivered.",
    "Compare the refund language to the sales page promises verbatim. If the gap is real, fix the copy or fix the delivery — not one without the other.",
    "RC-3: Expectation Gap — Timing",
    "The buyer expected the result faster than the offer delivers. Time Delay variable of the Value Equation was miscalibrated.",
    "Add a Quick Win in the first 72 hours. Add a timeline disclaimer to the sales page: 'Most members see [first result] by day [N].'",
    "RC-4: Delivery Friction",
    "A specific module, step, or access issue blocked the buyer from making progress. They abandoned due to a technical or instructional barrier, not lack of intent.",
    "Identify the specific friction point. Add a walkthrough video or simplify the action step. Check if this is Pattern RC-4 (appears 3+ times in 30 days).",
    "RC-5: External Circumstance",
    "Life event, financial change, or scheduling conflict unrelated to the offer. Not a product signal.",
    "Process refund. Offer to pause or defer for 90 days. Add them to a reactivation sequence for 90 days post-refund.",
    "RC-6: Guarantee-Exploiting Buyer",
    "Pattern of behaviour suggesting the purchase was made primarily to consume content with the intent to refund. Completion of entire programme before refund request.",
    "Process refund. Flag the email in your CRM. Do not offer to future cohorts. Review guarantee language to reduce attraction of this profile.",
    "",
    "The Forensic Reply Template",
    "Send this before processing the refund. Do not hold the refund hostage — you are collecting data, not negotiating. Include the refund confirmation in the same message.",
    "",
    "Forensic Reply Template",
    "Hi [Name], I'm processing your refund now — you'll see it in 3–5 business days. Before I do, I'd genuinely appreciate 60 seconds of honest feedback. Not to change your mind — I just want to understand what happened so I can make this better. What was the single biggest gap between what you expected and what you found? You don't need to be kind about it. Your honest answer is worth more to me than the sale. Either way, your refund is on its way.",
    "",
    "Dropout Detection Protocol",
    "Dropouts — buyers who purchase but stop engaging before completing the programme — are often more informative than refunders because they had enough intent to stay but something specific stopped them.",
    "",
    "Signal",
    "Trigger Condition",
    "Response Action",
    "No first login",
    "No access to course platform within 72 hours of purchase",
    "Send personal plain-text email: 'Your first step takes 8 minutes. Here's the link. Is there anything blocking you?'",
    "Module 1 not started",
    "7 days post-purchase, Module 1 incomplete",
    "Send: 'Quick check-in — did you get a chance to look at Module 1 yet? I ask because most people who don't start in week 1 don't finish, and I want to make sure you do.'",
    "Progress stall — mid programme",
    "No new activity for 10 consecutive days",
    "Send personal voice message (Loom, 60 seconds): acknowledge the stall, identify the last module completed, give one specific micro-action to restart.",
    "Community silence",
    "Member has not posted or commented in 14 days",
    "Tag in a relevant thread: '@[Name] — I think this applies to what you're working on' to re-engage without pressure.",
    "",
    "",
    "PHASE 6",
    "The Next Problem Signal",
    "Brunson's chain — every solution creates a new problem and that problem is your next product",
    "",
    "The Chain Mapping Framework",
    "Brunson's core insight is that you do not need to invent products. You need to observe what your buyers need next after they get the result your current offer provides. Every solution creates a new problem. Map that chain and you have your entire product roadmap handed to you by buyers who already trust you.",
    "",
    "The Chain Logic",
    "Your MVO solves Problem A. But now your buyer has Problem B — the next challenge that emerges once A is solved. And after B comes C. Each step in this chain is an offer. The buyer does not know you are building a roadmap. They just know they solved one problem and now have the next one. You are the only person who can see the full map.",
    "",
    "Next Problem Signal Mining",
    "The Next Problem Signal lives in very specific places. You are not looking for general feedback — you are looking for statements that reveal what the buyer needs immediately after completing or benefiting from your current offer.",
    "",
    "Signal Type",
    "Where It Appears",
    "Example",
    "Product Implication",
    "The 'Now What?' Question",
    "Exit interviews, community posts, support tickets in weeks 3–6 post-purchase",
    "I've got 10 leads now — how do I convert them to calls?",
    "The next offer is a call conversion or sales training product",
    "The Unexpected Bottleneck",
    "Support tickets referencing a new problem that emerged after using your method",
    "Your system worked but now I'm overwhelmed with the volume and can't keep up",
    "The next offer is a fulfilment, delegation, or automation product",
    "The 'I Wish This Included' Statement",
    "Exit interviews question 6, per-module pulse surveys",
    "I wish there was a section on what to do after you get the first result",
    "The next offer covers the scaling or consistency phase",
    "The Comparison Reference",
    "Community posts, email replies",
    "Your stuff is great for getting started but I've also been looking at [X] for the next step",
    "The next offer competes directly with what buyers are going to find elsewhere — build it first",
    "The Referral Qualifier",
    "Exit interviews question 7: 'Who else do you know who needs this?'",
    "'My colleague does, but she's further along than I was — she'd need something more advanced'",
    "There is a more advanced buyer segment who needs a higher-tier version of the transformation",
    "",
    "The Next Problem Chain Template",
    "After each Forensic Audit, map what you have learned about the chain. This becomes your product roadmap and your ascension sequence design document.",
    "",
    "Step",
    "Problem",
    "Current Offer (if exists)",
    "Next Offer (to build)",
    "Evidence Source",
    "Problem A",
    "[What the buyer struggled with before your MVO]",
    "[Your MVO name + tier + price]",
    "Already built",
    "Pre-purchase research",
    "Problem B",
    "[What they struggle with after getting the MVO result]",
    "[Core Offer name if built]",
    "[Describe what Core Offer needs to cover]",
    "[Exit interview / support ticket citation]",
    "Problem C",
    "[What they struggle with after the Core Offer]",
    "[High-ticket / DWY if built]",
    "[Describe what next tier needs to cover]",
    "[Exit interview / community post citation]",
    "Problem D",
    "[What they struggle with at scale]",
    "[Continuity / Inner Circle]",
    "[Describe ongoing support needed]",
    "[Top-buyer conversation / mastermind request]",
    "",
    "",
    "PHASE 7",
    "Mechanism Freshness Test",
    "Every 90 days: can the method be renamed to feel 10× more powerful?",
    "",
    "Why Mechanisms Get Stale",
    "The name you gave your methodology at launch was the best name available with the information you had at launch. After 90 days of buyer data, support conversations, and exit interviews, you know more about how your buyers think about the transformation than you did on day one. That knowledge should change how you describe the mechanism — not what the mechanism does, but how you name and frame it.",
    "",
    "The 10× Rename Test",
    "Take your current mechanism name. Read it to five people who match your target avatar and have not heard of your offer before. Ask them to rate how excited they are about it on a scale of 1–10 and describe what they imagine it involves. If the average score is below 7 or their description does not match what the mechanism actually does — rename it.",
    "",
    "The Mechanism Naming Criteria",
    "A great mechanism name passes all five of the following criteria. Evaluate your current name against each one:",
    "",
    "Criterion",
    "Test",
    "Pass",
    "Fail Example",
    "Specificity",
    "Does it describe a specific process, not a general category?",
    "'AI Forensic Offer Autopsy' — describes a specific diagnostic action",
    "'Marketing System' — describes a category",
    "Outcome implied",
    "Does the name imply the result without stating it generically?",
    "'30-Day Client Acquisition Accelerator' — implies clients, implies speed",
    "'Lead Generation Programme' — states category, implies nothing specific",
    "Distinctiveness",
    "Does it sound like something only you do, or like a commodity?",
    "'The Reverse Funnel Method' — named and owned",
    "'Funnel Strategy' — generic, anyone says this",
    "Repeatability",
    "Can your buyer explain it to a colleague in one sentence?",
    "Yes — 'It's a system where you build the backend offer first and work backward to the lead magnet'",
    "No — 'It's kind of like a multi-step thing for growing your audience...'",
    "Curiosity gap",
    "Does it make someone who has not heard of it want to ask what it is?",
    "'The Forensic Critic Positioning' — provokes 'what's that?'",
    "'Content Strategy Framework' — provokes nothing",
    "",
    "Mechanism Rename Protocol",
    "If the current mechanism name fails two or more criteria above, initiate a rename cycle. This does not require rebuilding the offer — only renaming and re-describing the method across copy assets.",
    "",
    "1.  Generate 10 new mechanism name candidates using the following structure: [Adjective/Method Type] + [Verb or Descriptor] + [Container Word].",
    "2.  Test the top 3 names with 5 avatar-matched individuals using the 10× Rename Test. Score each on excitement (1–10) and description accuracy.",
    "3.  Select the winner. Requires a score of 7+ average AND accurate description from 4 of 5 testers.",
    "4.  Update the mechanism name across: sales page, email sequence (Days 8–10), all ad creatives, course platform titles, and GEO schema markup.",
    "5.  Log the rename in Airtable: old name, new name, date, test scores, and conversion rate before and after the 30 days following rename.",
    "",
    "Mechanism Rename Asset Update Checklist",
    "",
    "☐  Sales page — headline, mechanism section, and all stack slide references",
    "☐  Email nurture sequence — Days 8, 9, and 10 (mechanism introduction emails)",
    "☐  Paid ad copy — all active creatives using the mechanism name",
    "☐  Course platform — module titles and overview description",
    "☐  YouTube and podcast episode titles referencing the mechanism",
    "☐  AEO/GEO schema — branded methodology keywords updated in L0 and L1 keyword grid",
    "☐  LLMs.txt file — mechanism name updated in authority declaration section",
    "☐  Pillar article — update H1 and mechanism definition section",
    "",
    "",
    "PHASE 8",
    "The Action Protocol",
    "Kill / Iterate / Scale / Launch Next — making the right decision with the data",
    "",
    "The Four Possible Outcomes",
    "Every Forensic Audit produces one of four action recommendations. The decision tree below maps your audit findings to the correct action. Do not run multiple actions simultaneously — prioritise the one highest in the stack and complete it before starting the next.",
    "",
    "Action 1 — SCALE",
    "Conditions: cold conversion above 2%, refund rate below 5%, ascension rate above 10%, Value Equation audit shows no critical variable degradation, buyer language is consistent with sales page copy.",
    "",
    "•  Increase paid ad spend by no more than 20% per day. Monitor CPA and refund rate daily for the first 7 days of scaling.",
    "•  Add one new traffic source (second platform) using the best-performing organic content as the basis for ad creative.",
    "•  Rebuild the sales page headline and hero section using the top three PAIN-ACUTE language tags from Phase 3.",
    "•  Activate the ascension sequence to the next value ladder tier for all buyers who have completed the programme.",
    "",
    "Action 2 — ITERATE",
    "Conditions: one or two metrics below threshold, root cause is diagnosable, fix does not require rebuilding the core mechanism or re-recording the programme.",
    "",
    "Failing Metric",
    "Iteration Action",
    "Test Window",
    "Cold conversion below 1.5%",
    "A/B test new headline using PAIN-ACUTE buyer language. Test a stronger guarantee (move one level up the guarantee hierarchy). Do not change both simultaneously.",
    "14 days — minimum 200 visitors per variant",
    "Opt-in rate below 15%",
    "Rewrite lead magnet headline to a more specific, faster result. Test a different lead magnet format (tool/quiz vs PDF).",
    "14 days — minimum 200 visitors per variant",
    "Email open rate below 22%",
    "Rewrite Days 1–3 subject lines using PAIN-ACUTE and DESIRE-HIDDEN tags. Test plain-text vs formatted email on Day 2.",
    "7 days — minimum 100 sends per variant",
    "Time Delay variable degradation",
    "Add a documented Quick Win deliverable to Module 1. Send a '72-hour check-in' email that tells buyers exactly what their first win should be and when.",
    "Immediate — apply to next 10 buyers and compare Day 7 engagement",
    "Ascension rate below 8%",
    "Rewrite ascension sequence. Change the trigger point — test presenting the Core Offer earlier (Day 14 vs Day 21 post-MVO purchase).",
    "30 days — compare ascension rate before and after trigger change",
    "",
    "Action 3 — KILL",
    "Conditions: refund rate above 15%, cold conversion below 0.5% after 500+ visitors, completion rate below 40%, or two or more root cause patterns (from Phase 5) appearing three or more times without a diagnosable fix.",
    "",
    "Kennedy's Kill Rule",
    "Most millionaires have a trail of failed offers. Killing a broken offer is not failure — it is the system working correctly. The failure is continuing to run ads to a broken offer because you are emotionally attached to having built it. Archive all buyer data. That data survives even when the offer does not.",
    "",
    "•  Archive all buyer language from Phase 3 — it is valid copy intelligence regardless of offer outcome.",
    "•  Complete a Negative Avatar profile (Phase 5 template) to document who this offer should NOT be sold to in future.",
    "•  Run Phase 6 analysis specifically: what problem did buyers think they were solving, and is there a different offer that solves it correctly?",
    "•  Return to MVO Playbook Phase 2 (Offer Construction) with all accumulated data as the brief.",
    "",
    "Action 4 — LAUNCH NEXT",
    "Conditions: Phase 6 (Next Problem Signal) has produced three or more consistent signals pointing to a specific Problem B. Current offer is performing at Scale threshold or above. Capacity exists to build and deliver a new tier.",
    "",
    "•  The Next Problem Signal data from Phase 6 becomes the MVO brief for the new offer. The buyer language you have mined is the first draft of the sales page copy.",
    "•  Do not launch the next offer until the current offer's ascension sequence is built and automated. Launching upward without an ascension funnel means the new offer cannibalises the current one.",
    "•  Position the new offer as the solution to the specific Problem B you have documented — not as a generic upgrade.",
    "•  Run the new offer through the Beta Testing Methodology SOP (RISER Nation SOP Series) before public launch.",
    "",
    "",
    "The 30-Day Forensic Audit Ritual Calendar",
    "This is the standing operational rhythm. It runs continuously regardless of whether a specific trigger has fired that week. The trigger-based phases are in addition to this baseline ritual, not instead of it.",
    "",
    "Cadence",
    "Activity",
    "Time Required",
    "Output",
    "Every Monday (15 min)",
    "Pull the seven funnel health metrics from Phase 1. Log in Airtable. Flag any metric below threshold.",
    "15 minutes",
    "Weekly metrics log. Flag any triggered audit.",
    "Every Tuesday (20 min)",
    "Review all new support tickets and email replies from the past 7 days. Tag language using the Phase 3 tagging system.",
    "20 minutes",
    "New language entries in mining database.",
    "Every Wednesday (10 min)",
    "Scan community platform. Screenshot any post with 3+ reactions or substantive questions. Archive and tag.",
    "10 minutes",
    "Community language additions to database.",
    "Every Thursday (10 min)",
    "Check for new refunds. Process any refund through the 5-step Refund Forensics Protocol.",
    "10 minutes per refund",
    "Refund archive updated. Patterns checked.",
    "Every Friday (20 min)",
    "Weekly audit summary: what changed this week, any patterns emerging, any trigger thresholds crossed?",
    "20 minutes",
    "Weekly Forensic Summary note in Airtable.",
    "After every 10 sales",
    "Full 8-Phase Audit. Block 2.5–3 hours. Do not skip phases.",
    "2.5–3 hours",
    "Completed Forensic Audit Scorecard. Action Protocol selected.",
    "Monthly (first Monday)",
    "Review full language mining database. Identify top 5 new phrases for copy deployment. Update sales page if PAIN-ACUTE or DESIRE-HIDDEN tags have produced better phrases than current copy.",
    "60–90 minutes",
    "Copy update brief. Sales page revision if warranted.",
    "Quarterly (every 90 days)",
    "Full 8-Phase Audit + Mechanism Freshness Test + Product Chain Map update + Value Ladder gap analysis.",
    "Half day",
    "90-Day Forensic Report. Product roadmap updated.",
    "",
    "",
    "Airtable Database Schema",
    "All Forensic Audit data lives in a single Airtable base with five linked tables. This schema ensures every piece of buyer intelligence is connected across offers, buyers, and time periods.",
    "",
    "Table 1 — Buyer Language",
    "Primary table. Every tagged phrase from Phase 3 sources.",
    "",
    "Field Name",
    "Field Type",
    "Purpose",
    "Phrase ID",
    "Autonumber",
    "Unique identifier for each phrase",
    "Verbatim Phrase",
    "Long text",
    "Exact words — never edited",
    "Source",
    "Single select",
    "Email Reply / Support Ticket / Community / Exit Interview / Refund / Sales Call",
    "Tag",
    "Multiple select",
    "PAIN-ACUTE / PAIN-CHRONIC / DESIRE-EXPLICIT / DESIRE-HIDDEN / OBJECTION / ANTI-LANGUAGE",
    "Offer",
    "Link → Offers table",
    "Which offer this language relates to",
    "Date Captured",
    "Date",
    "Mining date",
    "Deployed",
    "Checkbox",
    "Used in live copy yet?",
    "Deployed In",
    "Long text",
    "Which specific asset",
    "",
    "Table 2 — Audit Records",
    "One record per completed Forensic Audit run.",
    "",
    "Field Name",
    "Field Type",
    "Purpose",
    "Audit ID",
    "Autonumber",
    "Unique ID",
    "Date Run",
    "Date",
    "",
    "Trigger Type",
    "Single select",
    "10-Sale / First Refund / Conversion Drop / 30-Day / 90-Day / Ascension Anomaly",
    "Offer Audited",
    "Link → Offers table",
    "",
    "Phase 1 Flags",
    "Long text",
    "Which metrics below threshold",
    "Value Equation Finding",
    "Long text",
    "Which variable degraded and evidence",
    "Refund Patterns",
    "Long text",
    "RC codes appearing 2+ times",
    "Next Problem Signal",
    "Long text",
    "Problem B identified if applicable",
    "Mechanism Rename Triggered",
    "Checkbox",
    "",
    "Action Selected",
    "Single select",
    "Scale / Iterate / Kill / Launch Next",
    "Action Brief",
    "Long text",
    "Specific changes to implement",
    "Review Date",
    "Date",
    "30 days after — check if action produced results",
    "",
    "Table 3 — Refund Records",
    "One record per refund. Linked to Buyers and Offers tables.",
    "",
    "Field Name",
    "Field Type",
    "Purpose",
    "Refund ID",
    "Autonumber",
    "",
    "Buyer",
    "Link → Buyers table",
    "",
    "Offer",
    "Link → Offers table",
    "",
    "Date Requested",
    "Date",
    "",
    "Verbatim Refund Message",
    "Long text",
    "Never paraphrase",
    "Root Cause Code",
    "Single select",
    "RC-1 through RC-6",
    "Forensic Reply Sent",
    "Checkbox",
    "",
    "Response Received",
    "Long text",
    "Buyer's answer to forensic reply if they responded",
    "Negative Avatar Update",
    "Link → Negative Avatar table",
    "",
    "",
    "",
    "Forensic Audit Master Scorecard",
    "Complete this for every full 8-Phase Audit run. File in Airtable under Audit Records.",
    "",
    "Section",
    "Field",
    "Your Data",
    "Header",
    "Audit ID + Date",
    "",
    "Header",
    "Offer name + tier + launch date",
    "",
    "Header",
    "Trigger type that initiated this audit",
    "",
    "Header",
    "Total sales to date / Sales in last 30 days",
    "",
    "Phase 1",
    "Cold conversion rate",
    "",
    "Phase 1",
    "Refund rate (rolling 30 days)",
    "",
    "Phase 1",
    "Ascension rate (MVO to Core)",
    "",
    "Phase 1",
    "Primary funnel leak location (if any)",
    "",
    "Phase 2",
    "Value Equation variable with greatest degradation",
    "",
    "Phase 2",
    "Evidence supporting this finding",
    "",
    "Phase 2",
    "Specific offer change indicated",
    "",
    "Phase 3",
    "Top 3 new PAIN-ACUTE phrases mined this cycle",
    "1.\n2.\n3.",
    "Phase 3",
    "Top 2 OBJECTION phrases not addressed in current copy",
    "1.\n2.",
    "Phase 3",
    "Any ANTI-LANGUAGE identified — remove from all assets",
    "",
    "Phase 4",
    "Heatmap finding (if session recordings reviewed)",
    "",
    "Phase 4",
    "Biggest drop-off point in funnel this cycle",
    "",
    "Phase 5",
    "Number of refunds this cycle",
    "",
    "Phase 5",
    "Most common root cause code",
    "",
    "Phase 5",
    "Any RC pattern appearing 3+ times (immediate action trigger)",
    "",
    "Phase 6",
    "Next Problem Signal identified? (Y/N)",
    "",
    "Phase 6",
    "Problem B description (if signal found)",
    "",
    "Phase 6",
    "Evidence source for Problem B",
    "",
    "Phase 7",
    "Mechanism name reviewed — passed or failed criteria?",
    "☐ Pass  ☐ Fail",
    "Phase 7",
    "Rename triggered? (Y/N)",
    "",
    "Phase 8",
    "Action Protocol selected",
    "☐ Scale  ☐ Iterate  ☐ Kill  ☐ Launch Next",
    "Phase 8",
    "Specific action items (max 3)",
    "1.\n2.\n3.",
    "Phase 8",
    "Owner and deadline for each action",
    "",
    "Review",
    "Review date (30 days from today)",
    "",
    "",
    "",
    "Master Forensic Audit Checklist",
    "",
    "Weekly Standing Ritual",
    "☐  Monday: Pull 7 Phase 1 metrics, log in Airtable, flag thresholds",
    "☐  Tuesday: Tag new support tickets and email replies by language type",
    "☐  Wednesday: Scan community — archive posts with 3+ reactions",
    "☐  Thursday: Process any new refunds through 5-step protocol",
    "☐  Friday: Weekly summary note — patterns, flags, triggers crossed",
    "",
    "When 10-Sale Trigger Fires (Full Audit — block 3 hours)",
    "☐  Phase 1: Pull all 7 metrics. Run diagnostic flow chart. Identify primary leak if exists.",
    "☐  Phase 2: Run four-variable Value Equation Audit using buyer data from this cycle",
    "☐  Phase 2: Complete Value Equation Output table — fill all four rows with evidence",
    "☐  Phase 3: Review all new buyer language captured since last audit — tag and add to database",
    "☐  Phase 3: Identify top 3 PAIN-ACUTE phrases — compare to current sales page copy",
    "☐  Phase 4: Review funnel metric table — flag any stage below threshold",
    "☐  Phase 4: Watch 5 non-converting session recordings if conversion below threshold",
    "☐  Phase 5: Complete refund forensics for all refunds since last audit",
    "☐  Phase 5: Check for RC patterns appearing 3+ times — trigger fix protocol if found",
    "☐  Phase 6: Review exit interviews and community posts for Next Problem Signals",
    "☐  Phase 6: Update Next Problem Chain Map if new signal found",
    "☐  Phase 7: Run Mechanism Freshness Test if 90-day trigger is also active",
    "☐  Phase 8: Select one Action Protocol — write action brief with owner and deadline",
    "☐  Log completed scorecard in Airtable Audit Records table",
    "☐  Set 30-day review calendar reminder",
    "",
    "Quarterly Deep Audit (Add to Full Audit Above)",
    "☐  Run Mechanism Freshness Test regardless of 90-day timer",
    "☐  Run 10× Rename Test with 5 new avatar-matched individuals",
    "☐  Update Next Problem Chain Map with full product roadmap review",
    "☐  Review all ANTI-LANGUAGE tags — scrub from every active copy asset",
    "☐  Review Value Ladder gap analysis — are all ascension sequences live and automated?",
    "☐  Export full buyer language database — identify top 10 phrases not yet deployed in copy",
    "☐  Brief for Mechanism Rename if test score below 7.0",
    "☐  Update GEO/AEO schema with any new branded methodology terms",
    "",
    "",
    "",
    "RISER Nation Master Operating System  |  Post-MVO Forensic Audit Loop SOP  |  Version 1.0  |  2026 Edition",
    "Kennedy × Hormozi × Brunson  |  risernation.com"
  ],
  "other_parts": [
    {
      "part": "word/header1.xml",
      "paragraphs": [
        "RISER Nation  |  Post-MVO Forensic Audit Loop SOP  |  V1.0"
      ]
    },
    {
      "part": "word/footer1.xml",
      "paragraphs": [
        "Page PAGE of NUMPAGES"
      ]
    },
    {
      "part": "word/footnotes.xml",
      "paragraphs": [
        "",
        ""
      ]
    },
    {
      "part": "word/endnotes.xml",
      "paragraphs": [
        "",
        ""
      ]
    },
    {
      "part": "word/comments.xml",
      "paragraphs": []
    }
  ]
}

RISER Nation  |  Beta Testing Methodology SOP  |  V1.0

Page PAGE of NUMPAGES

{
  "body_paragraphs": [
    "RISER NATION",
    "MASTER OPERATING SYSTEM",
    "",
    "  SOP — BETA TESTING METHODOLOGY  ",
    "",
    "From Raw Idea to Launch-Ready, Proof-Backed Offer",
    "Kennedy × Hormozi × Brunson × 2026 Framework",
    "",
    "Version 1.0  |  2026 Edition  |  RISER Nation Master Operating System",
    "",
    "SOP Overview",
    "A Beta Test is the structured, paid validation of a new offer before full public launch. Its purpose is not to build confidence — it is to generate real buyer data, proof assets, product intelligence, and a Negative Avatar profile, all while funding initial delivery costs.",
    "",
    "This SOP covers eight phases: cohort design, pricing, delivery architecture, feedback collection, Negative Avatar extraction, proof harvesting, the beta-to-launch transition decision, and the kill/pivot/iterate framework.",
    "",
    "The Hormozi Principle",
    "Never build what you haven't sold. Never scale what you haven't proven. The beta is the moment between those two rules — you have sold it, you are now proving it before you scale it.",
    "",
    "The Kennedy Rule",
    "Every beta buyer is a research subject, a testimonial factory, and a funnel-design consultant — all at once. Extract maximum intelligence from minimum exposure.",
    "",
    "The Brunson Lens",
    "The beta is where your Epiphany Bridge story gets validated. The language your beta buyers use to describe their transformation is the copy for your launch.",
    "",
    "Pre-Beta Gate: When to Run a Beta",
    "A beta is appropriate under three conditions. You have validated market demand (someone said 'I would pay for that'), you have a deliverable you can fulfil even in rough form, and you do not yet have enough social proof or product-market language to launch publicly at full price.",
    "",
    "It is not a substitute for offer validation. If you have not run the MVO Playbook V5 Phase 1 kill filters and 6-score monetisation filter, do that first. A beta on a fundamentally broken offer produces expensive confusion, not data.",
    "",
    "Pre-Beta Launch Criteria — Required Before Proceeding",
    "",
    "Criterion",
    "Threshold",
    "Status",
    "Market pain validated",
    "At least 3 verbatim quotes from real people describing the problem in their own words",
    "☐ Pass / ☐ Fail",
    "6-Score Filter passed",
    "Score of 22 or higher on the MVO Playbook V5 monetisation filter",
    "☐ Pass / ☐ Fail",
    "Kill filters cleared",
    "All 3 kill filters: Cheap to Ignore, Massive Behaviour Change, Existing Excellent Cheap Solution — all negative",
    "☐ Pass / ☐ Fail",
    "Core deliverable defined",
    "You can describe what the buyer receives and the timeline in one sentence",
    "☐ Pass / ☐ Fail",
    "Fulfilment capacity confirmed",
    "You can deliver to 5–15 people without breaking your calendar, your margin, or your sanity",
    "☐ Pass / ☐ Fail",
    "Flagship Promise passes",
    "A non-marketer can repeat the core promise in one sentence after hearing it once",
    "☐ Pass / ☐ Fail",
    "Mechanism named",
    "Your unique method has a specific name (not 'my system' or 'my process')",
    "☐ Pass / ☐ Fail",
    "",
    "Hard Rule",
    "If more than one criterion shows Fail — do not proceed to beta. Return to MVO Playbook Phase 2 and rebuild the offer construction. A beta on a weak offer produces bad data and costs real buyers trust.",
    "",
    "",
    "PHASE 1",
    "Beta Cohort Design & Recruitment",
    "Who gets in, how many, and how you find them",
    "",
    "Cohort Size",
    "The ideal beta cohort is 5 to 15 people. Below 5 you lack enough signal diversity to draw reliable conclusions. Above 20 you are running a product launch, not a beta — the support load and feedback volume exceed what one operator can process and act on within the beta window.",
    "",
    "Cohort Size",
    "Best For",
    "Risk",
    "5–8 people",
    "High-touch done-with-you or done-for-you offers above $500",
    "Lower data volume — every dropout matters",
    "8–15 people",
    "Group programmes, courses, and workshops. The sweet spot for most MVOs",
    "Manageable feedback load with strong signal",
    "15–25 people",
    "Lower-ticket offers ($47–$197) with minimal live interaction required",
    "Feedback processing becomes time-intensive — assign a note-taker",
    "",
    "Recruitment Sources (Priority Order)",
    "Recruit in this order. Each source produces progressively colder buyers and requires more selling effort.",
    "",
    "•  Existing email list — warm audience, already aware of you. Highest conversion, fastest recruitment.",
    "•  Past buyers of related offers — already validated buyers. Offer beta as next logical step.",
    "•  Existing community members (Discord, Skool, Facebook Group) — medium warm, already engaged.",
    "•  Social media audience (organic posts announcing beta) — cold to warm depending on platform.",
    "•  Direct outreach via DM to people who have engaged with your content — cold, requires personalisation.",
    "",
    "Recruitment Message Framework",
    "The beta recruitment message is not a sales page. It is a direct, honest conversation. Use this structure:",
    "",
    "Element",
    "What to Write",
    "Example",
    "What you are building",
    "Name the offer and the transformation in one sentence",
    "I am building a 4-week intensive that helps HVAC contractors get 10 qualified service calls per week using a local content system.",
    "Why beta pricing",
    "Honest reason — you want real-world data, case studies, and feedback in exchange for a reduced price",
    "In exchange for the discounted beta price I am asking for one interview call at the end and honest written feedback on every module.",
    "What they commit to",
    "Be specific about their time, participation, and feedback obligations",
    "This requires 3–5 hours per week for 4 weeks, showing up to the two live calls, and completing the feedback form after each module.",
    "The beta price",
    "State the price clearly. Do not hide it.",
    "$297 for the full 4-week programme. It will be $997 at public launch.",
    "Hard deadline",
    "Create real urgency — beta spots are genuinely limited by your capacity",
    "I am taking exactly 10 people. Doors close Friday at midnight or when full.",
    "",
    "",
    "PHASE 2",
    "Beta Pricing Strategy",
    "Price for commitment, not for charity",
    "",
    "The Pricing Philosophy",
    "Beta pricing has one purpose: to attract committed buyers who will show up, do the work, and give you honest feedback. It is not a favour or a discount for fans. Free beta participants have zero skin in the game and produce near-zero useful data. Paid beta participants show up, complete modules, and tell you exactly where the offer breaks.",
    "",
    "Hormozi's Commitment Rule",
    "The lower the price, the lower the commitment. If your beta is free, expect 60–80% dropout. At $97, expect 40–60% dropout. At $297+, expect 80%+ completion. Price for the completion rate you need, not the conversion rate you want.",
    "",
    "Beta Pricing Matrix",
    "",
    "Offer Type",
    "Full Launch Price",
    "Beta Price Range",
    "Rationale",
    "Low-ticket MVO (template / mini-course)",
    "$97–$297",
    "$27–$67",
    "Price reduction is meaningful but still filters for intent",
    "Mid-ticket MVO (group intensive / workshop)",
    "$297–$997",
    "$97–$297",
    "Sweet spot for commitment — still an investment, clearly discounted",
    "Core Offer (group programme)",
    "$997–$4,997",
    "$297–$997",
    "Price must reflect the time investment required from the buyer",
    "High-ticket (DWY / DFY)",
    "$2,500–$10,000",
    "$497–$1,500",
    "Even at beta price this is a serious purchase — screen with application",
    "",
    "What the Beta Price Buys You",
    "The beta buyer receives the offer at a significant discount. In exchange they provide the following, which must be made explicit at the point of purchase:",
    "",
    "☐  Completion of a short feedback form (5–10 questions) after each module or milestone",
    "☐  Attendance at all live calls or access to recordings within 48 hours",
    "☐  A 20–30 minute exit interview call at the end of the beta",
    "☐  Written permission to use their results and feedback as a testimonial",
    "☐  Advance notice before any public screenshots or case study publication",
    "",
    "Guarantee Policy During Beta",
    "Apply a conditional guarantee during beta, not a full money-back. The buyer gets results if they complete the work. This is appropriate because the offer is unproven and unfinished — a full unconditional guarantee on an unproven product creates adverse selection (people who want to consume content and refund).",
    "",
    "Beta Guarantee Language",
    "If you complete all modules, attend both live calls, and submit all feedback forms within the programme window and do not see [specific promised result], I will work with you personally at no additional cost until you do.",
    "",
    "",
    "PHASE 3",
    "Beta Delivery Architecture",
    "Structure the experience to maximise completion and data output",
    "",
    "Core Delivery Principles",
    "•  Deliver in the simplest format you can. A Google Doc, Zoom call, and Notion page beat a polished course platform. The beta is testing the transformation, not the technology.",
    "•  Shorter is better. Four weeks maximum for a first beta. Six-week+ programmes lose participants to life and reduce feedback quality on later modules.",
    "•  Every session ends with a structured debrief question. Do not wait for the exit interview to collect data.",
    "•  Record everything. Your beta delivery recordings become your course content, ad testimonials, and case study material.",
    "",
    "Beta Delivery Schedule Template",
    "",
    "Week",
    "Delivery Activity",
    "Feedback Trigger",
    "Data Collected",
    "Week 0 (Pre-start)",
    "Welcome call (30 min). Onboarding survey. Baseline metrics captured. Set expectations for the programme.",
    "Baseline survey (see Phase 4)",
    "Current situation, goals, fears, anti-language",
    "Week 1",
    "Module 1 delivery. One live or recorded session (45–90 min). First quick win delivered.",
    "Module 1 feedback form (5 questions)",
    "Clarity of instruction, first win achieved yes/no, confusion points",
    "Week 2",
    "Module 2 delivery. Progress check-in. Address top objections from Week 1 feedback.",
    "Module 2 feedback form + 10-min group call",
    "Progress velocity, where they are getting stuck, support needs",
    "Week 3",
    "Module 3 delivery. Case study capture from any early winners. Peer share in community.",
    "Module 3 feedback form + peer testimonials",
    "Early results data, social proof harvesting begins",
    "Week 4",
    "Module 4 delivery. Final implementation session. Begin exit interview scheduling.",
    "Module 4 feedback form",
    "Completion status, confidence level, result achieved yes/no",
    "Week 5 (Post-programme)",
    "Exit interviews (20–30 min each). Final results capture. Testimonial collection. Offer for public launch at beta graduate price.",
    "Exit interview (see Phase 4 template)",
    "Full transformation arc, before/after metrics, referral intent, ascension readiness",
    "",
    "The Minimum Viable Delivery Stack",
    "You do not need a learning management system, a polished course platform, or a custom app to run a beta. Use the minimum viable tech stack:",
    "",
    "Function",
    "Tool",
    "Cost",
    "Why This Tool",
    "Video delivery",
    "Loom or Zoom recording",
    "Free–$15/mo",
    "Fast to produce, easy to update between cohorts",
    "Content hosting",
    "Notion, Google Drive, or Kajabi",
    "Free–$69/mo",
    "Accessible on any device, easy to update live",
    "Community / Q&A",
    "Private Slack, Discord, or Facebook Group",
    "Free",
    "All feedback in one searchable place",
    "Feedback forms",
    "Typeform or Google Forms",
    "Free–$25/mo",
    "Branching logic for richer responses",
    "Exit interviews",
    "Zoom or Google Meet",
    "Free",
    "Record for testimonial extraction",
    "Payment processing",
    "Stripe or ThriveCart",
    "$0 + 2.9%",
    "Clean checkout, easy refund processing if needed",
    "",
    "",
    "PHASE 4",
    "Feedback Collection System",
    "Extract signal, not sentiment",
    "",
    "The Three Feedback Instruments",
    "You need three distinct instruments. Each captures different data at a different emotional moment in the buyer's journey.",
    "",
    "Instrument 1 — Baseline Onboarding Survey",
    "Administered before Module 1 starts. Captures the buyer's current state, which becomes the 'before' half of your case study.",
    "",
    "•  Describe your current situation with [core problem] in 2–3 sentences. Use your own words.",
    "•  What have you already tried to solve? What happened?",
    "•  On a scale of 1–10, how urgent is solving this in the next 90 days? What is driving that score?",
    "•  What does success look like for you at the end of this programme? Be specific — numbers where possible.",
    "•  What is the single biggest thing that almost stopped you from joining today?",
    "•  Is there anything you are afraid this programme will NOT cover that you need?",
    "",
    "Why This Question Matters",
    "The answer to 'What almost stopped you from joining?' is your single most valuable piece of copy. It is the exact objection you need to address on your sales page, in your launch emails, and in your ads. Collect it before they feel good about their decision.",
    "",
    "Instrument 2 — Per-Module Pulse Survey (5 questions, under 3 minutes)",
    "Sent within 24 hours of each module delivery. Short enough to complete without friction. Do not ask open-ended questions at this stage — closed scales with one optional comment field only.",
    "",
    "Question",
    "Format",
    "What You Are Measuring",
    "How clear was this module? (1–10)",
    "Number scale",
    "Instruction quality — below 7 = rewrite the module",
    "Did you complete the action item from this module? (Yes / Partially / No)",
    "Multiple choice",
    "Completion rate — below 60% = the task is too hard or unclear",
    "What was your single biggest confusion or sticking point? (Optional)",
    "Short text",
    "Friction points to fix before public launch",
    "Rate the value delivered in this module relative to what you paid. (1–10)",
    "Number scale",
    "Perceived value — below 7 on any module = gap in the offer stack",
    "What do you wish was included in this module that wasn't? (Optional)",
    "Short text",
    "Missing content that becomes a bonus at public launch",
    "",
    "Instrument 3 — Exit Interview (20–30 minutes, recorded)",
    "The most valuable data source in the entire beta. Schedule with every participant who completes the programme. Use this exact question sequence:",
    "",
    "•  Can you walk me through what your situation was before you joined? What was happening?",
    "•  What had you already tried? Why didn't those things work?",
    "•  What made you decide to join this specific programme at this specific time?",
    "•  Walk me through what happened during the programme. What shifted first?",
    "•  What specific result have you achieved that you can put a number on?",
    "•  What was the most valuable part? What would you remove or improve?",
    "•  Who else do you know who needs this? Why would they need it?",
    "•  Knowing what you know now, would you pay the full public price of [launch price]? Why?",
    "•  Is there anything you were hoping to get from this that you didn't?",
    "",
    "Copy Mining Instruction",
    "During the exit interview, listen for exact phrases — 3-to-8-word strings that describe the transformation in the buyer's own voice. Circle them. Underline them. These phrases become your headline, your hook, your ad copy, and your email subject lines. Your copy should sound like your buyers, not like you.",
    "",
    "",
    "PHASE 5",
    "Negative Avatar Extraction",
    "The data most operators ignore — and the gold mine they are walking past",
    "",
    "What the Negative Avatar Is",
    "The Negative Avatar is the profile of the person who bought your beta, did not get results, or requested a refund. Most operators treat these people as a problem to manage. In reality, they are the single most valuable product development signal available.",
    "",
    "The Hormozi Insight",
    "Your refund rate and dropout rate are not failure metrics. They are product diagnostics. Each one tells you either that you attracted the wrong buyer, that a specific module has a fatal friction point, or that your guarantee is attracting people who should never have bought. Mine every single one.",
    "",
    "Negative Avatar Data Points to Capture",
    "",
    "Scenario",
    "Questions to Ask",
    "What It Reveals",
    "Buyer completes less than 50% of modules",
    "Which module did they stop at? What was happening in their life at that point? Did they find the content too hard, too easy, or unclear?",
    "Friction point in delivery — the exact module that needs to be rebuilt",
    "Buyer completes but reports no result",
    "What action steps did they complete? Where did implementation break down? What would have made the result achievable?",
    "Gap between instruction and implementation — a missing 'done-for-you' component or a missing prerequisite",
    "Buyer requests a refund",
    "Why did you decide this wasn't right for you? What were you hoping for that you didn't find? What would have made you stay?",
    "Expectation mismatch — either the sales copy overpromised or the wrong buyer profile is being attracted",
    "Buyer says 'it wasn't for me'",
    "Can you describe who you think this IS for? What kind of person would get the most from this?",
    "Avatar mismatch — they will describe your actual target buyer better than you can from the outside",
    "Buyer ghosts after purchase",
    "Send one short check-in: 'I noticed you haven't started yet — is everything okay? Is there anything stopping you from getting in?'",
    "Onboarding failure — the first step is too hard or the welcome experience is not creating momentum",
    "",
    "Negative Avatar Profile Template",
    "After every beta, complete this template. Feed it into your next offer design cycle and your avatar V2 update.",
    "",
    "•  Negative Avatar Name: [Give them a character name]",
    "•  Entry point: How did they find you? What language did they respond to in your recruitment message?",
    "•  Where they dropped off: Which module, week, or milestone marked their exit?",
    "•  Root cause (choose one): Wrong buyer profile / Missing prerequisite / Delivery friction / Expectation mismatch / External life event",
    "•  What offer would have served them: [Describe the offer they actually needed — this may become your next product]",
    "•  Copy and recruitment change triggered: [Specific change to sales page, ad targeting, or application screening]",
    "",
    "",
    "PHASE 6",
    "Proof Harvesting Protocol",
    "Every beta buyer is a testimonial factory",
    "",
    "The Four Proof Assets",
    "By the end of a properly run beta you should have four distinct types of proof asset, each serving a different function on your sales page, in your ads, and in your email sequences.",
    "",
    "Proof Asset",
    "How to Collect",
    "Where It Is Used",
    "Specific result testimonial",
    "Exit interview question 5: 'What specific result have you achieved that you can put a number on?' Capture exact numbers, timeframes, and before/after states.",
    "Sales page hero section, email Day 6 in 14-day sequence, ad creative (transformation hook)",
    "Story testimonial (Epiphany Bridge)",
    "Exit interview questions 1–4: the full before/during/after journey. Edit into a 150–300 word written testimonial using the buyer's own words.",
    "Sales page social proof section, case study article for AEO/GEO, webinar stack slide",
    "Objection-killing testimonial",
    "Exit interview question 8: 'Would you pay the full price knowing what you know now?' The answer directly addresses price objection on your sales page.",
    "Sales page FAQ section, email Day 11 (objection handling), ad variant targeting price-objection audience",
    "Video testimonial",
    "At the end of the exit interview, ask: 'Would you be willing to record a 60-second video summarising what you experienced?' Provide three prompts: where you were, what happened, where you are now.",
    "Sales page hero, YouTube channel, social proof ad variant, VSL social proof section",
    "",
    "The Proof-to-Promise Match Rule",
    "Every proof asset must match the exact promise you make in your core offer. If you promise '30 qualified leads in 30 days' and your testimonials say 'great experience' — your proof is worthless. Audit every testimonial against this standard before using it.",
    "",
    "Your Promise",
    "Required Proof Match",
    "Weak Proof (Discard)",
    "30 qualified leads in 30 days",
    "'We generated 34 qualified leads in the first 28 days' + screenshot",
    "'Really helpful programme, loved the community'",
    "Reduce employee churn by 40%",
    "'We went from 6 departures per quarter to 2, in 90 days' + HR data",
    "'Great frameworks, very actionable'",
    "Build and launch your first course in 14 days",
    "'I launched on day 11 with 12 pre-sales' + screenshot of sales dashboard",
    "'Russell really knows his stuff'",
    "",
    "Proof Collection Timing",
    "Request the video testimonial at the peak of the buyer's emotional high — immediately after they hit their first major result, not after the programme ends. Emotional proximity to the win produces better testimonials than reflective distance.",
    "",
    "",
    "PHASE 7",
    "Beta-to-Launch Transition Decision",
    "The data thresholds that tell you when you are ready",
    "",
    "The Go / No-Go Scorecard",
    "After the beta closes and exit interviews are complete, run this scorecard. It is pass/fail — not a weighted average. Every threshold must be met before proceeding to public launch at full price.",
    "",
    "Metric",
    "Minimum Threshold",
    "Strong Signal",
    "Status",
    "Programme completion rate",
    "60% of beta cohort completed the full programme",
    "80%+",
    "☐ Pass / ☐ Fail",
    "Result achievement rate",
    "50% of completers achieved a specific, measurable result",
    "70%+",
    "☐ Pass / ☐ Fail",
    "Average module clarity score",
    "7.0 or above across all module pulse surveys",
    "8.5+",
    "☐ Pass / ☐ Fail",
    "Perceived value score",
    "7.0 or above (relative to price paid)",
    "8.5+",
    "☐ Pass / ☐ Fail",
    "Refund rate",
    "Under 15% of beta cohort",
    "Under 5%",
    "☐ Pass / ☐ Fail",
    "Specific result testimonials collected",
    "At least 3 testimonials with specific metrics",
    "5+",
    "☐ Pass / ☐ Fail",
    "Video testimonials collected",
    "At least 1 video testimonial usable in ads and sales page",
    "3+",
    "☐ Pass / ☐ Fail",
    "Public launch price validated",
    "At least 4 of 8 exit interview respondents confirm they would pay full price",
    "7+/8",
    "☐ Pass / ☐ Fail",
    "",
    "The Single Veto Rule",
    "If completion rate falls below 60% OR result achievement rate falls below 50%, do not launch publicly regardless of other scores. These two metrics tell you the transformation is not yet reliable enough to charge full price and scale with paid ads.",
    "",
    "Beta Graduate Offer (Before Public Launch)",
    "Before closing the beta and opening public doors, offer beta graduates a preferential path to the next tier or a founding member price on the public launch. This serves three functions: it generates immediate revenue, it validates the ascension logic, and it creates urgency for the public launch through social proof from people already inside.",
    "",
    "•  Offer beta graduates the Core Offer or Continuity tier at the beta price for 72 hours after the programme ends.",
    "•  Use their testimonials to seed the public launch sequence — 'Here is what 10 beta participants experienced...'",
    "•  Invite the top 2–3 results-getters to a founding member inner circle at a reduced annual rate.",
    "",
    "",
    "PHASE 8",
    "Kill / Pivot / Iterate Framework",
    "Making the right decision when the data comes in",
    "",
    "The Three Possible Outcomes",
    "Every beta produces one of three outcomes. The decision framework below tells you which path to take based on the Go/No-Go scorecard and the qualitative data from exit interviews and Negative Avatar profiles.",
    "",
    "Outcome A — Launch (Scorecard passes, strong proof)",
    "All Go/No-Go thresholds met. At least 3 specific result testimonials. Refund rate below 10%. Proceed to public launch within 30 days.",
    "",
    "•  Apply Hormozi's Trim & Stack to rebuild the offer as a Grand Slam Offer using beta buyer language.",
    "•  Rewrite the sales page headline and hero using exact phrases from exit interviews.",
    "•  Build the Stack Slide with named bonuses, each solving a specific sub-problem identified in beta feedback.",
    "•  Set the guarantee level one tier higher than what you offered during beta.",
    "•  Deploy beta testimonials across sales page, email Day 6, and first ad creative.",
    "•  Open cart at full public price. Offer beta graduates a founding member discount for 72 hours only.",
    "",
    "Outcome B — Iterate (1–3 thresholds failed, clear fix exists)",
    "One to three Go/No-Go thresholds failed but the root cause is diagnosable and fixable. Run a second beta cohort after implementing the fixes. Do not launch publicly.",
    "",
    "Failed Threshold",
    "Likely Root Cause",
    "Specific Fix Before Beta 2",
    "Completion rate below 60%",
    "Module too complex, action steps unclear, or no accountability mechanism",
    "Simplify action steps to one per module. Add a weekly accountability check-in. Rebuild the module that had the lowest completion rate.",
    "Result achievement below 50%",
    "Missing prerequisite, implementation gap, or transformation promise too large for the timeframe",
    "Add a done-for-you component to the module where implementation breaks down. Adjust the promise to match actual result timeline.",
    "Module clarity score below 7.0",
    "Instruction assumes too much prior knowledge or lacks concrete examples",
    "Add a real-world example to every step. Record a 'watch me do this' walkthrough for each action item.",
    "Refund rate above 15%",
    "Sales copy is attracting the wrong buyer profile or expectation mismatch at checkout",
    "Add a 'This is NOT for you if...' section to the sales page. Add a pre-purchase checklist. Rewrite the promise to match actual delivery.",
    "Perceived value below 7.0",
    "Offer stack does not match the price or delivery format underdelivers on expectation",
    "Add one high-perceived-value bonus (name it, assign a standalone value). Upgrade the delivery format (add a live call if it was self-paced).",
    "",
    "Outcome C — Kill (Multiple core thresholds failed or root cause unclear)",
    "More than three thresholds failed, or the result achievement rate is below 30%, or the Negative Avatar profile reveals a fundamental mismatch between the offer and the market. Kill this version of the offer. Do not iterate — start again with a different mechanism or a different buyer profile.",
    "",
    "Kennedy's Rule on Killing Offers",
    "Most millionaires have a trail of failed offers behind them. Killing a beta that doesn't work is not failure — it is the system functioning correctly. The failure would be scaling a broken offer with paid ads because you were too attached to kill it.",
    "",
    "•  Archive all beta data — the buyer language, the objections, and the Negative Avatar profile are all assets even if the offer is dead.",
    "•  Return to MVO Playbook Phase 1 and Phase 2 with the new data. The kill is a redirect, not a reset.",
    "•  Consider whether the Negative Avatar profile points to a completely different offer that would serve the buyer who did engage.",
    "",
    "",
    "Master Beta Testing Checklist",
    "",
    "Before Beta Opens",
    "☐  Run all 7 Pre-Beta Gate criteria — all must pass",
    "☐  Cohort size defined (5–15 people)",
    "☐  Recruitment message written using the 5-element framework",
    "☐  Beta price set using Pricing Matrix — not free, not full price",
    "☐  Conditional guarantee written and reviewed",
    "☐  Buyer commitments documented and disclosed at purchase",
    "☐  Delivery schedule mapped (max 4 weeks)",
    "☐  Minimum viable tech stack confirmed (no over-building)",
    "☐  Baseline onboarding survey built in Typeform or Google Forms",
    "☐  Per-module pulse surveys built (one per module, 5 questions max)",
    "☐  Exit interview question list prepared and Zoom/Meet links ready",
    "☐  Recording consent language added to checkout and onboarding email",
    "",
    "During Beta Delivery",
    "☐  Baseline survey sent within 24 hours of purchase — before Module 1",
    "☐  Each module delivered with one clear action item attached",
    "☐  Pulse survey sent within 24 hours of each module delivery",
    "☐  Pulse survey responses reviewed within 48 hours — flag any score below 7",
    "☐  Early result achieved — request video testimonial immediately",
    "☐  Dropout identified — conduct short 5-minute check-in within 48 hours",
    "☐  All sessions recorded with participant consent",
    "☐  Negative Avatar data logged in Airtable as it emerges",
    "",
    "After Beta Closes",
    "☐  Exit interviews scheduled with all completers within 7 days of programme end",
    "☐  Exit interview recordings reviewed — exact phrases highlighted for copy",
    "☐  At least 3 specific result testimonials confirmed (with numbers)",
    "☐  At least 1 video testimonial recorded and ready",
    "☐  Negative Avatar Profile template completed for every refund and dropout",
    "☐  Go / No-Go Scorecard completed — all 8 metrics scored",
    "☐  Decision logged: Launch / Iterate / Kill",
    "☐  If Launch: offer stack rebuilt with Trim & Stack using beta buyer language",
    "☐  If Iterate: specific fixes documented and assigned before Beta 2 opens",
    "☐  If Kill: all data archived, MVO Playbook Phase 1 reopened with new data",
    "☐  Beta graduates offered next-tier or founding member price (72-hour window)",
    "☐  Beta results summary added to AEO/GEO keyword schema as citable case study data",
    "",
    "Beta Scorecard Template",
    "Complete this after exit interviews close. File in Airtable under Offer Iteration > Beta Records.",
    "",
    "Field",
    "Your Data",
    "Beta name and version",
    "",
    "Beta dates (open → close)",
    "",
    "Cohort size (enrolled)",
    "",
    "Cohort size (completed)",
    "",
    "Completion rate (%)",
    "",
    "Result achievement rate (% of completers with measurable result)",
    "",
    "Average module clarity score (1–10)",
    "",
    "Average perceived value score (1–10)",
    "",
    "Refund rate (%)",
    "",
    "Specific result testimonials collected (#)",
    "",
    "Video testimonials collected (#)",
    "",
    "Price validated by exit interview (# of 8 said yes to full price)",
    "",
    "Go / No-Go decision",
    "☐ Launch  ☐ Iterate  ☐ Kill",
    "Top 3 copy phrases from exit interviews",
    "1.2.3.",
    "Top 3 objections to address on sales page",
    "1.2.3.",
    "Negative Avatar root cause summary",
    "",
    "Single most important product change before launch",
    "",
    "",
    "Final Principle",
    "The beta is not a soft launch. It is a data collection instrument disguised as a programme. Run it with the discipline of a scientist and the care of a craftsman. Every data point it produces is worth 100 assumptions you would otherwise be making at full-price launch.",
    "",
    "",
    "",
    "RISER Nation Master Operating System  |  Beta Testing Methodology SOP  |  Version 1.0  |  2026 Edition",
    "Kennedy × Hormozi × Brunson  |  risernation.com"
  ],
  "other_parts": [
    {
      "part": "word/header1.xml",
      "paragraphs": [
        "RISER Nation  |  Beta Testing Methodology SOP  |  V1.0"
      ]
    },
    {
      "part": "word/footer1.xml",
      "paragraphs": [
        "Page PAGE of NUMPAGES"
      ]
    }
  ]
}