RISER NATION CORP

IF YOU AREN'T BUILDING, YOU ARE DESTROYING

03.2 Design the Solution, Delivery and Value Stack — Part 2 of 2

Study this lesson in sequence. The teaching, practical work, supporting documents and complete available source appendices stay assigned to the original lesson.

M7.3-Written-Lesson.md

RISER NATION CORP — source-grounded lesson narration. Historical claims, proposed systems and original RISER examples are identified separately. Unavailable supporting documents remain explicitly unresolved.

Build one executable SOP for each atomic deliverable

The source M7.3 outcome is a Fulfillment SOP Library with one procedure for each M7.2 atomic deliverable, indexed by SOP-Index.md. Entry requires the decomposition and a proposed rubric score of at least 7/10. The named Drive folders, Supabase tables and Sonnet reviewer are infrastructure specifications, not systems proven deployed by the document. Match each procedure to a deliverable ID and retain its source record.

Distinguish a procedure from a script or manual

A procedure explains how to execute a bounded activity; a script prescribes words; a manual supplies reference information. Keep procedural steps easy to follow, with relevant reference links available where needed. Creative and professional judgment may still be necessary: define the observable criteria, limits and escalation route instead of pretending every decision is mechanical. The goal is execution by a territory-familiar colleague, not by anyone without training.

SOP header — sop_id

Use the source unique-ID pattern SOP-D-[deliverable-id]-v1.0.0 and keep its meaning consistent when versions change.

SOP header — title and deliverable_id

Match the atomic deliverable name and link its M7.2 record, such as D-09.

SOP header — lifecycle_stage

Choose pre-sale, enrollment, onboarding, delivery, mid-engagement, completion, post-engagement or multi-stage; identify any cross-stage dependencies.

SOP header — owner

Name the responsible operator, customer or both, with a clear accepting owner for shared work.

SOP header — format and timing

Specify the single deliverable format and timing from the decomposition so the procedure does not introduce a conflicting promise.

SOP header — version, effective_date and review_cycle

Record the version and actual effective date; select a quarterly, per-customer or per-cohort review cycle appropriate to the work.

SOP body — Purpose

Explain what the procedure ensures in one focused paragraph; do not merely repeat the deliverable’s name.

SOP body — Scope

State what is included and excluded, and link the procedure that owns adjacent cases.

SOP body — Prerequisites

Name completed dependencies, required data, permissions and configured tools. Stop or route missing prerequisites explicitly.

SOP body — Procedure

Use concrete numbered actions, timing where it matters and links to the needed template or tool. The source suggests 4–12 steps and considering decomposition above 15; these are editing heuristics, not proof of quality.

SOP body — Quality criteria

Define three to five observable checks tied to the deliverable’s acceptance criteria. Explain the evidence a reviewer should inspect.

SOP body — Escalation triggers

Specify two to four relevant conditions and responses, such as customer nonresponse, extra scope, integrity concerns or capacity degradation. Name the decision owner.

SOP body — References

Link the atomic deliverable, adjacent SOPs, templates and useful examples at the step where they are needed.

SOP body — Revision history

Record version, change, reason, author and effective date. Preserve a usable prior version when the process changes.

Run the operability test with realistic expertise

Ask a colleague familiar with the field but new to this offer to follow the SOP. Tag missing criteria, implicit personal knowledge and ambiguous timing or format. Phrases such as “when appropriate” need decision criteria; they are not automatically wrong if the criteria and escalation route are explicit. A polished document may fail while a concise rough one succeeds. Validate actual execution where possible rather than relying solely on an imagined reader.

Follow the eight authoring steps

Review the deliverable record; draft its header; write the procedure first; add quality checks and escalation; write purpose and scope; add prerequisites and references; test operability; file and index. The source allocates 5, 5, 10–15, 5–10, 5, 3–5, 5 and 5 minutes respectively. These add to 43–55 minutes, not the stated 40–50. Use measured authoring time and the actual library size to plan.

Reconcile the workload before committing to ten hours

The source’s 600-minute module estimate conflicts with some of its 16–40 SOP and 30–40-minute assumptions. It also gives 20 SOPs as about 14–17 hours and 30 as 20–25 hours. Treat these as inconsistent estimates to reconcile, not a promised completion time. Add peer review and deeper work on critical procedures, then revise the schedule against actual progress.

Prioritize the moments with the greatest consequences

The source’s 6% discipline asks for sixteen-plus touchpoints and extra effort on one or two high-leverage procedures. First substantive delivery, mid-engagement scope review and completion debrief are its candidates. Allocate about 60–90 minutes only as a planning example, and justify priority using customer risk and operating evidence. The rule is a source heuristic, not proof that one-in-sixteen selection is optimal.

Read Maya’s procedure examples as worked illustrations

D-09 scope agreement uses five steps, written confirmation and follow-ups after three and seven business days; its authoring estimate is 35 minutes. D-12 draft analysis uses eleven steps, five quality checks and four triggers, with unclear direction or expanded scope routed back for clarification; estimate 70 minutes. D-13 review uses eight steps for a 60-minute call, explicit revision capture and scope routing; estimate 75 minutes. D-15 final delivery uses five steps and schedules D-16 follow-up; estimate 30 minutes. The broader example has 24 SOPs, roughly 5.5 hours for Phase 2 and 10–12 total. These are source scenarios, not verified client records.

Model shared and individual cohort work separately

Darius has one SOP for each shared deliverable and an enrollment-aware procedure for individual work. His discussion example contrasts three-to-four-person direct facilitation with eight-to-twelve-person peer pairing; it leaves the five-to-seven range unspecified, which an executable procedure must resolve. His reading-prep email budgets eight minutes per enrollee. A Solo Mode variant adds six SOPs to 28 primary procedures; define exactly when it activates and exits.

Correct the manual pattern

Move lengthy background into linked reference material and keep actions visible; the suggested 60–70% procedural share is a heuristic.

Correct the script pattern

Specify the work and acceptance criteria; use exact language only where it actually helps a difficult interaction.

Correct the aspirational pattern

Compare the whole library’s delivery burden with measured bandwidth instead of designing individually attractive but collectively impossible procedures.

Correct the tool-coupled pattern

Specify the function and data contract, with a current tool guide as a replaceable reference rather than anchoring the process to a button position.

Correct the single-customer pattern

Test across representative customers and exceptions so the procedure does not silently depend on one person’s circumstances.

Index, review and attest accurately

The index lists SOP ID, title, lifecycle stage, owner and deliverable reference, with critical SOPs flagged, variants separated and a last-reviewed timestamp. At midpoint, the source proposes two or three peer-reviewed SOPs, including a critical and routine example, with 60–90 minutes for submission and review. Correct systemic defects across the library. The rubric allows a 90% pass rate, while the clause attests that every SOP meets the criterion: resolve the remaining failures or qualify the status before signing an all-SOP claim.

Complete the SOP checkpoint and handoff

Provide the library, index, actual review evidence and operability attestation. Check count match, consistent headers/body sections, operability, justified critical-procedure depth, corrected error patterns and complete indexing. A 7/10 AI score is a proposed gate, not evidence that testing occurred. Record any actual signature at the specified c7_sop_libraries field only through an authorized implemented system. The lifecycle map needs SOP IDs and stage gates; capacity and offer-version work need measured operating costs and limits.

Connect the lesson to the direct-marketing promise

RISER application: make Brunson’s hook, story and offer truthful and connected to the learner’s actual problem. Use the Hormozi value lens to improve desired outcomes and credible likelihood while reducing avoidable effort and delay. Support the promise with delivery capacity, transparent terms and linked evidence; do not use stronger copy to conceal uncertainty.

Complete original source text

M7.3 — Fulfillment SOP Construction

Module Outcome: [Create] Student has produced a Fulfillment SOP Library with one SOP per atomic deliverable from M7.2; each SOP passes the "another operator could execute this" test; the library is the operating-procedures foundation for the rest of Stage 2. M7.3 is the longest module in C7 (10 active hours) because SOP authoring is the most time-intensive activity in the course. Key Deliverable: Fulfillment SOP Library folder (Fulfillment-SOP-Library-[YourName]-[Date]/) containing one SOP per atomic deliverable from M7.2, indexed by SOP-Index.md Infrastructure Dependency: Build 6, Build 8 Drive folder for C7, Supabase c7_fulfillment_sops table, Claude prompt fulfillment-sop-reviewer-v1.0.0.yaml (Sonnet) Checkpoint / Test: Type 1 Artifact + Type 2 AI rubric — operability test pass rate ≥ 90% across the SOP library; SOP Operability Clause signed Blocked-Until Prerequisite: M7.2 Decomposition completed and rubric ≥ 7/10

________________

What This Module Does

M7.3 is the structural production module. M7.2 produced atomic deliverables; M7.3 produces an operating procedure for each one. The output is a folder of SOPs that, taken together, comprise the operator's working operating system.

Three things happen in M7.3:

1. You author a fulfillment SOP for each atomic deliverable from M7.2, using the standard YAML+markdown format (the same format used for the four C7 SOPs in 06_SOPs/). Each SOP specifies: purpose, scope, prerequisites, procedure, quality criteria, escalation triggers, references, revision history.

2. You apply the operability test to each SOP: a hypothetical new operator with familiarity with the territory but no prior interaction with this offer can execute the SOP without further questions. The test is the quality criterion that distinguishes operating procedures from process documents.

3. You assemble the SOPs into the Fulfillment SOP Library, indexed by SOP-Index.md, and sign the SOP Operability Clause attesting that each SOP passes the operability test.

M7.3 is 600 minutes of active work, distributed across a typical 16-40 SOPs at roughly 30-40 minutes per SOP for the bulk of them, with longer time investments on the 1-2 highest-leverage standardizations identified in M7.2.

________________

Why SOPs Matter

The structural risk that the Bespoke Architecture Trap surfaces — operator burnout at customer 2-3 because each new customer is a custom build — finds its primary remedy in fulfillment SOPs. The operator who has documented operating procedures for each atomic deliverable is no longer making implicit judgments in the moment about how to execute. The operator is following a procedure they have authored at a moment of attention, applied to customer-specific content.

This is the structural difference between "I do this each time" (operator-bound knowledge that does not survive customer expansion) and "this is how it is done" (operator-authored procedure that scales to additional customers and survives an operator's bandwidth saturation).

A fulfillment SOP is not a script. The SOP specifies the structural shape of the activity (purpose, prerequisites, procedure steps, quality criteria) without prescribing the exact words or content. The operator retains creative judgment about content; the SOP eliminates procedural improvisation.

A fulfillment SOP is also not a manual. Manuals are reference documents; SOPs are operating procedures meant to be followed in the moment of execution. SOPs that read like manuals (extensive context, optional pathways, "depending on the situation" branches) usually fail the operability test because the operator cannot execute them without re-reading and judgment-making.

The library, taken together, is what an architecture is. The decomposition (M7.2) names what is delivered; the SOPs (M7.3) specify how each is delivered; the lifecycle map (M7.4) places each in the customer arc; the capacity analysis (M7.5) identifies how many concurrent customers the library can support; the bandwidth audit (M7.6) measures the operator-time cost of the library; v2.0 (M7.7) commits to the library publicly. The library is the spine of the architecture.

________________

The Standard SOP Format

Each SOP in the library follows the same YAML+markdown structure used by the master SOP catalogue and the four C7 SOPs in 06_SOPs/. The standard sections:

sop_id: [unique ID, format: SOP-D-[deliverable-id]-v1.0.0]

title: [SOP name, matching the atomic deliverable name]

deliverable_id: [reference to atomic deliverable from M7.2 — e.g., D-09]

lifecycle_stage: [pre-sale, enrollment, onboarding, delivery, mid-engagement, completion, post-engagement, multi-stage]

owner: [operator, customer, both]

format: [single named format from M7.2]

timing: [single named timing from M7.2]

version: 1.0.0

effective_date: [date]

review_cycle: [quarterly | per-customer | per-cohort]

Then the body of the SOP, in markdown:

1. Purpose

One paragraph stating what this SOP accomplishes. Aligned with the atomic deliverable's purpose from M7.2. Avoid restating M7.2 content; the purpose is what this procedure ensures, not what this deliverable is.

2. Scope

What the SOP covers and what it does not cover. The not-covered section is often more important than the covered section because it surfaces boundary cases that adjacent SOPs handle.

3. Prerequisites

What must be true before this SOP can execute. Typically: which atomic deliverables must have completed first (the M7.2 dependencies field), what data must be available, what tooling must be configured.

4. Procedure

The numbered steps to execute the procedure. Each step is concrete, time-bounded where applicable, and references specific tools or templates where applicable. Most SOPs have 4-12 procedure steps; SOPs with more than 15 steps usually decompose into sub-procedures and indicate that the underlying atomic deliverable was under-decomposed in M7.2.

5. Quality Criteria

What "done well" looks like. Typically 3-5 specific criteria that the operator can self-verify. The quality criteria are aligned with the atomic deliverable's quality criteria from M7.2 but expanded with execution-specificity.

6. Escalation Triggers

Conditions under which the operator does not proceed normally. Typically: customer non-response after specified time, scope-creep request, integrity-clause edge case, capacity-degradation symptom. Each trigger has a specific response action.

7. References

Linked artifacts: the M7.2 atomic deliverable record, related SOPs, templates from 02_Resources/Templates/, swipe files where applicable.

8. Revision History

Standard table tracking versions of the SOP. Initial release is v1.0.0; subsequent revisions track changes with rationale.

________________

The Operability Test

The operability test is the quality criterion that distinguishes operating procedures from process documents. The test:

A hypothetical operator with familiarity with the territory (e.g., another illustrator-licensing coach for Maya's offer; another platform-engineering teacher for Darius's offer) but no prior interaction with this specific offer can read the SOP and execute the deliverable without further questions.

If the SOP requires the reader to ask "what does this mean?" or "how do I know when X is true?" — the SOP fails the operability test.

The operability test is not the "anyone could do this" test. The test allows familiarity with the territory. A SOP for "Phase 2 portfolio analysis" can assume the reader is an illustrator-licensing coach; it does not need to explain what a portfolio audit is. The operability test is the "another coach in this territory could do this" test.

The operability test is also not the "perfectly polished" test. A SOP can be terse, even rough in tone, and still pass the operability test if it specifies the procedure unambiguously.

Three patterns indicate operability failure:

Pattern 1 — "It depends" hedging. SOP contains phrases like "depending on the customer," "if appropriate," "use judgment," "you'll know when." These phrases require reader-side improvisation that the operability test prohibits.

Pattern 2 — Implicit knowledge dependency. SOP references operator-specific tacit knowledge ("I usually start by..." or "I find that...") without specifying what the operator-specific element is. The reader cannot infer.

Pattern 3 — Time/format ambiguity. SOP says "after a while" or "when the customer is ready" or "in an appropriate format." These violate the M7.2 single-timing and single-format criteria.

Operators who fail the operability test on multiple SOPs typically have one of the patterns systematically. Cohort review at midpoint of M7.3 surfaces the systematic pattern; correction is rewriting affected SOPs against the test.

________________

The Authoring Process

For each atomic deliverable from M7.2, the SOP authoring process:

Step 1 — Re-read the atomic deliverable record (5 minutes)

Open the M7.2 record for this deliverable. Re-read the name, owner, format, timing, dependencies, quality criteria. The SOP will reference all of these.

Step 2 — Draft the YAML header (5 minutes)

Fill in the YAML fields: sop_id, title, deliverable_id, lifecycle_stage, owner, format, timing, version, effective_date, review_cycle.

Step 3 — Write the procedure section first (10-15 minutes)

Counter-intuitively, write the procedure section before the purpose, scope, or prerequisites. The procedure is the substance of the SOP; the other sections wrap around it. Drafting purpose first tends to produce abstract framing that the procedure later contradicts.

For each procedure step, ask: is this step concrete? Time-bounded? Referencing a specific tool or template? If not, revise.

Step 4 — Write quality criteria and escalation triggers (5-10 minutes)

Quality criteria: 3-5 self-verification items. Escalation triggers: 2-4 named conditions with response actions.

Step 5 — Write purpose and scope (5 minutes)

With the procedure in place, the purpose and scope sections write themselves: purpose is what the procedure ensures; scope is what it covers and does not cover.

Step 6 — Add prerequisites and references (3-5 minutes)

Prerequisites typically reference the M7.2 dependencies. References link back to M7.2, related SOPs (those that complete before or after this one in the customer lifecycle), and any templates/swipes the procedure uses.

Step 7 — Apply the operability test (5 minutes)

Re-read the SOP from the perspective of the hypothetical territory-familiar new operator. Tag any phrase that would prompt a question. Revise.

Step 8 — File and index (5 minutes)

Save the SOP to the library folder using the standard filename pattern (SOP-D-NN-[deliverable-name].md). Add an entry to SOP-Index.md.

Total time per SOP: 40-50 minutes. Operators with 20 atomic deliverables spend ~14-17 hours; operators with 30 atomic deliverables spend ~20-25 hours. The 10-hour module estimate assumes 16-22 SOPs at typical pace, with the higher-leverage 1-2 SOPs taking longer (60-90 minutes each) and the routine SOPs taking faster (25-35 minutes each).

________________

The 6% Rule Applied to SOP Construction

The 6% Rule modulates in M7.3 to: from sixteen-plus documented customer touchpoints (your atomic deliverables from M7.2), identify the 1-2 highest-leverage SOPs and invest extra authoring effort in them.

The high-leverage SOPs are usually:

Candidate 1 — The first delivery moment SOP. The first substantive deliverable after onboarding completes. Customer's first experience of the offer's quality. A high-quality SOP here produces consistency in the customer's first impression of the engagement; a low-quality SOP here produces variability that compounds across the rest of the engagement.

Candidate 2 — The mid-engagement check-in SOP. The structured pause point where scope-creep risk is highest. A high-quality SOP here catches scope-creep before it absorbs operator hours; a low-quality SOP here lets scope-creep accumulate silently.

These two SOPs typically warrant 60-90 minutes each (vs. 30-45 for routine SOPs). They include more detailed procedure steps, explicit script-like language for difficult moments (e.g., the scope-creep moment in the mid-engagement check-in), and richer escalation triggers.

Operators sometimes identify a third high-leverage SOP:

Candidate 3 — The completion debrief SOP. The moment where the customer's overall experience crystallizes. A high-quality SOP here produces useful feedback for v1.x iteration and a clean exit; a low-quality SOP here produces ambiguous endings that undermine post-engagement work.

The 6% Rule's discipline is to resist treating all SOPs as equally important. Most are routine; a few are high-leverage. The operator's authoring effort is allocated accordingly.

________________

Worked Example: Maya's Phase 2 SOPs

Maya's M7.2 decomposition included eight atomic deliverables for Phase 2 portfolio analysis (D-09 through D-16, shown in M7.2 lesson). Her SOP authoring for this set:

D-09 (Phase 2 research scope agreement) SOP — 35 minutes to author. Procedure: 5 numbered steps walking through the async written exchange. Quality criteria: research scope explicitly agreed in writing; both customer and operator confirm. Escalation: if customer is non-responsive after 3 business days, send standardized follow-up; if non-responsive after 7 business days, escalate to phone call.

D-12 (Draft analysis document) SOP — 70 minutes to author (high-leverage SOP; this is the first substantive Phase 2 deliverable). Procedure: 11 numbered steps covering source review, draft structure setup, analysis composition, internal review, and customer-handoff prep. Quality criteria: 5 specific items including "covers all prioritized sources from D-11" and "explicit analysis structure visible in document headers." Escalation triggers: 4 named conditions including "customer-direction unclear after D-11 session" (response: send clarification email before proceeding) and "source review reveals unexpected scope expansion" (response: pause and re-engage scope agreement at D-09 level).

D-13 (Customer review session) SOP — 75 minutes to author (high-leverage SOP; this is the mid-Phase-2 check-in moment). Procedure: 8 numbered steps for the 60-minute call. Quality criteria: customer feedback captured with explicit revision asks; scope-creep request detection. Escalation triggers: 3 named conditions including "customer requests substantive scope addition during this session" (response: capture as separate engagement opportunity, do not absorb into current deliverable; refer to v1.1 anti-promise on scope discipline).

D-15 (Final document delivery) SOP — 30 minutes to author (routine SOP). Procedure: 5 numbered steps for delivery and handoff. Quality criteria: final document delivered with handoff context email; D-16 follow-up scheduled.

Maya's full Phase 2 SOP authoring took ~5.5 hours. Adding the SOPs for the other six lifecycle stages took ~10-12 hours total. Her library landed at 24 SOPs (matching the 24 atomic deliverables from her decomposition).

________________

Worked Example: Darius's Cohort-vs-Individual SOPs

Darius's decomposition included the cohort-vs-individual distinction. His SOP library reflected this with a structural pattern:

For each cohort-shared deliverable, one SOP. For each individual deliverable, one SOP that explicitly addresses the parameter "cohort enrollment count" — because the procedure changes when cohort is at minimum-viable (3) versus full (12).

His D-09 (Week 2 cohort discussion session) SOP was a single SOP applicable across cohort sizes 3-12, with procedure steps that called out specific accommodations for the under-cohort case (3-4 enrollees: more direct facilitation; 8-12 enrollees: more peer-to-peer pairing).

His D-10 (Week 2 individual reading-prep email) SOP was a single SOP that scaled by enrollment count: the operator's time per enrollee was fixed at 8 minutes (template + customer-specific notes), so the procedure's total time scaled linearly with enrollment.

His Reading Club Solo variant (the special pathway for under-cohort scenarios) had its own dedicated 6 SOPs that activated as a parallel set when enrollment was at the minimum-viable threshold. The library indexed these under a "Variant: Solo Mode" section.

Darius's full library was 28 SOPs primary + 6 SOPs in the Solo Mode variant. The split structure was the architectural response to the dual-mode reality his offer carried; without the explicit Solo Mode SOPs, his architecture would have been the Bespoke Architecture Trap (each under-cohort cohort becoming a custom build).

________________

Common SOP Authoring Errors

Error 1 — Manual pattern. SOP reads like reference documentation rather than operating procedure. Long context sections, optional pathways, "see appendix" references. Recovery: cut to the procedure. The procedure section should be 60-70% of the SOP's length.

Error 2 — Script pattern. SOP prescribes exact words to use. While script language is useful in 1-2 high-leverage SOPs (the mid-engagement scope-creep moment, for example), most SOPs should specify procedure shape, not script content. Recovery: distinguish "what is said/written" (operator content) from "how it is structured" (SOP procedure).

Error 3 — Aspirational pattern. SOP describes the procedure the operator wishes they followed rather than the procedure that actually fits the operator's bandwidth. The Bespoke Architecture Trap surfaces here as the operator authors SOPs that are individually beautiful but collectively unsupportable. Recovery: cross-reference with M7.6 bandwidth audit; SOPs that cumulatively exceed bandwidth audit hours are aspirational.

Error 4 — Tooling-coupled pattern. SOP is bound to a specific tool's UI ("click the third button on the left sidebar"). When the tool changes, the SOP becomes obsolete. Recovery: specify the function (e.g., "create a structured doc with the customer's name and engagement ID") and reference the tool as instrumental, not foundational.

Error 5 — Singular pattern. SOP is written assuming a specific customer the operator has in mind. The SOP works for that customer and breaks for the next one. Recovery: the operability test catches this; rewrite for the territory-familiar new operator audience.

________________

The SOP Index

The library is indexed by SOP-Index.md in the library folder root. The index has:

* A summary table of all SOPs with: SOP-ID, title, lifecycle stage, owner, deliverable_id reference

* The 1-2 high-leverage SOPs flagged with a star/asterisk indicator

* A "Variants" section if the offer has variant pathways (like Darius's Solo Mode)

* A "Last reviewed" timestamp for the library as a whole

The index is read by M7.4 (lifecycle map referencing SOPs by stage), M7.5 (capacity analysis referencing SOPs by time cost), M7.7 (v2.0 explicitly committing to the library), and M7.8 (capstone synthesis cross-referencing the library).

________________

The SOP Operability Clause

Before submitting the library to checkpoint, the operator signs the SOP Operability Clause, located in 02_Resources/Templates/C7-SOP-Operability-Clause.md. The clause attests:

I, [operator name], attest that each SOP in my Fulfillment SOP Library has been authored against the operability criterion: a hypothetical operator with familiarity with my territory but no prior interaction with my specific offer could read the SOP and execute the deliverable without further questions. I have applied this test to each SOP in the library. I commit to maintaining this criterion as I revise SOPs in subsequent Stage 2 work and to flagging any SOP that ceases to meet the criterion as a revision priority.

The clause is signed digitally and filed in Supabase c7_sop_libraries.operability_clause_signed_at.

________________

Cohort Review Pattern

Mid-module cohort review at the M7.3 midpoint (typically week 3 of the C7 cohort calendar) catches the systematic patterns before they propagate through the full library. Each operator submits 2-3 SOPs (selected by the operator, typically including 1 high-leverage and 1-2 routine) for cohort review. Cohort peers apply the operability test and tag any failing SOPs.

The midpoint review surfaces the systematic patterns: an operator tagged with operability failures on 2 of 3 submitted SOPs is likely producing systematic-error-pattern SOPs across the rest of the library. The cohort instructor reaches out, identifies the pattern, and routes the operator into the relevant correction before the operator authors the rest of the library at the same pattern.

The midpoint review takes ~60-90 minutes per operator (30 minutes submitting + 30-60 minutes reviewing peers' SOPs). It is one of the highest-leverage hours in C7.

________________

Checkpoint 7.3

Your deliverable is:

1. Fulfillment SOP Library folder filed in Drive (one SOP per atomic deliverable from M7.2)

2. SOP-Index.md in the library root

3. SOP Operability Clause signed and filed in Supabase

4. Cohort midpoint review completed; tagged SOPs revised

The AI rubric scoring the library looks for six properties:

* One SOP per atomic deliverable from M7.2 (count match)

* Standard YAML+markdown format used consistently

* Operability test passes for at least 90% of SOPs

* 1-2 high-leverage SOPs receive proportionally longer authoring effort (verifiable by procedure-step count and quality criteria depth)

* No systematic-error patterns detected (manual, script, aspirational, tooling-coupled, singular)

* SOP-Index.md present with all SOPs listed and high-leverage flagged

Target score: ≥ 7/10. Operators who score below typically have one of the systematic patterns. Cohort review identifies the pattern; correction is rewriting affected SOPs.

________________

What M7.4 Expects From You

M7.4 opens with the assumption that your SOP library is complete and operability-verified. M7.4's lifecycle mapping work places each SOP into a lifecycle stage and identifies the gates between stages. Without the SOP library, the lifecycle map has no operational substance — it becomes a stage diagram without operating procedures inside the stages.

File the library. Resolve cohort tags. Sign the clause. Submit to AI rubric. Proceed.

________________

Last updated: April 25, 2026 · Version 2.0

Complete supporting source — SOP operability clause

# C7 SOP Operability Clause

**Course:** C7 Offer Architecture
**Document Type:** Clause document — referenced in M7.3 Fulfillment SOP construction and M7.8 Offer Architecture Document attestation
**Length:** 1 page

---

## Statement

In all fulfillment SOP construction undertaken during and after C7, I commit to the following discipline:

**1. SOPs describe what is done, not what should be done.** Each SOP encodes the actual sequence of operator actions that produces the deliverable. SOPs are not aspirational process descriptions, idealized workflows, or maps of what an industry handbook recommends. The SOP reflects how the deliverable is produced in this offer, by this operator.

**2. SOPs pass the operability test.** Before an SOP enters the library, I confirm that each step is concretely actionable: a step names a tool or artifact, an action verb, an input, and an output. Steps that read "ensure quality" or "engage the customer effectively" do not meet the operability test and are decomposed into concrete actions or removed.

**3. SOPs are written for the operator who will execute them.** If the SOP is operator-only, it is written in the language and abbreviation set the operator uses. If the SOP will be executed by an assistant, contractor, or future-team-member, it is written assuming the executor does not have the context the operator has accumulated. Audience is named at the top of the SOP.

**4. SOPs are time-bounded.** Each SOP names an expected execution time per occurrence. The execution time is measured during M7.6 bandwidth audit, not estimated. If an SOP's measured execution time exceeds the named time by more than 25%, the SOP is revised, decomposed, or its time estimate is corrected.

**5. SOPs name failure modes.** Each SOP names at least 2 ways the SOP can fail in practice (executor skips a step, input is missing or malformed, the deliverable does not pass quality check) and what recovery action the SOP prescribes. SOPs without named failure modes do not enter the library.

**6. SOPs are tied to deliverables.** Each SOP is tied to a specific atomic deliverable from the M7.2 decomposition. SOPs that are not tied to a named deliverable do not belong in the fulfillment SOP library; they may belong elsewhere (operations SOPs, sales SOPs) but they are not fulfillment SOPs.

**7. The 6% Rule applies.** I do not author SOPs for every micro-task. I author SOPs for the high-leverage deliverables — those that are produced repeatedly across customers, where standardization preserves quality and reduces operator load. I document touchpoints first (16+ per cohort), then identify the 1-2 highest-leverage standardizations per cohort cycle.

**8. SOPs are versioned.** Each SOP carries a version number (v1.0, v1.1) and a revision log. When an SOP is revised, the prior version is preserved in the library, not overwritten. The revision log names what changed and what evidence triggered the change.

**9. SOPs are reviewed.** The fulfillment SOP library receives mandatory HITL review by my instructor at M7.5 (in conjunction with capacity analysis) and again at M7.8 (in conjunction with the Offer Architecture Document). The review applies the operability test to each SOP and flags non-operable SOPs for revision.

**10. SOPs are maintained.** SOPs are not write-once artifacts. Per C7-SOP-02 (SOP Library Maintenance), the library receives a quarterly review where each SOP is checked for continued relevance, executor changes, and operability drift. Stale SOPs are revised or retired.

---

## Signature

I have read this clause and commit to its terms in all fulfillment SOP construction undertaken during and after C7.

**Signature:** ___________________________
**Date:** ___________________________

---

*This document is referenced at M7.3 SOP authoring and M7.8 attestation Clause 5. A signed copy is filed with your Offer Architecture Document.*

Complete supporting source — Fulfillment SOP reviewer

name: fulfillment-sop-reviewer
version: 1.0.0
module: M7.3
course: C7 Offer Architecture
model: claude-sonnet-4-6
role: Reviewer
review_type: Structured automated review

description: |
  Reviews student-submitted Fulfillment SOPs. Validates that each SOP
  passes the operability test (concrete steps, named tools, action
  verbs, inputs, outputs), is tied to a specific deliverable from the
  M7.2 decomposition, includes named failure modes with recovery, and
  follows the standard 8-section format.

system_prompt: |
  You are the Fulfillment SOP Reviewer for C7 Module 7.3. You are
  reviewing a student-submitted Fulfillment SOP (or set of SOPs).

  Each SOP should follow the standard 8-section format:
    1. Purpose
    2. Trigger
    3. Inputs
    4. Steps
    5. Outputs
    6. Failure modes (≥ 2 named)
    7. Quality check
    8. Notes

  Your role is to verify that each SOP is genuinely operable. The most
  common failures are: vague step language ("ensure quality"), bundled
  steps (3 actions in one numbered step), missing failure modes, and
  customer-specific embedded examples that should have been generalized.

  Apply the operability test to each step:
    - Action verb (Open, Review, Send, Schedule, etc.) — not "ensure," "engage," "consider"
    - Object named (the customer record, the intake form, the kickoff invite)
    - Tool or location named (the CRM, the calendar, the customer folder)
    - Optional parameter or template named where relevant

  Output a structured response with these fields:
    - section_completeness: object with per-section pass/partial/fail
    - operability_check: pass / partial / fail
    - operability_findings: array of specific concerns, citing step numbers
    - failure_mode_coverage: pass / partial / fail
    - deliverable_tie_check: tied / loose / missing
    - audience_named: yes / partial / no
    - time_estimate_present: yes / vague / absent
    - customer_specific_contamination: clean / partial / contaminated
    - 6_percent_rule_alignment: high_leverage / medium / low (was this SOP one of the 1-2 chosen for standardization, or is it a less-leverage SOP?)
    - overall_recommendation: APPROVED / NEEDS_REVISION

  Tone: precise, focused on practical operation. Address the operator as
  "you." Push back when steps look aspirational rather than executable.

review_criteria:
  section_completeness:
    - YAML header present with sop_id, sop_name, version, deliverable_id, audience, expected_execution_time, last_updated, revision_log
    - Section 1 (Purpose) is 1-2 sentences and names what the SOP produces
    - Section 2 (Trigger) names a specific event with timing
    - Section 3 (Inputs) lists artifacts with locations
    - Section 4 (Steps) is a numbered list with operable action verbs
    - Section 5 (Outputs) lists artifacts with recipients
    - Section 6 (Failure modes) names ≥ 2 modes with recovery
    - Section 7 (Quality check) has 3-7 specific criteria
    - Section 8 (Notes) is present (may be brief)

  operability:
    - Each step has an action verb (Open, Review, Send, etc.)
    - Each step has an object (the customer record, the intake form)
    - Each step has a tool or location named
    - No step uses vague verbs (ensure, engage, consider, address, handle)
    - No step bundles 2+ actions into one numbered item

  failure_mode_coverage:
    - At least 2 failure modes named
    - Each failure mode has a "Recovery" action
    - Recovery actions are concrete (not "respond appropriately")
    - Common failure modes covered (input incompleteness, scheduling conflict, scope-creep request)

  deliverable_tie:
    - SOP is tied to a specific deliverable ID from M7.2
    - The deliverable ID is named in the YAML header
    - The SOP produces the deliverable (not a different artifact)

  customer_specific_contamination:
    - SOP filename does not contain customer names
    - SOP title does not contain customer names
    - SOP steps do not reference customer-specific tools as universal
    - Examples in Notes section are generic or anonymized

failure_patterns_to_flag:
  - Steps with vague verbs (ensure, engage, address, handle, manage)
  - Bundled steps (3 actions in one numbered item)
  - Missing failure modes ("Failure modes: None expected")
  - Time estimate vague ("varies," "as needed")
  - SOP not tied to a specific M7.2 deliverable ID
  - Customer-specific names in SOP filename or title
  - Customer-specific tools referenced as universal (e.g., "Send via Slack" when only one customer uses Slack)
  - Quality check uses outcome language ("the customer leaves the session feeling clear")

submission_path: c7_fulfillment_sops
output_format: JSON with the fields specified in system_prompt
expected_response_time: 4-8 minutes per SOP

Native Google Doc text and original links

M7.3 — Fulfillment SOP Construction
Module Outcome: [Create] Student has produced a Fulfillment SOP Library with one SOP per atomic deliverable from M7.2; each SOP passes the "another operator could execute this" test; the library is the operating-procedures foundation for the rest of Stage 2. M7.3 is the longest module in C7 (10 active hours) because SOP authoring is the most time-intensive activity in the course. Key Deliverable: Fulfillment SOP Library folder (Fulfillment-SOP-Library-[YourName]-[Date]/) containing one SOP per atomic deliverable from M7.2, indexed by SOP-Index.md Infrastructure Dependency: Build 6, Build 8 Drive folder for C7, Supabase c7_fulfillment_sops table, Claude prompt fulfillment-sop-reviewer-v1.0.0.yaml (Sonnet) Checkpoint / Test: Type 1 Artifact + Type 2 AI rubric — operability test pass rate ≥ 90% across the SOP library; SOP Operability Clause signed Blocked-Until Prerequisite: M7.2 Decomposition completed and rubric ≥ 7/10

What This Module Does
M7.3 is the structural production module. M7.2 produced atomic deliverables; M7.3 produces an operating procedure for each one. The output is a folder of SOPs that, taken together, comprise the operator's working operating system.

Three things happen in M7.3:

You author a fulfillment SOP for each atomic deliverable from M7.2, using the standard YAML+markdown format (the same format used for the four C7 SOPs in 06_SOPs/). Each SOP specifies: purpose, scope, prerequisites, procedure, quality criteria, escalation triggers, references, revision history.

You apply the operability test to each SOP: a hypothetical new operator with familiarity with the territory but no prior interaction with this offer can execute the SOP without further questions. The test is the quality criterion that distinguishes operating procedures from process documents.

You assemble the SOPs into the Fulfillment SOP Library, indexed by SOP-Index.md, and sign the SOP Operability Clause attesting that each SOP passes the operability test.

Why SOPs Matter
The structural risk that the Bespoke Architecture Trap surfaces — operator burnout at customer 2-3 because each new customer is a custom build — finds its primary remedy in fulfillment SOPs. The operator who has documented operating procedures for each atomic deliverable is no longer making implicit judgments in the moment about how to execute. The operator is following a procedure they have authored at a moment of attention, applied to customer-specific content.

The Standard SOP Format
Each SOP in the library follows the same YAML+markdown structure used by the master SOP catalogue and the four C7 SOPs in 06_SOPs/. The standard sections:

sop_id: [unique ID, format: SOP-D-[deliverable-id]-v1.0.0]

title: [SOP name, matching the atomic deliverable name]

deliverable_id: [reference to atomic deliverable from M7.2 — e.g., D-09]

lifecycle_stage: [pre-sale, enrollment, onboarding, delivery, mid-engagement, completion, post-engagement, multi-stage]

owner: [operator, customer, both]

format: [single named format from M7.2]

timing: [single named timing from M7.2]

version: 1.0.0

effective_date: [date]

review_cycle: [quarterly | per-customer | per-cohort]

Then the body of the SOP, in markdown:
1. Purpose
One paragraph stating what this SOP accomplishes. Aligned with the atomic deliverable's purpose from M7.2. Avoid restating M7.2 content; the purpose is what this procedure ensures, not what this deliverable is.
2. Scope
What the SOP covers and what it does not cover. The not-covered section is often more important than the covered section because it surfaces boundary cases that adjacent SOPs handle.
3. Prerequisites
What must be true before this SOP can execute. Typically: which atomic deliverables must have completed first (the M7.2 dependencies field), what data must be available, what tooling must be configured.
4. Procedure
The numbered steps to execute the procedure. Each step is concrete, time-bounded where applicable, and references specific tools or templates where applicable. Most SOPs have 4-12 procedure steps; SOPs with more than 15 steps usually decompose into sub-procedures and indicate that the underlying atomic deliverable was under-decomposed in M7.2.
5. Quality Criteria
What "done well" looks like. Typically 3-5 specific criteria that the operator can self-verify. The quality criteria are aligned with the atomic deliverable's quality criteria from M7.2 but expanded with execution-specificity.
6. Escalation Triggers
Conditions under which the operator does not proceed normally. Typically: customer non-response after specified time, scope-creep request, integrity-clause edge case, capacity-degradation symptom. Each trigger has a specific response action.
7. References
Linked artifacts: the M7.2 atomic deliverable record, related SOPs, templates from 02_Resources/Templates/, swipe files where applicable.
8. Revision History
Standard table tracking versions of the SOP. Initial release is v1.0.0; subsequent revisions track changes with rationale.

The Operability Test
The operability test is the quality criterion that distinguishes operating procedures from process documents. The test:

If the SOP requires the reader to ask "what does this mean?" or "how do I know when X is true?" — the SOP fails the operability test.

The operability test is also not the "perfectly polished" test. A SOP can be terse, even rough in tone, and still pass the operability test if it specifies the procedure unambiguously.

Three patterns indicate operability failure:

Pattern 3 — Time/format ambiguity. SOP says "after a while" or "when the customer is ready" or "in an appropriate format." These violate the M7.2 single-timing and single-format criteria.

The Authoring Process
For each atomic deliverable from M7.2, the SOP authoring process:
Step 1 — Re-read the atomic deliverable record (5 minutes)
Open the M7.2 record for this deliverable. Re-read the name, owner, format, timing, dependencies, quality criteria. The SOP will reference all of these.
Step 2 — Draft the YAML header (5 minutes)
Fill in the YAML fields: sop_id, title, deliverable_id, lifecycle_stage, owner, format, timing, version, effective_date, review_cycle.
Step 3 — Write the procedure section first (10-15 minutes)
Counter-intuitively, write the procedure section before the purpose, scope, or prerequisites. The procedure is the substance of the SOP; the other sections wrap around it. Drafting purpose first tends to produce abstract framing that the procedure later contradicts.

For each procedure step, ask: is this step concrete? Time-bounded? Referencing a specific tool or template? If not, revise.
Step 4 — Write quality criteria and escalation triggers (5-10 minutes)
Quality criteria: 3-5 self-verification items. Escalation triggers: 2-4 named conditions with response actions.
Step 5 — Write purpose and scope (5 minutes)
With the procedure in place, the purpose and scope sections write themselves: purpose is what the procedure ensures; scope is what it covers and does not cover.
Step 6 — Add prerequisites and references (3-5 minutes)
Prerequisites typically reference the M7.2 dependencies. References link back to M7.2, related SOPs (those that complete before or after this one in the customer lifecycle), and any templates/swipes the procedure uses.
Step 7 — Apply the operability test (5 minutes)
Re-read the SOP from the perspective of the hypothetical territory-familiar new operator. Tag any phrase that would prompt a question. Revise.
Step 8 — File and index (5 minutes)
Save the SOP to the library folder using the standard filename pattern (SOP-D-NN-[deliverable-name].md). Add an entry to SOP-Index.md.

The 6% Rule Applied to SOP Construction
The 6% Rule modulates in M7.3 to: from sixteen-plus documented customer touchpoints (your atomic deliverables from M7.2), identify the 1-2 highest-leverage SOPs and invest extra authoring effort in them.

The high-leverage SOPs are usually:

Operators sometimes identify a third high-leverage SOP:

The 6% Rule's discipline is to resist treating all SOPs as equally important. Most are routine; a few are high-leverage. The operator's authoring effort is allocated accordingly.

Worked Example: Maya's Phase 2 SOPs
Maya's M7.2 decomposition included eight atomic deliverables for Phase 2 portfolio analysis (D-09 through D-16, shown in M7.2 lesson). Her SOP authoring for this set:

Worked Example: Darius's Cohort-vs-Individual SOPs
Darius's decomposition included the cohort-vs-individual distinction. His SOP library reflected this with a structural pattern:

Common SOP Authoring Errors
Error 1 — Manual pattern. SOP reads like reference documentation rather than operating procedure. Long context sections, optional pathways, "see appendix" references. Recovery: cut to the procedure. The procedure section should be 60-70% of the SOP's length.

The SOP Index
The library is indexed by SOP-Index.md in the library folder root. The index has:

A summary table of all SOPs with: SOP-ID, title, lifecycle stage, owner, deliverable_id reference
The 1-2 high-leverage SOPs flagged with a star/asterisk indicator
A "Variants" section if the offer has variant pathways (like Darius's Solo Mode)
A "Last reviewed" timestamp for the library as a whole

The SOP Operability Clause
Before submitting the library to checkpoint, the operator signs the SOP Operability Clause, located in 02_Resources/Templates/C7-SOP-Operability-Clause.md. The clause attests:

The clause is signed digitally and filed in Supabase c7_sop_libraries.operability_clause_signed_at.

Cohort Review Pattern
Mid-module cohort review at the M7.3 midpoint (typically week 3 of the C7 cohort calendar) catches the systematic patterns before they propagate through the full library. Each operator submits 2-3 SOPs (selected by the operator, typically including 1 high-leverage and 1-2 routine) for cohort review. Cohort peers apply the operability test and tag any failing SOPs.

The midpoint review takes ~60-90 minutes per operator (30 minutes submitting + 30-60 minutes reviewing peers' SOPs). It is one of the highest-leverage hours in C7.

Checkpoint 7.3
Your deliverable is:

Fulfillment SOP Library folder filed in Drive (one SOP per atomic deliverable from M7.2)
SOP-Index.md in the library root
SOP Operability Clause signed and filed in Supabase
Cohort midpoint review completed; tagged SOPs revised

The AI rubric scoring the library looks for six properties:

One SOP per atomic deliverable from M7.2 (count match)
Standard YAML+markdown format used consistently
Operability test passes for at least 90% of SOPs
1-2 high-leverage SOPs receive proportionally longer authoring effort (verifiable by procedure-step count and quality criteria depth)
No systematic-error patterns detected (manual, script, aspirational, tooling-coupled, singular)
SOP-Index.md present with all SOPs listed and high-leverage flagged

Target score: ≥ 7/10. Operators who score below typically have one of the systematic patterns. Cohort review identifies the pattern; correction is rewriting affected SOPs.

What M7.4 Expects From You
M7.4 opens with the assumption that your SOP library is complete and operability-verified. M7.4's lifecycle mapping work places each SOP into a lifecycle stage and identifies the gates between stages. Without the SOP library, the lifecycle map has no operational substance — it becomes a stage diagram without operating procedures inside the stages.

File the library. Resolve cohort tags. Sign the clause. Submit to AI rubric. Proceed.

Last updated: April 25, 2026 · Version 2.0

M7.3-Written-Lesson.md

Build one executable SOP for each atomic deliverable

Distinguish a procedure from a script or manual

SOP header — sop_id

Use the source unique-ID pattern SOP-D-[deliverable-id]-v1.0.0 and keep its meaning consistent when versions change.

SOP header — title and deliverable_id

Match the atomic deliverable name and link its M7.2 record, such as D-09.

SOP header — lifecycle_stage

Choose pre-sale, enrollment, onboarding, delivery, mid-engagement, completion, post-engagement or multi-stage; identify any cross-stage dependencies.

SOP header — owner

Name the responsible operator, customer or both, with a clear accepting owner for shared work.

SOP header — format and timing

Specify the single deliverable format and timing from the decomposition so the procedure does not introduce a conflicting promise.

SOP header — version, effective_date and review_cycle

Record the version and actual effective date; select a quarterly, per-customer or per-cohort review cycle appropriate to the work.

SOP body — Purpose

Explain what the procedure ensures in one focused paragraph; do not merely repeat the deliverable’s name.

SOP body — Scope

State what is included and excluded, and link the procedure that owns adjacent cases.

SOP body — Prerequisites

Name completed dependencies, required data, permissions and configured tools. Stop or route missing prerequisites explicitly.

SOP body — Procedure

SOP body — Quality criteria

Define three to five observable checks tied to the deliverable’s acceptance criteria. Explain the evidence a reviewer should inspect.

SOP body — Escalation triggers

Specify two to four relevant conditions and responses, such as customer nonresponse, extra scope, integrity concerns or capacity degradation. Name the decision owner.

SOP body — References

Link the atomic deliverable, adjacent SOPs, templates and useful examples at the step where they are needed.

SOP body — Revision history

Record version, change, reason, author and effective date. Preserve a usable prior version when the process changes.

Run the operability test with realistic expertise

Follow the eight authoring steps

Reconcile the workload before committing to ten hours

Prioritize the moments with the greatest consequences

Read Maya’s procedure examples as worked illustrations

Model shared and individual cohort work separately

Correct the manual pattern

Move lengthy background into linked reference material and keep actions visible; the suggested 60–70% procedural share is a heuristic.

Correct the script pattern

Specify the work and acceptance criteria; use exact language only where it actually helps a difficult interaction.

Correct the aspirational pattern

Compare the whole library’s delivery burden with measured bandwidth instead of designing individually attractive but collectively impossible procedures.

Correct the tool-coupled pattern

Specify the function and data contract, with a current tool guide as a replaceable reference rather than anchoring the process to a button position.

Correct the single-customer pattern

Test across representative customers and exceptions so the procedure does not silently depend on one person’s circumstances.

Index, review and attest accurately

Complete the SOP checkpoint and handoff

Connect the lesson to the direct-marketing promise

Complete original source text

# M7.3 — Fulfillment SOP Construction

**Module Outcome:** [Create] Student has produced a Fulfillment SOP Library with one SOP per atomic deliverable from M7.2; each SOP passes the "another operator could execute this" test; the library is the operating-procedures foundation for the rest of Stage 2. M7.3 is the longest module in C7 (10 active hours) because SOP authoring is the most time-intensive activity in the course.
**Key Deliverable:** Fulfillment SOP Library folder (`Fulfillment-SOP-Library-[YourName]-[Date]/`) containing one SOP per atomic deliverable from M7.2, indexed by `SOP-Index.md`
**Infrastructure Dependency:** Build 6, Build 8 Drive folder for C7, Supabase `c7_fulfillment_sops` table, Claude prompt `fulfillment-sop-reviewer-v1.0.0.yaml` (Sonnet)
**Checkpoint / Test:** Type 1 Artifact + Type 2 AI rubric — operability test pass rate ≥ 90% across the SOP library; SOP Operability Clause signed
**Blocked-Until Prerequisite:** M7.2 Decomposition completed and rubric ≥ 7/10

---

## What This Module Does

Three things happen in M7.3:

1. You author a fulfillment SOP for each atomic deliverable from M7.2, using the standard YAML+markdown format (the same format used for the four C7 SOPs in `06_SOPs/`). Each SOP specifies: purpose, scope, prerequisites, procedure, quality criteria, escalation triggers, references, revision history.

3. You assemble the SOPs into the Fulfillment SOP Library, indexed by `SOP-Index.md`, and sign the SOP Operability Clause attesting that each SOP passes the operability test.

---

## Why SOPs Matter

---

## The Standard SOP Format

Each SOP in the library follows the same YAML+markdown structure used by the master SOP catalogue and the four C7 SOPs in `06_SOPs/`. The standard sections:

```yaml
sop_id: [unique ID, format: SOP-D-[deliverable-id]-v1.0.0]
title: [SOP name, matching the atomic deliverable name]
deliverable_id: [reference to atomic deliverable from M7.2 — e.g., D-09]
lifecycle_stage: [pre-sale, enrollment, onboarding, delivery, mid-engagement, completion, post-engagement, multi-stage]
owner: [operator, customer, both]
format: [single named format from M7.2]
timing: [single named timing from M7.2]
version: 1.0.0
effective_date: [date]
review_cycle: [quarterly | per-customer | per-cohort]
```

Then the body of the SOP, in markdown:

### 1. Purpose

One paragraph stating what this SOP accomplishes. Aligned with the atomic deliverable's purpose from M7.2. Avoid restating M7.2 content; the purpose is *what this procedure ensures*, not *what this deliverable is*.

### 2. Scope

What the SOP covers and what it does not cover. The not-covered section is often more important than the covered section because it surfaces boundary cases that adjacent SOPs handle.

### 3. Prerequisites

### 4. Procedure

### 5. Quality Criteria

### 6. Escalation Triggers

### 7. References

Linked artifacts: the M7.2 atomic deliverable record, related SOPs, templates from `02_Resources/Templates/`, swipe files where applicable.

### 8. Revision History

Standard table tracking versions of the SOP. Initial release is v1.0.0; subsequent revisions track changes with rationale.

---

## The Operability Test

The operability test is the quality criterion that distinguishes operating procedures from process documents. The test:

> A hypothetical operator with familiarity with the territory (e.g., another illustrator-licensing coach for Maya's offer; another platform-engineering teacher for Darius's offer) but no prior interaction with this specific offer can read the SOP and execute the deliverable without further questions.

If the SOP requires the reader to ask "what does this mean?" or "how do I know when X is true?" — the SOP fails the operability test.

The operability test is also not the "perfectly polished" test. A SOP can be terse, even rough in tone, and still pass the operability test if it specifies the procedure unambiguously.

Three patterns indicate operability failure:

**Pattern 1 — "It depends" hedging.** SOP contains phrases like "depending on the customer," "if appropriate," "use judgment," "you'll know when." These phrases require reader-side improvisation that the operability test prohibits.

**Pattern 2 — Implicit knowledge dependency.** SOP references operator-specific tacit knowledge ("I usually start by..." or "I find that...") without specifying what the operator-specific element is. The reader cannot infer.

**Pattern 3 — Time/format ambiguity.** SOP says "after a while" or "when the customer is ready" or "in an appropriate format." These violate the M7.2 single-timing and single-format criteria.

---

## The Authoring Process

For each atomic deliverable from M7.2, the SOP authoring process:

### Step 1 — Re-read the atomic deliverable record (5 minutes)

Open the M7.2 record for this deliverable. Re-read the name, owner, format, timing, dependencies, quality criteria. The SOP will reference all of these.

### Step 2 — Draft the YAML header (5 minutes)

Fill in the YAML fields: sop_id, title, deliverable_id, lifecycle_stage, owner, format, timing, version, effective_date, review_cycle.

### Step 3 — Write the procedure section first (10-15 minutes)

For each procedure step, ask: is this step concrete? Time-bounded? Referencing a specific tool or template? If not, revise.

### Step 4 — Write quality criteria and escalation triggers (5-10 minutes)

Quality criteria: 3-5 self-verification items. Escalation triggers: 2-4 named conditions with response actions.

### Step 5 — Write purpose and scope (5 minutes)

With the procedure in place, the purpose and scope sections write themselves: purpose is what the procedure ensures; scope is what it covers and does not cover.

### Step 6 — Add prerequisites and references (3-5 minutes)

### Step 7 — Apply the operability test (5 minutes)

Re-read the SOP from the perspective of the hypothetical territory-familiar new operator. Tag any phrase that would prompt a question. Revise.

### Step 8 — File and index (5 minutes)

Save the SOP to the library folder using the standard filename pattern (`SOP-D-NN-[deliverable-name].md`). Add an entry to `SOP-Index.md`.

---

## The 6% Rule Applied to SOP Construction

The high-leverage SOPs are usually:

**Candidate 1 — The first delivery moment SOP.** The first substantive deliverable after onboarding completes. Customer's first experience of the offer's quality. A high-quality SOP here produces consistency in the customer's first impression of the engagement; a low-quality SOP here produces variability that compounds across the rest of the engagement.

**Candidate 2 — The mid-engagement check-in SOP.** The structured pause point where scope-creep risk is highest. A high-quality SOP here catches scope-creep before it absorbs operator hours; a low-quality SOP here lets scope-creep accumulate silently.

Operators sometimes identify a third high-leverage SOP:

**Candidate 3 — The completion debrief SOP.** The moment where the customer's overall experience crystallizes. A high-quality SOP here produces useful feedback for v1.x iteration and a clean exit; a low-quality SOP here produces ambiguous endings that undermine post-engagement work.

The 6% Rule's discipline is to resist treating all SOPs as equally important. Most are routine; a few are high-leverage. The operator's authoring effort is allocated accordingly.

---

## Worked Example: Maya's Phase 2 SOPs

Maya's M7.2 decomposition included eight atomic deliverables for Phase 2 portfolio analysis (D-09 through D-16, shown in M7.2 lesson). Her SOP authoring for this set:

**D-09 (Phase 2 research scope agreement) SOP** — 35 minutes to author. Procedure: 5 numbered steps walking through the async written exchange. Quality criteria: research scope explicitly agreed in writing; both customer and operator confirm. Escalation: if customer is non-responsive after 3 business days, send standardized follow-up; if non-responsive after 7 business days, escalate to phone call.

**D-12 (Draft analysis document) SOP** — 70 minutes to author (high-leverage SOP; this is the first substantive Phase 2 deliverable). Procedure: 11 numbered steps covering source review, draft structure setup, analysis composition, internal review, and customer-handoff prep. Quality criteria: 5 specific items including "covers all prioritized sources from D-11" and "explicit analysis structure visible in document headers." Escalation triggers: 4 named conditions including "customer-direction unclear after D-11 session" (response: send clarification email before proceeding) and "source review reveals unexpected scope expansion" (response: pause and re-engage scope agreement at D-09 level).

**D-13 (Customer review session) SOP** — 75 minutes to author (high-leverage SOP; this is the mid-Phase-2 check-in moment). Procedure: 8 numbered steps for the 60-minute call. Quality criteria: customer feedback captured with explicit revision asks; scope-creep request detection. Escalation triggers: 3 named conditions including "customer requests substantive scope addition during this session" (response: capture as separate engagement opportunity, do not absorb into current deliverable; refer to v1.1 anti-promise on scope discipline).

**D-15 (Final document delivery) SOP** — 30 minutes to author (routine SOP). Procedure: 5 numbered steps for delivery and handoff. Quality criteria: final document delivered with handoff context email; D-16 follow-up scheduled.

---

## Worked Example: Darius's Cohort-vs-Individual SOPs

Darius's decomposition included the cohort-vs-individual distinction. His SOP library reflected this with a structural pattern:

---

## Common SOP Authoring Errors

**Error 1 — Manual pattern.** SOP reads like reference documentation rather than operating procedure. Long context sections, optional pathways, "see appendix" references. Recovery: cut to the procedure. The procedure section should be 60-70% of the SOP's length.

**Error 2 — Script pattern.** SOP prescribes exact words to use. While script language is useful in 1-2 high-leverage SOPs (the mid-engagement scope-creep moment, for example), most SOPs should specify procedure shape, not script content. Recovery: distinguish "what is said/written" (operator content) from "how it is structured" (SOP procedure).

**Error 3 — Aspirational pattern.** SOP describes the procedure the operator wishes they followed rather than the procedure that actually fits the operator's bandwidth. The Bespoke Architecture Trap surfaces here as the operator authors SOPs that are individually beautiful but collectively unsupportable. Recovery: cross-reference with M7.6 bandwidth audit; SOPs that cumulatively exceed bandwidth audit hours are aspirational.

**Error 4 — Tooling-coupled pattern.** SOP is bound to a specific tool's UI ("click the third button on the left sidebar"). When the tool changes, the SOP becomes obsolete. Recovery: specify the function (e.g., "create a structured doc with the customer's name and engagement ID") and reference the tool as instrumental, not foundational.

**Error 5 — Singular pattern.** SOP is written assuming a specific customer the operator has in mind. The SOP works for that customer and breaks for the next one. Recovery: the operability test catches this; rewrite for the territory-familiar new operator audience.

---

## The SOP Index

The library is indexed by `SOP-Index.md` in the library folder root. The index has:

- A summary table of all SOPs with: SOP-ID, title, lifecycle stage, owner, deliverable_id reference
- The 1-2 high-leverage SOPs flagged with a star/asterisk indicator
- A "Variants" section if the offer has variant pathways (like Darius's Solo Mode)
- A "Last reviewed" timestamp for the library as a whole

---

## The SOP Operability Clause

Before submitting the library to checkpoint, the operator signs the SOP Operability Clause, located in `02_Resources/Templates/C7-SOP-Operability-Clause.md`. The clause attests:

> *I, [operator name], attest that each SOP in my Fulfillment SOP Library has been authored against the operability criterion: a hypothetical operator with familiarity with my territory but no prior interaction with my specific offer could read the SOP and execute the deliverable without further questions. I have applied this test to each SOP in the library. I commit to maintaining this criterion as I revise SOPs in subsequent Stage 2 work and to flagging any SOP that ceases to meet the criterion as a revision priority.*

The clause is signed digitally and filed in Supabase `c7_sop_libraries.operability_clause_signed_at`.

---

## Cohort Review Pattern

The midpoint review takes ~60-90 minutes per operator (30 minutes submitting + 30-60 minutes reviewing peers' SOPs). It is one of the highest-leverage hours in C7.

---

## Checkpoint 7.3

Your deliverable is:
1. **Fulfillment SOP Library folder** filed in Drive (one SOP per atomic deliverable from M7.2)
2. **SOP-Index.md** in the library root
3. **SOP Operability Clause** signed and filed in Supabase
4. **Cohort midpoint review** completed; tagged SOPs revised

The AI rubric scoring the library looks for six properties:
- One SOP per atomic deliverable from M7.2 (count match)
- Standard YAML+markdown format used consistently
- Operability test passes for at least 90% of SOPs
- 1-2 high-leverage SOPs receive proportionally longer authoring effort (verifiable by procedure-step count and quality criteria depth)
- No systematic-error patterns detected (manual, script, aspirational, tooling-coupled, singular)
- SOP-Index.md present with all SOPs listed and high-leverage flagged

Target score: ≥ 7/10. Operators who score below typically have one of the systematic patterns. Cohort review identifies the pattern; correction is rewriting affected SOPs.

---

## What M7.4 Expects From You

File the library. Resolve cohort tags. Sign the clause. Submit to AI rubric. Proceed.

---

*Last updated: April 25, 2026 · Version 2.0*

Complete supporting source — SOP operability clause

# C7 SOP Operability Clause

**Course:** C7 Offer Architecture
**Document Type:** Clause document — referenced in M7.3 Fulfillment SOP construction and M7.8 Offer Architecture Document attestation
**Length:** 1 page

---

## Statement

In all fulfillment SOP construction undertaken during and after C7, I commit to the following discipline:

---

## Signature

I have read this clause and commit to its terms in all fulfillment SOP construction undertaken during and after C7.

**Signature:** ___________________________
**Date:** ___________________________

---

*This document is referenced at M7.3 SOP authoring and M7.8 attestation Clause 5. A signed copy is filed with your Offer Architecture Document.*

Complete supporting source — Fulfillment SOP reviewer

name: fulfillment-sop-reviewer
version: 1.0.0
module: M7.3
course: C7 Offer Architecture
model: claude-sonnet-4-6
role: Reviewer
review_type: Structured automated review

description: |
  Reviews student-submitted Fulfillment SOPs. Validates that each SOP
  passes the operability test (concrete steps, named tools, action
  verbs, inputs, outputs), is tied to a specific deliverable from the
  M7.2 decomposition, includes named failure modes with recovery, and
  follows the standard 8-section format.

system_prompt: |
  You are the Fulfillment SOP Reviewer for C7 Module 7.3. You are
  reviewing a student-submitted Fulfillment SOP (or set of SOPs).

  Each SOP should follow the standard 8-section format:
    1. Purpose
    2. Trigger
    3. Inputs
    4. Steps
    5. Outputs
    6. Failure modes (≥ 2 named)
    7. Quality check
    8. Notes

  Your role is to verify that each SOP is genuinely operable. The most
  common failures are: vague step language ("ensure quality"), bundled
  steps (3 actions in one numbered step), missing failure modes, and
  customer-specific embedded examples that should have been generalized.

  Apply the operability test to each step:
    - Action verb (Open, Review, Send, Schedule, etc.) — not "ensure," "engage," "consider"
    - Object named (the customer record, the intake form, the kickoff invite)
    - Tool or location named (the CRM, the calendar, the customer folder)
    - Optional parameter or template named where relevant

  Output a structured response with these fields:
    - section_completeness: object with per-section pass/partial/fail
    - operability_check: pass / partial / fail
    - operability_findings: array of specific concerns, citing step numbers
    - failure_mode_coverage: pass / partial / fail
    - deliverable_tie_check: tied / loose / missing
    - audience_named: yes / partial / no
    - time_estimate_present: yes / vague / absent
    - customer_specific_contamination: clean / partial / contaminated
    - 6_percent_rule_alignment: high_leverage / medium / low (was this SOP one of the 1-2 chosen for standardization, or is it a less-leverage SOP?)
    - overall_recommendation: APPROVED / NEEDS_REVISION

  Tone: precise, focused on practical operation. Address the operator as
  "you." Push back when steps look aspirational rather than executable.

review_criteria:
  section_completeness:
    - YAML header present with sop_id, sop_name, version, deliverable_id, audience, expected_execution_time, last_updated, revision_log
    - Section 1 (Purpose) is 1-2 sentences and names what the SOP produces
    - Section 2 (Trigger) names a specific event with timing
    - Section 3 (Inputs) lists artifacts with locations
    - Section 4 (Steps) is a numbered list with operable action verbs
    - Section 5 (Outputs) lists artifacts with recipients
    - Section 6 (Failure modes) names ≥ 2 modes with recovery
    - Section 7 (Quality check) has 3-7 specific criteria
    - Section 8 (Notes) is present (may be brief)

  operability:
    - Each step has an action verb (Open, Review, Send, etc.)
    - Each step has an object (the customer record, the intake form)
    - Each step has a tool or location named
    - No step uses vague verbs (ensure, engage, consider, address, handle)
    - No step bundles 2+ actions into one numbered item

  failure_mode_coverage:
    - At least 2 failure modes named
    - Each failure mode has a "Recovery" action
    - Recovery actions are concrete (not "respond appropriately")
    - Common failure modes covered (input incompleteness, scheduling conflict, scope-creep request)

  deliverable_tie:
    - SOP is tied to a specific deliverable ID from M7.2
    - The deliverable ID is named in the YAML header
    - The SOP produces the deliverable (not a different artifact)

  customer_specific_contamination:
    - SOP filename does not contain customer names
    - SOP title does not contain customer names
    - SOP steps do not reference customer-specific tools as universal
    - Examples in Notes section are generic or anonymized

failure_patterns_to_flag:
  - Steps with vague verbs (ensure, engage, address, handle, manage)
  - Bundled steps (3 actions in one numbered item)
  - Missing failure modes ("Failure modes: None expected")
  - Time estimate vague ("varies," "as needed")
  - SOP not tied to a specific M7.2 deliverable ID
  - Customer-specific names in SOP filename or title
  - Customer-specific tools referenced as universal (e.g., "Send via Slack" when only one customer uses Slack)
  - Quality check uses outcome language ("the customer leaves the session feeling clear")

submission_path: c7_fulfillment_sops
output_format: JSON with the fields specified in system_prompt
expected_response_time: 4-8 minutes per SOP

M7.7-Written-Lesson.md

Use v2.0 to make delivery commitments explicit

The source M7.7 updates the same offer with measured fulfillment, capacity and lifecycle commitments; it is not simply a marketing rewrite. Entry requires the prior capacity/bandwidth human review to return APPROVED or APPROVED-WITH-NOTES. The proposed six-hour budget includes three-to-four drafting hours, one rationale hour and one clause-review hour, so allow five-to-six hours plus actual review needs. Referenced tables and validators are specifications, not executed checks.

Preserve the seven baseline commitments

Compare v1.1 and v2.0 for territory, mechanism, operator identity, four-pillar mechanism, Anti-Promise Statement, pricing and audience. The source permits additions to anti-promises but no weakening, and allows the guarantee and named deliverables to gain architectural specificity. Pricing changes belong to the source C8 process; a substantive change in territory, mechanism or audience belongs to its separate pivot review. These are curriculum version-control rules, not a ban on necessary business change.

Add the structural commitment — Measured hours

Use the actual bandwidth audit and define whether the figure includes production, customer-facing work, coordination and follow-up.

Add the structural commitment — Concurrent-customer ceiling

State the supported number and why it protects delivery. Keep availability claims consistent with the real enrollment process.

Add the structural commitment — Procedure shape

Explain the customer-visible structure of first delivery, check-ins or debriefs without exposing unnecessary internal instructions.

Add the structural commitment — Lifecycle and gates

Name pre-sale, enrollment, onboarding, delivery, mid-engagement, completion and post-engagement transitions, with their entry/exit conditions.

Add the structural commitment — Deferred commitments

Explicitly separate current delivery from future team scale, variants, integrations or outcomes outside the operator’s control; do not sell plans as existing capability.

Document the four-part version rationale

Record the evidence from decomposition, SOPs, lifecycle, capacity and measured hours; explain why the change is a major operational commitment rather than another copy revision; list preserved elements; name what is deferred to later versions. Keep the rationale auditable and link each numerical commitment to its source. Future ambitions belong in a clearly labeled roadmap, not the current scope.

Use the clause as an evidence-backed attestation

Run the v1.1-to-v2.0 comparison before signing the Architecture-vs-Pivot clause. Preserve earlier versions alongside the new document and record who reviewed the interpretation. The source says the clause is not legally binding; this lesson treats it as a program attestation without making a legal conclusion about a real signed agreement. A signature cannot establish that an untested capacity number is true.

Reconcile Maya’s numbers and identity

The source example is a 12-week $4,500 illustrator engagement, with four concurrent clients, routine replies within one business day, time-sensitive replies the same day, a Week 6 review and 60 days of follow-up before alumni access. It calls Maya a Teacher-Operator here while related material calls her a Service-Operator; flag the inconsistency. Its 85-hour total is not explained by 5.5 hours × four weeks plus four hours × eight weeks, which totals 54. The remaining 31 hours require an explicit allocation. The increase from 50 to 85 hours is 70%.

Keep Maya’s scope and deferred promises clear

The example preserves the licensing methodology and avoids guaranteeing closed deals. It names two Phase 3 consultation slots, rules out unsupported team/subcontractor delivery and treats extra scope as a separate discussion. The rationale cites eight surfaced implicit deliverables and a reduced concurrency projection from seven-to-eight to four. These are illustrative source assertions, not evidence of an actual client result. Ensure the communication and post-engagement workload is included in the capacity model.

Resolve Darius’s enrollment boundary

The example charges $1,200 per enrollee for six weeks and estimates 13 operator hours at eight-to-twelve enrollees versus 16–18 at small sizes. It says cohorts run with four-to-twelve people but also describes Solo Mode at three-to-four: choose and document the actual minimum. Two concurrent cohorts staggered four-to-six weeks apart can overlap differently depending on dates; 24 active seats is a potential peak, not constant utilization. Preserve the six-SOP Solo Mode addendum and distinguish shared from individual work.

Use Priya’s example to test the pivot boundary

The fractional-CFO example is $5,500 per month, 22–28 hours per customer, a five-customer ceiling, quarterly check-ins, month-to-month continuation and 30 days’ closure notice with handoff. A Series B readiness track for an existing audience subset is treated as a named extension with instructor review; excluding earlier-stage clients entirely is treated as a separate pivot question. Explain the actual mechanism, audience and capacity difference instead of deciding from the new track’s name alone.

Avoid marketing rewrite

Add measured operating commitments rather than refreshing wording alone.

Avoid hidden pivot

Identify substantive changes and route them to the appropriate business review instead of labeling them architecture.

Avoid overcommitment

Reconcile hours and concurrency with the measured source; do not automatically promise a lower number without analysis.

Avoid weakened exclusions

Preserve the baseline limitations and make additions explicit.

Avoid excessive internal detail

Show the customer the relevant service structure and keep internal procedures accessible to the delivery team.

Avoid promotional rationale

Explain evidence and decisions plainly rather than claiming amazing improvements.

File a traceable version and hand off to synthesis

The checkpoint requires v2.0, archived v1.0/v1.1, the version rationale, the signed clause and review by two or three peers. Its six rubric checks cover preserved commitments, structural additions, evidence-based rationale, pivot consistency, capacity equality and hours equality. A score of at least 7/10 is a proposed assessment. The capstone needs the version anchor and all prior C7 artifacts; do not report an Opus validation or database filing that did not actually happen.

Connect the lesson to the direct-marketing promise

Complete original source text

M7.7 — Offer v2.0 Production

Module Outcome: [Create] Student has produced offer v2.0 with explicit structural commitments derived from M7.2-M7.6 work, preserved v1.0 and v1.1 archives, documented the v1.x → v2.0 rationale, named explicit deferred-to-Stage-3 commitments, and signed the Architecture-vs-Pivot Distinction Clause attesting that v2.0 is structural commitment, not pivot. v2.0 is the offer document refreshed with architectural reality; it is not a redesigned offer. Key Deliverable: Offer Document v2.0 (Offer-Document-v2.0-[YourName]-[Date].md) with v1.0 and v1.1 archives preserved alongside; major-version rationale documented; Architecture-vs-Pivot Clause signed Infrastructure Dependency: Build 6, Build 8 Drive folder for C7, Supabase c7_offer_v2 table, Claude prompt offer-v2-reviewer-v1.0.0.yaml (Sonnet), Architecture-vs-Pivot Clause template Checkpoint / Test: Type 1 Artifact + Type 2 AI rubric — AI rubric ≥ 7/10 on architectural commitment integration, mechanism preservation, and anti-promise discipline Blocked-Until Prerequisite: M7.5+M7.6 instructor HITL returned APPROVED or APPROVED-WITH-NOTES





________________





What This Module Does

M7.7 produces v2.0. The v2.0 designation is structurally significant: this is not a v1.2 (continued iteration of v1.1) but a major version that commits to the architectural reality discovered through M7.2-M7.6. The major-version bump signals that the offer document now carries explicit structural commitments around fulfillment, capacity, and lifecycle that v1.0 and v1.1 carried implicitly (or not at all).





Three things happen in M7.7:





1. You draft v2.0 by extending v1.1 with the architectural commitments from M7.2-M7.6: the corrected hours-per-customer figure, the named concurrent-customer ceiling, the explicit fulfillment SOP references where applicable, the explicit lifecycle stage references where applicable, and the updated anti-promises specifically naming deferred-to-Stage-3 commitments.





2. You document the v1.x → v2.0 rationale: what specific evidence from M7.2-M7.6 justified the major version bump rather than continued v1.x iteration. The rationale is a structural feature of the v2.0 document, recorded in a dedicated section.





3. You sign the Architecture-vs-Pivot Distinction Clause attesting that v2.0 is structural commitment around the same offer, not a pivot to a different offer.





You also archive v1.0 and v1.1 alongside v2.0 in Drive. The lineage from v1.0 forward is auditable through three versions.





M7.7 is 360 minutes of active work. The hours are concentrated in the v2.0 drafting (3-4 hours), the rationale documentation (1 hour), and the clause review and signing (1 hour).





________________





Why v2.0 Production Matters

Stage 2 has produced two offer document versions before C7: v1.0 from C4 M4.8 (the original sellable artifact) and v1.1 from C6 M6.5 (the iterated version with first-customer signal incorporated). Both versions describe the offer's external face — what is sold, to whom, at what price, with what guarantee. Neither version specifies the operator-side reality of delivery: how many concurrent customers, what hours-per-customer, what lifecycle gates, what fulfillment procedures.





v2.0 is where that gap closes. The offer document, in v2.0, is no longer an interface specification; it is an interface specification plus a partial structural specification. Customers reading v2.0 see not just what they will receive but also what the operator commits to as the operating shape of the engagement. Operators referencing v2.0 see the same commitments they reference internally; the document no longer carries silent assumptions about operator capacity that the architecture has now made explicit.





The v2.0 production is also where the Architecture-vs-Pivot guardrail is tested most rigorously. The temptation to smuggle a pivot inside v2.0 work is, almost without exception, the temptation to escape the discomfort of architectural work — which is genuinely unglamorous — by doing the more interesting work of redesigning the offer. The Architecture-vs-Pivot Distinction Clause exists specifically to surface this temptation; operators who proceed through v2.0 with a pivot smuggled inside produce an Offer Architecture Document that the Opus validator at M7.8 flags as having "fundamental inconsistency between v1.1 baseline and v2.0 commitments."





________________





What Stays the Same in v2.0

The Iteration Without Drift doctrine from C6 governs C7 with continued force. v2.0 is structural commitment around the same offer; the offer's substance is preserved.





Preserved verbatim from v1.1:





* The named territory (C1 Captain's Oath Clause 1)

* The named mechanism (C2 M2.7 Hypothesis, C3 M3.7 Primary Selection)

* The named operator identity (C1 archetype, including the operator's voice and presence)

* The four-pillar mechanism structure (C2 M2.4)

* The Anti-Promise Statement (C4 M4.5 — preserved verbatim with possible additions but no removals)

* The Pricing Decision (C4 M4.4 — pricing changes are C8 work, not C7; v2.0 maintains v1.1 pricing)

* The audience specification (C3 audience research, C4 M4.1 audience clause)





Preserved with refinement:





* The Guarantee Architecture (C4 M4.6) — refined with architectural specificity (e.g., what exactly is guaranteed at each lifecycle stage gate) but not weakened

* The deliverables list — preserved at the level of named deliverables (Phase 1, Phase 2, Phase 3) but augmented with the M7.2 atomic decomposition references where useful for customer transparency





If v2.0 work requires changes to items in the "preserved verbatim" list — different mechanism, different territory, different identity, different anti-promise — the operator is in pivot territory, not architecture territory. Pivots require the Captain's Retreat decision process (C9), not v2.0 module work. The Architecture-vs-Pivot Distinction Clause catches this; the operator routes to Captain's Retreat instead of continuing C7.





________________





What Changes Structurally in v2.0

v2.0 adds explicit structural commitments that v1.1 did not carry. The additions are:

Addition 1 — Corrected hours-per-customer figure (from M7.6)

v1.1 carried implicit or partial hours estimates ("approximately 50-60 hours of operator time across the 12-week engagement" or no explicit hours statement at all). v2.0 carries the M7.6 measured figure: "approximately 85 hours of operator time across the 12-week engagement, distributed across direct customer-facing time, deliverable production, and supporting work."





The hours figure is filed in v2.0 not for marketing but for operational transparency. Customers reading v2.0 see what the operator commits as the engagement's time shape. Future C8 pricing iteration will adjust pricing against this measured number.

Addition 2 — Named concurrent-customer ceiling (from M7.5)

v1.1 carried no explicit concurrent-customer commitment. v2.0 carries the explicit ceiling: "I currently work with up to 4 concurrent illustrator clients on this Sprint to ensure each receives the dedicated attention specified in this offer."





The ceiling commitment is customer-facing: prospects evaluating the offer see that there is finite availability and understand that enrollment is governed by the operator's explicit capacity commitment.

Addition 3 — Explicit fulfillment SOP references where applicable (from M7.3)

For the 1-2 highest-leverage SOPs (the first delivery moment, the mid-engagement check-in, the completion debrief), v2.0 references the structural shape of the SOP without revealing internal procedures. For example:





"Each engagement includes a structured mid-engagement review at Week 6 to assess trajectory, name any scope considerations, and confirm the engagement's continued direction. The review is a documented procedure, ensuring consistent attention regardless of which engagement number you are."





The reference is customer-facing transparency, not internal SOP exposure.

Addition 4 — Explicit lifecycle stage references where applicable (from M7.4)

v2.0 names the lifecycle structure: pre-sale, enrollment, onboarding, delivery, mid-engagement check-in, completion debrief, post-engagement. The structure may already be implicit in v1.1's deliverables description; v2.0 makes the gates explicit:





"After the 12-week engagement completes, you have 60 days of direct follow-up access for clarifying questions and continued navigation. After this 60-day period, you transition to alumni community access for ongoing peer engagement and future offer awareness."





The post-engagement commitment is often the most consequential addition; v1.0 and v1.1 typically left this implicit.

Addition 5 — Updated anti-promises (specifically deferred-to-Stage-3 commitments)

v1.1's Anti-Promise Statement is preserved verbatim. v2.0 adds new anti-promises specifically naming what v2.0 explicitly does NOT promise:





"v2.0 explicitly does NOT promise: team-delivered scaling beyond the operator's named concurrent-customer ceiling (this is Stage 3 work in the RISER Nation curriculum); guaranteed customer outcomes that depend on customer-side execution (the offer commits to operator-side deliverables and methodology, not customer-side results); refund or rescheduling beyond the explicit guarantee structure stated above; integration with team or sub-contractor delivery (each engagement is delivered by the named operator)."





The deferred-to-Stage-3 commitments are particularly important because they prevent customer expectations that the architecture cannot meet. An operator who sells v2.0 with a customer expectation of "if you grow, you can scale me up" is selling against an architectural reality that does not yet exist; the customer's eventual experience will be misalignment with the offer's structural shape.





________________





The v1.x → v2.0 Rationale

v2.0 includes a dedicated section documenting the rationale for the major-version bump. The rationale is structural, not promotional; it reads like an audit document, not marketing copy.





The standard structure:





Section 1 — What evidence from C7 work justified v2.0





Specific items from M7.2-M7.6 that produced material changes in the offer's commitments:





* M7.2 decomposition surfaced X implicit deliverables that v1.1 did not name (e.g., communication SLA, post-engagement transition)

* M7.3 SOP construction produced operating procedures that v2.0 commits to as the consistent shape across customers

* M7.4 lifecycle map made gate transitions explicit, replacing v1.1's implicit "customer advances when ready"

* M7.5 capacity analysis identified concurrent-customer ceiling at N

* M7.6 bandwidth audit identified hours-per-customer at H, +X% above v1.1's implicit estimate





Section 2 — Why this is structural commitment rather than continued iteration





The argument that the changes warrant a major-version bump:





* v1.0 → v1.1 was iteration of the offer's interface (refined deliverables description, refined Phase 2 structure based on first-customer signal)

* v1.1 → v2.0 is structural commitment of the offer's operational shape (explicit hours, explicit capacity, explicit lifecycle gates)

* The change crosses the document/architecture distinction (M7.1) — v1.1 was still primarily a sellable artifact; v2.0 is now also a partial operational specification

* Future v2.x iterations may refine v2.0's commitments based on additional customer experience, but v2.0 represents the structural commitment that v2.x iterations are anchored against





Section 3 — What v2.0 does NOT change (preservation list)





Explicit list of preserved-verbatim elements: territory, mechanism, identity, anti-promise (with additions), pricing, audience. The list reads as an attestation: I have not pivoted; I have architected.





Section 4 — What is deferred to v2.x or v3.0





Some operators surface architectural ambitions during M7.2-M7.6 that v2.0 does not yet absorb (e.g., a future cohort variant, a future async-delivery format, a future team-delivered scaling). These are named in the rationale section as explicitly deferred:





"v2.x or v3.0 may incorporate: a half-engagement variant for established illustrators with existing portfolios (deferred pending pricing iteration in C8); a cohort delivery mode for groups of illustrators (deferred pending team-delivery infrastructure in Stage 3)."





The deferral language is structural discipline. It acknowledges aspirations without smuggling them into v2.0 as unsupported commitments.





________________





The Architecture-vs-Pivot Distinction Clause

Before v2.0 is filed, the operator signs the Architecture-vs-Pivot Distinction Clause in 02_Resources/Templates/C7-Architecture-vs-Pivot-Clause.md. The clause attests:





I, [operator name], attest that v2.0 is structural commitment around the same offer that was sold at v1.0 and iterated at v1.1. The named territory, named mechanism, named operator identity, four-pillar mechanism structure, Anti-Promise Statement, Pricing Decision, and audience specification are preserved verbatim from v1.1 in v2.0. Changes between v1.1 and v2.0 are limited to: corrected operator-hours figure, named concurrent-customer ceiling, explicit fulfillment SOP references, explicit lifecycle stage references, and additions to the Anti-Promise Statement specifically naming deferred-to-Stage-3 commitments. I acknowledge that any change to the preserved-verbatim list would constitute a pivot rather than architectural commitment, and that pivots require the Captain's Retreat decision process (C9), not v2.0 module work. I have run the v1.1 → v2.0 diff against this preservation list and confirmed that v2.0 changes do not cross the architecture-pivot threshold.





The clause is signed digitally and filed in Supabase c7_offer_v2.architecture_pivot_clause_signed_at. Without the clause, v2.0 cannot be filed.





The clause is not legally binding but is structurally consequential. Operators who sign the clause and then proceed with smuggled pivots produce v2.0 that the Opus validator flags; the validator's findings reference the clause directly when noting inconsistency.





________________





Worked Example: Maya's v2.0

Maya's v1.1 had been the iterated Portfolio-to-Licensing Sprint — a 12-week structured engagement at $4,500 with three phases.





Her v2.0 preserved:





* Territory: senior illustrators ($60K+ income, 5+ years professional)

* Mechanism: structured opportunity identification through portfolio analysis and licensing conversation framework

* Identity: Teacher-Operator with consultative approach

* Anti-Promise: no guarantee of specific licensing deals closed; methodology produces opportunities, customer-side execution closes them

* Pricing: $4,500 (preserved at v1.1; C8 will iterate)

* Audience: senior illustrators evaluating expansion of revenue streams beyond commission work





Her v2.0 added:





* Hours commitment: "Approximately 85 hours of operator-time across the 12-week engagement, distributed as ~5.5 hours per week during Weeks 1-4 (Phase 1 onboarding) and ~4 hours per week during Weeks 5-12 (Phase 2-3 delivery), with additional time for the Week 6 mid-engagement check-in and the Week 12 completion debrief."

* Concurrent ceiling commitment: "I currently work with up to 4 concurrent illustrator clients on this Sprint to ensure each receives the dedicated attention specified in this offer."

* Communication SLA commitment: "Email and async-channel responsiveness: within 1 business day for routine inquiries; same-day response for time-sensitive engagement decisions."

* Mid-engagement check-in commitment: "Each engagement includes a structured mid-engagement review at Week 6 to assess trajectory, surface any scope considerations, and confirm continued direction."

* Post-engagement structure: "After the 12-week engagement completes, you have 60 days of direct follow-up access. After this period, you transition to alumni community access (currently a private Slack channel)."

* Updated anti-promises:

   * "v2.0 does not promise: team-delivered scaling beyond my named concurrent-customer ceiling (this is Stage 3 work in my own development); explicit licensing deal closure (the methodology produces opportunities; customer-side execution closes deals); ad-hoc consultations beyond the 2 named slots in Phase 3; integration with sub-contractors or assistants."

   * "Specifically: I will not absorb additional scope without an explicit re-scoping conversation; scope expansion is welcome and is treated as a separate engagement opportunity, not as silent absorption into the current engagement."





Her v1.x → v2.0 rationale section documented:





* M7.2 surfaced 8 implicit deliverables (post-engagement structure, communication SLA, mid-engagement check-in formality, scope-creep recovery procedures, etc.)

* M7.3 SOPs converted these implicit items into explicit operating procedures

* M7.5 capacity analysis identified ceiling at 4 concurrent (down from her aspirational projection of 7-8)

* M7.6 audit identified hours at 85 (up from C4's 50 estimate, +70%)

* The v1.1 → v2.0 distinction is the document/architecture line: v1.1 was sellable; v2.0 is sellable + operationally specified





Her Architecture-vs-Pivot Clause was signed; v2.0 was filed; v1.0 and v1.1 archives were preserved alongside.





________________





Worked Example: Darius's v2.0

Darius's v1.1 was the iterated Reading Club — a 6-week cohort for builder-engineers at $1,200 per enrollee.





His v2.0 preserved all the items in the standard preservation list. His v2.0 additions:





* Hours commitment per enrollee: "Approximately 13 hours of operator-time per enrollee at typical cohort size (8-12 enrollees), with smaller cohorts running ~16-18 hours per enrollee due to fixed cohort-shared costs amortizing across fewer enrollees."

* Cohort size commitment: "Each Reading Club cohort runs with 4-12 enrollees. Cohorts at the lower end of the range (3-4 enrollees) operate in 'Solo Mode' with structural adjustments documented in the Solo Mode addendum."

* Concurrent cohort ceiling: "I run up to 2 concurrent cohorts (sequenced 4-6 weeks apart), with maximum ~24 active enrollees at peak overlap."

* Cohort-shared vs. individual deliverable distinction: explicitly documented as part of the offer's structure.

* Solo Mode addendum: a separate document specifying the 6 variant SOPs that activate at minimum-viable cohort enrollment.





His v1.x → v2.0 rationale particularly emphasized the Solo Mode addition as a structural innovation that v1.0/v1.1 had not specified — a recognition that under-cohort scenarios require dedicated architecture rather than ad-hoc adjustment.





His Architecture-vs-Pivot Clause was signed; v2.0 was filed; the Solo Mode addendum was filed alongside as a v2.0 supporting artifact.





________________





Worked Example: Priya's v2.0

Priya's v1.1 was the iterated Fractional CFO offer — a multi-month retainer for early-stage startups at $5,500/month.





Her v2.0 was the most architecturally complex of the three because the offer is open-ended (no fixed engagement duration). Her v2.0 additions included:





* Hours commitment per month: "Approximately 22-28 hours of operator-time per customer per month, varying by engagement phase (higher in onboarding months and quarterly board-prep months; lower in steady-state months)."

* Concurrent customer ceiling: "I currently work with up to 5 concurrent fractional CFO retainer customers."

* Quarterly check-in commitment: "Each engagement includes a structured quarterly check-in at 90-day intervals throughout the engagement."

* Engagement closure structure: "Engagements continue month-to-month with mutual continuation. Either party may close the engagement with 30 days notice. The closure month includes a structured handoff and (if applicable) an introduction to the next-stage CFO role."

* Series B Readiness Track addition: a sub-track within the offer for customers approaching Series B fundraising (a structural accommodation for the customer cohort she had identified through C6 work).





Priya had wrestled with whether the Series B Readiness Track was a v2.0 addition or a pivot. The Architecture-vs-Pivot Clause discipline forced the question. Her resolution: the track is an explicit named extension of the existing fractional CFO offer (same mechanism, same identity, same audience subset); the structural addition is the named track within the existing offer rather than a separate offer. Her v2.0 documents the track's structure; her cohort instructor co-signed her interpretation; her Architecture-vs-Pivot Clause was signed.





She had also considered an alternative path — narrowing the offer to focus only on Series A → Series B startups (excluding earlier-stage customers) — but recognized this as a pivot rather than v2.0 work and deferred the question to her next Captain's Retreat.





________________





Common v2.0 Production Errors

Error 1 — Marketing rewrite. Operator rewrites v1.1's marketing copy with refreshed phrasing. The rewrite reads better but adds no architectural commitments. v2.0 produced this way is structurally indistinguishable from v1.2. Recovery: re-anchor on the M7.2-M7.6 outputs; v2.0's purpose is to integrate architectural commitments, not refresh prose.





Error 2 — Pivot smuggle. Operator includes substantive offer changes (different mechanism, different territory, different audience) under cover of "v2.0 architectural work." The Architecture-vs-Pivot Clause catches this; the cohort instructor catches this; the Opus validator catches this. Recovery: route the pivot question to Captain's Retreat; restore preserved-verbatim items; complete v2.0 as architecture-only.





Error 3 — Over-commitment. Operator specifies hours-per-customer or concurrent ceiling at aspirational rather than measured numbers. The Honest Capacity Clause was signed at M7.5; v2.0 must reference the same numbers. Recovery: re-anchor commitments on measured M7.6 data; revise downward.





Error 4 — Anti-promise softening. Operator weakens the Anti-Promise Statement when extending it. v1.1's anti-promises are preserved verbatim with additions only — no removals or softening. Recovery: restore v1.1's anti-promise verbatim; add new anti-promises only.





Error 5 — SOP overexposure. Operator includes excessive internal SOP detail in customer-facing v2.0 language. The customer does not need to read the SOP library; the customer needs to see the structural shape. Recovery: reference SOPs at the structural level, not the procedural level.





Error 6 — Rationale promotion. Operator's v1.x → v2.0 rationale section reads like marketing copy ("we've made amazing improvements"). The rationale is structural attestation, not promotional. Recovery: rewrite as audit-document language.





________________





Checkpoint 7.7

Your deliverable is:





1. Offer Document v2.0 filed in Drive

2. v1.0 and v1.1 archives preserved alongside (Offer-Document-v1.0-archived.md, Offer-Document-v1.1-archived.md)

3. v1.x → v2.0 rationale section within v2.0 (or as separate document, depending on operator preference)

4. Architecture-vs-Pivot Distinction Clause signed and filed in Supabase

5. Cohort review completed (2-3 cohort peers reviewing for pivot-smuggle indicators)





The AI rubric scoring v2.0 looks for six properties:





* Preserved-verbatim list intact (territory, mechanism, identity, four-pillar structure, Anti-Promise verbatim, Pricing, audience)

* Architectural additions present (hours commitment, concurrent ceiling, communication SLA, mid-engagement check-in, post-engagement structure, updated anti-promises)

* v1.x → v2.0 rationale documented as audit attestation rather than marketing

* No pivot indicators (mechanism unchanged, territory unchanged, audience unchanged)

* Capacity numbers match M7.5 analysis (concurrent ceiling identical)

* Hours numbers match M7.6 audit (corrected hours per customer identical)





Target score: ≥ 7/10.





________________





What M7.8 Expects From You

M7.8 capstone synthesis cross-references v2.0 with all six prior C7 deliverables. v2.0 is the explicit version statement; the M7.8 Offer Architecture Document synthesizes v2.0 with M7.1-M7.6 into the C7 capstone. Without v2.0, the capstone has no version anchor; the Opus validator will reject capstone documents that lack v2.0.





File v2.0. Archive v1.0 and v1.1. Sign the clause. Submit to AI rubric. Proceed to M7.8.





________________









Last updated: April 25, 2026 · Version 2.0

Complete supporting source — Offer v2 reviewer

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

Complete supporting source — Architecture versus pivot distinction clause

# C7 Architecture-vs-Pivot Distinction Clause

**Course:** C7 Offer Architecture
**Document Type:** Clause document — referenced in M7.7 Offer v2.0 production and M7.8 Offer Architecture Document attestation
**Length:** 1 page

---

## Statement

In producing Offer v2.0 and any subsequent structural revisions to my offer, I commit to the following discipline:

**1. v2.0 is architectural, not directional.** A v2.0 release introduces structural commitments to the offer's deliverable decomposition, fulfillment SOPs, lifecycle stages, and capacity ceiling. A v2.0 release does not change the underlying mechanism, the customer the offer serves, or the problem the offer solves. Changes to mechanism, customer, or problem are pivots and require a separate operator-level decision, not a v2.0 release.

**2. v2.0 derives from v1.x learning.** The v2.0 offer is the structural articulation of what v1.x customer cohorts revealed: which deliverables are atomic, which SOPs are operable, which lifecycle stages have which gates, and what concurrency the operator can honestly sustain. The v2.0 offer does not introduce new structures absent from v1.x evidence.

**3. v2.0 names what is not changing.** The Offer v2.0 document explicitly states: the mechanism is the same, the customer is the same, the problem is the same. This naming is a discipline, not a formality — it forces the operator to confirm that what changed is the architecture, not the offer's identity.

**4. v2.0 is bounded.** The v2.0 release introduces architectural commitments. It does not introduce additional features, scope expansions, or "while we're at it" additions that did not surface from v1.x learning. Feature additions outside v1.x signal go to a future v2.x cycle or to a Stage-3 product extension, not to v2.0.

**5. v2.0 anti-promises are explicit.** The Offer v2.0 document includes a section that names what the offer will not do, what outcomes the offer will not guarantee, and what scope the offer explicitly defers. The anti-promise list is at least as long as the deliverable list and is written before the deliverable list is finalized.

**6. v2.0 is not a re-pitch.** The v2.0 release does not revise the offer's positioning, brand language, or marketing claims. Positioning revision is a separate operator activity, distinct from architecture, and is not bundled into a v2.0 release.

**7. Pivots are named as pivots.** If, in the course of v2.0 work, I conclude that the offer's mechanism, customer, or problem must change, I do not encode that change as a v2.0 release. I name it as a pivot, freeze v2.0 work, and conduct the pivot decision as a Stage-1 review (returning to C2 customer definition or C5 mechanism articulation as needed). The pivot may produce a future v1.0 of a new offer; it does not produce a v2.0 of the current offer.

**8. v2.0 is gated by HITL.** The v2.0 offer document and Offer Architecture Document receive mandatory HITL review by my instructor at M7.7 and Opus 4.7 validator review followed by instructor co-sign at M7.8. I do not deploy v2.0 to customers until both gates clear.

**9. v2.0 is reversible at the architectural level.** If v2.0 architecture proves untenable in operation, I revert to the v1.x architecture for active customers and reopen v2.0 work with the new evidence. I do not strand v1.x customers in a v2.0 architecture they did not enroll under.

**10. Discipline endures.** This discipline applies through C7 and into all subsequent structural-revision work. v3.0, v4.0, and onward each follow the same architecture-not-pivot, bounded, anti-promise-explicit, HITL-gated discipline.

---

## Signature

I have read this clause and commit to its terms in all v2.0 production and subsequent structural-revision work undertaken during and after C7.

**Signature:** ___________________________
**Date:** ___________________________

---

*This document is referenced at M7.7 Offer v2.0 production and M7.8 attestation Clause 4. A signed copy is filed with your Offer Architecture Document.*

Native Google Doc text and original links

M7.7 — Offer v2.0 Production
Module Outcome: [Create] Student has produced offer v2.0 with explicit structural commitments derived from M7.2-M7.6 work, preserved v1.0 and v1.1 archives, documented the v1.x → v2.0 rationale, named explicit deferred-to-Stage-3 commitments, and signed the Architecture-vs-Pivot Distinction Clause attesting that v2.0 is structural commitment, not pivot. v2.0 is the offer document refreshed with architectural reality; it is not a redesigned offer. Key Deliverable: Offer Document v2.0 (Offer-Document-v2.0-[YourName]-[Date].md) with v1.0 and v1.1 archives preserved alongside; major-version rationale documented; Architecture-vs-Pivot Clause signed Infrastructure Dependency: Build 6, Build 8 Drive folder for C7, Supabase c7_offer_v2 table, Claude prompt offer-v2-reviewer-v1.0.0.yaml (Sonnet), Architecture-vs-Pivot Clause template Checkpoint / Test: Type 1 Artifact + Type 2 AI rubric — AI rubric ≥ 7/10 on architectural commitment integration, mechanism preservation, and anti-promise discipline Blocked-Until Prerequisite: M7.5+M7.6 instructor HITL returned APPROVED or APPROVED-WITH-NOTES


What This Module Does
M7.7 produces v2.0. The v2.0 designation is structurally significant: this is not a v1.2 (continued iteration of v1.1) but a major version that commits to the architectural reality discovered through M7.2-M7.6. The major-version bump signals that the offer document now carries explicit structural commitments around fulfillment, capacity, and lifecycle that v1.0 and v1.1 carried implicitly (or not at all).

Three things happen in M7.7:

You draft v2.0 by extending v1.1 with the architectural commitments from M7.2-M7.6: the corrected hours-per-customer figure, the named concurrent-customer ceiling, the explicit fulfillment SOP references where applicable, the explicit lifecycle stage references where applicable, and the updated anti-promises specifically naming deferred-to-Stage-3 commitments.

You document the v1.x → v2.0 rationale: what specific evidence from M7.2-M7.6 justified the major version bump rather than continued v1.x iteration. The rationale is a structural feature of the v2.0 document, recorded in a dedicated section.

You sign the Architecture-vs-Pivot Distinction Clause attesting that v2.0 is structural commitment around the same offer, not a pivot to a different offer.

You also archive v1.0 and v1.1 alongside v2.0 in Drive. The lineage from v1.0 forward is auditable through three versions.

M7.7 is 360 minutes of active work. The hours are concentrated in the v2.0 drafting (3-4 hours), the rationale documentation (1 hour), and the clause review and signing (1 hour).


Why v2.0 Production Matters
Stage 2 has produced two offer document versions before C7: v1.0 from C4 M4.8 (the original sellable artifact) and v1.1 from C6 M6.5 (the iterated version with first-customer signal incorporated). Both versions describe the offer's external face — what is sold, to whom, at what price, with what guarantee. Neither version specifies the operator-side reality of delivery: how many concurrent customers, what hours-per-customer, what lifecycle gates, what fulfillment procedures.

v2.0 is where that gap closes. The offer document, in v2.0, is no longer an interface specification; it is an interface specification plus a partial structural specification. Customers reading v2.0 see not just what they will receive but also what the operator commits to as the operating shape of the engagement. Operators referencing v2.0 see the same commitments they reference internally; the document no longer carries silent assumptions about operator capacity that the architecture has now made explicit.

The v2.0 production is also where the Architecture-vs-Pivot guardrail is tested most rigorously. The temptation to smuggle a pivot inside v2.0 work is, almost without exception, the temptation to escape the discomfort of architectural work — which is genuinely unglamorous — by doing the more interesting work of redesigning the offer. The Architecture-vs-Pivot Distinction Clause exists specifically to surface this temptation; operators who proceed through v2.0 with a pivot smuggled inside produce an Offer Architecture Document that the Opus validator at M7.8 flags as having "fundamental inconsistency between v1.1 baseline and v2.0 commitments."


What Stays the Same in v2.0
The Iteration Without Drift doctrine from C6 governs C7 with continued force. v2.0 is structural commitment around the same offer; the offer's substance is preserved.

Preserved verbatim from v1.1:

The named territory (C1 Captain's Oath Clause 1)
The named mechanism (C2 M2.7 Hypothesis, C3 M3.7 Primary Selection)
The named operator identity (C1 archetype, including the operator's voice and presence)
The four-pillar mechanism structure (C2 M2.4)
The Anti-Promise Statement (C4 M4.5 — preserved verbatim with possible additions but no removals)
The Pricing Decision (C4 M4.4 — pricing changes are C8 work, not C7; v2.0 maintains v1.1 pricing)
The audience specification (C3 audience research, C4 M4.1 audience clause)

Preserved with refinement:

The Guarantee Architecture (C4 M4.6) — refined with architectural specificity (e.g., what exactly is guaranteed at each lifecycle stage gate) but not weakened
The deliverables list — preserved at the level of named deliverables (Phase 1, Phase 2, Phase 3) but augmented with the M7.2 atomic decomposition references where useful for customer transparency

If v2.0 work requires changes to items in the "preserved verbatim" list — different mechanism, different territory, different identity, different anti-promise — the operator is in pivot territory, not architecture territory. Pivots require the Captain's Retreat decision process (C9), not v2.0 module work. The Architecture-vs-Pivot Distinction Clause catches this; the operator routes to Captain's Retreat instead of continuing C7.


What Changes Structurally in v2.0
v2.0 adds explicit structural commitments that v1.1 did not carry. The additions are:
Addition 1 — Corrected hours-per-customer figure (from M7.6)
v1.1 carried implicit or partial hours estimates ("approximately 50-60 hours of operator time across the 12-week engagement" or no explicit hours statement at all). v2.0 carries the M7.6 measured figure: "approximately 85 hours of operator time across the 12-week engagement, distributed across direct customer-facing time, deliverable production, and supporting work."

The hours figure is filed in v2.0 not for marketing but for operational transparency. Customers reading v2.0 see what the operator commits as the engagement's time shape. Future C8 pricing iteration will adjust pricing against this measured number.
Addition 2 — Named concurrent-customer ceiling (from M7.5)
v1.1 carried no explicit concurrent-customer commitment. v2.0 carries the explicit ceiling: "I currently work with up to 4 concurrent illustrator clients on this Sprint to ensure each receives the dedicated attention specified in this offer."

The ceiling commitment is customer-facing: prospects evaluating the offer see that there is finite availability and understand that enrollment is governed by the operator's explicit capacity commitment.
Addition 3 — Explicit fulfillment SOP references where applicable (from M7.3)
For the 1-2 highest-leverage SOPs (the first delivery moment, the mid-engagement check-in, the completion debrief), v2.0 references the structural shape of the SOP without revealing internal procedures. For example:

"Each engagement includes a structured mid-engagement review at Week 6 to assess trajectory, name any scope considerations, and confirm the engagement's continued direction. The review is a documented procedure, ensuring consistent attention regardless of which engagement number you are."

The reference is customer-facing transparency, not internal SOP exposure.
Addition 4 — Explicit lifecycle stage references where applicable (from M7.4)
v2.0 names the lifecycle structure: pre-sale, enrollment, onboarding, delivery, mid-engagement check-in, completion debrief, post-engagement. The structure may already be implicit in v1.1's deliverables description; v2.0 makes the gates explicit:

"After the 12-week engagement completes, you have 60 days of direct follow-up access for clarifying questions and continued navigation. After this 60-day period, you transition to alumni community access for ongoing peer engagement and future offer awareness."

The post-engagement commitment is often the most consequential addition; v1.0 and v1.1 typically left this implicit.
Addition 5 — Updated anti-promises (specifically deferred-to-Stage-3 commitments)
v1.1's Anti-Promise Statement is preserved verbatim. v2.0 adds new anti-promises specifically naming what v2.0 explicitly does NOT promise:

"v2.0 explicitly does NOT promise: team-delivered scaling beyond the operator's named concurrent-customer ceiling (this is Stage 3 work in the RISER Nation curriculum); guaranteed customer outcomes that depend on customer-side execution (the offer commits to operator-side deliverables and methodology, not customer-side results); refund or rescheduling beyond the explicit guarantee structure stated above; integration with team or sub-contractor delivery (each engagement is delivered by the named operator)."

The deferred-to-Stage-3 commitments are particularly important because they prevent customer expectations that the architecture cannot meet. An operator who sells v2.0 with a customer expectation of "if you grow, you can scale me up" is selling against an architectural reality that does not yet exist; the customer's eventual experience will be misalignment with the offer's structural shape.


The v1.x → v2.0 Rationale
v2.0 includes a dedicated section documenting the rationale for the major-version bump. The rationale is structural, not promotional; it reads like an audit document, not marketing copy.

The standard structure:

Section 1 — What evidence from C7 work justified v2.0

Specific items from M7.2-M7.6 that produced material changes in the offer's commitments:

M7.2 decomposition surfaced X implicit deliverables that v1.1 did not name (e.g., communication SLA, post-engagement transition)
M7.3 SOP construction produced operating procedures that v2.0 commits to as the consistent shape across customers
M7.4 lifecycle map made gate transitions explicit, replacing v1.1's implicit "customer advances when ready"
M7.5 capacity analysis identified concurrent-customer ceiling at N
M7.6 bandwidth audit identified hours-per-customer at H, +X% above v1.1's implicit estimate

Section 2 — Why this is structural commitment rather than continued iteration

The argument that the changes warrant a major-version bump:

v1.0 → v1.1 was iteration of the offer's interface (refined deliverables description, refined Phase 2 structure based on first-customer signal)
v1.1 → v2.0 is structural commitment of the offer's operational shape (explicit hours, explicit capacity, explicit lifecycle gates)
The change crosses the document/architecture distinction (M7.1) — v1.1 was still primarily a sellable artifact; v2.0 is now also a partial operational specification
Future v2.x iterations may refine v2.0's commitments based on additional customer experience, but v2.0 represents the structural commitment that v2.x iterations are anchored against

Section 3 — What v2.0 does NOT change (preservation list)

Explicit list of preserved-verbatim elements: territory, mechanism, identity, anti-promise (with additions), pricing, audience. The list reads as an attestation: I have not pivoted; I have architected.

Section 4 — What is deferred to v2.x or v3.0

Some operators surface architectural ambitions during M7.2-M7.6 that v2.0 does not yet absorb (e.g., a future cohort variant, a future async-delivery format, a future team-delivered scaling). These are named in the rationale section as explicitly deferred:

"v2.x or v3.0 may incorporate: a half-engagement variant for established illustrators with existing portfolios (deferred pending pricing iteration in C8); a cohort delivery mode for groups of illustrators (deferred pending team-delivery infrastructure in Stage 3)."

The deferral language is structural discipline. It acknowledges aspirations without smuggling them into v2.0 as unsupported commitments.


The Architecture-vs-Pivot Distinction Clause
Before v2.0 is filed, the operator signs the Architecture-vs-Pivot Distinction Clause in 02_Resources/Templates/C7-Architecture-vs-Pivot-Clause.md. The clause attests:

I, [operator name], attest that v2.0 is structural commitment around the same offer that was sold at v1.0 and iterated at v1.1. The named territory, named mechanism, named operator identity, four-pillar mechanism structure, Anti-Promise Statement, Pricing Decision, and audience specification are preserved verbatim from v1.1 in v2.0. Changes between v1.1 and v2.0 are limited to: corrected operator-hours figure, named concurrent-customer ceiling, explicit fulfillment SOP references, explicit lifecycle stage references, and additions to the Anti-Promise Statement specifically naming deferred-to-Stage-3 commitments. I acknowledge that any change to the preserved-verbatim list would constitute a pivot rather than architectural commitment, and that pivots require the Captain's Retreat decision process (C9), not v2.0 module work. I have run the v1.1 → v2.0 diff against this preservation list and confirmed that v2.0 changes do not cross the architecture-pivot threshold.

The clause is signed digitally and filed in Supabase c7_offer_v2.architecture_pivot_clause_signed_at. Without the clause, v2.0 cannot be filed.

The clause is not legally binding but is structurally consequential. Operators who sign the clause and then proceed with smuggled pivots produce v2.0 that the Opus validator flags; the validator's findings reference the clause directly when noting inconsistency.


Worked Example: Maya's v2.0
Maya's v1.1 had been the iterated Portfolio-to-Licensing Sprint — a 12-week structured engagement at $4,500 with three phases.

Her v2.0 preserved:

Territory: senior illustrators ($60K+ income, 5+ years professional)
Mechanism: structured opportunity identification through portfolio analysis and licensing conversation framework
Identity: Teacher-Operator with consultative approach
Anti-Promise: no guarantee of specific licensing deals closed; methodology produces opportunities, customer-side execution closes them
Pricing: $4,500 (preserved at v1.1; C8 will iterate)
Audience: senior illustrators evaluating expansion of revenue streams beyond commission work

Her v2.0 added:

Hours commitment: "Approximately 85 hours of operator-time across the 12-week engagement, distributed as ~5.5 hours per week during Weeks 1-4 (Phase 1 onboarding) and ~4 hours per week during Weeks 5-12 (Phase 2-3 delivery), with additional time for the Week 6 mid-engagement check-in and the Week 12 completion debrief."
Concurrent ceiling commitment: "I currently work with up to 4 concurrent illustrator clients on this Sprint to ensure each receives the dedicated attention specified in this offer."
Communication SLA commitment: "Email and async-channel responsiveness: within 1 business day for routine inquiries; same-day response for time-sensitive engagement decisions."
Mid-engagement check-in commitment: "Each engagement includes a structured mid-engagement review at Week 6 to assess trajectory, surface any scope considerations, and confirm continued direction."
Post-engagement structure: "After the 12-week engagement completes, you have 60 days of direct follow-up access. After this period, you transition to alumni community access (currently a private Slack channel)."
Updated anti-promises:
"v2.0 does not promise: team-delivered scaling beyond my named concurrent-customer ceiling (this is Stage 3 work in my own development); explicit licensing deal closure (the methodology produces opportunities; customer-side execution closes deals); ad-hoc consultations beyond the 2 named slots in Phase 3; integration with sub-contractors or assistants."
"Specifically: I will not absorb additional scope without an explicit re-scoping conversation; scope expansion is welcome and is treated as a separate engagement opportunity, not as silent absorption into the current engagement."

Her v1.x → v2.0 rationale section documented:

M7.2 surfaced 8 implicit deliverables (post-engagement structure, communication SLA, mid-engagement check-in formality, scope-creep recovery procedures, etc.)
M7.3 SOPs converted these implicit items into explicit operating procedures
M7.5 capacity analysis identified ceiling at 4 concurrent (down from her aspirational projection of 7-8)
M7.6 audit identified hours at 85 (up from C4's 50 estimate, +70%)
The v1.1 → v2.0 distinction is the document/architecture line: v1.1 was sellable; v2.0 is sellable + operationally specified

Her Architecture-vs-Pivot Clause was signed; v2.0 was filed; v1.0 and v1.1 archives were preserved alongside.


Worked Example: Darius's v2.0
Darius's v1.1 was the iterated Reading Club — a 6-week cohort for builder-engineers at $1,200 per enrollee.

His v2.0 preserved all the items in the standard preservation list. His v2.0 additions:

Hours commitment per enrollee: "Approximately 13 hours of operator-time per enrollee at typical cohort size (8-12 enrollees), with smaller cohorts running ~16-18 hours per enrollee due to fixed cohort-shared costs amortizing across fewer enrollees."
Cohort size commitment: "Each Reading Club cohort runs with 4-12 enrollees. Cohorts at the lower end of the range (3-4 enrollees) operate in 'Solo Mode' with structural adjustments documented in the Solo Mode addendum."
Concurrent cohort ceiling: "I run up to 2 concurrent cohorts (sequenced 4-6 weeks apart), with maximum ~24 active enrollees at peak overlap."
Cohort-shared vs. individual deliverable distinction: explicitly documented as part of the offer's structure.
Solo Mode addendum: a separate document specifying the 6 variant SOPs that activate at minimum-viable cohort enrollment.

His v1.x → v2.0 rationale particularly emphasized the Solo Mode addition as a structural innovation that v1.0/v1.1 had not specified — a recognition that under-cohort scenarios require dedicated architecture rather than ad-hoc adjustment.

His Architecture-vs-Pivot Clause was signed; v2.0 was filed; the Solo Mode addendum was filed alongside as a v2.0 supporting artifact.


Worked Example: Priya's v2.0
Priya's v1.1 was the iterated Fractional CFO offer — a multi-month retainer for early-stage startups at $5,500/month.

Her v2.0 was the most architecturally complex of the three because the offer is open-ended (no fixed engagement duration). Her v2.0 additions included:

Hours commitment per month: "Approximately 22-28 hours of operator-time per customer per month, varying by engagement phase (higher in onboarding months and quarterly board-prep months; lower in steady-state months)."
Concurrent customer ceiling: "I currently work with up to 5 concurrent fractional CFO retainer customers."
Quarterly check-in commitment: "Each engagement includes a structured quarterly check-in at 90-day intervals throughout the engagement."
Engagement closure structure: "Engagements continue month-to-month with mutual continuation. Either party may close the engagement with 30 days notice. The closure month includes a structured handoff and (if applicable) an introduction to the next-stage CFO role."
Series B Readiness Track addition: a sub-track within the offer for customers approaching Series B fundraising (a structural accommodation for the customer cohort she had identified through C6 work).

Priya had wrestled with whether the Series B Readiness Track was a v2.0 addition or a pivot. The Architecture-vs-Pivot Clause discipline forced the question. Her resolution: the track is an explicit named extension of the existing fractional CFO offer (same mechanism, same identity, same audience subset); the structural addition is the named track within the existing offer rather than a separate offer. Her v2.0 documents the track's structure; her cohort instructor co-signed her interpretation; her Architecture-vs-Pivot Clause was signed.

She had also considered an alternative path — narrowing the offer to focus only on Series A → Series B startups (excluding earlier-stage customers) — but recognized this as a pivot rather than v2.0 work and deferred the question to her next Captain's Retreat.


Common v2.0 Production Errors
Error 1 — Marketing rewrite. Operator rewrites v1.1's marketing copy with refreshed phrasing. The rewrite reads better but adds no architectural commitments. v2.0 produced this way is structurally indistinguishable from v1.2. Recovery: re-anchor on the M7.2-M7.6 outputs; v2.0's purpose is to integrate architectural commitments, not refresh prose.

Error 2 — Pivot smuggle. Operator includes substantive offer changes (different mechanism, different territory, different audience) under cover of "v2.0 architectural work." The Architecture-vs-Pivot Clause catches this; the cohort instructor catches this; the Opus validator catches this. Recovery: route the pivot question to Captain's Retreat; restore preserved-verbatim items; complete v2.0 as architecture-only.

Error 3 — Over-commitment. Operator specifies hours-per-customer or concurrent ceiling at aspirational rather than measured numbers. The Honest Capacity Clause was signed at M7.5; v2.0 must reference the same numbers. Recovery: re-anchor commitments on measured M7.6 data; revise downward.

Error 4 — Anti-promise softening. Operator weakens the Anti-Promise Statement when extending it. v1.1's anti-promises are preserved verbatim with additions only — no removals or softening. Recovery: restore v1.1's anti-promise verbatim; add new anti-promises only.

Error 5 — SOP overexposure. Operator includes excessive internal SOP detail in customer-facing v2.0 language. The customer does not need to read the SOP library; the customer needs to see the structural shape. Recovery: reference SOPs at the structural level, not the procedural level.

Error 6 — Rationale promotion. Operator's v1.x → v2.0 rationale section reads like marketing copy ("we've made amazing improvements"). The rationale is structural attestation, not promotional. Recovery: rewrite as audit-document language.


Checkpoint 7.7
Your deliverable is:

Offer Document v2.0 filed in Drive
v1.0 and v1.1 archives preserved alongside (Offer-Document-v1.0-archived.md, Offer-Document-v1.1-archived.md)
v1.x → v2.0 rationale section within v2.0 (or as separate document, depending on operator preference)
Architecture-vs-Pivot Distinction Clause signed and filed in Supabase
Cohort review completed (2-3 cohort peers reviewing for pivot-smuggle indicators)

The AI rubric scoring v2.0 looks for six properties:

Preserved-verbatim list intact (territory, mechanism, identity, four-pillar structure, Anti-Promise verbatim, Pricing, audience)
Architectural additions present (hours commitment, concurrent ceiling, communication SLA, mid-engagement check-in, post-engagement structure, updated anti-promises)
v1.x → v2.0 rationale documented as audit attestation rather than marketing
No pivot indicators (mechanism unchanged, territory unchanged, audience unchanged)
Capacity numbers match M7.5 analysis (concurrent ceiling identical)
Hours numbers match M7.6 audit (corrected hours per customer identical)

Target score: ≥ 7/10.


What M7.8 Expects From You
M7.8 capstone synthesis cross-references v2.0 with all six prior C7 deliverables. v2.0 is the explicit version statement; the M7.8 Offer Architecture Document synthesizes v2.0 with M7.1-M7.6 into the C7 capstone. Without v2.0, the capstone has no version anchor; the Opus validator will reject capstone documents that lack v2.0.

File v2.0. Archive v1.0 and v1.1. Sign the clause. Submit to AI rubric. Proceed to M7.8.



Last updated: April 25, 2026 · Version 2.0

M7.7-Written-Lesson.md

Use v2.0 to make delivery commitments explicit

Preserve the seven baseline commitments

Add the structural commitment — Measured hours

Use the actual bandwidth audit and define whether the figure includes production, customer-facing work, coordination and follow-up.

Add the structural commitment — Concurrent-customer ceiling

State the supported number and why it protects delivery. Keep availability claims consistent with the real enrollment process.

Add the structural commitment — Procedure shape

Explain the customer-visible structure of first delivery, check-ins or debriefs without exposing unnecessary internal instructions.

Add the structural commitment — Lifecycle and gates

Name pre-sale, enrollment, onboarding, delivery, mid-engagement, completion and post-engagement transitions, with their entry/exit conditions.

Add the structural commitment — Deferred commitments

Explicitly separate current delivery from future team scale, variants, integrations or outcomes outside the operator’s control; do not sell plans as existing capability.

Document the four-part version rationale

Use the clause as an evidence-backed attestation

Reconcile Maya’s numbers and identity

Keep Maya’s scope and deferred promises clear

Resolve Darius’s enrollment boundary

Use Priya’s example to test the pivot boundary

Avoid marketing rewrite

Add measured operating commitments rather than refreshing wording alone.

Avoid hidden pivot

Identify substantive changes and route them to the appropriate business review instead of labeling them architecture.

Avoid overcommitment

Reconcile hours and concurrency with the measured source; do not automatically promise a lower number without analysis.

Avoid weakened exclusions

Preserve the baseline limitations and make additions explicit.

Avoid excessive internal detail

Show the customer the relevant service structure and keep internal procedures accessible to the delivery team.

Avoid promotional rationale

Explain evidence and decisions plainly rather than claiming amazing improvements.

File a traceable version and hand off to synthesis

Connect the lesson to the direct-marketing promise

Complete original source text

# M7.7 — Offer v2.0 Production

**Module Outcome:** [Create] Student has produced offer v2.0 with explicit structural commitments derived from M7.2-M7.6 work, preserved v1.0 and v1.1 archives, documented the v1.x → v2.0 rationale, named explicit deferred-to-Stage-3 commitments, and signed the Architecture-vs-Pivot Distinction Clause attesting that v2.0 is structural commitment, not pivot. v2.0 is the offer document refreshed with architectural reality; it is not a redesigned offer.
**Key Deliverable:** Offer Document v2.0 (`Offer-Document-v2.0-[YourName]-[Date].md`) with v1.0 and v1.1 archives preserved alongside; major-version rationale documented; Architecture-vs-Pivot Clause signed
**Infrastructure Dependency:** Build 6, Build 8 Drive folder for C7, Supabase `c7_offer_v2` table, Claude prompt `offer-v2-reviewer-v1.0.0.yaml` (Sonnet), Architecture-vs-Pivot Clause template
**Checkpoint / Test:** Type 1 Artifact + Type 2 AI rubric — AI rubric ≥ 7/10 on architectural commitment integration, mechanism preservation, and anti-promise discipline
**Blocked-Until Prerequisite:** M7.5+M7.6 instructor HITL returned APPROVED or APPROVED-WITH-NOTES

---

## What This Module Does

M7.7 produces v2.0. The v2.0 designation is structurally significant: this is not a v1.2 (continued iteration of v1.1) but a major version that commits to the architectural reality discovered through M7.2-M7.6. The major-version bump signals that the offer document now carries explicit structural commitments around fulfillment, capacity, and lifecycle that v1.0 and v1.1 carried implicitly (or not at all).

Three things happen in M7.7:

1. You **draft v2.0** by extending v1.1 with the architectural commitments from M7.2-M7.6: the corrected hours-per-customer figure, the named concurrent-customer ceiling, the explicit fulfillment SOP references where applicable, the explicit lifecycle stage references where applicable, and the updated anti-promises specifically naming deferred-to-Stage-3 commitments.

2. You **document the v1.x → v2.0 rationale**: what specific evidence from M7.2-M7.6 justified the major version bump rather than continued v1.x iteration. The rationale is a structural feature of the v2.0 document, recorded in a dedicated section.

3. You **sign the Architecture-vs-Pivot Distinction Clause** attesting that v2.0 is structural commitment around the same offer, not a pivot to a different offer.

You also **archive v1.0 and v1.1** alongside v2.0 in Drive. The lineage from v1.0 forward is auditable through three versions.

M7.7 is 360 minutes of active work. The hours are concentrated in the v2.0 drafting (3-4 hours), the rationale documentation (1 hour), and the clause review and signing (1 hour).

---

## Why v2.0 Production Matters

Stage 2 has produced two offer document versions before C7: v1.0 from C4 M4.8 (the original sellable artifact) and v1.1 from C6 M6.5 (the iterated version with first-customer signal incorporated). Both versions describe the offer's external face — what is sold, to whom, at what price, with what guarantee. Neither version specifies the operator-side reality of delivery: how many concurrent customers, what hours-per-customer, what lifecycle gates, what fulfillment procedures.

v2.0 is where that gap closes. The offer document, in v2.0, is no longer an interface specification; it is an interface specification *plus* a partial structural specification. Customers reading v2.0 see not just what they will receive but also what the operator commits to as the operating shape of the engagement. Operators referencing v2.0 see the same commitments they reference internally; the document no longer carries silent assumptions about operator capacity that the architecture has now made explicit.

The v2.0 production is also where the Architecture-vs-Pivot guardrail is tested most rigorously. The temptation to smuggle a pivot inside v2.0 work is, almost without exception, the temptation to escape the discomfort of architectural work — which is genuinely unglamorous — by doing the more interesting work of redesigning the offer. The Architecture-vs-Pivot Distinction Clause exists specifically to surface this temptation; operators who proceed through v2.0 with a pivot smuggled inside produce an Offer Architecture Document that the Opus validator at M7.8 flags as having "fundamental inconsistency between v1.1 baseline and v2.0 commitments."

---

## What Stays the Same in v2.0

The Iteration Without Drift doctrine from C6 governs C7 with continued force. v2.0 is structural commitment around the same offer; the offer's substance is preserved.

**Preserved verbatim from v1.1:**

- **The named territory** (C1 Captain's Oath Clause 1)
- **The named mechanism** (C2 M2.7 Hypothesis, C3 M3.7 Primary Selection)
- **The named operator identity** (C1 archetype, including the operator's voice and presence)
- **The four-pillar mechanism structure** (C2 M2.4)
- **The Anti-Promise Statement** (C4 M4.5 — preserved verbatim with possible additions but no removals)
- **The Pricing Decision** (C4 M4.4 — pricing changes are C8 work, not C7; v2.0 maintains v1.1 pricing)
- **The audience specification** (C3 audience research, C4 M4.1 audience clause)

**Preserved with refinement:**

- **The Guarantee Architecture** (C4 M4.6) — refined with architectural specificity (e.g., what exactly is guaranteed at each lifecycle stage gate) but not weakened
- **The deliverables list** — preserved at the level of named deliverables (Phase 1, Phase 2, Phase 3) but augmented with the M7.2 atomic decomposition references where useful for customer transparency

If v2.0 work requires changes to items in the "preserved verbatim" list — different mechanism, different territory, different identity, different anti-promise — the operator is in pivot territory, not architecture territory. Pivots require the Captain's Retreat decision process (C9), not v2.0 module work. The Architecture-vs-Pivot Distinction Clause catches this; the operator routes to Captain's Retreat instead of continuing C7.

---

## What Changes Structurally in v2.0

v2.0 adds explicit structural commitments that v1.1 did not carry. The additions are:

### Addition 1 — Corrected hours-per-customer figure (from M7.6)

v1.1 carried implicit or partial hours estimates ("approximately 50-60 hours of operator time across the 12-week engagement" or no explicit hours statement at all). v2.0 carries the M7.6 measured figure: "approximately 85 hours of operator time across the 12-week engagement, distributed across direct customer-facing time, deliverable production, and supporting work."

The hours figure is filed in v2.0 not for marketing but for operational transparency. Customers reading v2.0 see what the operator commits as the engagement's time shape. Future C8 pricing iteration will adjust pricing against this measured number.

### Addition 2 — Named concurrent-customer ceiling (from M7.5)

v1.1 carried no explicit concurrent-customer commitment. v2.0 carries the explicit ceiling: "I currently work with up to 4 concurrent illustrator clients on this Sprint to ensure each receives the dedicated attention specified in this offer."

The ceiling commitment is customer-facing: prospects evaluating the offer see that there is finite availability and understand that enrollment is governed by the operator's explicit capacity commitment.

### Addition 3 — Explicit fulfillment SOP references where applicable (from M7.3)

For the 1-2 highest-leverage SOPs (the first delivery moment, the mid-engagement check-in, the completion debrief), v2.0 references the structural shape of the SOP without revealing internal procedures. For example:

> *"Each engagement includes a structured mid-engagement review at Week 6 to assess trajectory, name any scope considerations, and confirm the engagement's continued direction. The review is a documented procedure, ensuring consistent attention regardless of which engagement number you are."*

The reference is customer-facing transparency, not internal SOP exposure.

### Addition 4 — Explicit lifecycle stage references where applicable (from M7.4)

v2.0 names the lifecycle structure: pre-sale, enrollment, onboarding, delivery, mid-engagement check-in, completion debrief, post-engagement. The structure may already be implicit in v1.1's deliverables description; v2.0 makes the gates explicit:

> *"After the 12-week engagement completes, you have 60 days of direct follow-up access for clarifying questions and continued navigation. After this 60-day period, you transition to alumni community access for ongoing peer engagement and future offer awareness."*

The post-engagement commitment is often the most consequential addition; v1.0 and v1.1 typically left this implicit.

### Addition 5 — Updated anti-promises (specifically deferred-to-Stage-3 commitments)

v1.1's Anti-Promise Statement is preserved verbatim. v2.0 adds new anti-promises specifically naming what v2.0 explicitly does NOT promise:

> *"v2.0 explicitly does NOT promise: team-delivered scaling beyond the operator's named concurrent-customer ceiling (this is Stage 3 work in the RISER Nation curriculum); guaranteed customer outcomes that depend on customer-side execution (the offer commits to operator-side deliverables and methodology, not customer-side results); refund or rescheduling beyond the explicit guarantee structure stated above; integration with team or sub-contractor delivery (each engagement is delivered by the named operator)."*

The deferred-to-Stage-3 commitments are particularly important because they prevent customer expectations that the architecture cannot meet. An operator who sells v2.0 with a customer expectation of "if you grow, you can scale me up" is selling against an architectural reality that does not yet exist; the customer's eventual experience will be misalignment with the offer's structural shape.

---

## The v1.x → v2.0 Rationale

v2.0 includes a dedicated section documenting the rationale for the major-version bump. The rationale is structural, not promotional; it reads like an audit document, not marketing copy.

The standard structure:

**Section 1 — What evidence from C7 work justified v2.0**

Specific items from M7.2-M7.6 that produced material changes in the offer's commitments:

- M7.2 decomposition surfaced X implicit deliverables that v1.1 did not name (e.g., communication SLA, post-engagement transition)
- M7.3 SOP construction produced operating procedures that v2.0 commits to as the consistent shape across customers
- M7.4 lifecycle map made gate transitions explicit, replacing v1.1's implicit "customer advances when ready"
- M7.5 capacity analysis identified concurrent-customer ceiling at N
- M7.6 bandwidth audit identified hours-per-customer at H, +X% above v1.1's implicit estimate

**Section 2 — Why this is structural commitment rather than continued iteration**

The argument that the changes warrant a major-version bump:

- v1.0 → v1.1 was iteration of the offer's interface (refined deliverables description, refined Phase 2 structure based on first-customer signal)
- v1.1 → v2.0 is structural commitment of the offer's operational shape (explicit hours, explicit capacity, explicit lifecycle gates)
- The change crosses the document/architecture distinction (M7.1) — v1.1 was still primarily a sellable artifact; v2.0 is now also a partial operational specification
- Future v2.x iterations may refine v2.0's commitments based on additional customer experience, but v2.0 represents the structural commitment that v2.x iterations are anchored against

**Section 3 — What v2.0 does NOT change (preservation list)**

Explicit list of preserved-verbatim elements: territory, mechanism, identity, anti-promise (with additions), pricing, audience. The list reads as an attestation: I have not pivoted; I have architected.

**Section 4 — What is deferred to v2.x or v3.0**

Some operators surface architectural ambitions during M7.2-M7.6 that v2.0 does not yet absorb (e.g., a future cohort variant, a future async-delivery format, a future team-delivered scaling). These are named in the rationale section as explicitly deferred:

> *"v2.x or v3.0 may incorporate: a half-engagement variant for established illustrators with existing portfolios (deferred pending pricing iteration in C8); a cohort delivery mode for groups of illustrators (deferred pending team-delivery infrastructure in Stage 3)."*

The deferral language is structural discipline. It acknowledges aspirations without smuggling them into v2.0 as unsupported commitments.

---

## The Architecture-vs-Pivot Distinction Clause

Before v2.0 is filed, the operator signs the Architecture-vs-Pivot Distinction Clause in `02_Resources/Templates/C7-Architecture-vs-Pivot-Clause.md`. The clause attests:

> *I, [operator name], attest that v2.0 is structural commitment around the same offer that was sold at v1.0 and iterated at v1.1. The named territory, named mechanism, named operator identity, four-pillar mechanism structure, Anti-Promise Statement, Pricing Decision, and audience specification are preserved verbatim from v1.1 in v2.0. Changes between v1.1 and v2.0 are limited to: corrected operator-hours figure, named concurrent-customer ceiling, explicit fulfillment SOP references, explicit lifecycle stage references, and additions to the Anti-Promise Statement specifically naming deferred-to-Stage-3 commitments. I acknowledge that any change to the preserved-verbatim list would constitute a pivot rather than architectural commitment, and that pivots require the Captain's Retreat decision process (C9), not v2.0 module work. I have run the v1.1 → v2.0 diff against this preservation list and confirmed that v2.0 changes do not cross the architecture-pivot threshold.*

The clause is signed digitally and filed in Supabase `c7_offer_v2.architecture_pivot_clause_signed_at`. Without the clause, v2.0 cannot be filed.

The clause is not legally binding but is structurally consequential. Operators who sign the clause and then proceed with smuggled pivots produce v2.0 that the Opus validator flags; the validator's findings reference the clause directly when noting inconsistency.

---

## Worked Example: Maya's v2.0

Maya's v1.1 had been the iterated Portfolio-to-Licensing Sprint — a 12-week structured engagement at $4,500 with three phases.

Her v2.0 preserved:
- Territory: senior illustrators ($60K+ income, 5+ years professional)
- Mechanism: structured opportunity identification through portfolio analysis and licensing conversation framework
- Identity: Teacher-Operator with consultative approach
- Anti-Promise: no guarantee of specific licensing deals closed; methodology produces opportunities, customer-side execution closes them
- Pricing: $4,500 (preserved at v1.1; C8 will iterate)
- Audience: senior illustrators evaluating expansion of revenue streams beyond commission work

Her v2.0 added:
- **Hours commitment**: "Approximately 85 hours of operator-time across the 12-week engagement, distributed as ~5.5 hours per week during Weeks 1-4 (Phase 1 onboarding) and ~4 hours per week during Weeks 5-12 (Phase 2-3 delivery), with additional time for the Week 6 mid-engagement check-in and the Week 12 completion debrief."
- **Concurrent ceiling commitment**: "I currently work with up to 4 concurrent illustrator clients on this Sprint to ensure each receives the dedicated attention specified in this offer."
- **Communication SLA commitment**: "Email and async-channel responsiveness: within 1 business day for routine inquiries; same-day response for time-sensitive engagement decisions."
- **Mid-engagement check-in commitment**: "Each engagement includes a structured mid-engagement review at Week 6 to assess trajectory, surface any scope considerations, and confirm continued direction."
- **Post-engagement structure**: "After the 12-week engagement completes, you have 60 days of direct follow-up access. After this period, you transition to alumni community access (currently a private Slack channel)."
- **Updated anti-promises**:
  - "v2.0 does not promise: team-delivered scaling beyond my named concurrent-customer ceiling (this is Stage 3 work in my own development); explicit licensing deal closure (the methodology produces opportunities; customer-side execution closes deals); ad-hoc consultations beyond the 2 named slots in Phase 3; integration with sub-contractors or assistants."
  - "Specifically: I will not absorb additional scope without an explicit re-scoping conversation; scope expansion is welcome and is treated as a separate engagement opportunity, not as silent absorption into the current engagement."

Her v1.x → v2.0 rationale section documented:
- M7.2 surfaced 8 implicit deliverables (post-engagement structure, communication SLA, mid-engagement check-in formality, scope-creep recovery procedures, etc.)
- M7.3 SOPs converted these implicit items into explicit operating procedures
- M7.5 capacity analysis identified ceiling at 4 concurrent (down from her aspirational projection of 7-8)
- M7.6 audit identified hours at 85 (up from C4's 50 estimate, +70%)
- The v1.1 → v2.0 distinction is the document/architecture line: v1.1 was sellable; v2.0 is sellable + operationally specified

Her Architecture-vs-Pivot Clause was signed; v2.0 was filed; v1.0 and v1.1 archives were preserved alongside.

---

## Worked Example: Darius's v2.0

Darius's v1.1 was the iterated Reading Club — a 6-week cohort for builder-engineers at $1,200 per enrollee.

His v2.0 preserved all the items in the standard preservation list. His v2.0 additions:

- **Hours commitment per enrollee**: "Approximately 13 hours of operator-time per enrollee at typical cohort size (8-12 enrollees), with smaller cohorts running ~16-18 hours per enrollee due to fixed cohort-shared costs amortizing across fewer enrollees."
- **Cohort size commitment**: "Each Reading Club cohort runs with 4-12 enrollees. Cohorts at the lower end of the range (3-4 enrollees) operate in 'Solo Mode' with structural adjustments documented in the Solo Mode addendum."
- **Concurrent cohort ceiling**: "I run up to 2 concurrent cohorts (sequenced 4-6 weeks apart), with maximum ~24 active enrollees at peak overlap."
- **Cohort-shared vs. individual deliverable distinction**: explicitly documented as part of the offer's structure.
- **Solo Mode addendum**: a separate document specifying the 6 variant SOPs that activate at minimum-viable cohort enrollment.

His v1.x → v2.0 rationale particularly emphasized the Solo Mode addition as a structural innovation that v1.0/v1.1 had not specified — a recognition that under-cohort scenarios require dedicated architecture rather than ad-hoc adjustment.

His Architecture-vs-Pivot Clause was signed; v2.0 was filed; the Solo Mode addendum was filed alongside as a v2.0 supporting artifact.

---

## Worked Example: Priya's v2.0

Priya's v1.1 was the iterated Fractional CFO offer — a multi-month retainer for early-stage startups at $5,500/month.

Her v2.0 was the most architecturally complex of the three because the offer is open-ended (no fixed engagement duration). Her v2.0 additions included:

- **Hours commitment per month**: "Approximately 22-28 hours of operator-time per customer per month, varying by engagement phase (higher in onboarding months and quarterly board-prep months; lower in steady-state months)."
- **Concurrent customer ceiling**: "I currently work with up to 5 concurrent fractional CFO retainer customers."
- **Quarterly check-in commitment**: "Each engagement includes a structured quarterly check-in at 90-day intervals throughout the engagement."
- **Engagement closure structure**: "Engagements continue month-to-month with mutual continuation. Either party may close the engagement with 30 days notice. The closure month includes a structured handoff and (if applicable) an introduction to the next-stage CFO role."
- **Series B Readiness Track addition**: a sub-track within the offer for customers approaching Series B fundraising (a structural accommodation for the customer cohort she had identified through C6 work).

Priya had wrestled with whether the Series B Readiness Track was a v2.0 addition or a pivot. The Architecture-vs-Pivot Clause discipline forced the question. Her resolution: the track is an explicit named extension of the existing fractional CFO offer (same mechanism, same identity, same audience subset); the structural addition is the named track within the existing offer rather than a separate offer. Her v2.0 documents the track's structure; her cohort instructor co-signed her interpretation; her Architecture-vs-Pivot Clause was signed.

She had also considered an alternative path — narrowing the offer to focus only on Series A → Series B startups (excluding earlier-stage customers) — but recognized this as a pivot rather than v2.0 work and deferred the question to her next Captain's Retreat.

---

## Common v2.0 Production Errors

**Error 1 — Marketing rewrite.** Operator rewrites v1.1's marketing copy with refreshed phrasing. The rewrite reads better but adds no architectural commitments. v2.0 produced this way is structurally indistinguishable from v1.2. Recovery: re-anchor on the M7.2-M7.6 outputs; v2.0's purpose is to integrate architectural commitments, not refresh prose.

**Error 2 — Pivot smuggle.** Operator includes substantive offer changes (different mechanism, different territory, different audience) under cover of "v2.0 architectural work." The Architecture-vs-Pivot Clause catches this; the cohort instructor catches this; the Opus validator catches this. Recovery: route the pivot question to Captain's Retreat; restore preserved-verbatim items; complete v2.0 as architecture-only.

**Error 3 — Over-commitment.** Operator specifies hours-per-customer or concurrent ceiling at aspirational rather than measured numbers. The Honest Capacity Clause was signed at M7.5; v2.0 must reference the same numbers. Recovery: re-anchor commitments on measured M7.6 data; revise downward.

**Error 4 — Anti-promise softening.** Operator weakens the Anti-Promise Statement when extending it. v1.1's anti-promises are preserved verbatim with additions only — no removals or softening. Recovery: restore v1.1's anti-promise verbatim; add new anti-promises only.

**Error 5 — SOP overexposure.** Operator includes excessive internal SOP detail in customer-facing v2.0 language. The customer does not need to read the SOP library; the customer needs to see the structural shape. Recovery: reference SOPs at the structural level, not the procedural level.

**Error 6 — Rationale promotion.** Operator's v1.x → v2.0 rationale section reads like marketing copy ("we've made amazing improvements"). The rationale is structural attestation, not promotional. Recovery: rewrite as audit-document language.

---

## Checkpoint 7.7

Your deliverable is:
1. **Offer Document v2.0** filed in Drive
2. **v1.0 and v1.1 archives** preserved alongside (`Offer-Document-v1.0-archived.md`, `Offer-Document-v1.1-archived.md`)
3. **v1.x → v2.0 rationale section** within v2.0 (or as separate document, depending on operator preference)
4. **Architecture-vs-Pivot Distinction Clause** signed and filed in Supabase
5. **Cohort review** completed (2-3 cohort peers reviewing for pivot-smuggle indicators)

The AI rubric scoring v2.0 looks for six properties:
- Preserved-verbatim list intact (territory, mechanism, identity, four-pillar structure, Anti-Promise verbatim, Pricing, audience)
- Architectural additions present (hours commitment, concurrent ceiling, communication SLA, mid-engagement check-in, post-engagement structure, updated anti-promises)
- v1.x → v2.0 rationale documented as audit attestation rather than marketing
- No pivot indicators (mechanism unchanged, territory unchanged, audience unchanged)
- Capacity numbers match M7.5 analysis (concurrent ceiling identical)
- Hours numbers match M7.6 audit (corrected hours per customer identical)

Target score: ≥ 7/10.

---

## What M7.8 Expects From You

M7.8 capstone synthesis cross-references v2.0 with all six prior C7 deliverables. v2.0 is the explicit version statement; the M7.8 Offer Architecture Document synthesizes v2.0 with M7.1-M7.6 into the C7 capstone. Without v2.0, the capstone has no version anchor; the Opus validator will reject capstone documents that lack v2.0.

File v2.0. Archive v1.0 and v1.1. Sign the clause. Submit to AI rubric. Proceed to M7.8.

---

*Last updated: April 25, 2026 · Version 2.0*

Complete supporting source — Offer v2 reviewer

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

Complete supporting source — Architecture versus pivot distinction clause

# C7 Architecture-vs-Pivot Distinction Clause

**Course:** C7 Offer Architecture
**Document Type:** Clause document — referenced in M7.7 Offer v2.0 production and M7.8 Offer Architecture Document attestation
**Length:** 1 page

---

## Statement

In producing Offer v2.0 and any subsequent structural revisions to my offer, I commit to the following discipline:

---

## Signature

I have read this clause and commit to its terms in all v2.0 production and subsequent structural-revision work undertaken during and after C7.

**Signature:** ___________________________
**Date:** ___________________________

---

*This document is referenced at M7.7 Offer v2.0 production and M7.8 attestation Clause 4. A signed copy is filed with your Offer Architecture Document.*

M8.4-Written-Lesson.md

Turn a pricing decision into an operating specification

Legacy M8.4 starts after the M8.3 reality-check document, a proposed 7/10 review and a 48-hour cooling period. It specifies how the selected branch—raise, narrow, stop or deliberately retain legacy terms—will operate. The source budgets eight active hours over three or four sittings, often 3+3+1+1. Its Drive, Supabase and Sonnet-reviewer references are proposed infrastructure; this lesson does not establish their deployment.

Cover all six dimensions

Scan pricing patterns; set the base price; specify payment terms; define refunds; document segmentation or uniform pricing; place the offer on the value/access matrix. Connect every choice to unit economics, customer needs and delivery capacity. The resulting document feeds tier design, discount policy and raise scheduling, so a price number alone is insufficient.

Use the six benefits as design goals

A documented architecture can pre-answer recurring questions, reveal margin erosion, make customer explanations consistent, preserve decision history, support delegated operations and make a pricing policy actionable. These are design goals to test in use. A price is not a measure of personal worth, and adopting the source’s self-respect language does not establish a sustainable margin.

Treat the 6% scan as a structured comparison

The source asks for at least sixteen candidate patterns and selecting one or two after comparison. This can counter first-thought selection, but the claim that a one-in-sixteen rate produces better decisions is not substantiated here. Compare operator/service model, mechanism, customer expectations, capacity and discount discipline. Record why a candidate was excluded rather than padding a list just to reach sixteen.

Pricing pattern — Flat fixed price

A single price for a clearly defined scope; control additions and acceptance criteria. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Tiered fixed price

Two or three packages with meaningful differences; cost and explain each package. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Per-unit

Price by a measurable unit such as session, word or project; define the unit and minimums. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Hourly

Price by time worked; clarify estimates, tracking and incentives without assuming every hourly arrangement is inappropriate. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Project with a revision cap

Fix the core scope and revision allowance, with clearly disclosed charges or change approval beyond it. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Retainer or subscription

Charge recurring fees for specified recurring service or access, with clear renewal/cancellation terms. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Cohort seat

Price per participant in a time-bound group; model fixed cohort costs and minimum viable enrollment. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Sliding scale or pay-what-you-can

Define bounds and eligibility/choice rules; model whether the mix supports delivery. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Performance-based

Tie payment to a defined outcome with credible measurement, attribution and agreed limits. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Base plus performance

Use a fixed component plus an outcome-based component; specify both calculation bases. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Per customer-of-customer

Scale a B2B charge with the client’s customer count; define reporting, tiers and reconciliation. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Geographic or regional

Differentiate by region only with an explicit rationale and attention to administration, transparency and arbitrage. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Cohort early/late enrollment

Use genuine dates and clear price changes, explaining the planning benefit and cutoff. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Partner or affiliate

Define customer price and partner compensation separately, including the commission base and refund treatment. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Scholarship or need-based

Specify eligibility, allocation limits and funding rather than improvising exceptions under pressure. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Productized fixed scope

Offer a repeatable bounded service with explicit limits on customization. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Value-based with an anchor

Relate price to supported customer value and an honest comparison; avoid fabricated savings or reference prices. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Value ladder

Connect entry, core and continuing offers to successive customer needs without assuming every buyer must ascend. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Day or week rate

Sell a defined time block with scope, availability and overrun rules. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Outcome-guarantee pricing

Specify the covered result, conditions and refund or credit remedy, then cost the commitment. This is one of the source’s twenty patterns, not a recommendation for every offer.

Read the two pattern selections critically

Maya screens twenty patterns down to fixed, revision-capped project, retainer, productized and value-based options, then chooses fixed scope with a revision cap at a proposed $6,750. Darius screens cohort, subscription, base-plus-outcome, productized and ladder options, then chooses $300 per month with a three-month minimum and an optional $300 cohort fee when enrollment reaches eight. These are worked examples. Subscription revenue does not automatically make every enrollment level profitable; recalculate fixed and per-customer costs.

Ground the base price in evidence

Use the prior branch and target, selected pattern, delivery model, capacity and a current comparable-offer scan. Document the price, source rationale, competitive position, identity/service coherence, capacity coherence and structural test. A claimed percentile needs an actual comparable dataset. Source competitor prices and market ranges are examples, not verified current quotations.

Keep revenue, margin and owner income separate

The example $6,750 × four concurrent customers × four turns per year equals $108,000 gross revenue at that utilization. It does not establish profit, owner income or 25% headroom. Darius’s $300 × ten subscribers × twelve months equals $36,000 annual gross revenue if those seats remain filled. Deduct actual delivery costs, refunds, acquisition, fees, overhead and applicable obligations before drawing an income conclusion.

Specify all payment-term fields

State whether pay-in-full exists and its discount; the number, amount and dates of installments; failed-payment handling; late fees if any; and who absorbs processing charges. Model default, timing and collection costs as well as transaction fees. Source examples of retries on days 1, 3 and 5, pause on day 7 and termination on day 14 with 50% balance forgiveness are proposed terms, not configured automations or universally valid contract provisions.

Correct the processing-fee calculation

For the source’s assumed 2.9% plus $0.30 per charge, one $6,750 charge costs $196.05. Three $2,250 charges cost $65.55 each, or $196.65 total: a $0.60 difference, not $94 and not triple the percentage fee. This compares equal gross totals only. Stripe currently lists this standard domestic-card rate, but country, method, currency, other products and custom pricing can change actual charges. Model your actual contract.

Correct discounts and installment premiums

Five percent off $6,750 is $6,412.50; the source’s $6,413 is a rounded whole-dollar figure that must be disclosed consistently. Six payments of $1,150 total $6,900, a $150 or approximately 2.22% premium over $6,750, not exactly 2%. Compare discounted pay-in-full and installments separately so a discount is not confused with a processing-fee difference. Maya ultimately selects three payments, not the six-pay template option.

Avoid unsupported payment psychology rules

The source describes 5–10% discounts as fair, discounts above 15% as desperate and plans beyond twelve months as financing. Those are unsupported generalizations, not universal customer reactions or legal classifications. Choose terms from customer evidence, cash-flow needs, transparent total cost and applicable rules. Do not present a financing or surcharge arrangement as compliant merely because a template names it.

Separate the Maya and Darius payment examples

Maya’s example uses a $6,750 base, the rounded 5% pay-in-full option or three $2,250 payments with operator-absorbed processing, no extended plan, and the stated missed-payment process. Darius uses $300 monthly with a three-month minimum, seven-day grace, access pause and cancellation if unresolved by fourteen days. A three-month minimum is at least $900 before any optional cohort fee; indefinite continuation is a separate renewal/cancellation question.

Define refunds without contradictory wording

Specify start date, duration, eligibility, remedy, request method, partial-refund formula and alignment with the existing guarantee and exclusions. The source phrase “full refund minus $200” describes a deduction, not an unqualified full refund. Maya’s fourteen-day window and separate no-refund-after-Week-4 statement leave the intervening period unclear; resolve it in actual terms. Darius’s example refunds the first month for timely cancellation, then describes later months as nonrefundable. Real terms must remain consistent with applicable customer rights.

Evaluate refund cost and customer clarity

The source claims long unconditional windows signal low confidence and short windows are customer-hostile. These are not universal facts. Choose a clear policy consistent with the service, existing promise and actual obligations, model refund and nonreturned processing costs, and ensure staff can apply it. A stronger guarantee should have a defined remedy and capacity behind it, not just stronger wording.

Document segmentation rather than improvising it

The source prefers three planned cases: genuine early enrollment, partner/affiliate channels and need-based scholarships. Its illustrative early discounts are 10–20% and scholarship allocation is one or two per year; neither is a universal standard. It discourages negotiated, loyalty, regional, undefined-hardship and competitor-matching discounts. Treat those as policy choices to evaluate, not proof that every such pricing model is inherently invalid. If price is uniform, explain the reason.

Calculate partner compensation on the stated base

With a 15% customer discount, collected price is 85% of list. A commission equal to 20% of list leaves 65% before other costs; a commission equal to 20% of the collected amount leaves 68% of list. The source’s 65% result assumes the first basis. State which applies, how refunds affect commissions and whether the remaining contribution supports delivery.

Keep segmentation examples internally consistent

Maya selects uniform pricing with no current partner, scholarship or cohort program, citing simplicity and scope. Darius keeps subscriptions undiscounted but lists optional cohort prices of $250 early, $300 standard and $400 later. Define exact dates and eligibility; “within the first month” is not a sufficient enrollment calendar by itself. These are proposed terms in a worked example, not current RISER prices.

Use the value/access matrix — Q1: lower value, broad access

The source associates mass-market ebooks, templates and basic software with volume economics. Low price does not itself prove low customer value. Operator identity is a discussion aid, not a deterministic rule that excludes another valid model.

Use the value/access matrix — Q2: higher value, broad access

The source uses broadly available premium courses or software as examples. Broad availability still requires sustainable support and a substantiated value claim. Operator identity is a discussion aid, not a deterministic rule that excludes another valid model.

Use the value/access matrix — Q3: lower value, narrow access

The source treats this as a possible underpricing or fit warning. Investigate the audience, cost and intended mission; the quadrant alone cannot diagnose a business failure. Operator identity is a discussion aid, not a deterministic rule that excludes another valid model.

Use the value/access matrix — Q4: higher value, narrow access

The source uses intensive coaching and advisory examples. Model the limited delivery capacity and demonstrate the value rather than inferring it from a high price. Operator identity is a discussion aid, not a deterministic rule that excludes another valid model.

Position the examples without turning labels into evidence

The source places Maya’s $6,750 intensive service in Q4 and Darius’s $300 subscription in Q2. Its industry price ranges and identity assignments are illustrative; verify relevant comparables and customer value. A business can change the scope or service model instead of forcing a preferred quadrant. Record the reason and any unresolved mismatch.

Pricing Architecture Document section 1 — Branch and bridge

100–150 words linking the M8.3 decision to this implementation. Keep linked evidence beside the relevant decision.

Pricing Architecture Document section 2 — Pattern scan

200–300 words listing sixteen-plus patterns, filters, rejected options and the selected one or two. Keep linked evidence beside the relevant decision.

Pricing Architecture Document section 3 — Base price

200–300 words with the price, source evidence, competitive position, identity/capacity coherence and structural test. Keep linked evidence beside the relevant decision.

Pricing Architecture Document section 4 — Payment terms

200–250 words covering payment structure, failures, fees and margin implications. Keep linked evidence beside the relevant decision.

Pricing Architecture Document section 5 — Refunds

150–200 words covering window, conditions, amount, partial formula and promise alignment. Keep linked evidence beside the relevant decision.

Pricing Architecture Document section 6 — Segmentation

200–300 words describing planned cases or justified uniform pricing, with sustainable economics. Keep linked evidence beside the relevant decision.

Pricing Architecture Document section 7 — Matrix

150–200 words explaining the value/access position and delivery-model fit. Keep linked evidence beside the relevant decision.

Pricing Architecture Document section 8 — Handoffs

100–150 words specifying the inputs needed by tier design, discount policy and raise scheduling. Keep linked evidence beside the relevant decision.

Reconcile the document-length targets

The source says 1,500–2,000 words overall, while its eight section ranges sum to 1,300–1,850. To satisfy both as written, aim within the intersection of 1,500–1,850 or explicitly revise the assessment budget. Completeness and clear decisions matter more than padding. Maya’s reported 1,750-word example sits inside the intersection; it is not proof an actual document was submitted.

Check seven common failure modes

Do not skip the comparison; do not set an unsupported aspirational price; compute payment economics; align refunds with the existing guarantee; prevent undefined exceptions from masquerading as segmentation; investigate matrix/service-model mismatch; and include the next-stage cross-references. Each correction should produce evidence, not just a higher self-assigned rubric score.

Complete the architecture checkpoint honestly

The source requests the eight-section document plus selected_pattern, base_price and matrix_quadrant in c8_pricing_architectures. Its eight review criteria cover scan, price rationale, payment economics, refund alignment, segmentation, matrix, handoffs and section targets, with 7/10 as the proposed gate. These fields and reviewer are not proven deployed. Tier design needs the baseline price; discount policy needs segmentation; raise scheduling needs position and evidence. Record actual completion separately from the plan.

Connect the lesson to the direct-marketing promise

Read the alternate ten-section pricing review

This reviewer is a version 1.0.0 artifact-review prompt labeled M8.4, C8 Pricing Discipline, with a named Claude model. It is source configuration, not a deployed assessor or evidence of model availability. It expects ten sections: linked C7/M8.2/M8.3 inputs; cost-anchored base price; payment terms; refund window and non-triggers; structural segmentation; customer/scope quadrant rules; quantified scope premiums; quarterly margin path; computed coherence checks; and operator sign-off. This differs from the eight-section main lesson. Preserve both versions and explicitly select or reconcile the assessment contract before grading.

Apply pricing review numbers as declared policy

The reviewer proposes deposits of at least 25% for offers above $500, with documented exceptions such as procurement constraints; a 60% knowledge-work margin target or justified exception; average effective price at least base price × 0.92; a scope premium that covers measured extra work; and a 12-month commitment with schedule-triggered changes. Calculate price, weighted segment mix, measured costs and quarterly milestones. These are program policies, not universal economic or legal requirements. An example of 10% extra for up to four hours must be costed before adoption.

Resolve the reviewer’s incompatible thresholds

The introduction says average at least 7 and no score below 5, but the decision block clears only an average at least 8 with no score below 6. It routes averages 6–7.9 or individual scores 4–5.9 to revision, and averages below 6 or any score below 4 to not cleared. Decimal ranges leave gaps unless a rounding rule is defined. Criterion 8 below 6 imposes revision at minimum; severe failures must still take precedence. Define the authoritative rule, precision and precedence rather than returning conflicting decisions.

Produce an auditable pricing review and handoff

The source requests a score table, decision, section-specific notes, upstream coherence flags, M8.5 readiness and final paragraph. Persistent coherence failure or not-cleared status routes to a proposed C8 instructor queue with normal priority and a 14-day window. It proposes 48 hours after clearance to confirm the architecture before M8.5. Name each defect and correction, accept documented policy exceptions where permitted, and record actual review/handoff status. Neither a queue nor a binding agreement is created by this prompt.

Build the five-tab pricing workbook deliberately

The supporting file is a Markdown specification, not a functioning spreadsheet. It describes twelve months of data and quarterly review. Tab 1 tracks delivery ID, customer, start/end, price, stated hours, actual hours, hidden hours, total hours, loaded operator rate, direct costs, total cost, profit, margin and effective hourly revenue. Keep measured actual hours separate from estimates, define whether hidden hours are already included, and use one consistent cost convention.

Correct the delivery formulas before using them

The source uses total hours = stated hours + hidden hours and ignores its actual-hours column. For measured performance, choose the verified actual-hours definition and add only previously excluded time. Total cost = included hours × loaded rate + direct cost; contribution under that convention = revenue − included cost; margin = contribution / revenue; effective hourly revenue = revenue / included hours. Guard zero denominators and distinguish this owner-labor management metric from a financial-statement gross margin. Six observations are not automatically statistically meaningful; eight deliveries is a program requirement, not a universal proof threshold.

Separate architecture rules from observed results

Tab 2 records base price, payment/refund rules, raise triggers, tier prices and target mix. Its 60% standard, 30% entry and 10% premium mix and 60% margin are examples/policies. Preserve effective dates and the chosen policy version so later results can be evaluated against the rule that applied at the time. Add a tier field to the delivery log if the summary must calculate actual tier mix; the specified Tab 1 has none.

Correct the exception-log compliance calculation

Tab 3 records date, customer, request, exception classification, decline/grant outcome, justification and a 1 for rule-matched or 0 for deviation. Deviations divided by requests is a deviation rate, not a compliance rate. Compliance is one minus that rate, or the average of valid binary flags; zero requests is not applicable. A justified permitted exception is not automatically a deviation. The source suggestion that justification should always be empty conflicts with its allowance for documented exceptions; retain the decision rationale.

Track trigger decisions without silently executing raises

Tab 4 covers T1–T4 capacity, waitlist, demand and indexing triggers: threshold, observed reading, fired status/date, execution within 30 days, magnitude and cap. Treat these as the source policy design and record the responsible decision, effective date and customer terms. A worksheet flag does not authorize an automatic price change or establish that a customer notification was sent.

Use weighted and time-consistent quarterly summaries

Tab 5 summarizes margins, hourly results, mix, exceptions, triggers and raises. Average row margins are not the same as total contribution divided by total revenue; average hourly rates differ from total revenue divided by total hours. Filter all measures to the same quarter and define the basis. Sequential percentage raises compound as product(1 + rate) − 1, rather than a simple sum, unless each is explicitly applied to the same original base. The source setup estimate of 2–3 hours plus four 1–1.5-hour reviews totals 6–9 hours; roughly ten is a planning allowance. Proposed database tables are not deployed by this specification.

Distinguish the two four-quadrant tools

The supporting framework crosses new versus existing customers with standard versus custom scope. The main lesson instead discusses value/access positioning. They are different matrices and cannot share an unexplained section label. In this customer/scope matrix, Q1 is new/standard at base price; Q2 existing/standard with any explicitly earned loyalty rule; Q3 new/custom at base plus priced scope; Q4 existing/custom with loyalty applied to base and scope premium calculated on the original base. Define the applicable customer universe and route ambiguous cases.

Reconcile loyalty rules and worked amounts

This framework uses Maya’s $5,625 base, three prior deliveries and renewal within 30 days for 10% loyalty, and 10% scope premium for up to four extra hours. Exact results are $5,062.50 for loyalty only, $6,187.50 for scope only, and $5,625 for both. The source rounds these inconsistently to $5,063 and $6,187. Its base and loyalty policy differ from the main $6,750 uniform-price example; do not blend versions. Cost extra work and define rounding before quoting. Other three- or four-delivery criteria are examples to select explicitly.

Prevent the four quadrant pricing errors

Avoid discretionary treatment of existing/custom customers, manufacturing custom scope to move Q1 into Q3, absorbing custom work at standard price, and automatic loyalty merely because a customer is existing. Record the qualifying evidence, original base, premium and final price. Downstream scheduled raises and indexing must update the base and percentage calculations consistently. The framework references sections 2, 6 and 7 differently from the main lesson; link the named artifact and concept instead of assuming identical numbering.

Complete original source text

M8.4 — Pricing Architecture Construction: The Multi-Dimensional System

Module Outcome: [Create] Student has applied the 6% Rule to pricing patterns; specified base price, payment terms, refund window, and segmentation logic; positioned the offer on the four-quadrant pricing matrix; produced the Pricing Architecture Document that implements the M8.3 branch decision and serves as the primary input to M8.5-M8.7. Key Deliverable: Pricing Architecture Document (Pricing-Architecture-Document-[YourName]-[Date].md, 1,500-2,000 words, eight sections) Infrastructure Dependency: Build 6, Build 8 Drive folder, Supabase c8_pricing_architectures table, Claude prompt pricing-architecture-reviewer-v1.0.0 (Sonnet), Pricing-Math-Spreadsheet template, Four-Quadrant Pricing Matrix Framework Checkpoint / Test: Type 1 Artifact + Type 2 AI rubric ≥ 7/10 Blocked-Until Prerequisite: M8.3 Reality Check Document filed AND AI rubric ≥ 7/10 AND 48-hour cooling period elapsed since M8.3 filing

________________

What This Module Does

M8.4 is the deepest module of C8 in active hours. Six things happen:

1. You apply the 6% Rule to pricing: scan 16+ pricing patterns from market and competitor data to identify the 1-2 strongest models for your offer's structural shape. The rule's discipline is the same as in C1 (sixteen patterns minimum); the application context shifts from operator-pattern selection to pricing-pattern selection.

2. You specify the base price for the corrected offer (post-M8.3 decision), grounded in the unit economics target margin. The base price is not the M8.3 target rounded; it is the M8.3 target tested against the chosen pricing pattern, the operator identity, and the C7 capacity ceiling.

3. You specify payment terms: pay-in-full discount (if any), installment plan structure (if any), payment-plan default and late-payment provisions. Payment terms have margin implications that the M8.2 math may not have captured (a 3-pay plan with a 2.9% per-transaction processing fee triples the processing cost compared to pay-in-full).

4. You specify the refund window: duration, conditions, partial-refund formula if applicable. The refund window aligns with the C4 M4.6 Guarantee Architecture — strengthened or refined per M8.4 work but not weakened.

5. You specify segmentation logic: when do different customer types pay different prices (cohort early-bird, partner referral, scholarship case, regional pricing), and what is the documented rationale? If uniform pricing, document why uniformity was chosen.

6. You position the offer on the four-quadrant pricing matrix along the value axis (low ↔ high) and access axis (broad ↔ narrow). The quadrant must match operator identity; mismatches are flagged.

The deliverable is the Pricing Architecture Document — 1,500-2,000 words, eight sections. The document is the primary input to M8.5 (tier design), M8.6 (anti-discount policy), and M8.7 (raise schedule). It is the densest pricing artifact in C8 and the most heavily cross-referenced.

M8.4 is 8 hours of active work distributed across 3-4 sittings. Most operators run a 6% Rule scan as the first sitting (3 hours), specify base price and payment terms as the second sitting (3 hours), specify refund window and segmentation as the third sitting (1 hour), and complete matrix positioning + document writing as the fourth sitting (1 hour).

________________

Why This Module Matters

The M8.3 decision branch named what to do (raise prices for new, narrow scope, kill, or accept legacy). M8.4 specifies how. Pricing without architecture is a number floating in space; pricing with architecture is a system that handles the dozens of pricing-adjacent decisions the next 12 months will surface (the prospect asking for installments, the partner asking for affiliate terms, the regional-market customer asking about geographic pricing, the next-cohort prospect asking why pricing changed).

Architectural pricing has six structural advantages over single-number pricing:

1. Decision pre-emption. The architecture handles common pricing questions without ad-hoc judgment. When a prospect asks for an installment plan, the architecture answers; the operator does not have to decide in the moment.

2. Margin protection at edges. Payment processing fees, partial refunds, and late payments all erode margin if not specified upfront. The architecture quantifies the erosion.

3. Communication clarity. Customers experience a coherent pricing story when architecture is documented; they experience inconsistency when each decision is ad-hoc.

4. Audit traceability. When the operator looks back and asks "why did I price this customer this way?" the architecture answers; ad-hoc memory does not.

5. Scaling readiness. Stage 3 expansion (C11+) requires pricing that operates without operator intervention on most decisions. Architecture is the input to that scaling.

6. Self-respect operationalization. The doctrine "Pricing Is Operator Self-Respect" becomes operational through architecture; without architecture, the doctrine is aspirational.

The 6% Rule applied to pricing patterns is the same disciplinary mechanism as in C1's archetype selection: don't select the first pattern that comes to mind; select among 16+ candidates with documented reasoning. Operators who skip the scan tend to default to pricing patterns from their reference industry or their personal experience, missing the patterns that fit their specific offer shape better.

________________

The 6% Rule Applied to Pricing Patterns

The 6% Rule (originating from C1) holds that a 1-in-16 selection rate produces structurally better choices than first-thought selection. Applied to pricing, the rule directs the operator to scan at least 16 pricing patterns from market and competitor data before specifying their own.

Pricing patterns are not the same as pricing levels. A pricing pattern is a structural model for how price relates to value, scope, customer count, and time. Common patterns include:

1. Flat fixed price — single price for single offer scope (Maya's $4,500 Sprint at C4)

2. Tiered fixed price — two or three discrete tiers (Standard / Premium / VIP)

3. Per-unit pricing — price scales with measurable units (per session, per word, per project)

4. Hourly billing — price scales with hours; Stark's caution on hidden incentives applies

5. Project-based with revisions cap — fixed price for defined scope, additional fee per revision beyond cap

6. Retainer / subscription — recurring fixed fee for recurring access

7. Cohort pricing — fixed price per seat in a time-bound cohort (Darius's Reading Club at $1,200/seat)

8. Pay-what-you-can / sliding scale — variable price by customer self-determination within bounds

9. Performance-based — price scales with measurable outcomes (e.g., percentage of revenue generated)

10. Hybrid base + performance — fixed base + outcome-tied bonus

11. Per-customer-of-customer — pricing scales with the customer's customer count (B2B common)

12. Geographic / regional pricing — different prices by customer geography (controversial; Hermann Simon notes implementation difficulty)

13. Cohort early-bird / late — price varies by time of cohort enrollment relative to start

14. Partner / affiliate pricing — discount available to customers from designated partner channels

15. Scholarship / need-based pricing — discounted access for documented need cases

16. Productized fixed-scope — single price, no scope variation, no customization

17. Value-based with anchor — pricing tied to the customer's value capture, anchored to a reference

18. Ladder pricing — entry product → main product → continuity (Brunson's ladder)

19. Day-rate / week-rate — fixed time blocks at fixed rates

20. Outcome-guarantee pricing — price tied to outcome with refund/credit if outcome not achieved

The operator scans these 16-20+ patterns against their offer shape and selects 1-2 candidates that fit best. The selection criteria:

* Match to operator identity (Service / Teacher / Builder)

* Match to mechanism (the C2 M2.7 hypothesis structurally)

* Match to customer experience expectation (what does the audience expect at this price level?)

* Match to operator capacity ceiling (some patterns require concurrent-customer counts the M7.5 ceiling cannot support)

* Match to operator's anti-discount discipline (some patterns embed discounting into the architecture in ways the operator cannot defend)

For Maya's Portfolio-to-Licensing Sprint:

* Scanned all 20 patterns

* Filtered to: flat fixed price (current pattern, refined), project-based with revisions cap, retainer, productized fixed-scope, value-based with anchor

* Compared each: flat fixed price fits the 12-week defined scope; productized fixed-scope eliminates the customization Maya intentionally provides; retainer doesn't fit the time-bounded mechanism; value-based with anchor would require Maya to capture downstream licensing income (complex for a coaching engagement)

* Selected: Flat fixed price refined with explicit scope boundaries and revisions cap. New base price target from M8.3: $6,750.

For Darius's Reading Club:

* Scanned all 20 patterns

* Filtered to: cohort pricing (current pattern), per-individual subscription, hybrid base + outcome, productized fixed-scope, ladder pricing

* Compared each: cohort pricing has the structural problem M8.2 surfaced (3 of 12 seats produces disastrous unit economics); per-individual subscription decouples pricing from cohort dynamics; ladder pricing introduces a low-cost entry product that funnels to the cohort

* Selected: Per-individual subscription ($300/month for 3-month minimum commitment) plus optional cohort upgrade ($300 cohort fee added when cohort runs at 8+ enrollment). This solves the structural problem from M8.2 (the cohort's economics no longer depend on hitting 12 seats; individual subscription supports the offer at any seat count).

The 6% Rule scan takes 2-3 hours of active work and produces materially better pricing patterns than first-thought selection.

________________

Base Price Specification

After the 6% Rule scan, you specify the base price for the corrected offer.

Inputs:

* M8.3 decision branch and price target

* Selected pricing pattern from the 6% Rule scan

* Operator identity (Service / Teacher / Builder)

* Capacity ceiling × stated minimum target hours

* Competitive scan benchmark range

Specification template:

Base price: $[X] Pricing pattern: [Pattern from 6% Rule selection] Source rationale: [link to M8.2 unit economics target margin and M8.3 decision branch] Competitive position: [position relative to scanned competitive offers — e.g., "$6,750 places this offer at the 60th percentile of comparable offers in the senior-illustrator coaching market, range $5,000-$8,500"] Identity coherence: [Service-Operator pricing tone explanation — e.g., "premium positioning is consistent with the Sprint's intensive-personal-attention delivery"] Capacity coherence: [check against M7.5 — e.g., "at $6,750 × 4 concurrent × 4 turns/year = $108,000 max annual revenue, exceeds operator income target with 25% margin headroom"]

The base price is not aspirational; it is grounded. The rationale lines must each cite specific evidence. Operators who specify a base price without grounding it tend to specify aspirationally and produce architecture that cannot withstand the first prospect objection.

For Maya: $6,750 (50% increase from $4,500 anchor). Pricing pattern: flat fixed price with revisions cap. Source rationale: M8.3 decision branch 1; M8.2 stated minimum × hours × adjusted-fulfillment math. Competitive position: 60th percentile in scanned market. Identity coherence: Service-Operator with intensive personal attention. Capacity coherence: confirmed at M7.5 ceiling.

For Darius: $300/month per individual subscription with 3-month minimum. Pricing pattern: per-individual subscription. Source rationale: M8.3 decision branch 2 (narrow scope, but Darius chose Branch 1+pattern shift). Competitive position: between Codecademy Pro ($24/month) and engineering coaching ($1,500-$3,000/month) — solidly in the middle of the platform-engineering education market. Identity coherence: Teacher-Operator with cohort-style group dynamics. Capacity coherence: at M7.5 ceiling, ~10 concurrent subscribers; revenue $3,000/month × 12 = $36,000 annual base.

________________

Payment Terms Specification

Payment terms are not optional. Even if you offer pay-in-full only, document that explicitly.

Inputs:

* Base price from the prior section

* Customer cash-flow expectations (from C3 audience research)

* Operator cash-flow needs (from C6 financial baseline)

* Payment processor fee structure (Stripe ~2.9% + $0.30; PayPal similar)

Specification template:

Pay-in-full: [yes/no, and discount if any — e.g., "5% pay-in-full discount, base $6,750 → $6,413"] Installment plan: [yes/no, and structure — e.g., "3-pay at $2,250/month, no discount; 6-pay at $1,150/month, 2% premium"] Default provisions: [what happens if a payment fails — e.g., "automatic retry at day 1, day 3, day 5; access pause at day 7; engagement termination at day 14 with 50% balance forgiveness"] Late-payment fees: [yes/no — e.g., "no late fees but engagement pauses on missed payment"] Processing fee absorbed: [operator absorbs or passed to customer — e.g., "operator absorbs Stripe fee on pay-in-full; customer absorbs ~$10 processing fee on per-installment basis"]

The payment terms have meaningful margin implications. A 3-pay plan at $2,250 produces 3 transactions × ($2,250 × 2.9% + $0.30) = $196 in processing fees vs. $196 for one pay-in-full transaction; the difference is $94 — small per customer but material at scale.

The payment terms also have psychological effects. Customers perceive pay-in-full discounts at 5-10% as fair; discounts above 15% read as desperation. Customers perceive installment plans as access-enabling; plans above 12 months read as financing rather than payment terms.

Maya's specification: pay-in-full $6,750, 5% discount to $6,413; 3-pay at $2,250/month with no discount and operator-absorbed processing; no 6-pay or extended plan. Default: pause at day 7 missed payment, terminate at day 14 with 50% forgiveness.

Darius's specification: $300/month subscription, no pay-in-full option (the subscription model doesn't have a finite total). 3-month minimum commitment; cancellation policy specified. Failed payment: 7-day grace, then access pause; cancellation if not resolved in 14 days.

________________

Refund Window Specification

The refund window aligns with the C4 M4.6 Guarantee Architecture but may be refined per M8.4 work.

Inputs:

* C4 M4.6 Guarantee Architecture

* C7 v2.0 offer document refund language

* M8.6 anti-discount policy (referenced forward)

Specification template:

Refund window: [duration — e.g., "14 days from engagement start"] Refund conditions: [what qualifies — e.g., "if the customer has completed Module 1 sessions and concludes the Sprint is not the right fit"] Refund amount: [full / partial — e.g., "full refund minus $200 administrative fee"] Partial refund formula (for mid-engagement): [if applicable — e.g., "after Module 1, prorated by remaining modules; after Module 4, no refund"] Anti-promise alignment: [reference C4 M4.5 — e.g., "consistent with anti-promise that Sprint outcome depends on customer's specific licensing portfolio readiness"]

Refund windows that are too generous (60+ days, no conditions) erode margin and signal lack of confidence. Refund windows that are too restrictive (7 days, no conditions, no partial) read as customer-hostile. The discipline is to find the alignment with C4 M4.6 and the operator identity.

For Maya: 14 days from engagement start; refund qualifies if customer has completed Week 1 session and concludes the Sprint is not the right fit; refund is full minus $200 administrative fee; after Week 4, no refund (consistent with C4 M4.6 architecture).

For Darius: 30 days from subscription start; refund qualifies if cancellation request received before Day 30; full refund of first month's payment; subsequent months non-refundable.

________________

Segmentation Logic Specification

Segmentation is the most error-prone area of M8.4. Many operators want to offer different prices to different customer types but lack the discipline to do so coherently.

Three legitimate segmentation patterns:

1. Cohort timing segmentation: early-bird vs. standard vs. late pricing for time-bound cohorts. Discount typically 10-20% for early-bird; rationale is cash-flow-forward and conversion-de-risking. Anti-discount policy must specify this is a time-bound cohort discount, not a negotiation discount.

2. Partner / affiliate segmentation: designated partners can offer the operator's offer to their network at a discount, with the partner taking a commission. The arithmetic must work: if partner takes 20% commission and discount is 15%, operator nets 65% of base price; this must still produce sustainable margin.

3. Scholarship / need-based segmentation: documented need cases at reduced price; operator commits to a defined number per cohort/year (typically 1-2 per year). Rationale: portfolio-builder, mission-aligned access. Specific to the operator's identity and stage.

Anti-segmentation patterns to avoid:

* Negotiated discounts ("special deal for you because we got along well") — destroys pricing coherence

* Loyalty discounts ("returning customer gets 15% off") — erodes margin without structural justification

* Geographic / regional pricing without strong defensible rationale — Hermann Simon notes high implementation difficulty and high arbitrage risk

* Hardship discounts without defined need-based criteria — slips into negotiation territory

* Comparable-competitor matching ("your competitor charges X, I'll match") — abandons the architecture entirely

If uniform pricing (no segmentation): document why. Operators who select uniform pricing typically cite operator identity, simplicity preference, and discipline against ad-hoc adjustment.

For Maya: uniform pricing for v2.1; no cohort timing (she runs 1:1, not cohort); no partner program at this stage; no scholarship currently planned. Documented rationale: simplicity, discipline against ad-hoc adjustment, operator-identity coherence.

For Darius: cohort timing segmentation for the optional cohort upgrade (early-bird $250 cohort fee, standard $300 within first month, $400 after that). No individual-subscription discounts. No partner program at this stage.

________________

Four-Quadrant Pricing Matrix

The matrix positions the offer along two axes: value (low ↔ high) and access (broad ↔ narrow).

Narrow Access

Low Value | High Value

Narrow Access | Narrow Access

──────────────────────────────────

Low Value | High Value

Broad Access | Broad Access

Broad Access

The four quadrants:

Q1 (Low Value, Broad Access): Mass-market commodity pricing. Examples: $9 ebooks, $50 templates, $30/month basic SaaS. Volume-driven economics. Identity match: Builder-Operator scaling productized output.

Q2 (High Value, Broad Access): Premium product widely available. Examples: $200 books with broad distribution, $500-$2,000 self-paced courses, $5,000-$20,000 annual SaaS. Identity match: Teacher-Operator at scale or Builder-Operator with brand premium.

Q3 (Low Value, Narrow Access): Boutique low-price offerings. Rare in knowledge-work; usually indicates an operator who is under-priced. Identity match: rare; usually misalignment.

Q4 (High Value, Narrow Access): Premium bespoke / coaching / advisory. Examples: $5,000-$50,000 personal coaching, $25,000-$200,000 advisory engagements, $50,000+ executive consulting. Identity match: Service-Operator with intensive personal attention.

The operator positions their offer in the matrix and verifies the position matches operator identity:

* Service-Operator pricing typically lives in Q4 (or upper Q2 if productized)

* Teacher-Operator pricing typically lives in Q2 (cohort) or Q1 (self-paced)

* Builder-Operator pricing typically lives in Q1 or Q2 (productized scaling)

For Maya: Q4 (High Value, Narrow Access) at $6,750 with intensive 1:1 coaching. Identity match: Service-Operator. Coherent.

For Darius: Q2 (High Value, Broad Access) at $300/month subscription with cohort access. Identity match: Teacher-Operator at scale. Coherent.

Operators whose offer lands in a quadrant inconsistent with their identity should re-examine the pricing pattern. Q3 (Low Value, Narrow Access) is the most common misalignment: it indicates a Service-Operator who has under-priced themselves; the M8.3 decision branch typically already addresses this.

________________

The Eight-Section Document Template

Your Pricing Architecture Document is 1,500-2,000 words, with eight sections:

Section 1 — M8.3 Branch and Implementation Bridge (100-150 words)

State which M8.3 branch you committed to and how M8.4 architecture implements it. Brief — most of the architecture work is below.

Section 2 — 6% Rule Pricing Pattern Scan (200-300 words)

List 16+ pricing patterns scanned. Show your filtering: which patterns survived initial screening, which were eliminated and why, which 1-2 were selected. Show your selection criteria explicitly.

Section 3 — Base Price Specification (200-300 words)

Specify the base price with the five rationale lines (source, competitive position, identity coherence, capacity coherence, and structural test).

Section 4 — Payment Terms Specification (200-250 words)

Specify pay-in-full discount, installment structure, default provisions, late-payment provisions, processing-fee handling. Show the margin impact of payment-term decisions.

Section 5 — Refund Window Specification (150-200 words)

Specify duration, conditions, refund amount, partial-refund formula, anti-promise alignment.

Section 6 — Segmentation Logic Specification (200-300 words)

Specify segmentation patterns selected (cohort timing / partner / scholarship) or document uniform pricing. If segmented, show the math: does the segmented pricing still produce sustainable margin?

Section 7 — Four-Quadrant Matrix Positioning (150-200 words)

State which quadrant the offer occupies, the rationale for positioning, and the identity coherence verification.

Section 8 — Cross-References (100-150 words)

Specify what M8.5 (tier design), M8.6 (anti-discount), and M8.7 (raise schedule) will need from this architecture. Be specific about inputs.

________________

Worked Example: Maya's Pricing Architecture

Maya's M8.4 sittings:

Sitting 1 (3 hours): 6% Rule scan. Maya scanned 20 pricing patterns. Filtered to 5: flat fixed, project-based with revisions cap, retainer, productized fixed-scope, value-based with anchor. Selected: flat fixed price refined with explicit scope boundaries and revisions cap.

Sitting 2 (3 hours): base price + payment terms. Maya specified $6,750 as base price (50% increase from C4 anchor). Pay-in-full discount: 5% to $6,413. 3-pay installment plan: $2,250/month with no discount, operator absorbs processing. No 6-pay or extended plan. Default: pause at day 7, terminate at day 14 with 50% forgiveness.

Sitting 3 (1 hour): refund window + segmentation. Refund window: 14 days from engagement start; refund qualifies if customer has completed Week 1 and concludes Sprint not right fit; full refund minus $200 admin fee; after Week 4, no refund. Segmentation: uniform pricing for v2.1, no cohort timing, no partner, no scholarship currently. Documented rationale.

Sitting 4 (1 hour): matrix positioning + document writing. Positioning: Q4 (High Value, Narrow Access). Identity match: Service-Operator with intensive 1:1 coaching. Coherent. Document compiled to 1,750 words.

Maya's architecture is filed. The document is the input to M8.5 (Maya considers tier design), M8.6 (anti-discount policy with the new architecture as anchor), and M8.7 (raise schedule with $6,750 as the current baseline).

________________

Common Failure Modes at M8.4

The Sonnet pricing-architecture-reviewer-v1.0.0 prompt and the AI rubric look for these:

1. Skipping the 6% Rule scan. Operator specifies a pricing pattern as the first-thought selection without showing the 16+ scan. The AI rubric flags any document that lists fewer than 16 patterns.

2. Aspirational base price. Operator specifies a base price that is not grounded in M8.3 unit economics or competitive scan. The price is a wish, not an architectural choice. The rubric expects each rationale line cited.

3. Payment terms with margin erosion uncalculated. Operator specifies installment plans without computing the margin impact (processing fees, default risk).

4. Refund window misaligned with C4 M4.6. Operator specifies a refund window inconsistent with the existing Guarantee Architecture without explanation.

5. Segmentation pattern slipping into negotiation. Operator specifies "case-by-case discounts for fit" or similar; the AI rubric flags this as ad-hoc, not architectural.

6. Quadrant misalignment. Operator's identity (Service-Operator) doesn't match the quadrant (Q1 Low Value Broad Access). The mismatch is a signal; the operator should re-examine pattern selection.

7. Section 8 cross-references missing. Operator does not specify M8.5/M8.6/M8.7 input requirements; the next modules will start without context.

________________

Checkpoint 8.4

Your deliverable is:

1. Pricing Architecture Document filed in Drive, 1,500-2,000 words, eight sections

2. Pricing pattern selection recorded in Supabase c8_pricing_architectures.selected_pattern

3. Base price recorded in c8_pricing_architectures.base_price

4. Quadrant positioning recorded in c8_pricing_architectures.matrix_quadrant

The AI rubric scoring the document looks for eight properties:

* 6% Rule scan with 16+ patterns shown and filtered

* Base price with all five rationale lines

* Payment terms with margin impact computed

* Refund window aligned with C4 M4.6

* Segmentation logic specific (or uniform with documented rationale)

* Quadrant positioning with identity coherence verification

* Cross-references to M8.5/M8.6/M8.7 inputs

* All eight sections meet word-count targets

Target score: ≥ 7/10. Operators who score below typically have either skipped the 6% Rule scan (the most common gap) or specified base price aspirationally without grounding (the second most common). Re-read this lesson, run the architecture work again with rigor, and resubmit.

________________

What M8.5 Expects From You

M8.5 opens with the assumption that your pricing architecture is filed and architecturally coherent. M8.5 begins by asking whether your offer is appropriate for tiered pricing — the Tier Appropriateness Diagnostic. If yes, M8.5 designs three tiers (entry/standard/premium) with structurally different deliverables. If no, M8.5 documents the flat-pricing rationale with the diagnostic findings.

The M8.4 base price feeds into M8.5: if tiered, the base price typically becomes the standard tier's price, with entry below and premium above. If flat, the base price is the price.

M8.6 (anti-discount policy) and M8.7 (raise schedule) also read from M8.4. M8.6 needs the architecture's segmentation logic to produce the explicit exception/non-exception lists. M8.7 needs the matrix positioning to ground its raise triggers.

File the Pricing Architecture Document. Proceed to M8.5.

________________

Last updated: April 25, 2026 · Version 2.0

Complete supporting source — Pricing architecture reviewer

name: pricing-architecture-reviewer
version: 1.0.0
module: M8.4
course: C8 Pricing Discipline
model: claude-sonnet-4-6
role: Pricing Architecture Reviewer
review_type: artifact_review
description: >
  Reviews the M8.4 Pricing Architecture Document. Verifies that base price,
  payment terms, refund window/triggers, segmentation rules, four-quadrant
  matrix, and scope premium schedule are specified rules-based (not
  discretionary), grounded in M8.2 unit economics and M8.3 decision branch,
  and architected toward the C8 doctrine 60% sustainability margin.

system_prompt: |
  You are the Pricing Architecture Reviewer for the RISER Nation Maritime
  Academy C8 Pricing Discipline course, Module 8.4. You review Pricing
  Architecture Documents.

  This module turns the M8.3 decision into a structural pricing system. The
  architecture is what M8.5-M8.7 build against and what M8.6 anti-discount
  policy enforces. Architectural ambiguity propagates into every downstream
  artifact.

  ## What to evaluate

  Read the submitted Pricing Architecture Document plus the linked M8.2
  Unit Economics Document and M8.3 Decision Memo. The Architecture must
  be coherent with both upstream artifacts.

  Score against ten criteria. Pass threshold: average ≥ 7.0 AND no
  individual criterion below 5.0.

  **Criterion 1 — Architecture inputs documented**
  Section 1 must reference C7 Offer Architecture, M8.2 Unit Economics, and
  M8.3 Decision Memo with links. Architecture cannot be built in isolation
  from upstream artifacts.

  **Criterion 2 — Base price specified with cost-anchored rationale**
  Section 2 base price must reference M8.2 unit economics in its rationale.
  Rationale that anchors only to "competitive pricing" or "what feels right"
  fails this criterion. Acceptable rationale ties price to measured cost
  and target margin.

  **Criterion 3 — Payment terms specify deposit ≥ 25% for offers > $500**
  Section 3 must specify deposit percentage. Below-25% deposits on offers
  > $500 are flagged as customer-risk-on-operator failures. Documents may
  specify lower deposits with explicit rationale (e.g., compliance with
  customer procurement requirements).

  **Criterion 4 — Refund window with non-trigger list**
  Section 4 must specify refund window AND non-trigger list. Refund policies
  without non-triggers ("we'll evaluate refund requests case by case") fail
  this criterion because they enable pressure-based refunds.

  **Criterion 5 — Segmentation rules are rules-based, not discretionary**
  Section 5 must specify customer segments with structural criteria (e.g.,
  "≥ 3 prior deliveries renewing within 30 days"). Discretionary segmentation
  ("long-time customers may receive loyalty pricing") fails this criterion.

  **Criterion 6 — Four-quadrant matrix populated**
  Section 6 must show the four-quadrant matrix with pricing rules per
  quadrant. Empty quadrants or vague quadrant entries ("TBD" or "case-by-case")
  fail this criterion.

  **Criterion 7 — Scope premium schedule specified**
  Section 7 must specify scope premium magnitudes (e.g., "+10% for ≤ 4
  hour additions"). Generic language ("custom scope priced separately")
  without magnitudes fails this criterion. The schedule's function is
  to make scope-creep pricing automatic.

  **Criterion 8 — Sustainability margin path specified**
  Section 8 must show quarterly margin trajectory from current (M8.2
  measured) to target (60% knowledge-work doctrine, or documented exception).
  Targets without a path ("we'll get to 60% eventually") fail this
  criterion.

  **Criterion 9 — Architecture coherence check addressed**
  Section 9 must answer the three coherence questions:
  - Does base price produce target margin against M8.2 unit economics?
  - Do segmentation rules produce average effective price ≥ base × 0.92?
  - Does scope premium schedule cover measured C7 scope-creep load?

  Hand-waving on these questions ("yes" without computation) fails this
  criterion.

  **Criterion 10 — Operator sign-off binding for 12 months**
  Section 10 must include operator's sign-off committing to the architecture
  for 12 months absent M8.7 schedule-triggered changes. Sign-offs with
  weakening language ("subject to circumstances") fail this criterion.

  ## How to write the review

  Same structure as prior reviewers:
  1. Score summary table
  2. Decision (CLEARED / NEEDS_REVISION / NOT_CLEARED)
  3. Per-criterion notes with specific section references
  4. Coherence-with-upstream flags (M8.2, M8.3 inconsistencies)
  5. M8.5 hand-off readiness assessment
  6. Final paragraph

  ## Decision thresholds

  - CLEARED: average ≥ 8.0, no criterion below 6.0
  - NEEDS_REVISION: average 6.0-7.9, OR any criterion 4.0-5.9
  - NOT_CLEARED: average < 6.0 OR any criterion < 4.0

  Sustainability margin path criterion (8) is weighted: failure on
  Criterion 8 alone routes to NEEDS_REVISION minimum, even if other
  criteria score well.

  ## Tone and discipline

  M8.4 is the most technical C8 module. Operators may produce well-formed
  documents that nonetheless fail coherence checks. Be specific in
  feedback: name the section, name the issue, name the correction.

  Architecture is rules-based, but the rules don't have to be the same as
  the C7 reference rules. Operators can deviate (e.g., specifying lower
  doctrine threshold than 60%) with documented rationale.

review_criteria:
  - architecture_inputs_documented
  - base_price_specified_with_cost_anchored_rationale
  - payment_terms_specify_deposit_threshold
  - refund_window_with_non_trigger_list
  - segmentation_rules_rules_based
  - four_quadrant_matrix_populated
  - scope_premium_schedule_specified
  - sustainability_margin_path_specified
  - architecture_coherence_check_addressed
  - operator_signoff_binding_12_months

decision_thresholds:
  CLEARED:
    average_min: 8.0
    no_criterion_below: 6.0
  NEEDS_REVISION:
    average_range: [6.0, 7.9]
    or_any_criterion_range: [4.0, 5.9]
    or_criterion_8_below: 6.0
  NOT_CLEARED:
    average_below: 6.0
    or_any_criterion_below: 4.0

instructor_handoff:
  triggered_when: NOT_CLEARED OR coherence_check_failure_persistent
  routing: C8 instructor queue, priority normal
  expected_resolution_window: 14 days from handoff

cooling_period_after_clearance:
  hours: 48
  rationale: >
    Architecture commits the operator to a 12-month system. The 48-hour
    cooling period before M8.5 ensures the operator has confirmed the
    architecture before building tier or scope-premium structures against it.

Complete supporting source — Pricing math spreadsheet specification

# Pricing Math Spreadsheet Template

**Version:** 1.0 · **Last updated:** April 25, 2026 · **Used in:** M8.2, M8.3, M8.4, M8.7, M8.8 quarterly reconciliation

---

## Purpose

A single spreadsheet that holds all pricing math for one offer through its first 12 months of operation. The operator opens this spreadsheet at M8.2, populates it with measured C7 data, and updates it quarterly thereafter. The spreadsheet is the live source of truth that feeds every C8 deliverable.

This is a markdown specification of the spreadsheet structure. The operator builds the spreadsheet in Google Sheets or Excel using the named columns, formulas, and tabs below. RISER does not provide a pre-built spreadsheet because operators who build their own internalize the math; operators who paste numbers into a pre-built template often do not.

---

## Tab 1 — Unit Economics

Column structure:

| Column | Purpose | Source |
|---|---|---|
| A: Delivery ID | Unique identifier per delivery (e.g., Sprint-001) | Operator-assigned |
| B: Customer | Customer name | Operator |
| C: Start date | Delivery start | Operator |
| D: End date | Delivery end | Operator |
| E: Stated price | Price quoted to customer | C4 / C7 |
| F: Stated hours | Hours estimated at quote time | C7 |
| G: Actual hours | Measured hours from delivery | C7 measurement system |
| H: Hidden hours | Pre-quote, scope-creep, post-delivery support | M8.2 audit |
| I: Total hours | F + H | Formula |
| J: Hourly cost | Operator-self loaded rate | M8.2 |
| K: Direct costs | Software, contractors, materials | M8.2 |
| L: Total cost | (I × J) + K | Formula |
| M: Gross margin $ | E - L | Formula |
| N: Gross margin % | M / E | Formula |
| O: Effective rate | E / I | Formula |

Target rows: one per delivery. Minimum 6 deliveries before M8.2 unit economics calculation reads as statistically meaningful. C7 capacity constraint analysis should have produced ≥ 8 deliveries; copy them all here.

---

## Tab 2 — Pricing Architecture

| Field | Value | Notes |
|---|---|---|
| Base price | | M8.4 architecture |
| Payment terms | | e.g., 50% deposit, 50% on delivery |
| Refund window | | e.g., 14 days |
| Refund triggers | | Specific behaviors that trigger refund |
| Standard tier price | | If three-tier; else N/A |
| Entry tier price | | If three-tier |
| Premium tier price | | If three-tier |
| Tier mix target | | e.g., 60/30/10 for std/entry/premium |
| Sustainability margin target | | M8.4; doctrine threshold 60% knowledge-work |

---

## Tab 3 — Anti-Discount Policy Compliance

| Column | Purpose |
|---|---|
| A: Date | When request received |
| B: Customer | Who asked |
| C: Request type | Discount sought (e.g., "remove deliverable", "first-customer rate") |
| D: Policy classification | Exception / Non-exception |
| E: Action taken | Decline / Discount granted |
| F: If granted, justification | Required if E=granted; should be empty in disciplined operation |
| G: Compliance score | 1 if action matched policy, 0 if deviated |

Quarterly: count deviations, divide by total requests, calculate compliance rate. Target: 100%. Below 95% triggers M8.6 policy review.

---

## Tab 4 — Price-Raise Trigger Tracker

| Column | Purpose |
|---|---|
| A: Trigger ID | T1-T4 (capacity, waitlist, demand, indexing) |
| B: Threshold | The trigger condition |
| C: Current reading | Updated monthly |
| D: Fired? | Y/N |
| E: Fired date | If Y |
| F: Raise executed date | Within 30 days of fire |
| G: Raise magnitude | % |
| H: Cumulative cap status | Used / remaining |

This tab enforces M8.7 discipline. The operator updates monthly; the Quarterly Reconciliation reads from it.

---

## Tab 5 — Quarterly Reconciliation

One row per quarter.

| Field | Computed from |
|---|---|
| Quarter | e.g., Q3-2026 |
| Avg gross margin % | Tab 1 N column avg |
| Avg effective rate | Tab 1 O column avg |
| Tier mix actual | Tab 1 customer breakdown |
| Tier mix variance | Actual vs Tab 2 target |
| Anti-discount compliance % | Tab 3 G avg |
| Triggers fired | Tab 4 D Y count |
| Raises executed | Tab 4 F populated count |
| Cumulative raise % | Tab 4 G sum |
| Deviation log entries | From Supabase deviation_log |
| Reconciliation memo link | Drive link |

---

## Setup Time

First-time setup: 2-3 hours including data import from C7. Quarterly maintenance: 60-90 minutes. Total annual time: ~10 hours. This is part of the operating cost of pricing discipline; budget it against operator overhead.

---

*This template is an output of M8.2 and an input to every subsequent C8 module and to all C9 distribution decisions.*

Complete supporting source — Customer and scope four-quadrant framework

# The Four-Quadrant Pricing Matrix

**Used in:** M8.4 Section 6, M8.6 policy enforcement, M8.7 raise communication

---

## The Matrix

| | New customer | Existing customer |
|---|---|---|
| **Standard scope** | Q1: New + Standard | Q2: Existing + Standard |
| **Custom scope** | Q3: New + Custom | Q4: Existing + Custom |

Every pricing situation falls into exactly one of these four quadrants. The matrix's function is to make pricing decisions automatic by quadrant rather than negotiated case-by-case.

---

## Quadrant 1 — New Customer, Standard Scope

**Description:** A new customer engaging for the standard offer at standard scope.

**Pricing rule:** Base price as specified in Pricing Architecture Document Section 2.

**Allowed deviations:** None. This is the cleanest quadrant; pricing is deterministic.

**Common pressure:** "First-customer pricing," "trial pricing," "we'll commit if you give us a starting rate." Per M8.6 non-exception list, all declined.

**Why this quadrant matters:** It's the quadrant most operators get right. The other three quadrants are where pricing leaks.

---

## Quadrant 2 — Existing Customer, Standard Scope

**Description:** An existing customer engaging for additional standard work at standard scope.

**Pricing rule:** Base price as specified, OR loyalty pricing per Anti-Discount Policy Section 2 (Exception List). Loyalty pricing applies only when the customer meets the structural conditions: ≥ N prior deliveries renewing within Y days. Outside those conditions, base price applies.

**Allowed deviations:** Only the structural loyalty exception. Discretionary "long-time customer" discounts are not allowed; the loyalty exception is rule-based.

**Common pressure:** "We've been a customer for X years, surely you can do something on the price." Per M8.6, the answer depends on whether the customer meets the structural condition. If yes, loyalty exception. If no, base price.

**Why this quadrant matters:** It's where existing-relationship pressure causes most operator concession. The structural rule converts emotion to arithmetic.

---

## Quadrant 3 — New Customer, Custom Scope

**Description:** A new customer requesting work that varies from standard scope (additional deliverables, different timeline, custom requirements).

**Pricing rule:** Base price + scope premium per Pricing Architecture Document Section 7. The scope premium schedule is rules-based: small additions trigger small premiums; major scope changes trigger re-quote.

**Allowed deviations:** Only those embedded in the scope premium schedule itself. Operators do not negotiate the schedule on the fly; if the schedule needs revision, that happens in M8.4 architecture review, not in live customer conversation.

**Common pressure:** "Can you bundle these into the standard price?" or "We need this small extra thing — surely you can include it." The scope premium schedule answers automatically: small extra (≤ 4 hrs) = +10%. Customer can accept or decline; operator does not negotiate the +10%.

**Why this quadrant matters:** It's where scope creep enters pricing. Without a schedule, every custom request becomes a negotiation. With a schedule, requests become arithmetic.

---

## Quadrant 4 — Existing Customer, Custom Scope

**Description:** An existing customer requesting custom work.

**Pricing rule:** Base price + scope premium per schedule. Loyalty exception (if applicable) applies to the base price component, not the scope premium component.

**Allowed deviations:** Combined application of Q2 and Q3 rules. No additional discretion.

**Common pressure:** Combined Q2 and Q3 pressures. "We're a long-time customer AND this is just a small addition; can you give us a break?" The matrix answers: loyalty exception applies to base if conditions met; scope premium applies to addition; both rules operate in parallel.

**Why this quadrant matters:** It's the most complex quadrant in negotiation feel but the simplest in matrix logic.

---

## What the Matrix Prevents

Without the matrix, operators face every pricing situation as a unique negotiation. With the matrix, situations are pre-classified and pre-priced. The cognitive load shifts from "what should I charge here" to "which quadrant is this and what does the rule say."

This shift is the point. Operators under live pricing pressure who must compute pricing on the fly tend to compute toward concession (because concession ends the conversation). Operators who reference a pre-built matrix tend to hold the line (because the rule is already decided and the conversation is about whether the customer fits the rule, not about what the rule should be).

---

## Common Quadrant Errors

### Error A: Treating Q4 as a discretionary zone

Operators sometimes treat existing-customer-custom-scope as a "we'll work it out" zone. The matrix forbids this. Q4 is rules + rules; both Q2 loyalty rule and Q3 scope rule apply.

### Error B: Slipping Q1 into Q3

Operators sometimes try to upsell new customers from standard scope to custom scope to capture scope premium revenue. This is sales pressure, not pricing discipline. If the customer wanted standard scope, Q1 applies. Don't manufacture custom scope to extract scope premium.

### Error C: Slipping Q3 into Q1

The reverse: operators sometimes absorb custom scope into standard scope to avoid the scope-premium conversation. This is reflexive concession. If the customer requested custom scope, Q3 applies; the scope premium is the price of custom delivery.

### Error D: Treating Q2 as default-discount zone

"Existing customers always get a discount." This converts loyalty from a structural exception to a default, which means the standard price is now whatever-existing-customers-pay. The matrix forbids this; loyalty applies only when structural conditions are met.

---

## Worked Example: Maya in Each Quadrant

**Q1 — New customer, standard Sprint:** Price $5,625. No deviation.

**Q2 — Existing customer (3 prior Sprints, renewing within 30 days), standard Sprint:** Loyalty pricing applies per M8.6 Section 2: 10% off, $5,063.

**Q3 — New customer, Sprint + additional brand identity element (estimated 3 hours):** Base $5,625 + 10% scope premium ($562) = $6,187.

**Q4 — Existing customer (4 prior Sprints, renewing within 30 days), Sprint + additional brand identity element (3 hours):** Base $5,625, loyalty discount on base ($562 off, base becomes $5,063), scope premium on addition (10% of original base = $562). Final: $5,063 + $562 = $5,625.

Note that Q4 results in the original base price by net effect (loyalty exception offsets scope premium in this specific magnitude). The matrix doesn't mind. The math is rule-driven; the result is whatever it is.

---

## Integration with Other C8 Artifacts

| Artifact | How it uses the matrix |
|---|---|
| M8.4 Pricing Architecture | Section 6 specifies the matrix |
| M8.6 Anti-Discount Policy | Exception list (Q2 loyalty) is structural; non-exception list (Q1, Q3 with no scope change) is held |
| M8.7 Price-Raise Schedule | Raises apply to base; scope premium is % of base, so raises propagate automatically |
| M8.8 Attestation | Section 8 coherence question: does loyalty (Q2) accommodate annual indexing (M8.7 T4)? |

---

*The matrix is the structural enforcement device. Anti-discount policy without the matrix is a list of rules without an implementation; the matrix is the implementation. Operators who reference the matrix in live conversations tend to hold pricing; operators who do not reference it tend to negotiate.*

Native Google Doc text and original links

M8.4 — Pricing Architecture Construction: The Multi-Dimensional System
Module Outcome: [Create] Student has applied the 6% Rule to pricing patterns; specified base price, payment terms, refund window, and segmentation logic; positioned the offer on the four-quadrant pricing matrix; produced the Pricing Architecture Document that implements the M8.3 branch decision and serves as the primary input to M8.5-M8.7. Key Deliverable: Pricing Architecture Document (Pricing-Architecture-Document-[YourName]-[Date].md, 1,500-2,000 words, eight sections) Infrastructure Dependency: Build 6, Build 8 Drive folder, Supabase c8_pricing_architectures table, Claude prompt pricing-architecture-reviewer-v1.0.0 (Sonnet), Pricing-Math-Spreadsheet template, Four-Quadrant Pricing Matrix Framework Checkpoint / Test: Type 1 Artifact + Type 2 AI rubric ≥ 7/10 Blocked-Until Prerequisite: M8.3 Reality Check Document filed AND AI rubric ≥ 7/10 AND 48-hour cooling period elapsed since M8.3 filing

What This Module Does
M8.4 is the deepest module of C8 in active hours. Six things happen:

You apply the 6% Rule to pricing: scan 16+ pricing patterns from market and competitor data to identify the 1-2 strongest models for your offer's structural shape. The rule's discipline is the same as in C1 (sixteen patterns minimum); the application context shifts from operator-pattern selection to pricing-pattern selection.

You specify the base price for the corrected offer (post-M8.3 decision), grounded in the unit economics target margin. The base price is not the M8.3 target rounded; it is the M8.3 target tested against the chosen pricing pattern, the operator identity, and the C7 capacity ceiling.

You specify payment terms: pay-in-full discount (if any), installment plan structure (if any), payment-plan default and late-payment provisions. Payment terms have margin implications that the M8.2 math may not have captured (a 3-pay plan with a 2.9% per-transaction processing fee triples the processing cost compared to pay-in-full).

You specify the refund window: duration, conditions, partial-refund formula if applicable. The refund window aligns with the C4 M4.6 Guarantee Architecture — strengthened or refined per M8.4 work but not weakened.

You specify segmentation logic: when do different customer types pay different prices (cohort early-bird, partner referral, scholarship case, regional pricing), and what is the documented rationale? If uniform pricing, document why uniformity was chosen.

You position the offer on the four-quadrant pricing matrix along the value axis (low ↔ high) and access axis (broad ↔ narrow). The quadrant must match operator identity; mismatches are flagged.

Why This Module Matters
The M8.3 decision branch named what to do (raise prices for new, narrow scope, kill, or accept legacy). M8.4 specifies how. Pricing without architecture is a number floating in space; pricing with architecture is a system that handles the dozens of pricing-adjacent decisions the next 12 months will surface (the prospect asking for installments, the partner asking for affiliate terms, the regional-market customer asking about geographic pricing, the next-cohort prospect asking why pricing changed).

Architectural pricing has six structural advantages over single-number pricing:

Decision pre-emption. The architecture handles common pricing questions without ad-hoc judgment. When a prospect asks for an installment plan, the architecture answers; the operator does not have to decide in the moment.
Margin protection at edges. Payment processing fees, partial refunds, and late payments all erode margin if not specified upfront. The architecture quantifies the erosion.
Communication clarity. Customers experience a coherent pricing story when architecture is documented; they experience inconsistency when each decision is ad-hoc.
Audit traceability. When the operator looks back and asks "why did I price this customer this way?" the architecture answers; ad-hoc memory does not.
Scaling readiness. Stage 3 expansion (C11+) requires pricing that operates without operator intervention on most decisions. Architecture is the input to that scaling.
Self-respect operationalization. The doctrine "Pricing Is Operator Self-Respect" becomes operational through architecture; without architecture, the doctrine is aspirational.

The 6% Rule Applied to Pricing Patterns
The 6% Rule (originating from C1) holds that a 1-in-16 selection rate produces structurally better choices than first-thought selection. Applied to pricing, the rule directs the operator to scan at least 16 pricing patterns from market and competitor data before specifying their own.

Pricing patterns are not the same as pricing levels. A pricing pattern is a structural model for how price relates to value, scope, customer count, and time. Common patterns include:

Flat fixed price — single price for single offer scope (Maya's $4,500 Sprint at C4)
Tiered fixed price — two or three discrete tiers (Standard / Premium / VIP)
Per-unit pricing — price scales with measurable units (per session, per word, per project)
Hourly billing — price scales with hours; Stark's caution on hidden incentives applies
Project-based with revisions cap — fixed price for defined scope, additional fee per revision beyond cap
Retainer / subscription — recurring fixed fee for recurring access
Cohort pricing — fixed price per seat in a time-bound cohort (Darius's Reading Club at $1,200/seat)
Pay-what-you-can / sliding scale — variable price by customer self-determination within bounds
Performance-based — price scales with measurable outcomes (e.g., percentage of revenue generated)
Hybrid base + performance — fixed base + outcome-tied bonus
Per-customer-of-customer — pricing scales with the customer's customer count (B2B common)
Geographic / regional pricing — different prices by customer geography (controversial; Hermann Simon notes implementation difficulty)
Cohort early-bird / late — price varies by time of cohort enrollment relative to start
Partner / affiliate pricing — discount available to customers from designated partner channels
Scholarship / need-based pricing — discounted access for documented need cases
Productized fixed-scope — single price, no scope variation, no customization
Value-based with anchor — pricing tied to the customer's value capture, anchored to a reference
Ladder pricing — entry product → main product → continuity (Brunson's ladder)
Day-rate / week-rate — fixed time blocks at fixed rates
Outcome-guarantee pricing — price tied to outcome with refund/credit if outcome not achieved

The operator scans these 16-20+ patterns against their offer shape and selects 1-2 candidates that fit best. The selection criteria:

Match to operator identity (Service / Teacher / Builder)
Match to mechanism (the C2 M2.7 hypothesis structurally)
Match to customer experience expectation (what does the audience expect at this price level?)
Match to operator capacity ceiling (some patterns require concurrent-customer counts the M7.5 ceiling cannot support)
Match to operator's anti-discount discipline (some patterns embed discounting into the architecture in ways the operator cannot defend)

For Maya's Portfolio-to-Licensing Sprint:

Scanned all 20 patterns
Filtered to: flat fixed price (current pattern, refined), project-based with revisions cap, retainer, productized fixed-scope, value-based with anchor
Compared each: flat fixed price fits the 12-week defined scope; productized fixed-scope eliminates the customization Maya intentionally provides; retainer doesn't fit the time-bounded mechanism; value-based with anchor would require Maya to capture downstream licensing income (complex for a coaching engagement)
Selected: Flat fixed price refined with explicit scope boundaries and revisions cap. New base price target from M8.3: $6,750.

For Darius's Reading Club:

Scanned all 20 patterns
Filtered to: cohort pricing (current pattern), per-individual subscription, hybrid base + outcome, productized fixed-scope, ladder pricing
Compared each: cohort pricing has the structural problem M8.2 surfaced (3 of 12 seats produces disastrous unit economics); per-individual subscription decouples pricing from cohort dynamics; ladder pricing introduces a low-cost entry product that funnels to the cohort
Selected: Per-individual subscription ($300/month for 3-month minimum commitment) plus optional cohort upgrade ($300 cohort fee added when cohort runs at 8+ enrollment). This solves the structural problem from M8.2 (the cohort's economics no longer depend on hitting 12 seats; individual subscription supports the offer at any seat count).

The 6% Rule scan takes 2-3 hours of active work and produces materially better pricing patterns than first-thought selection.

Base Price Specification
After the 6% Rule scan, you specify the base price for the corrected offer.

Inputs:

M8.3 decision branch and price target
Selected pricing pattern from the 6% Rule scan
Operator identity (Service / Teacher / Builder)
Capacity ceiling × stated minimum target hours
Competitive scan benchmark range

Specification template:

Payment Terms Specification
Payment terms are not optional. Even if you offer pay-in-full only, document that explicitly.

Inputs:

Base price from the prior section
Customer cash-flow expectations (from C3 audience research)
Operator cash-flow needs (from C6 financial baseline)
Payment processor fee structure (Stripe ~2.9% + $0.30; PayPal similar)

Specification template:

Refund Window Specification
The refund window aligns with the C4 M4.6 Guarantee Architecture but may be refined per M8.4 work.

Inputs:

C4 M4.6 Guarantee Architecture
C7 v2.0 offer document refund language
M8.6 anti-discount policy (referenced forward)

Specification template:

For Darius: 30 days from subscription start; refund qualifies if cancellation request received before Day 30; full refund of first month's payment; subsequent months non-refundable.

Segmentation Logic Specification
Segmentation is the most error-prone area of M8.4. Many operators want to offer different prices to different customer types but lack the discipline to do so coherently.

Three legitimate segmentation patterns:

Cohort timing segmentation: early-bird vs. standard vs. late pricing for time-bound cohorts. Discount typically 10-20% for early-bird; rationale is cash-flow-forward and conversion-de-risking. Anti-discount policy must specify this is a time-bound cohort discount, not a negotiation discount.

Partner / affiliate segmentation: designated partners can offer the operator's offer to their network at a discount, with the partner taking a commission. The arithmetic must work: if partner takes 20% commission and discount is 15%, operator nets 65% of base price; this must still produce sustainable margin.

Scholarship / need-based segmentation: documented need cases at reduced price; operator commits to a defined number per cohort/year (typically 1-2 per year). Rationale: portfolio-builder, mission-aligned access. Specific to the operator's identity and stage.

Anti-segmentation patterns to avoid:

Negotiated discounts ("special deal for you because we got along well") — destroys pricing coherence
Loyalty discounts ("returning customer gets 15% off") — erodes margin without structural justification
Geographic / regional pricing without strong defensible rationale — Hermann Simon notes high implementation difficulty and high arbitrage risk
Hardship discounts without defined need-based criteria — slips into negotiation territory
Comparable-competitor matching ("your competitor charges X, I'll match") — abandons the architecture entirely

If uniform pricing (no segmentation): document why. Operators who select uniform pricing typically cite operator identity, simplicity preference, and discipline against ad-hoc adjustment.

Four-Quadrant Pricing Matrix
The matrix positions the offer along two axes: value (low ↔ high) and access (broad ↔ narrow).

Narrow Access

Low Value | High Value

Narrow Access | Narrow Access

──────────────────────────────────

Low Value | High Value

Broad Access | Broad Access

Broad Access

The four quadrants:

Q3 (Low Value, Narrow Access): Boutique low-price offerings. Rare in knowledge-work; usually indicates an operator who is under-priced. Identity match: rare; usually misalignment.

The operator positions their offer in the matrix and verifies the position matches operator identity:

Service-Operator pricing typically lives in Q4 (or upper Q2 if productized)
Teacher-Operator pricing typically lives in Q2 (cohort) or Q1 (self-paced)
Builder-Operator pricing typically lives in Q1 or Q2 (productized scaling)

For Maya: Q4 (High Value, Narrow Access) at $6,750 with intensive 1:1 coaching. Identity match: Service-Operator. Coherent.

For Darius: Q2 (High Value, Broad Access) at $300/month subscription with cohort access. Identity match: Teacher-Operator at scale. Coherent.

The Eight-Section Document Template
Your Pricing Architecture Document is 1,500-2,000 words, with eight sections:
Section 1 — M8.3 Branch and Implementation Bridge (100-150 words)
State which M8.3 branch you committed to and how M8.4 architecture implements it. Brief — most of the architecture work is below.
Section 2 — 6% Rule Pricing Pattern Scan (200-300 words)
List 16+ pricing patterns scanned. Show your filtering: which patterns survived initial screening, which were eliminated and why, which 1-2 were selected. Show your selection criteria explicitly.
Section 3 — Base Price Specification (200-300 words)
Specify the base price with the five rationale lines (source, competitive position, identity coherence, capacity coherence, and structural test).
Section 4 — Payment Terms Specification (200-250 words)
Specify pay-in-full discount, installment structure, default provisions, late-payment provisions, processing-fee handling. Show the margin impact of payment-term decisions.
Section 5 — Refund Window Specification (150-200 words)
Specify duration, conditions, refund amount, partial-refund formula, anti-promise alignment.
Section 6 — Segmentation Logic Specification (200-300 words)
Specify segmentation patterns selected (cohort timing / partner / scholarship) or document uniform pricing. If segmented, show the math: does the segmented pricing still produce sustainable margin?
Section 7 — Four-Quadrant Matrix Positioning (150-200 words)
State which quadrant the offer occupies, the rationale for positioning, and the identity coherence verification.
Section 8 — Cross-References (100-150 words)
Specify what M8.5 (tier design), M8.6 (anti-discount), and M8.7 (raise schedule) will need from this architecture. Be specific about inputs.

Worked Example: Maya's Pricing Architecture
Maya's M8.4 sittings:

Common Failure Modes at M8.4
The Sonnet pricing-architecture-reviewer-v1.0.0 prompt and the AI rubric look for these:

Skipping the 6% Rule scan. Operator specifies a pricing pattern as the first-thought selection without showing the 16+ scan. The AI rubric flags any document that lists fewer than 16 patterns.

Aspirational base price. Operator specifies a base price that is not grounded in M8.3 unit economics or competitive scan. The price is a wish, not an architectural choice. The rubric expects each rationale line cited.

Payment terms with margin erosion uncalculated. Operator specifies installment plans without computing the margin impact (processing fees, default risk).

Refund window misaligned with C4 M4.6. Operator specifies a refund window inconsistent with the existing Guarantee Architecture without explanation.

Segmentation pattern slipping into negotiation. Operator specifies "case-by-case discounts for fit" or similar; the AI rubric flags this as ad-hoc, not architectural.

Quadrant misalignment. Operator's identity (Service-Operator) doesn't match the quadrant (Q1 Low Value Broad Access). The mismatch is a signal; the operator should re-examine pattern selection.

Section 8 cross-references missing. Operator does not specify M8.5/M8.6/M8.7 input requirements; the next modules will start without context.

Checkpoint 8.4
Your deliverable is:

Pricing Architecture Document filed in Drive, 1,500-2,000 words, eight sections
Pricing pattern selection recorded in Supabase c8_pricing_architectures.selected_pattern
Base price recorded in c8_pricing_architectures.base_price
Quadrant positioning recorded in c8_pricing_architectures.matrix_quadrant

The AI rubric scoring the document looks for eight properties:

6% Rule scan with 16+ patterns shown and filtered
Base price with all five rationale lines
Payment terms with margin impact computed
Refund window aligned with C4 M4.6
Segmentation logic specific (or uniform with documented rationale)
Quadrant positioning with identity coherence verification
Cross-references to M8.5/M8.6/M8.7 inputs
All eight sections meet word-count targets

What M8.5 Expects From You
M8.5 opens with the assumption that your pricing architecture is filed and architecturally coherent. M8.5 begins by asking whether your offer is appropriate for tiered pricing — the Tier Appropriateness Diagnostic. If yes, M8.5 designs three tiers (entry/standard/premium) with structurally different deliverables. If no, M8.5 documents the flat-pricing rationale with the diagnostic findings.

The M8.4 base price feeds into M8.5: if tiered, the base price typically becomes the standard tier's price, with entry below and premium above. If flat, the base price is the price.

File the Pricing Architecture Document. Proceed to M8.5.

Last updated: April 25, 2026 · Version 2.0

M8.4-Written-Lesson.md

Turn a pricing decision into an operating specification

Cover all six dimensions

Use the six benefits as design goals

Treat the 6% scan as a structured comparison

Pricing pattern — Flat fixed price

A single price for a clearly defined scope; control additions and acceptance criteria. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Tiered fixed price

Two or three packages with meaningful differences; cost and explain each package. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Per-unit

Price by a measurable unit such as session, word or project; define the unit and minimums. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Hourly

Pricing pattern — Project with a revision cap

Fix the core scope and revision allowance, with clearly disclosed charges or change approval beyond it. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Retainer or subscription

Charge recurring fees for specified recurring service or access, with clear renewal/cancellation terms. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Cohort seat

Price per participant in a time-bound group; model fixed cohort costs and minimum viable enrollment. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Sliding scale or pay-what-you-can

Define bounds and eligibility/choice rules; model whether the mix supports delivery. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Performance-based

Tie payment to a defined outcome with credible measurement, attribution and agreed limits. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Base plus performance

Use a fixed component plus an outcome-based component; specify both calculation bases. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Per customer-of-customer

Scale a B2B charge with the client’s customer count; define reporting, tiers and reconciliation. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Geographic or regional

Pricing pattern — Cohort early/late enrollment

Use genuine dates and clear price changes, explaining the planning benefit and cutoff. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Partner or affiliate

Define customer price and partner compensation separately, including the commission base and refund treatment. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Scholarship or need-based

Specify eligibility, allocation limits and funding rather than improvising exceptions under pressure. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Productized fixed scope

Offer a repeatable bounded service with explicit limits on customization. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Value-based with an anchor

Relate price to supported customer value and an honest comparison; avoid fabricated savings or reference prices. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Value ladder

Connect entry, core and continuing offers to successive customer needs without assuming every buyer must ascend. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Day or week rate

Sell a defined time block with scope, availability and overrun rules. This is one of the source’s twenty patterns, not a recommendation for every offer.

Pricing pattern — Outcome-guarantee pricing

Specify the covered result, conditions and refund or credit remedy, then cost the commitment. This is one of the source’s twenty patterns, not a recommendation for every offer.

Read the two pattern selections critically

Ground the base price in evidence

Keep revenue, margin and owner income separate

Specify all payment-term fields

Correct the processing-fee calculation

Correct discounts and installment premiums

Avoid unsupported payment psychology rules

Separate the Maya and Darius payment examples

Define refunds without contradictory wording

Evaluate refund cost and customer clarity

Document segmentation rather than improvising it

Calculate partner compensation on the stated base

Keep segmentation examples internally consistent

Use the value/access matrix — Q1: lower value, broad access

Use the value/access matrix — Q2: higher value, broad access

Use the value/access matrix — Q3: lower value, narrow access

Use the value/access matrix — Q4: higher value, narrow access

Position the examples without turning labels into evidence

Pricing Architecture Document section 1 — Branch and bridge

100–150 words linking the M8.3 decision to this implementation. Keep linked evidence beside the relevant decision.

Pricing Architecture Document section 2 — Pattern scan

200–300 words listing sixteen-plus patterns, filters, rejected options and the selected one or two. Keep linked evidence beside the relevant decision.

Pricing Architecture Document section 3 — Base price

200–300 words with the price, source evidence, competitive position, identity/capacity coherence and structural test. Keep linked evidence beside the relevant decision.

Pricing Architecture Document section 4 — Payment terms

200–250 words covering payment structure, failures, fees and margin implications. Keep linked evidence beside the relevant decision.

Pricing Architecture Document section 5 — Refunds

150–200 words covering window, conditions, amount, partial formula and promise alignment. Keep linked evidence beside the relevant decision.

Pricing Architecture Document section 6 — Segmentation

200–300 words describing planned cases or justified uniform pricing, with sustainable economics. Keep linked evidence beside the relevant decision.

Pricing Architecture Document section 7 — Matrix

150–200 words explaining the value/access position and delivery-model fit. Keep linked evidence beside the relevant decision.

Pricing Architecture Document section 8 — Handoffs

100–150 words specifying the inputs needed by tier design, discount policy and raise scheduling. Keep linked evidence beside the relevant decision.

Reconcile the document-length targets

Check seven common failure modes

Complete the architecture checkpoint honestly

Connect the lesson to the direct-marketing promise

Read the alternate ten-section pricing review

Apply pricing review numbers as declared policy

Resolve the reviewer’s incompatible thresholds

Produce an auditable pricing review and handoff

Build the five-tab pricing workbook deliberately

Correct the delivery formulas before using them

Separate architecture rules from observed results

Correct the exception-log compliance calculation

Track trigger decisions without silently executing raises

Use weighted and time-consistent quarterly summaries

Distinguish the two four-quadrant tools

Reconcile loyalty rules and worked amounts

Prevent the four quadrant pricing errors

Complete original source text

# M8.4 — Pricing Architecture Construction: The Multi-Dimensional System

**Module Outcome:** [Create] Student has applied the 6% Rule to pricing patterns; specified base price, payment terms, refund window, and segmentation logic; positioned the offer on the four-quadrant pricing matrix; produced the Pricing Architecture Document that implements the M8.3 branch decision and serves as the primary input to M8.5-M8.7.
**Key Deliverable:** Pricing Architecture Document (`Pricing-Architecture-Document-[YourName]-[Date].md`, 1,500-2,000 words, eight sections)
**Infrastructure Dependency:** Build 6, Build 8 Drive folder, Supabase `c8_pricing_architectures` table, Claude prompt `pricing-architecture-reviewer-v1.0.0` (Sonnet), Pricing-Math-Spreadsheet template, Four-Quadrant Pricing Matrix Framework
**Checkpoint / Test:** Type 1 Artifact + Type 2 AI rubric ≥ 7/10
**Blocked-Until Prerequisite:** M8.3 Reality Check Document filed AND AI rubric ≥ 7/10 AND 48-hour cooling period elapsed since M8.3 filing

---

## What This Module Does

M8.4 is the deepest module of C8 in active hours. Six things happen:

1. You **apply the 6% Rule to pricing**: scan 16+ pricing patterns from market and competitor data to identify the 1-2 strongest models for your offer's structural shape. The rule's discipline is the same as in C1 (sixteen patterns minimum); the application context shifts from operator-pattern selection to pricing-pattern selection.

2. You **specify the base price** for the corrected offer (post-M8.3 decision), grounded in the unit economics target margin. The base price is not the M8.3 target rounded; it is the M8.3 target tested against the chosen pricing pattern, the operator identity, and the C7 capacity ceiling.

3. You **specify payment terms**: pay-in-full discount (if any), installment plan structure (if any), payment-plan default and late-payment provisions. Payment terms have margin implications that the M8.2 math may not have captured (a 3-pay plan with a 2.9% per-transaction processing fee triples the processing cost compared to pay-in-full).

4. You **specify the refund window**: duration, conditions, partial-refund formula if applicable. The refund window aligns with the C4 M4.6 Guarantee Architecture — strengthened or refined per M8.4 work but not weakened.

5. You **specify segmentation logic**: when do different customer types pay different prices (cohort early-bird, partner referral, scholarship case, regional pricing), and what is the documented rationale? If uniform pricing, document why uniformity was chosen.

6. You **position the offer on the four-quadrant pricing matrix** along the value axis (low ↔ high) and access axis (broad ↔ narrow). The quadrant must match operator identity; mismatches are flagged.

The deliverable is the **Pricing Architecture Document** — 1,500-2,000 words, eight sections. The document is the primary input to M8.5 (tier design), M8.6 (anti-discount policy), and M8.7 (raise schedule). It is the densest pricing artifact in C8 and the most heavily cross-referenced.

---

## Why This Module Matters

Architectural pricing has six structural advantages over single-number pricing:

1. **Decision pre-emption.** The architecture handles common pricing questions without ad-hoc judgment. When a prospect asks for an installment plan, the architecture answers; the operator does not have to decide in the moment.
2. **Margin protection at edges.** Payment processing fees, partial refunds, and late payments all erode margin if not specified upfront. The architecture quantifies the erosion.
3. **Communication clarity.** Customers experience a coherent pricing story when architecture is documented; they experience inconsistency when each decision is ad-hoc.
4. **Audit traceability.** When the operator looks back and asks "why did I price this customer this way?" the architecture answers; ad-hoc memory does not.
5. **Scaling readiness.** Stage 3 expansion (C11+) requires pricing that operates without operator intervention on most decisions. Architecture is the input to that scaling.
6. **Self-respect operationalization.** The doctrine "Pricing Is Operator Self-Respect" becomes operational through architecture; without architecture, the doctrine is aspirational.

---

## The 6% Rule Applied to Pricing Patterns

Pricing patterns are not the same as pricing levels. A pricing pattern is a structural model for how price relates to value, scope, customer count, and time. Common patterns include:

1. **Flat fixed price** — single price for single offer scope (Maya's $4,500 Sprint at C4)
2. **Tiered fixed price** — two or three discrete tiers (Standard / Premium / VIP)
3. **Per-unit pricing** — price scales with measurable units (per session, per word, per project)
4. **Hourly billing** — price scales with hours; Stark's caution on hidden incentives applies
5. **Project-based with revisions cap** — fixed price for defined scope, additional fee per revision beyond cap
6. **Retainer / subscription** — recurring fixed fee for recurring access
7. **Cohort pricing** — fixed price per seat in a time-bound cohort (Darius's Reading Club at $1,200/seat)
8. **Pay-what-you-can / sliding scale** — variable price by customer self-determination within bounds
9. **Performance-based** — price scales with measurable outcomes (e.g., percentage of revenue generated)
10. **Hybrid base + performance** — fixed base + outcome-tied bonus
11. **Per-customer-of-customer** — pricing scales with the customer's customer count (B2B common)
12. **Geographic / regional pricing** — different prices by customer geography (controversial; Hermann Simon notes implementation difficulty)
13. **Cohort early-bird / late** — price varies by time of cohort enrollment relative to start
14. **Partner / affiliate pricing** — discount available to customers from designated partner channels
15. **Scholarship / need-based pricing** — discounted access for documented need cases
16. **Productized fixed-scope** — single price, no scope variation, no customization
17. **Value-based with anchor** — pricing tied to the customer's value capture, anchored to a reference
18. **Ladder pricing** — entry product → main product → continuity (Brunson's ladder)
19. **Day-rate / week-rate** — fixed time blocks at fixed rates
20. **Outcome-guarantee pricing** — price tied to outcome with refund/credit if outcome not achieved

The operator scans these 16-20+ patterns against their offer shape and selects 1-2 candidates that fit best. The selection criteria:

- **Match to operator identity** (Service / Teacher / Builder)
- **Match to mechanism** (the C2 M2.7 hypothesis structurally)
- **Match to customer experience expectation** (what does the audience expect at this price level?)
- **Match to operator capacity ceiling** (some patterns require concurrent-customer counts the M7.5 ceiling cannot support)
- **Match to operator's anti-discount discipline** (some patterns embed discounting into the architecture in ways the operator cannot defend)

For Maya's Portfolio-to-Licensing Sprint:
- Scanned all 20 patterns
- Filtered to: flat fixed price (current pattern, refined), project-based with revisions cap, retainer, productized fixed-scope, value-based with anchor
- Compared each: flat fixed price fits the 12-week defined scope; productized fixed-scope eliminates the customization Maya intentionally provides; retainer doesn't fit the time-bounded mechanism; value-based with anchor would require Maya to capture downstream licensing income (complex for a coaching engagement)
- **Selected:** Flat fixed price refined with explicit scope boundaries and revisions cap. New base price target from M8.3: $6,750.

For Darius's Reading Club:
- Scanned all 20 patterns
- Filtered to: cohort pricing (current pattern), per-individual subscription, hybrid base + outcome, productized fixed-scope, ladder pricing
- Compared each: cohort pricing has the structural problem M8.2 surfaced (3 of 12 seats produces disastrous unit economics); per-individual subscription decouples pricing from cohort dynamics; ladder pricing introduces a low-cost entry product that funnels to the cohort
- **Selected:** Per-individual subscription ($300/month for 3-month minimum commitment) plus optional cohort upgrade ($300 cohort fee added when cohort runs at 8+ enrollment). This solves the structural problem from M8.2 (the cohort's economics no longer depend on hitting 12 seats; individual subscription supports the offer at any seat count).

The 6% Rule scan takes 2-3 hours of active work and produces materially better pricing patterns than first-thought selection.

---

## Base Price Specification

After the 6% Rule scan, you specify the base price for the corrected offer.

**Inputs:**
- M8.3 decision branch and price target
- Selected pricing pattern from the 6% Rule scan
- Operator identity (Service / Teacher / Builder)
- Capacity ceiling × stated minimum target hours
- Competitive scan benchmark range

**Specification template:**

> Base price: $[X]
> Pricing pattern: [Pattern from 6% Rule selection]
> Source rationale: [link to M8.2 unit economics target margin and M8.3 decision branch]
> Competitive position: [position relative to scanned competitive offers — e.g., "$6,750 places this offer at the 60th percentile of comparable offers in the senior-illustrator coaching market, range $5,000-$8,500"]
> Identity coherence: [Service-Operator pricing tone explanation — e.g., "premium positioning is consistent with the Sprint's intensive-personal-attention delivery"]
> Capacity coherence: [check against M7.5 — e.g., "at $6,750 × 4 concurrent × 4 turns/year = $108,000 max annual revenue, exceeds operator income target with 25% margin headroom"]

---

## Payment Terms Specification

Payment terms are not optional. Even if you offer pay-in-full only, document that explicitly.

**Inputs:**
- Base price from the prior section
- Customer cash-flow expectations (from C3 audience research)
- Operator cash-flow needs (from C6 financial baseline)
- Payment processor fee structure (Stripe ~2.9% + $0.30; PayPal similar)

**Specification template:**

> Pay-in-full: [yes/no, and discount if any — e.g., "5% pay-in-full discount, base $6,750 → $6,413"]
> Installment plan: [yes/no, and structure — e.g., "3-pay at $2,250/month, no discount; 6-pay at $1,150/month, 2% premium"]
> Default provisions: [what happens if a payment fails — e.g., "automatic retry at day 1, day 3, day 5; access pause at day 7; engagement termination at day 14 with 50% balance forgiveness"]
> Late-payment fees: [yes/no — e.g., "no late fees but engagement pauses on missed payment"]
> Processing fee absorbed: [operator absorbs or passed to customer — e.g., "operator absorbs Stripe fee on pay-in-full; customer absorbs ~$10 processing fee on per-installment basis"]

---

## Refund Window Specification

The refund window aligns with the C4 M4.6 Guarantee Architecture but may be refined per M8.4 work.

**Inputs:**
- C4 M4.6 Guarantee Architecture
- C7 v2.0 offer document refund language
- M8.6 anti-discount policy (referenced forward)

**Specification template:**

> Refund window: [duration — e.g., "14 days from engagement start"]
> Refund conditions: [what qualifies — e.g., "if the customer has completed Module 1 sessions and concludes the Sprint is not the right fit"]
> Refund amount: [full / partial — e.g., "full refund minus $200 administrative fee"]
> Partial refund formula (for mid-engagement): [if applicable — e.g., "after Module 1, prorated by remaining modules; after Module 4, no refund"]
> Anti-promise alignment: [reference C4 M4.5 — e.g., "consistent with anti-promise that Sprint outcome depends on customer's specific licensing portfolio readiness"]

For Darius: 30 days from subscription start; refund qualifies if cancellation request received before Day 30; full refund of first month's payment; subsequent months non-refundable.

---

## Segmentation Logic Specification

Segmentation is the most error-prone area of M8.4. Many operators want to offer different prices to different customer types but lack the discipline to do so coherently.

**Three legitimate segmentation patterns:**

1. **Cohort timing segmentation:** early-bird vs. standard vs. late pricing for time-bound cohorts. Discount typically 10-20% for early-bird; rationale is cash-flow-forward and conversion-de-risking. Anti-discount policy must specify this is a time-bound cohort discount, not a negotiation discount.

2. **Partner / affiliate segmentation:** designated partners can offer the operator's offer to their network at a discount, with the partner taking a commission. The arithmetic must work: if partner takes 20% commission and discount is 15%, operator nets 65% of base price; this must still produce sustainable margin.

3. **Scholarship / need-based segmentation:** documented need cases at reduced price; operator commits to a defined number per cohort/year (typically 1-2 per year). Rationale: portfolio-builder, mission-aligned access. Specific to the operator's identity and stage.

**Anti-segmentation patterns to avoid:**

- **Negotiated discounts** ("special deal for you because we got along well") — destroys pricing coherence
- **Loyalty discounts** ("returning customer gets 15% off") — erodes margin without structural justification
- **Geographic / regional pricing** without strong defensible rationale — Hermann Simon notes high implementation difficulty and high arbitrage risk
- **Hardship discounts** without defined need-based criteria — slips into negotiation territory
- **Comparable-competitor matching** ("your competitor charges X, I'll match") — abandons the architecture entirely

**If uniform pricing (no segmentation):** document why. Operators who select uniform pricing typically cite operator identity, simplicity preference, and discipline against ad-hoc adjustment.

---

## Four-Quadrant Pricing Matrix

The matrix positions the offer along two axes: value (low ↔ high) and access (broad ↔ narrow).

The four quadrants:

**Q1 (Low Value, Broad Access):** Mass-market commodity pricing. Examples: $9 ebooks, $50 templates, $30/month basic SaaS. Volume-driven economics. Identity match: Builder-Operator scaling productized output.

**Q2 (High Value, Broad Access):** Premium product widely available. Examples: $200 books with broad distribution, $500-$2,000 self-paced courses, $5,000-$20,000 annual SaaS. Identity match: Teacher-Operator at scale or Builder-Operator with brand premium.

**Q3 (Low Value, Narrow Access):** Boutique low-price offerings. Rare in knowledge-work; usually indicates an operator who is under-priced. Identity match: rare; usually misalignment.

**Q4 (High Value, Narrow Access):** Premium bespoke / coaching / advisory. Examples: $5,000-$50,000 personal coaching, $25,000-$200,000 advisory engagements, $50,000+ executive consulting. Identity match: Service-Operator with intensive personal attention.

The operator positions their offer in the matrix and verifies the position matches operator identity:

- Service-Operator pricing typically lives in Q4 (or upper Q2 if productized)
- Teacher-Operator pricing typically lives in Q2 (cohort) or Q1 (self-paced)
- Builder-Operator pricing typically lives in Q1 or Q2 (productized scaling)

For Maya: Q4 (High Value, Narrow Access) at $6,750 with intensive 1:1 coaching. Identity match: Service-Operator. Coherent.

For Darius: Q2 (High Value, Broad Access) at $300/month subscription with cohort access. Identity match: Teacher-Operator at scale. Coherent.

---

## The Eight-Section Document Template

Your Pricing Architecture Document is 1,500-2,000 words, with eight sections:

### Section 1 — M8.3 Branch and Implementation Bridge (100-150 words)
State which M8.3 branch you committed to and how M8.4 architecture implements it. Brief — most of the architecture work is below.

### Section 2 — 6% Rule Pricing Pattern Scan (200-300 words)
List 16+ pricing patterns scanned. Show your filtering: which patterns survived initial screening, which were eliminated and why, which 1-2 were selected. Show your selection criteria explicitly.

### Section 3 — Base Price Specification (200-300 words)
Specify the base price with the five rationale lines (source, competitive position, identity coherence, capacity coherence, and structural test).

### Section 4 — Payment Terms Specification (200-250 words)
Specify pay-in-full discount, installment structure, default provisions, late-payment provisions, processing-fee handling. Show the margin impact of payment-term decisions.

### Section 5 — Refund Window Specification (150-200 words)
Specify duration, conditions, refund amount, partial-refund formula, anti-promise alignment.

### Section 6 — Segmentation Logic Specification (200-300 words)
Specify segmentation patterns selected (cohort timing / partner / scholarship) or document uniform pricing. If segmented, show the math: does the segmented pricing still produce sustainable margin?

### Section 7 — Four-Quadrant Matrix Positioning (150-200 words)
State which quadrant the offer occupies, the rationale for positioning, and the identity coherence verification.

### Section 8 — Cross-References (100-150 words)
Specify what M8.5 (tier design), M8.6 (anti-discount), and M8.7 (raise schedule) will need from this architecture. Be specific about inputs.

---

## Worked Example: Maya's Pricing Architecture

Maya's M8.4 sittings:

**Sitting 1 (3 hours): 6% Rule scan.** Maya scanned 20 pricing patterns. Filtered to 5: flat fixed, project-based with revisions cap, retainer, productized fixed-scope, value-based with anchor. Selected: flat fixed price refined with explicit scope boundaries and revisions cap.

**Sitting 2 (3 hours): base price + payment terms.** Maya specified $6,750 as base price (50% increase from C4 anchor). Pay-in-full discount: 5% to $6,413. 3-pay installment plan: $2,250/month with no discount, operator absorbs processing. No 6-pay or extended plan. Default: pause at day 7, terminate at day 14 with 50% forgiveness.

**Sitting 3 (1 hour): refund window + segmentation.** Refund window: 14 days from engagement start; refund qualifies if customer has completed Week 1 and concludes Sprint not right fit; full refund minus $200 admin fee; after Week 4, no refund. Segmentation: uniform pricing for v2.1, no cohort timing, no partner, no scholarship currently. Documented rationale.

**Sitting 4 (1 hour): matrix positioning + document writing.** Positioning: Q4 (High Value, Narrow Access). Identity match: Service-Operator with intensive 1:1 coaching. Coherent. Document compiled to 1,750 words.

---

## Common Failure Modes at M8.4

The Sonnet `pricing-architecture-reviewer-v1.0.0` prompt and the AI rubric look for these:

1. **Skipping the 6% Rule scan.** Operator specifies a pricing pattern as the first-thought selection without showing the 16+ scan. The AI rubric flags any document that lists fewer than 16 patterns.

2. **Aspirational base price.** Operator specifies a base price that is not grounded in M8.3 unit economics or competitive scan. The price is a wish, not an architectural choice. The rubric expects each rationale line cited.

3. **Payment terms with margin erosion uncalculated.** Operator specifies installment plans without computing the margin impact (processing fees, default risk).

4. **Refund window misaligned with C4 M4.6.** Operator specifies a refund window inconsistent with the existing Guarantee Architecture without explanation.

5. **Segmentation pattern slipping into negotiation.** Operator specifies "case-by-case discounts for fit" or similar; the AI rubric flags this as ad-hoc, not architectural.

6. **Quadrant misalignment.** Operator's identity (Service-Operator) doesn't match the quadrant (Q1 Low Value Broad Access). The mismatch is a signal; the operator should re-examine pattern selection.

7. **Section 8 cross-references missing.** Operator does not specify M8.5/M8.6/M8.7 input requirements; the next modules will start without context.

---

## Checkpoint 8.4

Your deliverable is:
1. **Pricing Architecture Document** filed in Drive, 1,500-2,000 words, eight sections
2. **Pricing pattern selection** recorded in Supabase `c8_pricing_architectures.selected_pattern`
3. **Base price** recorded in `c8_pricing_architectures.base_price`
4. **Quadrant positioning** recorded in `c8_pricing_architectures.matrix_quadrant`

The AI rubric scoring the document looks for eight properties:
- 6% Rule scan with 16+ patterns shown and filtered
- Base price with all five rationale lines
- Payment terms with margin impact computed
- Refund window aligned with C4 M4.6
- Segmentation logic specific (or uniform with documented rationale)
- Quadrant positioning with identity coherence verification
- Cross-references to M8.5/M8.6/M8.7 inputs
- All eight sections meet word-count targets

---

## What M8.5 Expects From You

The M8.4 base price feeds into M8.5: if tiered, the base price typically becomes the standard tier's price, with entry below and premium above. If flat, the base price is the price.

File the Pricing Architecture Document. Proceed to M8.5.

---

*Last updated: April 25, 2026 · Version 2.0*

Complete supporting source — Pricing architecture reviewer

name: pricing-architecture-reviewer
version: 1.0.0
module: M8.4
course: C8 Pricing Discipline
model: claude-sonnet-4-6
role: Pricing Architecture Reviewer
review_type: artifact_review
description: >
  Reviews the M8.4 Pricing Architecture Document. Verifies that base price,
  payment terms, refund window/triggers, segmentation rules, four-quadrant
  matrix, and scope premium schedule are specified rules-based (not
  discretionary), grounded in M8.2 unit economics and M8.3 decision branch,
  and architected toward the C8 doctrine 60% sustainability margin.

system_prompt: |
  You are the Pricing Architecture Reviewer for the RISER Nation Maritime
  Academy C8 Pricing Discipline course, Module 8.4. You review Pricing
  Architecture Documents.

  This module turns the M8.3 decision into a structural pricing system. The
  architecture is what M8.5-M8.7 build against and what M8.6 anti-discount
  policy enforces. Architectural ambiguity propagates into every downstream
  artifact.

  ## What to evaluate

  Read the submitted Pricing Architecture Document plus the linked M8.2
  Unit Economics Document and M8.3 Decision Memo. The Architecture must
  be coherent with both upstream artifacts.

  Score against ten criteria. Pass threshold: average ≥ 7.0 AND no
  individual criterion below 5.0.

  **Criterion 1 — Architecture inputs documented**
  Section 1 must reference C7 Offer Architecture, M8.2 Unit Economics, and
  M8.3 Decision Memo with links. Architecture cannot be built in isolation
  from upstream artifacts.

  **Criterion 2 — Base price specified with cost-anchored rationale**
  Section 2 base price must reference M8.2 unit economics in its rationale.
  Rationale that anchors only to "competitive pricing" or "what feels right"
  fails this criterion. Acceptable rationale ties price to measured cost
  and target margin.

  **Criterion 3 — Payment terms specify deposit ≥ 25% for offers > $500**
  Section 3 must specify deposit percentage. Below-25% deposits on offers
  > $500 are flagged as customer-risk-on-operator failures. Documents may
  specify lower deposits with explicit rationale (e.g., compliance with
  customer procurement requirements).

  **Criterion 4 — Refund window with non-trigger list**
  Section 4 must specify refund window AND non-trigger list. Refund policies
  without non-triggers ("we'll evaluate refund requests case by case") fail
  this criterion because they enable pressure-based refunds.

  **Criterion 5 — Segmentation rules are rules-based, not discretionary**
  Section 5 must specify customer segments with structural criteria (e.g.,
  "≥ 3 prior deliveries renewing within 30 days"). Discretionary segmentation
  ("long-time customers may receive loyalty pricing") fails this criterion.

  **Criterion 6 — Four-quadrant matrix populated**
  Section 6 must show the four-quadrant matrix with pricing rules per
  quadrant. Empty quadrants or vague quadrant entries ("TBD" or "case-by-case")
  fail this criterion.

  **Criterion 7 — Scope premium schedule specified**
  Section 7 must specify scope premium magnitudes (e.g., "+10% for ≤ 4
  hour additions"). Generic language ("custom scope priced separately")
  without magnitudes fails this criterion. The schedule's function is
  to make scope-creep pricing automatic.

  **Criterion 8 — Sustainability margin path specified**
  Section 8 must show quarterly margin trajectory from current (M8.2
  measured) to target (60% knowledge-work doctrine, or documented exception).
  Targets without a path ("we'll get to 60% eventually") fail this
  criterion.

  **Criterion 9 — Architecture coherence check addressed**
  Section 9 must answer the three coherence questions:
  - Does base price produce target margin against M8.2 unit economics?
  - Do segmentation rules produce average effective price ≥ base × 0.92?
  - Does scope premium schedule cover measured C7 scope-creep load?

  Hand-waving on these questions ("yes" without computation) fails this
  criterion.

  **Criterion 10 — Operator sign-off binding for 12 months**
  Section 10 must include operator's sign-off committing to the architecture
  for 12 months absent M8.7 schedule-triggered changes. Sign-offs with
  weakening language ("subject to circumstances") fail this criterion.

  ## How to write the review

  Same structure as prior reviewers:
  1. Score summary table
  2. Decision (CLEARED / NEEDS_REVISION / NOT_CLEARED)
  3. Per-criterion notes with specific section references
  4. Coherence-with-upstream flags (M8.2, M8.3 inconsistencies)
  5. M8.5 hand-off readiness assessment
  6. Final paragraph

  ## Decision thresholds

  - CLEARED: average ≥ 8.0, no criterion below 6.0
  - NEEDS_REVISION: average 6.0-7.9, OR any criterion 4.0-5.9
  - NOT_CLEARED: average < 6.0 OR any criterion < 4.0

  Sustainability margin path criterion (8) is weighted: failure on
  Criterion 8 alone routes to NEEDS_REVISION minimum, even if other
  criteria score well.

  ## Tone and discipline

  M8.4 is the most technical C8 module. Operators may produce well-formed
  documents that nonetheless fail coherence checks. Be specific in
  feedback: name the section, name the issue, name the correction.

  Architecture is rules-based, but the rules don't have to be the same as
  the C7 reference rules. Operators can deviate (e.g., specifying lower
  doctrine threshold than 60%) with documented rationale.

review_criteria:
  - architecture_inputs_documented
  - base_price_specified_with_cost_anchored_rationale
  - payment_terms_specify_deposit_threshold
  - refund_window_with_non_trigger_list
  - segmentation_rules_rules_based
  - four_quadrant_matrix_populated
  - scope_premium_schedule_specified
  - sustainability_margin_path_specified
  - architecture_coherence_check_addressed
  - operator_signoff_binding_12_months

decision_thresholds:
  CLEARED:
    average_min: 8.0
    no_criterion_below: 6.0
  NEEDS_REVISION:
    average_range: [6.0, 7.9]
    or_any_criterion_range: [4.0, 5.9]
    or_criterion_8_below: 6.0
  NOT_CLEARED:
    average_below: 6.0
    or_any_criterion_below: 4.0

instructor_handoff:
  triggered_when: NOT_CLEARED OR coherence_check_failure_persistent
  routing: C8 instructor queue, priority normal
  expected_resolution_window: 14 days from handoff

cooling_period_after_clearance:
  hours: 48
  rationale: >
    Architecture commits the operator to a 12-month system. The 48-hour
    cooling period before M8.5 ensures the operator has confirmed the
    architecture before building tier or scope-premium structures against it.

Complete supporting source — Pricing math spreadsheet specification

# Pricing Math Spreadsheet Template

**Version:** 1.0 · **Last updated:** April 25, 2026 · **Used in:** M8.2, M8.3, M8.4, M8.7, M8.8 quarterly reconciliation

---

## Purpose

A single spreadsheet that holds all pricing math for one offer through its first 12 months of operation. The operator opens this spreadsheet at M8.2, populates it with measured C7 data, and updates it quarterly thereafter. The spreadsheet is the live source of truth that feeds every C8 deliverable.

This is a markdown specification of the spreadsheet structure. The operator builds the spreadsheet in Google Sheets or Excel using the named columns, formulas, and tabs below. RISER does not provide a pre-built spreadsheet because operators who build their own internalize the math; operators who paste numbers into a pre-built template often do not.

---

## Tab 1 — Unit Economics

Column structure:

| Column | Purpose | Source |
|---|---|---|
| A: Delivery ID | Unique identifier per delivery (e.g., Sprint-001) | Operator-assigned |
| B: Customer | Customer name | Operator |
| C: Start date | Delivery start | Operator |
| D: End date | Delivery end | Operator |
| E: Stated price | Price quoted to customer | C4 / C7 |
| F: Stated hours | Hours estimated at quote time | C7 |
| G: Actual hours | Measured hours from delivery | C7 measurement system |
| H: Hidden hours | Pre-quote, scope-creep, post-delivery support | M8.2 audit |
| I: Total hours | F + H | Formula |
| J: Hourly cost | Operator-self loaded rate | M8.2 |
| K: Direct costs | Software, contractors, materials | M8.2 |
| L: Total cost | (I × J) + K | Formula |
| M: Gross margin $ | E - L | Formula |
| N: Gross margin % | M / E | Formula |
| O: Effective rate | E / I | Formula |

Target rows: one per delivery. Minimum 6 deliveries before M8.2 unit economics calculation reads as statistically meaningful. C7 capacity constraint analysis should have produced ≥ 8 deliveries; copy them all here.

---

## Tab 2 — Pricing Architecture

| Field | Value | Notes |
|---|---|---|
| Base price | | M8.4 architecture |
| Payment terms | | e.g., 50% deposit, 50% on delivery |
| Refund window | | e.g., 14 days |
| Refund triggers | | Specific behaviors that trigger refund |
| Standard tier price | | If three-tier; else N/A |
| Entry tier price | | If three-tier |
| Premium tier price | | If three-tier |
| Tier mix target | | e.g., 60/30/10 for std/entry/premium |
| Sustainability margin target | | M8.4; doctrine threshold 60% knowledge-work |

---

## Tab 3 — Anti-Discount Policy Compliance

| Column | Purpose |
|---|---|
| A: Date | When request received |
| B: Customer | Who asked |
| C: Request type | Discount sought (e.g., "remove deliverable", "first-customer rate") |
| D: Policy classification | Exception / Non-exception |
| E: Action taken | Decline / Discount granted |
| F: If granted, justification | Required if E=granted; should be empty in disciplined operation |
| G: Compliance score | 1 if action matched policy, 0 if deviated |

Quarterly: count deviations, divide by total requests, calculate compliance rate. Target: 100%. Below 95% triggers M8.6 policy review.

---

## Tab 4 — Price-Raise Trigger Tracker

| Column | Purpose |
|---|---|
| A: Trigger ID | T1-T4 (capacity, waitlist, demand, indexing) |
| B: Threshold | The trigger condition |
| C: Current reading | Updated monthly |
| D: Fired? | Y/N |
| E: Fired date | If Y |
| F: Raise executed date | Within 30 days of fire |
| G: Raise magnitude | % |
| H: Cumulative cap status | Used / remaining |

This tab enforces M8.7 discipline. The operator updates monthly; the Quarterly Reconciliation reads from it.

---

## Tab 5 — Quarterly Reconciliation

One row per quarter.

| Field | Computed from |
|---|---|
| Quarter | e.g., Q3-2026 |
| Avg gross margin % | Tab 1 N column avg |
| Avg effective rate | Tab 1 O column avg |
| Tier mix actual | Tab 1 customer breakdown |
| Tier mix variance | Actual vs Tab 2 target |
| Anti-discount compliance % | Tab 3 G avg |
| Triggers fired | Tab 4 D Y count |
| Raises executed | Tab 4 F populated count |
| Cumulative raise % | Tab 4 G sum |
| Deviation log entries | From Supabase deviation_log |
| Reconciliation memo link | Drive link |

---

## Setup Time

First-time setup: 2-3 hours including data import from C7. Quarterly maintenance: 60-90 minutes. Total annual time: ~10 hours. This is part of the operating cost of pricing discipline; budget it against operator overhead.

---

*This template is an output of M8.2 and an input to every subsequent C8 module and to all C9 distribution decisions.*

Complete supporting source — Customer and scope four-quadrant framework

# The Four-Quadrant Pricing Matrix

**Used in:** M8.4 Section 6, M8.6 policy enforcement, M8.7 raise communication

---

## The Matrix

| | New customer | Existing customer |
|---|---|---|
| **Standard scope** | Q1: New + Standard | Q2: Existing + Standard |
| **Custom scope** | Q3: New + Custom | Q4: Existing + Custom |

Every pricing situation falls into exactly one of these four quadrants. The matrix's function is to make pricing decisions automatic by quadrant rather than negotiated case-by-case.

---

## Quadrant 1 — New Customer, Standard Scope

**Description:** A new customer engaging for the standard offer at standard scope.

**Pricing rule:** Base price as specified in Pricing Architecture Document Section 2.

**Allowed deviations:** None. This is the cleanest quadrant; pricing is deterministic.

**Common pressure:** "First-customer pricing," "trial pricing," "we'll commit if you give us a starting rate." Per M8.6 non-exception list, all declined.

**Why this quadrant matters:** It's the quadrant most operators get right. The other three quadrants are where pricing leaks.

---

## Quadrant 2 — Existing Customer, Standard Scope

**Description:** An existing customer engaging for additional standard work at standard scope.

**Allowed deviations:** Only the structural loyalty exception. Discretionary "long-time customer" discounts are not allowed; the loyalty exception is rule-based.

**Why this quadrant matters:** It's where existing-relationship pressure causes most operator concession. The structural rule converts emotion to arithmetic.

---

## Quadrant 3 — New Customer, Custom Scope

**Description:** A new customer requesting work that varies from standard scope (additional deliverables, different timeline, custom requirements).

**Why this quadrant matters:** It's where scope creep enters pricing. Without a schedule, every custom request becomes a negotiation. With a schedule, requests become arithmetic.

---

## Quadrant 4 — Existing Customer, Custom Scope

**Description:** An existing customer requesting custom work.

**Pricing rule:** Base price + scope premium per schedule. Loyalty exception (if applicable) applies to the base price component, not the scope premium component.

**Allowed deviations:** Combined application of Q2 and Q3 rules. No additional discretion.

**Why this quadrant matters:** It's the most complex quadrant in negotiation feel but the simplest in matrix logic.

---

## What the Matrix Prevents

---

## Common Quadrant Errors

### Error A: Treating Q4 as a discretionary zone

Operators sometimes treat existing-customer-custom-scope as a "we'll work it out" zone. The matrix forbids this. Q4 is rules + rules; both Q2 loyalty rule and Q3 scope rule apply.

### Error B: Slipping Q1 into Q3

### Error C: Slipping Q3 into Q1

### Error D: Treating Q2 as default-discount zone

---

## Worked Example: Maya in Each Quadrant

**Q1 — New customer, standard Sprint:** Price $5,625. No deviation.

**Q2 — Existing customer (3 prior Sprints, renewing within 30 days), standard Sprint:** Loyalty pricing applies per M8.6 Section 2: 10% off, $5,063.

**Q3 — New customer, Sprint + additional brand identity element (estimated 3 hours):** Base $5,625 + 10% scope premium ($562) = $6,187.

---

## Integration with Other C8 Artifacts

---

M8.5-Written-Lesson.md

Choose the pricing path before designing tiers

Legacy M8.5 follows the filed M8.4 architecture and proposed 7/10 review. It starts with a one-hour diagnostic, then budgets five more hours for tier design or two more for a flat-pricing rationale—six or three total. The source’s 50/50 or 40–50% pass estimates are unsupported population claims. Both paths can be legitimate; the diagnostic should reflect the actual offer.

Question the claimed middle-tier statistic

The source attributes 60–70% middle-tier selection with three tiers versus about 40% selecting the middle of two tiers to pricing research. No supporting study is supplied, and a two-tier display has no unique middle tier. Do not teach this as an established fact. Measure real choice, revenue, support load and outcomes when testing an actual comparison page.

Gate 1 — verify distinct customer needs

Identify two or three segments that need meaningfully different delivery, not simply people you believe will pay more. The source’s engineering example distinguishes foundational, practitioner and leadership needs; its illustration-coaching example treats the needed engagement as similar across buyers. Test those assumptions through actual research. A career-stage label alone does not establish willingness to pay or the right service.

Gate 2 — define meaningful delivery differences

Explain the different artifacts, support, implementation, workload or scope each tier provides. The source rejects volume/access-only differences, yet its positive examples add group and one-to-one access. Treat that as an internal tension: volume and access can be legitimate distinctions if they create clear customer utility and have honest costs. Do not call a package fake solely because it shares the same core mechanism.

Gate 3 — verify delivery capacity

Model simultaneous customers, shared sessions, individual support, preparation and peak demand. Shared infrastructure or sequential delivery can help, but a future team must not be counted as available capacity before it exists. The source routes any failed gate to flat pricing; use that as its assessment policy while documenting evidence and any justified alternative. Four total customers does not mathematically forbid tiers by itself.

Make the three-gate decision inspectable

Record pass/fail, evidence and unresolved assumptions for needs, delivery differences and capacity. All three pass leads to the source tiered path; a failure leads to its flat path. Avoid both automatic enthusiasm for tiers and automatic rejection of tiers for custom services. A coherent flat offer can be more useful than three unclear packages.

Name and map the tiers clearly

The source prefers structural names such as Self-Study/Cohort/Cohort+1:1, Foundations/Practitioner/Master or Library/Workshop/Studio over Bronze/Silver/Gold or Basic/Pro/Enterprise. This is a clarity preference, not proof generic names are deceptive. For each tier record mechanism components, operator hours per customer, customer self-work, duration/cadence and received artifacts, sessions, access and support.

Treat price ratios as examples, not laws

The source suggests entry at 25–40% of standard and premium at 1.8–2.5 times standard, with the M8.4 base becoming standard. It supplies no evidence for a universal logarithmic willingness-to-pay distribution. Close or wide spacing should be evaluated against meaningful scope, customer needs and costs. Darius’s $300/$600/$1,200 example has entry at 50% of standard, outside its own suggested band; explain rather than conceal that inconsistency.

Review the tier design — Mechanism and deliverables

Check whether the differences provide distinct, useful value. Shared components do not invalidate clear packages. The source requires all six checks for its Anti-Fake-Tiering assessment; treat the checklist as a design aid with explicit exceptions, not a universal definition of valid pricing.

Review the tier design — Operator-time economics

Measure delivery cost across tiers. More value does not always require proportionally more human time, especially in software or licensed content. The source requires all six checks for its Anti-Fake-Tiering assessment; treat the checklist as a design aid with explicit exceptions, not a universal definition of valid pricing.

Review the tier design — Customer self-work

Explain required effort at each level. Premium support may reduce some work but cannot guarantee effort-free results. The source requires all six checks for its Anti-Fake-Tiering assessment; treat the checklist as a design aid with explicit exceptions, not a universal definition of valid pricing.

Review the tier design — Outcome trajectory

Describe supportable differences in scope, speed or confidence without inventing better outcomes just to justify a price. The source requires all six checks for its Anti-Fake-Tiering assessment; treat the checklist as a design aid with explicit exceptions, not a universal definition of valid pricing.

Review the tier design — Upgrade mechanics

Specify eligibility, credits, proration, timing and capacity. A legitimate specialized offer need not allow every midstream upgrade. The source requires all six checks for its Anti-Fake-Tiering assessment; treat the checklist as a design aid with explicit exceptions, not a universal definition of valid pricing.

Review the tier design — Self-selection clarity

Test whether a prospect can identify the best-fit option and understand limitations without being steered by misleading comparisons. The source requires all six checks for its Anti-Fake-Tiering assessment; treat the checklist as a design aid with explicit exceptions, not a universal definition of valid pricing.

Darius example — Foundations

The source Foundations tier is $300 per month with a three-month minimum: at least $900 before other disclosed charges. It includes self-paced platform-engineering material, community and a monthly office hour; learner effort is estimated at 10–15 hours weekly and allocated operator time at about thirty minutes monthly. Clarify whether shared-session time is allocated per customer and test capacity. Foundational competency is an intended learning outcome, not a guaranteed result.

Darius example — Practitioner

Practitioner is $600 monthly with a three-month minimum: at least $1,800. It adds weekly cohort sessions, practitioner curriculum and Slack mentor access, with five-to-ten weekly learner hours and about three monthly operator hours in the source. Define response windows and support limits. This $600 standard price differs from the prior $300 architecture baseline; document the version change and re-run economics before combining the examples.

Darius example — Master

Master is $1,200 monthly with a six-month minimum: at least $7,200. It adds biweekly one-to-one work, executive-presence coaching and leadership curriculum, with three-to-five weekly learner hours plus meetings and about eight monthly operator hours. Staff-engineer preparation is a learning intention, not a job guarantee. Model premium seat limits and dates; do not assume every buyer can upgrade immediately without capacity.

Make the example’s tier transitions explicit

The source says Foundations-to-Practitioner upgrades are prorated and Practitioner-to-Master can occur at any point. It does not fully specify credit calculations, minimum-term resets, downgrades or refunds. Define those before sale. Do not silently combine the prior architecture’s optional $300 cohort fee with this separate three-tier example. Their reported six-check pass is illustrative, not a review performed on RISER’s deployed offer.

Write a flat-pricing rationale with four components

Name the failed diagnostic gate and evidence; explain the delivery-model fit; describe why one offer improves customer clarity; and specify how price-sensitive prospects will be routed without an invented downgrade. A referral, self-study resource, later start or respectful no can be valid. Flat pricing does not require hostility toward affordability concerns.

Read Maya’s flat-price decision as an example

The source says Maya’s illustrators need the same intensive engagement, proposed tiers would be artificial variations, and four-client capacity favors focus. It therefore keeps one price and routes unsuitable budgets to relevant alternatives such as books or self-paced courses. These are assumptions to verify for an actual business. Operator identity and low customer count alone do not prove that tiering could never work.

Tier Structure Document — Diagnostic results

150–200 words documenting all three gates with evidence.

Tier Structure Document — Tier definitions

300–400 words covering names, prices, components, operator time, learner work, duration and deliverables.

Tier Structure Document — Price rationale

150–200 words explaining actual price relationships and costs.

Tier Structure Document — Six-check review

200–300 words reporting evidence and unresolved issues for each test.

Tier Structure Document — Cross-tier mechanics

100–150 words specifying upgrades, downgrades and mid-engagement changes.

Tier Structure Document — Handoffs

100–150 words identifying what discount policy and raise scheduling need for each tier.

Reconcile the tier-document length

The source’s six section ranges total 1,000–1,400 words, while its headline target is 1,000–1,500. Use the shared 1,000–1,400 range if retaining both constraints, or revise them explicitly. Do not add filler to meet a conflicting number. Completeness requires all actual terms and economics, not simply a word count.

Flat Pricing Rationale — Diagnostic findings

200–250 words identifying the failed gates and evidence. The source total is 600–800 words across these four sections.

Flat Pricing Rationale — Delivery-model coherence

150–200 words explaining why one price fits this offer. The source total is 600–800 words across these four sections.

Flat Pricing Rationale — Customer experience

150–200 words explaining clarity and the absence of meaningful tier choices. The source total is 600–800 words across these four sections.

Flat Pricing Rationale — Discount-policy handoff

100–150 words describing suitable alternatives and exception handling without a tier downgrade. The source total is 600–800 words across these four sections.

Correct the six listed failure modes

Run the diagnostic; explain any override rather than forcing tiers after failure; make differences substantive and honest; test naming clarity; justify price spacing rather than blindly applying a ratio; and cite the reason for choosing flat pricing. A checklist flag calls for investigation. It is not proof that a real offer is deceptive, unprofitable or invalid.

Complete the checkpoint and next-stage handoff

Provide the six-section tier document or four-section flat rationale, diagnostic evidence, applicable six-check review and explicit inputs for discount policy and raises. The source names diagnostic_outcome and structure_specification in c8_tier_structures and a 7/10 reviewer gate; they are planned records, not proof of a deployed assessment. Parallel work on the discount policy is appropriate only after the necessary pricing decisions are stable. Mark unresolved terms before the offer is presented as ready.

Connect the lesson to the direct-marketing promise

Use the seven-condition diagnostic as a separate version

Score each condition from one to five: genuine scope/depth/support/speed variation; evidence of three distinct needs; delivery capacity; manageable customer decision complexity; visible premium value; viable entry economics; and clear boundaries. Source bands are 30–35 strong, 22–29 moderate, 14–21 weak and 7–13 poor. These are program scoring rules, not validated science, and differ from the main lesson’s three gates. Retain both instruments and declare which controls the decision.

Interpret the five tier tests with evidence

For scores at least 22, the worksheet asks for a 30-second standalone tier description, a distinct buyer for each tier, a projected twelve-month mix with no 80% concentration, viable entry economics without subsidy, and premium pricing at least twice standard. These differ from the main six tests and 1.8–2.5 ratio. They are diagnostic flags, not universal proofs that a tier is fake. A cross-subsidy model can be deliberate if measured and disclosed; adjacent-tier interest is not itself evidence of failure. The claim that three offers triple maintenance is unsupported when infrastructure is shared.

Document flat pricing and future triggers without losing fields

The worksheet asks for three parts: why flat fits, evidence that would reopen tiering, and customer-size variation handled through a scope premium. The main lesson asks for four sections; preserve every requested field in a mapped combined document. An example trigger is at least twelve conversations within ninety days requesting both cheaper/shorter and premium/longer variations. The worksheet’s rejection of every “standard plus” design conflicts with tier examples elsewhere; evaluate meaningful differences rather than banning the phrase. Claims about 40% arriving with tiers or 60% switching lack cohort evidence.

Use the correct five applicable reviewer criteria

The version 1.0.0 M8.5 reviewer accepts either a tier structure or flat-pricing rationale, supported by the diagnostic and M8.4 architecture. Tiered criteria are diagnostic-grounded choice, the five tier tests, concrete prices and projected mix, anti-cannibalization rules, and architecture coherence. Flat criteria are diagnostic-grounded choice, substantive rationale, future triggers, scope-premium routing and coherence. Mark the other path’s criteria not applicable and exclude them from the average. Scores at least 22 typically suggest tiers and 21 or below flat; defend exceptions rather than treating them as automatically wrong.

Reconcile tier prices and service boundaries

For tiers, the reviewer requires actual prices rather than ranges and a mix target, plus rules such as premium 48-hour turnaround requiring an upgrade when requested by a standard customer. Standard should match the M8.4 base or explain a variance; flat must match the chosen base exactly under this rubric. Compare versions before declaring a mismatch resolved. This is assessment policy, not permission to deny an existing contractual promise. The reviewer repeats the five tests, including premium at least twice standard, so disclose its disagreement with the main lesson’s thresholds.

Resolve tier-review thresholds and decision precedence

The reviewer introduction uses average 7/minimum 5, while clearance requires average 8/minimum 6 across applicable criteria. Revision applies to average 6–7.9, a criterion 4–5.9 or one failed tier test; not cleared applies below 6 average, below 4 on any criterion or at least two failed tests. Define precision, fill decimal gaps and make the most severe applicable condition control. State the chosen path, scores and specific evidence; do not imply an automated review actually ran.

Complete the tier review handoff truthfully

The final paragraph addresses M8.6 anti-discount policy and tier-mix complexity. Not-cleared or persistent path mismatch routes to a proposed normal-priority C8 instructor queue with a fourteen-day resolution window; clearance is followed by a proposed 24-hour cooling period. These are planned workflow settings, not active systems. Both flat and tiered outcomes are legitimate; the claim that roughly 60% switch to flat has no supporting cohort data. External pricing literature does not remove the need to test the operator’s own economics and customer fit.

Complete original source text

# M8.5 — Three-Tier Offer Design: Tiered Pricing or Documented Flat

**Module Outcome:** [Apply] Student has run the Tier Appropriateness Diagnostic; if appropriate, has designed entry/standard/premium tiers with structurally different deliverables and applied the Anti-Fake-Tiering Test; if inappropriate, has documented the flat-pricing rationale with diagnostic findings; produced the Tier Structure Document or Flat Pricing Rationale Statement that integrates with M8.4 architecture.
**Key Deliverable:** Tier Structure Document (`Tier-Structure-Document-[YourName]-[Date].md`, 1,000-1,500 words, six sections) OR Flat Pricing Rationale Statement (`Flat-Pricing-Rationale-Statement-[YourName]-[Date].md`, 600-800 words, four sections)
**Infrastructure Dependency:** Build 6, Build 8 Drive folder, Supabase `c8_tier_structures` table, Claude prompt `tier-structure-reviewer-v1.0.0` (Sonnet), Tier-Appropriateness-Diagnostic Worksheet, Anti-Fake-Tiering Test Checklist
**Checkpoint / Test:** Type 1 Artifact + Type 2 AI rubric ≥ 7/10
**Blocked-Until Prerequisite:** M8.4 Pricing Architecture Document filed AND AI rubric ≥ 7/10

---

## What This Module Does

M8.5 is the only conditional module in C8. The module's first hour determines its path:

1. **Tier Appropriateness Diagnostic (1 hour, all operators).** Run the diagnostic to determine whether your offer's structural shape supports legitimate tiered pricing or is better served by flat pricing. The diagnostic has three gates; failing any gate routes the operator to the flat-pricing path.

2. **Tiered path (5 additional hours, ~50% of operators):** if the diagnostic clears, design three tiers (entry/standard/premium) with structurally different deliverables, apply the Anti-Fake-Tiering Test, produce the Tier Structure Document.

3. **Flat path (2 additional hours, ~50% of operators):** if the diagnostic fails, document the flat-pricing rationale citing diagnostic findings, produce the Flat Pricing Rationale Statement.

The conditional structure is structural to C8: tiered pricing is one legitimate pattern among several from M8.4's 6% Rule scan, not the default. Many offers — particularly intensive 1:1 coaching, bespoke advisory engagements, and deeply customized service work — are structurally inappropriate for tiered pricing. Operators who force tiering onto these offers produce fake tiers (price-point variations of the same offer) that the Anti-Fake-Tiering Test catches.

The deliverable is the **Tier Structure Document** (1,000-1,500 words, six sections) for the tiered path or the **Flat Pricing Rationale Statement** (600-800 words, four sections) for the flat path. Either deliverable becomes the input to M8.6 (anti-discount policy) and M8.7 (raise schedule).

M8.5 active time is 6 hours for the tiered path or 3 hours for the flat path.

---

## Why This Module Matters

Tiered pricing has structural advantages when the offer's shape supports it: it captures wider willingness-to-pay distribution, provides upgrade paths, allows segmentation without ad-hoc discounting, and produces a "good-better-best" frame that helps customer self-selection (Hermann Simon's research on three-tier pricing shows 60-70% of customers select the middle tier when three tiers are presented, vs. ~40% selecting middle when only two tiers exist).

Tiered pricing has structural failures when forced onto inappropriate offers: customers experience the tiers as artificial price discrimination, premium-tier deliverables become hollow upgrades the operator does not actually deliver differently, and the operator's attention fragments across maintaining three offers when one would have served better.

The discipline at M8.5 is to apply the diagnostic honestly. Most operators arrive at M8.5 with one of two biases:

- **Pro-tier bias:** "Tiering will increase my revenue." Operators who learned pricing from Hormozi, Brunson, or productized-service playbooks tend to assume tiering is always appropriate. The bias produces fake tiers.
- **Anti-tier bias:** "My offer is too custom for tiers." Operators who deliver intensive 1:1 work tend to assume tiering is impossible. The bias misses legitimate tiering opportunities (e.g., adding a self-paced entry tier below the 1:1 standard tier).

The diagnostic is the discipline that overrides both biases. Operators who run the diagnostic honestly arrive at the right path; operators who skip it produce architecture that doesn't fit.

---

## The Tier Appropriateness Diagnostic

The diagnostic has three gates. All three must clear for the offer to be tier-appropriate.

### Gate 1 — Genuine Segment Differentiation

**Question:** Does your target audience contain genuinely distinct segments with different willingness-to-pay AND different deliverable needs?

**Pass condition:** You can identify 2-3 specific customer segments where one segment legitimately needs (and is willing to pay for) a different deliverable scope than another segment. The segments are not just "willing to pay more" — they are "willing to pay more AND want or need different things."

**Fail condition:** Your audience is largely homogeneous, OR segments differ in willingness-to-pay but not in deliverable need. Forcing tiers on a homogeneous audience produces price discrimination that customers experience as unfair.

**Examples:**

- **Pass:** A platform-engineering education offer can serve early-career engineers (need: foundational concepts, peer cohort, low cost), mid-career engineers (need: advanced patterns, mentor access, moderate cost), and staff engineers (need: leadership patterns, executive coaching, high cost). Three genuinely different deliverables for three genuinely different segments.

- **Fail:** An intensive 1:1 illustration-licensing coaching engagement serves illustrators at various career stages who all need the same deliverable (Maya's portfolio audit, market positioning, licensing strategy, contract negotiation). The deliverable is the same; only willingness-to-pay differs. Tiering would produce three price points for substantively the same engagement, which is fake tiering.

### Gate 2 — Structural Deliverable Differentiation

**Question:** Can the three tiers deliver structurally different things — not just different access levels or different volumes of the same thing?

**Pass condition:** Each tier delivers a different mix of mechanism components, different levels of operator personal involvement, or different scope of customer work. The tiers are not "same offer, more sessions."

**Fail condition:** The tiers differ only by volume (3 sessions vs. 6 sessions vs. 10 sessions), access (group vs. small group vs. 1:1), or duration. These are real differences but not structural deliverables. Operators forcing volume-only tiering produce offers that feel transparently price-driven.

**Examples:**

- **Pass:** Entry tier is self-paced course + community access; Standard tier is self-paced course + cohort + 4 group sessions; Premium tier is self-paced course + cohort + group sessions + 4 1:1 sessions + portfolio review. Each tier introduces structurally different deliverables, not just more of the same.

- **Fail:** Entry tier is "5 coaching sessions + workbook"; Standard tier is "8 sessions + workbook + Slack"; Premium tier is "12 sessions + workbook + Slack + extra portfolio review." Volume + minor access differences. Customers will perceive this as "same thing, different prices" because it is.

### Gate 3 — Operator Capacity to Deliver Multiple Tiers

**Question:** Does the operator have capacity (currently or via documented Stage 2-3 plan) to deliver three different versions of the offer concurrently without quality degradation?

**Pass condition:** The C7 M7.5 capacity ceiling supports concurrent tiers, OR the tiers are sequential (e.g., entry tier delivered to one cohort while premium tier serves a different cohort), OR the tiers share fulfillment infrastructure that scales (e.g., self-paced material common across tiers, with operator time concentrated in premium).

**Fail condition:** Operating three tiers concurrently would breach the M7.5 ceiling, OR fulfillment infrastructure for the three tiers is too divergent to maintain at the operator's current capacity, OR the operator would need to add team or systems before delivering tiers (in which case tiering is a Stage 3 work item, not a Stage 2 C8 deliverable).

**Examples:**

- **Pass:** Darius's platform-engineering offer can support tiers because the cohort infrastructure is shared (1 group session per week serves all tiers), and 1:1 time scales with premium tier seat count.

- **Fail:** Maya's intensive 1:1 Sprint cannot support three concurrent tiers because her capacity ceiling is 4 concurrent customers; operating three tiers would mean roughly one customer per tier at a time, fragmenting her attention without scale benefit.

### Diagnostic Outcomes

- **Three gates pass → tiered path.** Proceed to tier construction.
- **Any gate fails → flat path.** Document the flat-pricing rationale with the failed gate finding.

About 40-50% of Stage 2 operators clear all three gates. The remaining 50-60% take the flat path. Both are legitimate; the discipline is the diagnostic, not the outcome.

---

## The Tiered Path

If your diagnostic cleared, you design three tiers.

### Tier Construction Discipline

**Tier names:** use names that reflect the tier's structural nature, not generic terms.

- Generic (avoid): Bronze/Silver/Gold; Basic/Pro/Enterprise; Tier 1/Tier 2/Tier 3
- Structural (prefer): Self-Study/Cohort/Cohort+1:1; Foundations/Practitioner/Master; Library/Workshop/Studio

The naming choice signals to customers that tiers are structurally different, not just price-level different.

**Tier deliverable mapping:** for each tier, specify:

- The mechanism components included (which of the C2 M2.4 4-pillar elements does this tier deliver?)
- The operator-time allocation per customer (hours of operator's personal involvement per customer in this tier)
- The customer self-work expectations (what does the customer need to do to receive value?)
- The duration / cadence
- The deliverables the customer receives (artifacts, sessions, access, support)

**Tier price points:** typical structural relationships:

- Entry tier: 25-40% of standard tier price
- Standard tier: the M8.4 base price
- Premium tier: 1.8-2.5x of standard tier price

These ratios are derived from the empirical pattern that customer willingness-to-pay follows roughly logarithmic distributions; tiers spaced too closely (e.g., $2,000 / $2,400 / $2,800) feel like price discrimination, while tiers spaced too widely (e.g., $500 / $5,000 / $50,000) feel like different offers entirely.

### The Anti-Fake-Tiering Test

After tier design, run the Anti-Fake-Tiering Test. The test has six checks:

**Check 1 — Mechanism component differentiation.** Do the three tiers deliver different mechanism components, not just different volumes of the same components? If all three tiers deliver the same components and only differ in volume or duration, the tiering is fake.

**Check 2 — Operator-time scaling alignment.** Does operator time per customer increase materially across tiers? Tiers where operator time is roughly the same indicate fake tiering (the operator is charging more for the premium without delivering more).

**Check 3 — Self-work expectation alignment.** Does the customer's self-work expectation differ across tiers in ways that match the tier's positioning? Premium tiers typically have less self-work (the operator provides more), while entry tiers have more self-work (the customer does more independently).

**Check 4 — Outcome trajectory alignment.** Does each tier produce a different reasonable outcome trajectory? Premium tiers should produce faster or higher-confidence outcomes; entry tiers should produce slower or self-paced outcomes. If the outcome description is identical across tiers, the tiering is fake.

**Check 5 — Cross-tier accessibility.** Can a customer enter at entry tier and upgrade to standard or premium mid-engagement? If upgrade paths are clear and structurally supported, the tiers cohere; if upgrade is impossible or financially punishing, the tiers are siloed offers in tier costume.

**Check 6 — Customer self-selection clarity.** Can a prospective customer read the three tiers and clearly identify which tier matches their situation, or do all three tiers seem like potentially-fitting choices? Clear differentiation supports customer self-selection; ambiguity indicates tier overlap.

**Test result:** all six checks must pass for the tiering to be legitimate. Any failure indicates either fake tiering (revise the tier design) or that the offer is not appropriate for tiering after all (route back to the diagnostic and consider the flat path).

### Worked Example: Darius's Tiered Design

Darius's Reading Club passed all three diagnostic gates: genuine segments (early-career, mid-career, staff engineers), structural differentiation (different mechanism components per tier), capacity to deliver (cohort infrastructure shared, 1:1 time scales with premium count).

**Darius's three tiers:**

- **Foundations** ($300/month, 3-month minimum) — Self-paced platform-engineering curriculum + community access + monthly office hour. Mechanism: self-study + peer learning. Customer self-work: high (10-15 hrs/week independent study). Outcome: foundational platform-engineering competency.

- **Practitioner** ($600/month, 3-month minimum) — Foundations + weekly cohort sessions + practitioner-track curriculum + Slack mentor access. Mechanism: self-study + peer learning + cohort dynamics + mentor guidance. Customer self-work: moderate (5-10 hrs/week independent + cohort work). Outcome: applied platform-engineering capability.

- **Master** ($1,200/month, 6-month minimum) — Practitioner + biweekly 1:1 with Darius + executive presence coaching + leadership patterns curriculum. Mechanism: all of Practitioner + senior mentorship + leadership development. Customer self-work: low-moderate (3-5 hrs/week + 1:1 work). Outcome: staff-engineer-track preparation.

**Anti-Fake-Tiering Test results for Darius:**
- Check 1 (mechanism differentiation): Pass. Each tier introduces structurally different mechanism components.
- Check 2 (operator-time scaling): Pass. Foundations: ~30 min/month operator time. Practitioner: ~3 hours/month. Master: ~8 hours/month.
- Check 3 (self-work alignment): Pass. Self-work expectation decreases across tiers as operator involvement increases.
- Check 4 (outcome trajectory): Pass. Three different outcome trajectories defined.
- Check 5 (cross-tier accessibility): Pass. Customer can upgrade from Foundations to Practitioner mid-engagement (prorated); from Practitioner to Master at any point.
- Check 6 (self-selection clarity): Pass. The descriptions allow prospective customers to clearly identify their tier.

Darius's tiering passes the test. The Tier Structure Document specifies the three tiers, the price points, the deliverable mapping, and the test results.

---

## The Flat Path

If your diagnostic failed any gate, you take the flat path.

### Flat-Pricing Rationale Components

**Component 1 — Diagnostic finding.** Which gate failed and why? Be specific:
- Gate 1 fail: audience is homogeneous; document the homogeneity evidence
- Gate 2 fail: deliverable cannot be structurally differentiated; document why
- Gate 3 fail: operator capacity does not support concurrent tiers; reference M7.5

**Component 2 — Operator identity coherence.** Service-Operator and Builder-Operator offers often live more naturally in flat pricing; Teacher-Operator offers more often support tiering. State how flat pricing aligns with operator identity.

**Component 3 — Customer experience reasoning.** Flat pricing produces simpler customer experience (no choice paralysis, no upgrade ladder anxiety, no comparison shopping within tiers). For some offers, this simplicity is structurally valuable.

**Component 4 — Anti-discount integration.** Flat pricing requires stronger anti-discount discipline (because there is no entry tier as a "lower-cost option" to redirect price-sensitive prospects). State how M8.6 will handle prospects who cannot afford the flat price.

### Worked Example: Maya's Flat-Pricing Rationale

Maya runs the diagnostic:

- Gate 1: her audience is homogeneous (senior illustrators ready for licensing-track expansion). Different willingness-to-pay across the audience exists, but the deliverable need is uniform. **Gate 1 fails.**
- Gate 2: she could theoretically design tiers, but the deliverables would be artificial volume-variations of her core Sprint. **Gate 2 fails.**
- Gate 3: her capacity ceiling (4 concurrent) cannot support three tiers without fragmentation. **Gate 3 fails.**

All three gates fail. Maya takes the flat path.

**Maya's Flat-Pricing Rationale:**

- Diagnostic finding: all three gates failed. The audience is homogeneous; the deliverable cannot be structurally differentiated without producing volume-only fake tiers; capacity ceiling does not support three concurrent tiers.
- Operator identity coherence: Service-Operator pricing in Q4 (High Value, Narrow Access) lives naturally in flat pricing. The intensity of 1:1 Service-Operator delivery is the value; tiering would dilute the intensity.
- Customer experience reasoning: senior illustrators evaluating Maya's offer are evaluating one engagement, not choosing between three engagement levels. The clarity of one offer at one price simplifies their decision.
- Anti-discount integration: M8.6 will need to handle price-sensitive prospects through anti-discount scripts (Voss/Enns/Stark patterns) and through the partial-scope referral path (recommending self-paced alternatives such as books or Skillshare courses) rather than through tier downgrades.

Maya files the Flat Pricing Rationale Statement (~700 words) and proceeds to M8.6.

---

## The Document Templates

### Tier Structure Document Template (1,000-1,500 words, six sections)

**Section 1 — Diagnostic Results (150-200 words)** — show the three gates passed with specific evidence.

**Section 2 — Tier Definitions (300-400 words)** — for each tier, specify: name, price, mechanism components included, operator-time allocation, customer self-work expectation, duration/cadence, deliverables.

**Section 3 — Tier Price Point Rationale (150-200 words)** — show the price relationships (entry as % of standard; premium as multiple of standard) and justify the spacing.

**Section 4 — Anti-Fake-Tiering Test Results (200-300 words)** — show all six checks with specific pass evidence.

**Section 5 — Cross-Tier Mechanics (100-150 words)** — upgrade paths, downgrade conditions, mid-engagement tier changes.

**Section 6 — Cross-References (100-150 words)** — what M8.6 anti-discount policy will need to handle differently across tiers; what M8.7 raise schedule will need to address per tier.

### Flat Pricing Rationale Statement Template (600-800 words, four sections)

**Section 1 — Diagnostic Findings (200-250 words)** — which gate(s) failed, with specific evidence.

**Section 2 — Operator Identity Coherence (150-200 words)** — how flat pricing aligns with operator identity and offer structure.

**Section 3 — Customer Experience Reasoning (150-200 words)** — why flat pricing produces better customer experience for this offer.

**Section 4 — M8.6 Integration Note (100-150 words)** — how the anti-discount policy will handle the absence of a tier-downgrade option for price-sensitive prospects.

---

## Common Failure Modes at M8.5

The Sonnet `tier-structure-reviewer-v1.0.0` prompt and AI rubric look for these:

1. **Skipping the diagnostic.** Operator proceeds straight to tier design without running the three-gate diagnostic. The rubric flags any document missing diagnostic results.

2. **Failing the diagnostic but forcing tiers anyway.** Operator's diagnostic shows all three gates fail, but the operator designs tiers regardless, often citing pro-tier bias ("but tiering will increase my revenue"). The Anti-Fake-Tiering Test catches this; the AI rubric flags any document where diagnostic fail and tier design coexist without explicit reasoning override.

3. **Fake tiering disguised as structural.** Operator presents three tiers that the Anti-Fake-Tiering Test fails on Checks 1 or 2. The rubric runs the test independently; if the test fails, the document is flagged.

4. **Generic tier names.** Bronze/Silver/Gold or Basic/Pro/Enterprise — the names signal that the tiering may be price-discrimination-shaped rather than structural. The rubric flags generic names as worth examining.

5. **Inappropriate price ratios.** Tiers spaced too closely (entry at 80% of standard, premium at 110% of standard) suggest forced tiering. The rubric checks ratio ranges.

6. **Flat path without diagnostic citation.** Operator takes the flat path but does not cite which gate failed and why. The rationale must be specific.

---

## Checkpoint 8.5

Your deliverable is one of:
1. **Tier Structure Document** filed in Drive, 1,000-1,500 words, six sections (tiered path)
2. **Flat Pricing Rationale Statement** filed in Drive, 600-800 words, four sections (flat path)

Plus:
- Diagnostic results recorded in Supabase `c8_tier_structures.diagnostic_outcome`
- Tier definitions or flat rationale recorded in `c8_tier_structures.structure_specification`

The AI rubric scoring the document looks for these properties:
- Diagnostic run with all three gates assessed
- Path selection (tiered or flat) consistent with diagnostic results
- If tiered: Anti-Fake-Tiering Test run with all six checks
- If flat: rationale specific to which gate(s) failed
- Cross-references to M8.6 and M8.7 needs

Target score: ≥ 7/10. Operators who score below typically have either skipped the diagnostic (the most common gap) or forced tiers despite a failing diagnostic (the second most common).

---

## What M8.6 Expects From You

M8.6 (anti-discount policy) reads from your M8.5 deliverable:

- If tiered: M8.6 specifies discount policy per tier, with the entry tier serving as the natural "downgrade path" for price-sensitive prospects.
- If flat: M8.6 must handle price-sensitive prospects without a tier-downgrade option, requiring stronger language patterns and clearer alternative-routing.

File the M8.5 deliverable. Proceed to M8.6 (which can run in parallel with the second sitting of M8.5 if scheduling supports).

---

*Last updated: April 25, 2026 · Version 2.0*

Complete supporting source — Tier appropriateness diagnostic

# Tier Appropriateness Diagnostic Worksheet

**Used in:** M8.5 — to determine whether three-tier pricing fits the offer or whether flat-pricing is correct · **Time required:** 45-60 minutes

---

## Purpose

Three-tier pricing is fashionable. Many operators introduce tiers because conventional wisdom (Hermann Simon, conversion-rate playbooks) suggests tiers increase conversion through anchoring effects. But tiers introduce real costs: customer cognitive load, decision friction, scope-design effort across three points, and the risk of fake tiers (entry tier is artificially weak, premium tier is artificially expensive, only standard tier is real).

This worksheet diagnoses whether tiers fit *your* offer. Flat-pricing is a valid choice; the worksheet protects operators from introducing tiers reflexively.

---

## Section 1 — Tier-Fit Conditions

Score 1 (low) to 5 (high) for each condition.

### Condition 1: Genuine differentiation across tiers exists

Three tiers requires three genuinely different offers, not one offer with three packaging variations. The differentiation is in scope, depth, support level, or speed — not in line items added or removed cosmetically.

**Score:** ___ /5

If you cannot describe the entry tier in 30 seconds without referencing the standard tier, the entry tier is not differentiated. If you cannot describe the premium tier without saying "everything in standard plus...", the premium tier is not differentiated.

### Condition 2: Customer segments naturally cluster into 3 levels

Tier pricing fits when your customer base has natural segmentation into 3 willingness-to-pay levels. This requires either: (a) measurable customer attribute differences (company size, role seniority, use-case complexity), or (b) measurable price-sensitivity stratification observed in actual sales conversations.

**Score:** ___ /5

If your customer segmentation is hypothetical ("there might be smaller/larger customers"), score 1-2. If it's measured, score 4-5.

### Condition 3: Operator has capacity to maintain three offers

Each tier is a real offer requiring scope discipline, delivery quality, and ongoing iteration. Three tiers triple the operator's offer-maintenance load.

**Score:** ___ /5

If you are at C7 capacity-constraint level and adding tier complexity, score 1-2. If you have substantial buffer, score 4-5.

### Condition 4: Customer decision process accommodates tier choice

Some customer decision contexts handle 3 options well (B2C, low-stakes, fast-decision). Others handle them poorly (B2B with procurement, high-stakes, multi-stakeholder). If your customer decision process is high-stakes and multi-stakeholder, three tiers add coordination cost on the customer side.

**Score:** ___ /5

### Condition 5: Premium tier signals are visible

Premium tiers work when premium signals are visible to customers (faster turnaround, named-senior delivery, dedicated channel, etc.). If the premium tier looks identical to standard tier from outside, it cannot price like a premium tier.

**Score:** ___ /5

### Condition 6: Entry tier doesn't cannibalize standard tier

Entry tier is intended to capture price-sensitive customers who would otherwise walk. It works when the entry tier is genuinely a smaller offer for a smaller need, not a discounted standard tier. If customers can use entry tier where they would have bought standard tier, entry tier cannibalizes.

**Score:** ___ /5

### Condition 7: Operator has clear anti-cannibalization rules

If conditions 5-6 require active enforcement, the operator must have rules ready: e.g., "premium tier customers get 48-hour turnaround; if standard tier customers ask for 48-hour turnaround, they upgrade." Without these rules, tier integrity collapses.

**Score:** ___ /5

---

## Section 2 — Total Score and Interpretation

| Total | Interpretation |
|---|---|
| 30-35 | Strong fit for three-tier. Proceed to M8.5 tier design. |
| 22-29 | Moderate fit. Three-tier is viable but requires careful design and the Anti-Fake-Tiering Test. |
| 14-21 | Weak fit. Strongly consider flat-pricing. If tier design is pursued, expect significant iteration in M8.5. |
| 7-13 | Poor fit. Flat-pricing is correct. Document the rationale per M8.5 flat-pricing path. |

---

## Section 3 — Anti-Fake-Tiering Test (if scoring 22+)

If proceeding with three-tier, run this test:

**Test 1 — Describe each tier in 30 seconds without reference to other tiers.** If you cannot, that tier is not real.

**Test 2 — Identify a customer who would buy each tier and not be tempted by adjacent tiers.** If the same customer profile would be torn between two adjacent tiers, the tiering is not real.

**Test 3 — Project tier mix at 12 months: what % of customers will land in each tier?** Healthy distributions vary, but 80%+ in one tier suggests the other tiers are decoy or vestigial.

**Test 4 — Verify the entry tier survives without cross-subsidy from standard tier.** Entry tier must be sustainably priced on its own unit economics, not subsidized by standard tier margin.

**Test 5 — Verify the premium tier prices ≥ 2× standard tier.** Premium tiers that price at 1.3× standard tier rarely work; the price difference is too small to signal differentiation.

If any of these tests fails, tiers are fake. Either redesign or revert to flat-pricing.

---

## Section 4 — Flat-Pricing Path Documentation

If choosing flat-pricing, document:

1. **Why flat-pricing fits this offer.** Reference the Section 1 scores.
2. **What conditions would trigger tier introduction in the future.** Specify thresholds (e.g., "introduce tiers when consistent demand for both shorter/cheaper and longer/more-premium variations is observed in ≥ 12 sales conversations over a 90-day window").
3. **How segmentation handles different customer sizes without tiers.** Often via scope-premium schedule (M8.4 Section 7) rather than tier pricing.

This documentation is the M8.5 deliverable for flat-pricing operators. It is not a placeholder; it is a substantive defense of the choice.

---

*This worksheet protects operators from introducing tier complexity reflexively. Roughly 40% of C8 operators arrive intending to build three tiers; after the diagnostic, ~60% of them switch to flat-pricing. Tier complexity is a tool, not a default.*

Complete supporting source — Tier structure reviewer

name: tier-structure-reviewer
version: 1.0.0
module: M8.5
course: C8 Pricing Discipline
model: claude-sonnet-4-6
role: Tier Structure Reviewer
review_type: artifact_review
description: >
  Reviews the M8.5 deliverable, which is either a Three-Tier Structure
  Document or a Flat-Pricing Rationale. Verifies that the choice between
  tiered and flat pricing is grounded in the Tier Appropriateness Diagnostic,
  that tiers (if chosen) pass the Anti-Fake-Tiering Test, and that flat
  pricing (if chosen) is defended substantively rather than as a default.

system_prompt: |
  You are the Tier Structure Reviewer for the RISER Nation Maritime Academy
  C8 Pricing Discipline course, Module 8.5. You review the operator's
  decision between three-tier pricing and flat pricing, plus the resulting
  artifact.

  M8.5 is unique in C8: there are two valid paths. Three-tier and flat are
  both legitimate. Your role is to verify that the chosen path is
  appropriate and well-executed, not to favor one over the other.

  ## What to evaluate

  Read the submitted Tier Structure Document OR Flat-Pricing Rationale,
  plus the linked Tier Appropriateness Diagnostic Worksheet results and
  M8.4 Pricing Architecture Document.

  Score against eight criteria. Pass threshold: average ≥ 7.0 AND no
  individual criterion below 5.0.

  **Criterion 1 — Path choice grounded in diagnostic**
  Did the operator complete the Tier Appropriateness Diagnostic and use
  its scoring to guide the path choice? Operators with diagnostic scores
  ≥ 22 typically choose tiered; operators with scores ≤ 21 typically
  choose flat. Mismatches between diagnostic score and path choice must
  be explicitly defended.

  **Criterion 2 — IF TIERED: Anti-Fake-Tiering Test passed**
  Three-tier documents must show the operator running the five Anti-Fake-
  Tiering tests:
  - Each tier describable in 30 seconds without reference to others
  - Identifiable customer who buys each tier without temptation toward
    adjacent tiers
  - Projected tier mix doesn't show 80%+ in one tier
  - Entry tier survives without cross-subsidy
  - Premium tier prices ≥ 2× standard tier

  Failures on any of these tests must be addressed (redesign or path
  switch to flat).

  **Criterion 3 — IF TIERED: Three tier prices specified with magnitudes**
  Tier prices must be concrete numbers, not ranges. Tier mix targets
  (% projected per tier) must be specified.

  **Criterion 4 — IF TIERED: Anti-cannibalization rules specified**
  Tiered offers require rules preventing premium-tier-attribute leakage to
  standard-tier customers (e.g., "premium tier customers get 48-hour
  turnaround; standard tier customers requesting 48-hour turnaround upgrade
  to premium"). Without these rules, tier integrity erodes.

  **Criterion 5 — IF FLAT: Flat-pricing rationale references diagnostic**
  Flat-pricing documents must cite the diagnostic result and explain why
  the operator's offer doesn't fit tiered structure. Generic flat-pricing
  rationale ("I prefer simplicity") fails this criterion.

  **Criterion 6 — IF FLAT: Future tier-introduction triggers specified**
  Flat pricing today doesn't preclude tiers later. The document must
  specify what conditions would trigger a future M8.5 tier-design exercise
  (e.g., "≥ 12 sales conversations in 90 days requesting both
  shorter-cheaper and longer-premium variations").

  **Criterion 7 — IF FLAT: Segmentation handled via scope-premium**
  Flat pricing handles customer-size variation through M8.4 scope premium
  schedule, not through pretend-tiers. The flat-pricing document must
  explicitly route customer-size questions to the scope premium schedule.

  **Criterion 8 — Coherence with M8.4 architecture**
  IF TIERED: standard tier price should match M8.4 base price (or explain
  variance).
  IF FLAT: flat price should match M8.4 base price exactly.

  Discrepancies between M8.5 and M8.4 must be reconciled before clearance.

  ## How to write the review

  Same structure as prior reviewers, with one addition:
  - State explicitly which path (tiered or flat) the operator chose
  - Score the appropriate criteria for that path
  - Use NA for criteria that don't apply to the chosen path

  Final paragraph addresses M8.6 hand-off (anti-discount policy must
  accommodate any tier-mix complexity).

  ## Decision thresholds

  - CLEARED: average ≥ 8.0 (across applicable criteria), no applicable
    criterion below 6.0
  - NEEDS_REVISION: average 6.0-7.9, OR any applicable criterion 4.0-5.9,
    OR Anti-Fake-Tiering Test failure
  - NOT_CLEARED: average < 6.0 OR any applicable criterion < 4.0 OR ≥ 2
    Anti-Fake-Tiering Test failures

  ## Tone and discipline

  Roughly 60% of operators arrive at M8.5 intending three-tier and
  switching to flat after the diagnostic. Both outcomes are legitimate.
  Frame the diagnostic as protective, not as failure-detection.

  Operators sometimes arrive convinced of three-tier from external
  pricing literature (Hermann Simon, conversion-rate playbooks). Be
  willing to flag fake-tier patterns that come from imported templates.

  Operators who choose flat-pricing should not feel like they "settled."
  Flat pricing is operationally simpler and often produces better
  customer-decision flow than tiered. The diagnostic protects them from
  importing complexity.

review_criteria_if_tiered:
  - path_choice_grounded_in_diagnostic
  - anti_fake_tiering_test_passed
  - three_tier_prices_specified_with_magnitudes
  - anti_cannibalization_rules_specified
  - coherence_with_m84_architecture

review_criteria_if_flat:
  - path_choice_grounded_in_diagnostic
  - flat_pricing_rationale_references_diagnostic
  - future_tier_introduction_triggers_specified
  - segmentation_handled_via_scope_premium
  - coherence_with_m84_architecture

decision_thresholds:
  CLEARED:
    average_min: 8.0
    no_applicable_criterion_below: 6.0
  NEEDS_REVISION:
    average_range: [6.0, 7.9]
    or_any_applicable_criterion_range: [4.0, 5.9]
    or_anti_fake_tiering_failure: true
  NOT_CLEARED:
    average_below: 6.0
    or_any_applicable_criterion_below: 4.0
    or_two_or_more_anti_fake_tiering_failures: true

instructor_handoff:
  triggered_when: NOT_CLEARED OR persistent_path_mismatch
  routing: C8 instructor queue, priority normal
  expected_resolution_window: 14 days from handoff

cooling_period_after_clearance:
  hours: 24
  rationale: >
    Tier or flat is a structural commitment. Brief cooling period allows
    operator to verify the choice fits their voice and operating model
    before M8.6 anti-discount policy is built against it.

Lesson 03.2 — sources for the added teaching sections

M9.2 - AWARENESS-LEVEL MATCHING

Match the next offer to demonstrated readiness

The syllabus places awareness matching inside the legacy C9 Eight-Tier Value Ladder, Stage 2 Build, with C8 approval and an 8–12-hour, two-week course estimate. Its repeated stage line is formatting duplication. The central task is to match the information and commitment a person needs, rather than assume everyone must begin with the same offer. This C9 title differs from the quarterly-retreat C9 elsewhere; the current spreadsheet assignment remains the placement authority.

Use awareness as a hypothesis, not a buying law

The source says most-aware prospects buy T6 directly while unaware prospects need T0, and contrasts a stranger with a fan buying $25,000. These are illustrations, not categorical rules: trust, urgency, fit, resources and buying process matter. Assess what the person understands about the problem, possible solution and specific offer. A high-priced offer is not appropriate merely because someone follows you.

Build the awareness-by-tier matrix explicitly

The excerpt names an Awareness × Tier matrix but does not supply its cells or define all eight tiers. RISER exercise: for each actual offer, record intended problem, prerequisites, proof needed, commitment, delivery limits and useful next step. Then map the prospect’s demonstrated awareness to the smallest appropriate decision. Do not invent a universal T0–T7 price ladder or imply eight products must be created before learning from customers.

Correct mismatches and test the next step

An unaware visitor may need a clear problem explanation; an informed buyer may need scope, proof and terms instead of another introductory download. Track qualified progression, customer outcomes, delivery burden and retention. Front-end-only thinking can miss follow-on needs, but recurring offers and ladders do not guarantee compounding revenue. Customers may enter at different points, remain at one level or leave when their need is met.

Connect the lesson to the direct-marketing promise

RISER application: use Brunson’s hook, story and offer to explain a real problem, credible mechanism and appropriate next action. Apply the Hormozi value lens to improve useful outcomes and credible likelihood while reducing avoidable time and effort. Match the promise to evidence, delivery capacity and transparent terms. These are instructional connections, not endorsements or guaranteed results.

Complete original source text

M9.2 — AWARENESS-LEVEL MATCHING

============================================================





Source: Riser Nation Academy 2026 Syllabus





NOTE: This document is an excerpt copied from the master syllabus.

The master syllabus remains intact and unmodified.





---





PARENT COURSE: C9 — The 8-Tier Value Ladder

---

Stage: Stage 2 — Sailboat  ·  Phase: Build  ·  Prereq: C8 approved  ·  Time: 8–12 hours over 2 weeks





Stage: Stage 2 — Sailboat  ·  Phase: Build  ·  Prereq: C8 approved  ·  Time: 8–12 hours over 2 weeks

In Plain Words

A value ladder is a set of offers from free to expensive. Customers climb the ladder over time. We design 8 tiers, set guarantees per tier, and do the math. Most operators design only the front end and wonder why they have no recurring revenue.

The Mismatch This Course Fixes

Front-end-only thinking produces feast-or-famine. Ladder thinking produces compounding.

Modules





---





M9.2 — AWARENESS-LEVEL MATCHING

---





Most-Aware buys T6 directly. Unaware needs T0.

In plain words: Match offer to where they are. A stranger doesn't buy $25K. A fan does.

The Awareness × Tier matrix.

Common mismatch errors.

The 'Right Tier × Right Awareness' filter.





---

END OF M9.2

---

Native Google Doc text and original links

M9.2 — AWARENESS-LEVEL MATCHING
============================================================

Source: Riser Nation Academy 2026 Syllabus

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

---

PARENT COURSE: C9 — The 8-Tier Value Ladder
---
Stage: Stage 2 — Sailboat  ·  Phase: Build  ·  Prereq: C8 approved  ·  Time: 8–12 hours over 2 weeks

Stage: Stage 2 — Sailboat  ·  Phase: Build  ·  Prereq: C8 approved  ·  Time: 8–12 hours over 2 weeks
In Plain Words
A value ladder is a set of offers from free to expensive. Customers climb the ladder over time. We design 8 tiers, set guarantees per tier, and do the math. Most operators design only the front end and wonder why they have no recurring revenue.
The Mismatch This Course Fixes
Front-end-only thinking produces feast-or-famine. Ladder thinking produces compounding.
Modules

---

M9.2 — AWARENESS-LEVEL MATCHING
---

Most-Aware buys T6 directly. Unaware needs T0.
In plain words: Match offer to where they are. A stranger doesn't buy $25K. A fan does.
The Awareness × Tier matrix.
Common mismatch errors.
The 'Right Tier × Right Awareness' filter.

---
END OF M9.2
---

M9.6-Setting-the-New-Heading.md

Define the mission plan’s scope and evidence

M9.6 proposes a signed, one-page next-90-day plan after M9.5’s forecast and drift inventory, with 4–6 active hours and human review before progression. Its five elements are one destination, three milestones, two forcing trades, one kill criterion and a weekly review cadence. It reuses the C1 Harbor Launch structure and proposes renewal at C18, C27 and later retreats. These are program design choices; the excerpt does not prove that every downstream tool reads the plan.

Choose one dated destination and explain the choice

Write one observable outcome by a specific date. The source example is a third full-price customer under offer v2.1, not a promise of acquisition. Explain which audit gap, drift or strategic opportunity it addresses and what success or failure changes. Keep other projects in a separate backlog. One destination is a prioritization constraint; ongoing customer obligations still require capacity.

Write three dated evidence checkpoints

The example moves from a Day-30 sales call and full-price presentation to Day-60 onboarding and a first delivery survey at least 8/10, then Day-90 active engagement. For each milestone name date, observable result, yes/no test and evidence such as a CRM record. A scheduled call does not prove it occurred, and satisfaction from one customer does not prove general results. Verify logical sequence and realistic time for delivery.

Reconcile the plan calendar

A calendar quarter may not equal ninety days, and twelve weeks equals eighty-four days. The source alternates Day 30/60/90, week 4/8/12, quarter-end and signature-based start. Record one actual start/end and dated checkpoints, then explain any deviation. Resolve whether review approval precedes the start; do not promise a full ninety-day execution window after days have already elapsed.

Make two real forcing trades

Name two activities that were actually planned or underway, what is reduced or postponed, the lost benefit, evidence of the prior commitment and how the trade will be checked. Examples postpone a workshop and reduce LinkedIn posts from three to one per week to protect a Wednesday work block. “Work harder” is not a trade. The claim that exactly two is an empirical sweet spot is unsupported here; use it as the program’s format rule.

Write an actionable stop or revision condition

Include trigger, evaluation date, response and decision authority. The source example fires at Day 60 only if the third customer is not onboarded AND no qualified inbound lead arrived in the preceding thirty days. Both conditions must be true. Explain what qualifies as a lead, who reviews the evidence and how existing obligations continue. The template adds a one-page learning/abandonment memo submitted within seven days; do not merely promise to reassess.

Install a specific review cadence

Name day, time, duration, three review checks, evidence location and what warrants a mid-week adjustment. The example uses Sunday 6–6:30 p.m., weekly milestone review in a Captain’s Log and a month-end reread against the forecast. The validator’s “30–60 minutes minimum” is ambiguous; define the chosen duration. Calendar evidence is a required learner artifact, not proof that this lesson created an event.

Complete all template fields while keeping the summary usable

Include operator, period, signature date and actual database-write timestamp; destination rationale and consequences; three milestone evidence tests; two trades with cost and verification; kill response; weekly and exception review; top three audit domains; Open Ocean insights; forecast dependencies; categorized drift; signature and optional witness; verification/review timestamps and outcomes. The expanded template will not necessarily fit one page. Use a concise signed summary with linked supporting detail instead of deleting fields.

Treat signatures and workflow records accurately

The template requests a literal rather than typed signature as a program convention, plus five commitments: prioritize the destination, hold trades, review weekly, invoke the kill rule and evaluate actual outcomes at the next retreat. Preserve the actual signed version and revision history. This lesson neither signs for an operator nor establishes legal effect. The template’s filename omits the lesson’s M9.6 prefix; choose a consistent recorded path without losing the original reference.

Use human review to assess alignment and capacity

The proposed instructor check compares the destination with audit gaps, drift and honest capacity. It offers approval, approval with revision due within seven days, or substantial rewrite, with a claimed 48-hour response. The closing text instead says no unlock until revision is approved. Resolve this conflict in the actual course rules. Do not represent the turnaround or conditional unlock as implemented service behavior.

Correct six mission-plan failure patterns

Choose one destination rather than disguising several; address the consequential gap rather than only a comfortable task; match milestones to measured capacity, such as five supported customers rather than eight implied; replace vague stop criteria with observable rules; supply real calendar evidence; and make trades that genuinely free resources. Treat discrepancies as correctable evidence gaps, not proof of dishonesty or unwillingness.

Read the mission validator as a proposed assessment

The YAML checks outcome specificity, feasibility, forecast/drift alignment, three dated/verifiable/sequenced milestones, two real trades, one observable stop rule and concrete cadence. It also checks carried-forward items and prior-quarter actuals. Its assertion that hundreds of operators validate the format is unsupported. Its harsh presumption that mistakes are bargaining is not a justified diagnosis. Provide precise, respectful feedback and preserve the human review gate.

Define the validator output contract before implementation

The proposed JSON includes destination validity/specificity/forecast/drift flags; milestone count/date/verification/sequence flags; trade count/specificity; kill/cadence/carry flags; instructor concerns, strengths, recommendation and narrative summary. Its alternatives and 0–N placeholders are notation, not valid executable JSON. Define real field types, accepted values, missing-evidence behavior and tests. The named model is source configuration, not a verified deployed service.

Preserve the intended approval order

The validator’s workflow is submission, machine assessment, instructor review with M9.5 evidence, instructor decision, then writing approved context and unlocking M9.7. The lesson/template suggest verification at submission, creating an ordering conflict. Use a draft record separate from active approved context, with explicit version and approval evidence. A title saying validated is not instructor approval.

Understand the six supplied database functions

The SQL proposes enrollment eligibility, C9 completion, Stage 1 audit, Stage 2 audit, C10 readiness and mission-plan writing. It creates functions, not the underlying tables, policies, queue or application. No SQL was executed. The source’s claim that all functions verify the caller is contradicted by the bodies: they accept supplied IDs without a caller/subject or instructor authorization check.

Review enrollment and completion checks precisely

Enrollment checks for a signed C8 attestation and eight distinct completed course codes; it does not prove chronological sequence. C9 completion checks retreat existence, M9.7 record, M9.8 assessment, signed attestation and approved/written mission plan in that order. Record existence is not full artifact validation. Unconstrained multiple assessment rows make selection ambiguous; schema constraints and deterministic version selection are required.

Keep audit snapshots separate from historical truth

Stage 1 returns the current operator brief as C1, plus identity, offer, market-signal and rhythm collections. Overwriting that brief with a later plan would lose its ability to represent the original C1 artifact unless history is separately retained. Stage 2 reads latest console, voice and pricing records plus ninety-day invoices. Its C6 console/C7 voice labels conflict with offer-course references elsewhere. Define versioned course identifiers, stable ordering, empty-array handling and historical snapshots.

Correct the readiness function’s interface and side effects

The template says assess_c10_readiness(user_id) verifies and returns plan content. The actual function takes a retreat ID, calls C9 completion, checks log entries and can write an enrollment timestamp; it does not return the plan. Its comment says two of three active changes, while code counts at least five entries with progress at least three. It does not enforce seven unique dated days and may fail on malformed integer strings. Its returned current timestamp can differ from an earlier stored unlock time. Use a separate authorized read to verify the exact stored plan.

Fix the missing-approval and write-verification gaps

The writer rejects decision != approve, but a NULL decision yields an unknown condition and does not enter that rejection branch. A null-safe requirement such as IS DISTINCT FROM approve is needed. It copies fields without validating one/three/two counts, dates, signature, calendar or feasibility, despite the lesson’s format-validation claim. It overwrites the whole operator brief and marks the review written without checking a user row was updated. Preserve prior versions, validate fields, enforce actual approval, check affected rows and test the atomic operation before deployment.

Protect privileged database functions before using them

All six are SECURITY DEFINER; the script has no fixed search_path, caller authorization or explicit execution-grant policy. Review whether elevated privilege is necessary, restrict callable roles, verify ownership/admin scope, set a safe search path and qualify relations. Test unauthenticated, wrong-user, NULL approval, absent-user, duplicate-row and malformed-log cases on isolated data. A source comment is not a security control.

Keep the reading list connected to the actual exercise

The source names The 12 Week Year, Measure What Matters, Immunity to Change and Tiny Habits. Use these as further reading on execution cycles, goal construction, change and habit design; the cited titles do not prove RISER’s exact numeric rules or outcomes. The official author/publisher pages below identify the works. The supplied source gives Tiny Habits a 2019 date; verify the edition before reproducing bibliographic details.

Connect the lesson to the direct-marketing promise

Complete original source text

M9.6 — Setting the New Heading: Next Quarter Mission Plan

Module: 9.6 Title: Setting the New Heading — Next Quarter Mission Plan Stage: 2 — The Sailboat Duration: 4–6 hours active (the most cognitively dense module after M9.2) Deliverable: Signed Next-90-Day Mission Plan + Supabase users.operator_brief row updated Validator: mission-plan-validator-v1.0.0.yaml (Opus 4.7 — gated, course-critical) HITL: Manual instructor review required before M9.7–M9.8 unlock Prerequisite: M9.5 complete (12-Point Forecast + Drift Inventory filed)

________________

What This Module Does

M9.6 produces the Mission Plan — the single forward-pointing document that integrates everything surfaced in the prior five modules into a structured commitment for the next 90 days. The Mission Plan is the highest-leverage artifact in C9. Every downstream tool reads from it. The C1 Captain's Oath rotated forward becomes the C9 Mission Plan; the Mission Plan rotated forward at the next quarterly retreat (C18) becomes the next quarter's plan.

The Mission Plan format matches the C1 Harbor Launch format exactly:

* One destination — singular, specific, dated

* Three milestones — dated, falsifiable, mapped to the destination

* Two forcing trades — what is given up to make the destination possible

* One kill-criterion — the condition under which the destination is abandoned, with the abandonment process specified

* Weekly review cadence — the calendar discipline that maintains the plan over 90 days

The plan is signed (literal signature, not metaphor — the operator dates and signs the document) and written to Supabase users.operator_brief, which is the persistent context field every downstream Claude tool reads from. A bad Mission Plan contaminates 90 days of automated work; the M9.6 validator (Opus 4.7) is the highest-stakes prompt in C9.

This module is HITL-gated: an instructor must manually review the Mission Plan before M9.7 and M9.8 unlock. This is the only HITL gate in C9.

________________

Why The C1 Format

The C1 Harbor Launch format was designed to be operator-portable. The same structure that worked at C1 (when the operator had no customers and was making first commitments) works at C9 (when the operator has multiple customers and is rotating forward). It will work at C18, C27, C36, and beyond.

The format is constrained for two reasons:

Reason 1 — Constraint forces priority. "One destination" is intentional. Operators given freedom to specify multiple destinations reliably specify three or four, which produces a 90-day plan that fragments execution attention. The single-destination constraint forces the operator to choose what is most important, with everything else either subordinated or postponed.

Reason 2 — Repeatability over time. The same five-element structure across every quarterly retreat means operators develop a year-over-year comparison set. The operator's third Mission Plan (at C27) can be compared directly to the first (at C9), and patterns surface. Operators who deliver against their stated kill-criteria are operating different from operators who never invoke them.

________________

The Five Elements — Detailed

Element 1 — One Destination

A single, specific, dated outcome the operator commits to over the next 90 days.

Acceptable form:

"By [Q-end date], I will have onboarded a third paying customer at full price under the v2.1 offer architecture, completing the Proof Threshold for C10 graduation."

Unacceptable forms:

"Grow the business" — not specific "Acquire 3 customers and ship the new course and launch the partnership" — not singular "Be in a better place by Q-end" — not dated, not specific

The destination is typically the closing of the highest-leverage gap from the M9.2 audit, OR the resolution of the most consequential drift from the M9.5 inventory, OR a forward strategic move surfaced in M9.4 Open Ocean. It is rarely all three. Choose one.

The destination is dated to a specific Q-end date, not "next quarter" or "in 90 days." The specific date is part of the discipline.

Element 2 — Three Milestones

Three dated, falsifiable checkpoints between today and the destination. The milestones are not deliverables — they are evidence-points that confirm the destination is on track.

Acceptable form:

Milestone 1 (Day 30): Customer 3 sales call completed; offer v2.1 formally presented; pricing held at $X. Milestone 2 (Day 60): Customer 3 onboarded; first delivery cycle complete; satisfaction survey scored ≥8/10. Milestone 3 (Day 90): Customer 3 in-engagement; Voyage Log Review for next retreat reflects 3 paying customers active.

Each milestone is falsifiable: at the milestone date, either the milestone was met or it wasn't. No "kind of" — yes/no.

Unacceptable forms:

"Make progress on customer acquisition" — not falsifiable "Have a great Q2" — not specific, not falsifiable

Element 3 — Two Forcing Trades

Two specific things the operator is giving up to make the destination possible. The forcing trades are the cost of the destination.

Acceptable forms:

Forcing Trade 1: I will not launch the secondary offer (the workshop) until after Q-end. The workshop is queued for next quarter. Forcing Trade 2: I will reduce LinkedIn posting frequency from 3x/week to 1x/week to protect the Wednesday Deep Work block.

The trades must be real losses. Operators who specify trades that they were not going to do anyway ("I will not launch a podcast this quarter" — when they had no plans to launch a podcast) fail the validator. The trade must be something the operator was actively doing or planning, that they are now postponing or reducing.

Why two, not three or one:

* One trade typically isn't enough — most destinations require multiple things to be given up

* Three or more trades signal that the destination is too large, or that the operator hasn't chosen

* Two is the empirical sweet spot across cohort

Unacceptable forms:

"I will work harder" — not a trade "I will be more focused" — not a specific behavioral change "I will not do anything that doesn't matter" — not testable

Element 4 — One Kill-Criterion

The single condition under which the destination is abandoned, with the abandonment process specified. The kill-criterion exists because operators who commit to a destination without a kill-criterion reliably stay committed past the point where the commitment is destroying value. The kill-criterion is the formal release valve.

Acceptable form:

Kill-Criterion: If by Day 60 (Milestone 2), Customer 3 is not yet onboarded AND I have not received any qualified inbound leads matching ICP in the prior 30 days, I will abandon the Q2 destination, return to the M9.5 forecast, and revise the Mission Plan with my instructor.

The kill-criterion has three required components:

* The trigger condition (specific, dated, observable)

* The action triggered (abandon, revise, escalate)

* The decision authority (operator alone, with instructor, with peer)

Unacceptable forms:

"I will reassess if things aren't working" — not specific, not dated "If I'm struggling, I'll make changes" — not falsifiable

Element 5 — Weekly Review Cadence

The calendar discipline that maintains the Mission Plan over 90 days. Specifically: when the operator will review the plan against current state, what they will check, and how they will adjust.

Acceptable form:

Weekly Review: Sunday evenings, 30 minutes, reviewing the three milestones against current week's actions, logging in Captain's Log. Monthly review at end of each calendar month including a full Mission Plan re-read against M9.5 forecast.

The review cadence is calendar-blocked at the time the Mission Plan is signed, not later. The validator checks for a calendar block in the operator's Calendar reflecting the cadence.

________________

Writing to Supabase users.operator_brief

The Mission Plan is not just filed in Drive — it is written to the Supabase users.operator_brief field. This field is the persistent context every downstream Claude tool reads from. The operator's Priority Brief Agent (Build 7), the content-generation tools (Build 6), the customer-onboarding tools, and the agent fleet all use this context.

Why this matters: the Mission Plan you sign in C9 shapes every prompt every tool sends every day for 90 days. A vague Mission Plan ("grow the business") produces vague tool outputs. A sharp Mission Plan ("close Customer 3 at full price under v2.1 by Q-end, with Wednesday block protected at ≥75%") produces tool outputs that systematically support that destination.

The Supabase write is performed via the M9.6 helper (04_Tools-and-Infrastructure/c9-supabase-functions.sql), which validates the Mission Plan format before writing. A poorly-formatted plan fails the write and returns to the operator for revision.

________________

The HITL Gate

M9.6 is the only HITL gate in C9. After the Opus 4.7 validator confirms the plan format is structurally sound, the plan is queued for instructor review. The instructor reviews the plan against three specific criteria:

Criterion 1 — Coherence with M9.2 audit. Does the destination address the actual top-three gap domains, or does it address something more comfortable?

Criterion 2 — Coherence with M9.5 drift inventory. Does the Mission Plan correct the consequential drift identified, or does it ignore drift in favor of forward growth?

Criterion 3 — Plausibility against capacity. Does the destination + milestones + forcing trades fit within the operator's honest capacity (M9.5 Surface 5)?

Instructor review is delivered within 48 hours. Possible outcomes:

* Approved — M9.7 and M9.8 unlock. The Mission Plan is final.

* Approved with revision — Operator addresses specific feedback and resubmits. M9.7 and M9.8 unlock conditional on revision being filed within 7 days.

* Returned for substantial revision — The Mission Plan is rewritten. Validator + HITL run again.

The HITL gate is not optional. The Mission Plan is the most consequential artifact in C9; instructor review is the safety check on operator self-deception that the Opus validator may not catch.

________________

Common Failure Modes in M9.6

Failure Mode 1 — Multiple Destinations

The operator splits attention across two or three destinations because choosing one feels like losing the others. The validator returns this for revision: choose one. The others are queued for the next retreat.

Failure Mode 2 — Comfortable Destination

The destination is chosen for its comfort rather than its leverage. The most consequential gap from M9.2 was Pricing Drift; the operator chooses Customer Acquisition as the destination because pricing conversations are uncomfortable. The HITL gate flags this — the instructor compares the destination against the audit gaps and surfaces the misalignment.

Failure Mode 3 — Aspirational Capacity

The operator's forcing trades and milestones assume capacity that does not match the M9.5 Surface 5 forecast. The validator cross-references and flags: "M9.5 Surface 5 forecasts maximum 5 concurrent customers; M9.6 milestones imply 8."

Failure Mode 4 — Soft Kill-Criterion

The kill-criterion is unenforceable theater. "I'll reassess if things aren't working." The validator returns for revision until the kill-criterion is binary, dated, and tied to a specific action.

Failure Mode 5 — No Calendar Block for Review Cadence

The operator commits to a weekly review cadence but does not block the calendar at the time of signing. The validator requires evidence of the calendar block. Operators who do not block the calendar at signing reliably do not maintain the cadence at week 4.

Failure Mode 6 — Unrealistic Forcing Trades

Trades that are not real losses. "I'll stop the podcast I never started." The validator requires the trade to be something the operator was actively doing. The instructor HITL surfaces non-real trades that the validator may have missed.

________________

What You Will Submit for M9.6

Two artifacts, both submitted via the C9 module 9.6 Supabase row:

Deliverable 1 — Signed Next-90-Day Mission Plan (PDF)

A 1-page Mission Plan in the C1 Harbor Launch format, signed (literal signature with date), filed to Drive at Drive/Retreat/[Q-end-date]/M9.6-Mission-Plan-Signed.pdf. Use the template in 02_Resources/Mission-Plan-Template.md.

Deliverable 2 — Supabase users.operator_brief Update

The Mission Plan written to Supabase via the M9.6 helper function. Verification of the write is via assess_c10_readiness(user_id) which reads from users.operator_brief and confirms the plan is present and structurally valid.

________________

What Comes Next

When the validator confirms structural soundness AND the HITL instructor approves:

* M9.7 (Reinforcing the Crew) unlocks

* The Mission Plan is now active context for every downstream Claude tool

* The 90-day clock starts on the operator's signed commitment

* The weekly review cadence begins this Sunday

If the HITL gate returns the plan for revision, M9.7 and M9.8 do not unlock until revision is approved. The retreat does not advance on a contaminated Mission Plan.

________________

Reading and References

Primary references:

* Brian P. Moran + Michael Lennington, The 12 Week Year (2013) — quarterly cycles as the primary planning unit

* John Doerr, Measure What Matters (2018) — OKR construction discipline

* Robert Kegan + Lisa Lahey, Immunity to Change (2009) — why renewal is harder than initial commitment

* B.J. Fogg, Tiny Habits (2019) — recommitment as reinstallation, not willpower

Connected RISER doctrines:

* C1 — Captain's Oath (the Mission Plan is the Captain's Oath rotated forward)

* All Stage 1 + Stage 2 doctrines re-locked through the plan

* New C9 doctrine — Quarterly Maintenance Is Strategy (encoded in next-quarter plan)

________________

M9.6 of 8. The single highest-stakes artifact in C9. Sign it. Write it to Supabase. Wait for HITL approval before continuing.

Complete supporting source — Mission plan validator

name: mission-plan-validator
version: 1.0.0
model: claude-opus-4-7
course: C9 Bora Bora Captain's Retreat — Strategic Renewal
modules: [M9.6 Setting the New Heading]
stage: 2
hitl_gated: true

description: >
  Validates the M9.6 Mission Plan in C1 Harbor Launch format. This is the
  HITL-gated validator: Opus 4.7 produces a structured assessment, and an
  instructor reviews and signs off before the Mission Plan is written to
  Supabase users.operator_brief and the operator proceeds to M9.7.

system_prompt: |
  You are the validator for a RISER Nation operator's M9.6 Mission Plan
  for the next 90 days. You operate at HITL gate: your output is reviewed
  by a human instructor before the Mission Plan is written to the
  operator's record.

  CONTEXT: The Mission Plan is the operator's commitment for the next
  quarter. It must be in the C1 Harbor Launch canonical format:

  - 1 destination (one specific outcome by end of quarter)
  - 3 milestones (specific, dated, verifiable interim results)
  - 2 forcing trades (what the operator will explicitly NOT do, in order
    to make the destination achievable)
  - 1 kill-criterion (the specific signal that would cause the operator
    to abandon this destination before the quarter ends)
  - Weekly review cadence (the day, time, and protocol for weekly
    review)

  This format is canonical because it has produced reliable execution
  across hundreds of RISER operators. Deviations from this format
  (e.g., 5 destinations, no kill-criterion, no forcing trades) almost
  always correlate with quarter-end failure.

  YOUR JOB: Apply rigorous checks. Stage 2 operators have been
  through C1 and know this format; failures here are not honest mistakes,
  they are bargaining with the protocol.

  ### Validation checks

  DESTINATION:
  - Exactly 1 destination (not 2, not "1 main + 1 secondary")
  - Specific (named outcome, not "grow the business")
  - Outcome-stated, not activity-stated ("3 new Tier-2 customers
    onboarded and producing recurring revenue", not "do more sales calls")
  - Stretching but plausible — given the operator's current state from
    M9.2 Voyage Log, is this achievable in 90 days?
  - Aligned with M9.5 forecast — does the destination respond to
    surfaced market changes, or ignore them?
  - Aligned with M9.5 drift inventory — does the destination correct
    the primary drift, or sidestep it?

  MILESTONES:
  - Exactly 3 milestones (not 2, not 5)
  - Each dated (specific week or date)
  - Each verifiable (someone external could confirm whether it happened)
  - Distributed across the quarter (typically week 4, week 8, week 12;
    not all clustered in week 12)
  - Sequence-logical (M2 depends on M1, M3 depends on M2)

  FORCING TRADES:
  - Exactly 2 forcing trades (the discipline of choosing only 2 is
    part of the format — operators who list 5 things they won't do
    are listing preferences, not making trades)
  - Each is something the operator was actually going to do, and is
    now explicitly choosing not to
  - Each is specific enough to enforce (not "say no more often" but
    "decline all speaking engagements through end of quarter")
  - Together they create capacity for the milestones

  KILL-CRITERION:
  - Exactly 1 kill-criterion
  - Specific and observable ("if I don't have at least 1 signed
    Tier-2 by week 6, I abandon this destination" — not "if it's
    going badly")
  - Triggered by a specific date or signal, not by feeling
  - The operator has thought about what they would do if the
    kill-criterion fires (not required to be in the plan, but a
    sign of seriousness)

  WEEKLY REVIEW CADENCE:
  - Specific day and time named
  - Protocol named (Friday Sweep, Sunday review, etc. — typically
    operator's existing C5 cadence extended to include Mission Plan
    progress check)
  - 30-60 minutes minimum

  ### Critical alignment checks

  Cross-check the Mission Plan against M9.5 outputs:

  1. Was the primary drift surfaced in M9.5 either corrected by this
     plan or explicitly defended as not requiring correction?
  2. Were the items flagged "to_carry_into_M9.6" either incorporated
     or addressed?
  3. Is the destination in tension with the forecast? (E.g., "grow
     into Channel X" while the forecast says Channel X is collapsing
     — this is a critical misalignment.)

  ### Red flags requiring instructor review

  - Destination is a vague growth statement
  - Forcing trades are weak ("delegate more")
  - Kill-criterion is missing or non-specific
  - Mission Plan ignores primary drift surfaced in M9.5
  - Operator has 3+ destinations stacked into one (counted as 1 to
    pass the format but actually multiple commitments)
  - Operator's last quarter's Mission Plan was not reviewed against
    actuals before this one was written (history not addressed)

  ### Output format

  Return JSON:

  ```json
  {
    "destination_valid": true | false,
    "destination_specific": true | false,
    "destination_aligned_with_forecast": true | false,
    "destination_addresses_primary_drift": true | false,
    "milestones_count": 0-N,
    "milestones_dated": true | false,
    "milestones_verifiable": true | false,
    "milestones_sequenced": true | false,
    "forcing_trades_count": 0-N,
    "forcing_trades_specific": true | false,
    "kill_criterion_specific": true | false,
    "weekly_review_cadence_concrete": true | false,
    "carry_items_addressed": true | false,
    "concerns_for_instructor": ["specific concern 1", "specific concern 2"],
    "strengths": ["specific strength 1", "specific strength 2"],
    "validator_recommendation": "approve | request_revision | escalate_to_instructor_call",
    "narrative_summary": "string for the instructor reviewer"
  }
  ```

  TONE: Rigorous and protective. The Mission Plan governs the next 90
  days of the operator's business. Loose validation here costs the
  operator a quarter. Be uncomfortable to talk to. Be the friend who
  asks the question the operator is hoping no one asks.

  Your output goes to a human instructor. Write your narrative_summary
  to make the instructor's review fast: lead with the most important
  concern; don't bury it.

usage_notes: |
  This validator runs at M9.6 with HITL gate. Workflow:
  1. Operator submits Mission Plan
  2. Opus 4.7 mission-plan-validator produces JSON assessment
  3. Instructor reviews JSON + plan + operator's M9.5 outputs
  4. Instructor approves, requests revision, or schedules call
  5. On approval, function write_mission_plan_to_operator_brief()
     writes the plan to users.operator_brief and unblocks M9.7

  Opus 4.7 is used here (not Sonnet) because the alignment-cross-check
  reasoning between forecast, drift, and plan requires the higher-tier
  model. This is the only Sonnet → Opus escalation in C1-C9.

Complete supporting source — C9 Supabase functions — unexecuted source

-- C9 Bora Bora Captain's Retreat — Supabase Functions
-- Migration: c9_captains_retreat_functions_v1.0.0.sql
--
-- These functions support the C9 course infrastructure:
--   1. check_c9_enrollment_eligible(operator_id)
--   2. check_c9_completion(retreat_id)
--   3. audit_stage_1_artifacts(operator_id)
--   4. audit_stage_2_artifacts(operator_id)
--   5. assess_c10_readiness(retreat_id)
--   6. write_mission_plan_to_operator_brief(qreview_id)
--
-- All functions are SECURITY DEFINER and validate the calling operator
-- is the subject of the query (or is an instructor/admin for cross-
-- operator queries).

-- ============================================================================
-- 1. check_c9_enrollment_eligible
--    Returns TRUE if operator has filed C8 Pricing Discipline Attestation
--    and has completed C1-C8 in sequence
-- ============================================================================

CREATE OR REPLACE FUNCTION check_c9_enrollment_eligible(p_operator_id UUID)
RETURNS BOOLEAN
LANGUAGE plpgsql SECURITY DEFINER AS $$
DECLARE
  v_c8_filed BOOLEAN;
  v_completed_c1_through_c8 BOOLEAN;
BEGIN
  -- Check C8 Pricing Discipline Attestation filed
  SELECT EXISTS (
    SELECT 1 FROM public.attestations
    WHERE operator_id = p_operator_id
      AND attestation_type = 'c8_pricing_discipline'
      AND signed_at IS NOT NULL
  ) INTO v_c8_filed;

  -- Check C1 through C8 all marked complete in course_completions
  SELECT (
    SELECT COUNT(DISTINCT course_code)
    FROM public.course_completions
    WHERE operator_id = p_operator_id
      AND course_code IN ('C1','C2','C3','C4','C5','C6','C7','C8')
      AND completed_at IS NOT NULL
  ) = 8 INTO v_completed_c1_through_c8;

  RETURN v_c8_filed AND v_completed_c1_through_c8;
END;
$$;

-- ============================================================================
-- 2. check_c9_completion
--    Returns the course-completion gate result for a given retreat.
--    Called by the M9.8 quarterly-review-validator workflow.
-- ============================================================================

CREATE OR REPLACE FUNCTION check_c9_completion(p_retreat_id UUID)
RETURNS JSONB
LANGUAGE plpgsql SECURITY DEFINER AS $$
DECLARE
  v_operator_id UUID;
  v_m9_7_filed BOOLEAN;
  v_m9_8_filed BOOLEAN;
  v_attestation_signed BOOLEAN;
  v_mission_plan_approved BOOLEAN;
  v_c10_assessment c9_c10_readiness_assessments%ROWTYPE;
  v_result JSONB;
BEGIN
  -- Identify operator
  SELECT operator_id INTO v_operator_id
  FROM quarterly_retreat_records
  WHERE id = p_retreat_id;

  IF v_operator_id IS NULL THEN
    RETURN jsonb_build_object(
      'gate_passed', false,
      'blocking_reason', 'retreat_not_found'
    );
  END IF;

  -- M9.7 Crew Review filed
  SELECT EXISTS (
    SELECT 1 FROM c9_rhythm_audits WHERE retreat_id = p_retreat_id
  ) INTO v_m9_7_filed;

  -- M9.8 Return-to-Deck filed
  SELECT * INTO v_c10_assessment FROM c9_c10_readiness_assessments
  WHERE retreat_id = p_retreat_id;

  v_m9_8_filed := v_c10_assessment.id IS NOT NULL;

  -- Attestation signed
  v_attestation_signed := COALESCE(v_c10_assessment.attestation_signed, false);

  -- Mission Plan was approved at HITL gate
  SELECT EXISTS (
    SELECT 1 FROM c9_quarterly_reviews
    WHERE retreat_id = p_retreat_id
      AND hitl_review_decision = 'approve'
      AND written_to_operator_brief = true
  ) INTO v_mission_plan_approved;

  -- Compose result
  IF NOT v_m9_7_filed THEN
    v_result := jsonb_build_object(
      'gate_passed', false,
      'blocking_reason', 'm9_7_crew_review_not_filed'
    );
  ELSIF NOT v_m9_8_filed THEN
    v_result := jsonb_build_object(
      'gate_passed', false,
      'blocking_reason', 'm9_8_return_to_deck_not_filed'
    );
  ELSIF NOT v_attestation_signed THEN
    v_result := jsonb_build_object(
      'gate_passed', false,
      'blocking_reason', 'm9_8_attestation_not_signed'
    );
  ELSIF NOT v_mission_plan_approved THEN
    v_result := jsonb_build_object(
      'gate_passed', false,
      'blocking_reason', 'm9_6_mission_plan_not_approved_at_hitl'
    );
  ELSE
    v_result := jsonb_build_object(
      'gate_passed', true,
      'remediation_path', 'none'
    );
  END IF;

  RETURN v_result;
END;
$$;

-- ============================================================================
-- 3. audit_stage_1_artifacts
--    Returns the operator's Stage 1 (C1-C5) artifacts in summarized form,
--    used by M9.2 Voyage Log Review to prefill compounded-items axis.
-- ============================================================================

CREATE OR REPLACE FUNCTION audit_stage_1_artifacts(p_operator_id UUID)
RETURNS JSONB
LANGUAGE plpgsql SECURITY DEFINER AS $$
DECLARE
  v_result JSONB;
BEGIN
  SELECT jsonb_build_object(
    'c1_harbor_launch', (SELECT operator_brief FROM public.users WHERE id = p_operator_id),
    'c2_compass_identity', (
      SELECT jsonb_agg(jsonb_build_object('version', version, 'positioning', positioning))
      FROM public.identity_statements
      WHERE operator_id = p_operator_id
    ),
    'c3_first_offer', (
      SELECT jsonb_agg(jsonb_build_object('version', version, 'offer_name', offer_name, 'price', price))
      FROM public.offers
      WHERE operator_id = p_operator_id
    ),
    'c4_first_signals', (
      SELECT jsonb_agg(jsonb_build_object('signal_type', signal_type, 'date', detected_at))
      FROM public.market_signals
      WHERE operator_id = p_operator_id
    ),
    'c5_rhythms', (
      SELECT jsonb_agg(jsonb_build_object('rhythm_name', rhythm_name, 'cadence', cadence))
      FROM public.operator_rhythms
      WHERE operator_id = p_operator_id
    )
  ) INTO v_result;

  RETURN v_result;
END;
$$;

-- ============================================================================
-- 4. audit_stage_2_artifacts
--    Returns the operator's Stage 2 (C6-C8) artifacts in summarized form,
--    used by M9.5 Drift Inventory to detect drift across pricing/scope.
-- ============================================================================

CREATE OR REPLACE FUNCTION audit_stage_2_artifacts(p_operator_id UUID)
RETURNS JSONB
LANGUAGE plpgsql SECURITY DEFINER AS $$
DECLARE
  v_result JSONB;
BEGIN
  SELECT jsonb_build_object(
    'c6_captains_console_baselines', (
      SELECT jsonb_build_object('established_at', created_at, 'baselines', baselines)
      FROM public.captains_console_records
      WHERE operator_id = p_operator_id
      ORDER BY created_at DESC LIMIT 1
    ),
    'c7_voice_canon', (
      SELECT jsonb_build_object('established_at', created_at, 'voice_attributes', voice_attributes)
      FROM public.voice_canon_records
      WHERE operator_id = p_operator_id
      ORDER BY created_at DESC LIMIT 1
    ),
    'c8_pricing_attestation', (
      SELECT jsonb_build_object(
        'attestation_signed_at', signed_at,
        'declared_floor_price', declared_floor_price,
        'declared_target_price', declared_target_price
      )
      FROM public.attestations
      WHERE operator_id = p_operator_id
        AND attestation_type = 'c8_pricing_discipline'
      ORDER BY signed_at DESC LIMIT 1
    ),
    'recent_pricing_actuals', (
      SELECT jsonb_agg(jsonb_build_object(
        'customer_id', customer_id,
        'price_charged', price_charged,
        'date_charged', invoice_date
      ))
      FROM public.invoices
      WHERE operator_id = p_operator_id
        AND invoice_date >= now() - interval '90 days'
    )
  ) INTO v_result;

  RETURN v_result;
END;
$$;

-- ============================================================================
-- 5. assess_c10_readiness
--    Returns whether the operator is ready to enroll in C10 Funnel Fleet
--    Engineering. Wraps check_c9_completion and adds Stage 2 capstone gates.
-- ============================================================================

CREATE OR REPLACE FUNCTION assess_c10_readiness(p_retreat_id UUID)
RETURNS JSONB
LANGUAGE plpgsql SECURITY DEFINER AS $$
DECLARE
  v_completion_result JSONB;
  v_operator_id UUID;
  v_active_changes_landed BOOLEAN;
  v_assessment c9_c10_readiness_assessments%ROWTYPE;
BEGIN
  -- Get C9 completion result first
  v_completion_result := check_c9_completion(p_retreat_id);

  IF (v_completion_result ->> 'gate_passed')::BOOLEAN = false THEN
    RETURN jsonb_build_object(
      'c10_enrollment_unlocked', false,
      'blocking_reason', v_completion_result ->> 'blocking_reason'
    );
  END IF;

  -- Additional Stage 2 capstone gate: at least 2 of 3 active changes landed
  SELECT operator_id INTO v_operator_id
  FROM quarterly_retreat_records WHERE id = p_retreat_id;

  SELECT * INTO v_assessment
  FROM c9_c10_readiness_assessments
  WHERE retreat_id = p_retreat_id;

  -- Check captains_log_week_1 entries for active_change_progress >= 3
  -- across at least 5 of 7 days (interpreted from JSONB)
  SELECT (
    SELECT COUNT(*)
    FROM jsonb_array_elements(v_assessment.captains_log_week_1) AS entry
    WHERE (entry ->> 'active_change_progress')::INT >= 3
  ) >= 5 INTO v_active_changes_landed;

  IF NOT v_active_changes_landed THEN
    RETURN jsonb_build_object(
      'c10_enrollment_unlocked', false,
      'blocking_reason', 'active_changes_not_sufficiently_landed_in_week_1',
      'remediation_path', 'mid_quarter_mini_retreat'
    );
  END IF;

  -- All gates cleared
  UPDATE c9_c10_readiness_assessments
  SET c10_enrollment_unlocked_at = now()
  WHERE retreat_id = p_retreat_id
    AND c10_enrollment_unlocked_at IS NULL;

  RETURN jsonb_build_object(
    'c10_enrollment_unlocked', true,
    'unlocked_at', now()
  );
END;
$$;

-- ============================================================================
-- 6. write_mission_plan_to_operator_brief
--    Called at M9.6 HITL gate after instructor approval. Writes the
--    Mission Plan to public.users.operator_brief (canonical canonical
--    operator-state record), and flips written_to_operator_brief = true.
-- ============================================================================

CREATE OR REPLACE FUNCTION write_mission_plan_to_operator_brief(p_qreview_id UUID)
RETURNS BOOLEAN
LANGUAGE plpgsql SECURITY DEFINER AS $$
DECLARE
  v_qreview c9_quarterly_reviews%ROWTYPE;
  v_brief JSONB;
BEGIN
  -- Get the quarterly review record
  SELECT * INTO v_qreview FROM c9_quarterly_reviews WHERE id = p_qreview_id;

  IF v_qreview.id IS NULL THEN
    RAISE EXCEPTION 'quarterly_review_not_found';
  END IF;

  IF v_qreview.hitl_review_decision != 'approve' THEN
    RAISE EXCEPTION 'mission_plan_not_approved_at_hitl';
  END IF;

  -- Compose Mission Plan as operator_brief
  v_brief := jsonb_build_object(
    'mission_plan_quarter_start', (SELECT retreat_end_date FROM quarterly_retreat_records
                                    WHERE id = v_qreview.retreat_id),
    'destination', v_qreview.destination,
    'milestones', v_qreview.milestones,
    'forcing_trades', v_qreview.forcing_trades,
    'kill_criterion', v_qreview.kill_criterion,
    'weekly_review_cadence', v_qreview.weekly_review_cadence,
    'source_retreat_id', v_qreview.retreat_id,
    'written_at', now()
  );

  -- Write to users.operator_brief
  UPDATE public.users
  SET operator_brief = v_brief,
      operator_brief_updated_at = now()
  WHERE id = v_qreview.operator_id;

  -- Mark written
  UPDATE c9_quarterly_reviews
  SET written_to_operator_brief = true
  WHERE id = p_qreview_id;

  RETURN true;
END;
$$;

-- End of c9_captains_retreat_functions_v1.0.0.sql

Complete supporting source — Mission plan template

# Mission Plan Template — M9.6 Deliverable 1

**Use:** Fill this template at M9.6 to produce your signed Next-90-Day Mission Plan. Format matches the C1 Harbor Launch exactly. Filed to Drive at `Drive/Retreat/[Q-end-date]/Mission-Plan-Signed.pdf`. Written to Supabase `users.operator_brief` field via the M9.6 helper function.

This is the highest-stakes artifact in C9. The Mission Plan is read by every downstream tool for the next 90 days. Sharp plans produce sharp tool outputs. Vague plans produce vague tool outputs.

---

## Header

**Operator:** [Your name]
**Plan period:** [Q-start: ____] to [Q-end: ____]
**Plan signed on:** [M9.6 date]
**Plan written to Supabase on:** [Date and time of `users.operator_brief` update]

---

## ELEMENT 1 — One Destination

A single, specific, dated outcome you commit to over the next 90 days.

**Destination:**

> [Specific, singular, dated. Example structure:
>
> "By [specific Q-end date], I will have onboarded a third paying customer at full price ($X) under the v2.1 offer architecture, completing the Proof Threshold for C10 graduation."]

### Why this destination (1 paragraph)

[Reasoning grounded in M9.2 audit gaps, M9.4 surfaces, and M9.5 forecast. Not aspiration — alignment with the data surfaced in the retreat.]

### What it would mean to achieve this

[The downstream consequence. Not "growth" — specific implications. "C10 enrollment unlocks Funnel Fleet Engineering work; Stage 3 Authority Engine becomes possible; foundation is intact for first $10K month projection."]

### What it would mean to fail this

[The honest cost of failure. "Proof Threshold delayed; C10 deferred; Stage 2 → Stage 3 timeline slips by one quarter."]

---

## ELEMENT 2 — Three Milestones

Three dated, falsifiable checkpoints between today and the destination.

### Milestone 1 (Day 30 of plan)

**Date:** [Specific]
**Checkpoint:** [Specific. Example: "Customer 3 sales call completed; offer v2.1 formally presented; pricing held at $X (no discount granted under pressure)."]
**Falsifiability test:** [Yes/no test on milestone date. Example: "On [date], either Customer 3 sales call has happened with v2.1 + full pricing, or it has not."]
**Evidence I will use:** [Specific. Calendar entry, CRM record, recorded call.]

### Milestone 2 (Day 60 of plan)

**Date:** [Specific]
**Checkpoint:**
**Falsifiability test:**
**Evidence I will use:**

### Milestone 3 (Day 90 of plan)

**Date:** [Specific — Q-end]
**Checkpoint:**
**Falsifiability test:**
**Evidence I will use:**

---

## ELEMENT 3 — Two Forcing Trades

Two specific things you are giving up to make the destination possible. Real losses, not theoretical ones.

### Forcing Trade 1

**What I'm giving up:** [Specific. Example: "I will not launch the secondary offer (the workshop) until after Q-end. The workshop is queued for next quarter."]
**Why this is a real trade:** [Evidence the operator was actually doing or planning this thing. Not "I'll stop the podcast I never started."]
**The cost of the trade:** [What's lost by not doing it this quarter. Honest accounting.]
**How I will verify the trade is held:** [Specific. Calendar evidence, content-plan evidence, etc.]

### Forcing Trade 2

**What I'm giving up:**
**Why this is a real trade:**
**The cost of the trade:**
**How I will verify the trade is held:**

---

## ELEMENT 4 — One Kill-Criterion

The single condition under which the destination is abandoned, with the abandonment process specified.

**Kill-Criterion:**

> [Specific, dated, observable. Example: "If by Day 60 (Milestone 2), Customer 3 is not yet onboarded AND I have not received any qualified inbound leads matching ICP in the prior 30 days, I will abandon the Q2 destination, return to the M9.5 forecast, and revise the Mission Plan with my instructor."]

### Components of the kill-criterion

**Trigger condition:** [Specific, observable, evaluable on a specific date]
**Action triggered:** [Abandon / Revise / Escalate]
**Decision authority:** [Operator alone / With instructor / With peer]
**Date the kill-criterion will be evaluated:** [Specific]

### What I will do if the kill-criterion fires

[Specific protocol. Not "I'll figure it out" — the procedure for abandoning gracefully and constructing the next plan. Example: "I will write a 1-page abandonment memo documenting why the destination was missed, what the actual learning was, and what next-quarter destination is now appropriate. I will submit the memo to my instructor within 7 days of the trigger date."]

---

## ELEMENT 5 — Weekly Review Cadence

The calendar discipline that maintains the plan over 90 days.

**Cadence:**

> [Specific. Example: "Sunday evenings, 6pm to 6:30pm, 30 minutes, reviewing the three milestones against current week's actions, logging in Captain's Log. Monthly review at end of each calendar month including a full Mission Plan re-read against the M9.5 forecast."]

### What I will check during each weekly review

- [Specific check 1]
- [Specific check 2]
- [Specific check 3]

### What triggers a mid-week adjustment

[The Mission Plan is meant to be stable; weekly review confirms course. But sometimes mid-week external events require adjustment. Specify the threshold: at what point does the operator pause and re-evaluate before Sunday?]

### Calendar evidence

[Confirmation that this cadence is calendar-blocked at the time of plan signing — not "I'll add it later." Specific calendar reference.]

---

## Forward Connection — Mission Plan Inputs

For the validator and instructor, document which retreat surfaces shaped this plan:

### From M9.2 audit (top three gap domains)

1. Domain ___: [How this plan addresses it, or why it doesn't]
2. Domain ___: [How this plan addresses it, or why it doesn't]
3. Domain ___: [How this plan addresses it, or why it doesn't]

### From M9.4 Open Ocean

[Specific surface from the long-form thinking sessions that this plan responds to]

### From M9.5 forecast

[Which forecast points the plan is defensible against, and which forecast points the destination depends on being correct]

### From M9.5 drift inventory

[Which categorized drifts this plan corrects in its three milestones or two forcing trades]

---

## Signature

**Operator signature:** [Literal signature, not typed]
**Date:** [Same as M9.6 date]
**Witness (optional):** [Peer accountability partner or advisor signature, with date]

---

## Supabase Write Verification

**`users.operator_brief` row updated on:** [Date and time]
**Update verified by:** Running `assess_c10_readiness(user_id)` and confirming the function returns the Mission Plan content.
**Verification timestamp:** [Date and time]

---

## Validator and HITL Submission

Submitted to `mission-plan-validator-v1.0.0.yaml` (Opus 4.7) on: [Date and time]
Submitted to instructor for HITL review on: [Date and time]
HITL response received on: [Date and time]
HITL outcome: [Approved / Approved with revision / Returned for substantial revision]

If revisions made, this template is updated and re-submitted. Final approved version becomes load-bearing for downstream tools.

---

## Plan Fidelity Statement

By signing this plan, I commit to:

1. Working primarily on the destination during the next 90 days
2. Holding the two forcing trades — not silently restoring what I committed to give up
3. Reviewing the milestones weekly per the cadence specified
4. Triggering the kill-criterion if it fires — not rationalizing it away
5. Bringing this plan to my next quarterly retreat for evaluation against actual outcomes

---

*Mission Plan Template v2.0. Format matches C1 Harbor Launch. Signed in C9. Rotated forward at every quarterly retreat. Read by every downstream tool for the next 90 days.*

Native Google Doc text and original links

M9.6 — Setting the New Heading: Next Quarter Mission Plan
Module: 9.6 Title: Setting the New Heading — Next Quarter Mission Plan Stage: 2 — The Sailboat Duration: 4–6 hours active (the most cognitively dense module after M9.2) Deliverable: Signed Next-90-Day Mission Plan + Supabase users.operator_brief row updated Validator: mission-plan-validator-v1.0.0.yaml (Opus 4.7 — gated, course-critical) HITL: Manual instructor review required before M9.7–M9.8 unlock Prerequisite: M9.5 complete (12-Point Forecast + Drift Inventory filed)

What This Module Does
M9.6 produces the Mission Plan — the single forward-pointing document that integrates everything surfaced in the prior five modules into a structured commitment for the next 90 days. The Mission Plan is the highest-leverage artifact in C9. Every downstream tool reads from it. The C1 Captain's Oath rotated forward becomes the C9 Mission Plan; the Mission Plan rotated forward at the next quarterly retreat (C18) becomes the next quarter's plan.

The Mission Plan format matches the C1 Harbor Launch format exactly:

One destination — singular, specific, dated
Three milestones — dated, falsifiable, mapped to the destination
Two forcing trades — what is given up to make the destination possible
One kill-criterion — the condition under which the destination is abandoned, with the abandonment process specified
Weekly review cadence — the calendar discipline that maintains the plan over 90 days

This module is HITL-gated: an instructor must manually review the Mission Plan before M9.7 and M9.8 unlock. This is the only HITL gate in C9.

Why The C1 Format
The C1 Harbor Launch format was designed to be operator-portable. The same structure that worked at C1 (when the operator had no customers and was making first commitments) works at C9 (when the operator has multiple customers and is rotating forward). It will work at C18, C27, C36, and beyond.

The format is constrained for two reasons:

The Five Elements — Detailed
Element 1 — One Destination
A single, specific, dated outcome the operator commits to over the next 90 days.

Acceptable form:

"By [Q-end date], I will have onboarded a third paying customer at full price under the v2.1 offer architecture, completing the Proof Threshold for C10 graduation."

Unacceptable forms:

"Grow the business" — not specific "Acquire 3 customers and ship the new course and launch the partnership" — not singular "Be in a better place by Q-end" — not dated, not specific

The destination is dated to a specific Q-end date, not "next quarter" or "in 90 days." The specific date is part of the discipline.
Element 2 — Three Milestones
Three dated, falsifiable checkpoints between today and the destination. The milestones are not deliverables — they are evidence-points that confirm the destination is on track.

Acceptable form:

Each milestone is falsifiable: at the milestone date, either the milestone was met or it wasn't. No "kind of" — yes/no.

Unacceptable forms:

"Make progress on customer acquisition" — not falsifiable "Have a great Q2" — not specific, not falsifiable

The milestones are not the only work the operator will do over 90 days; they are the work that proves the destination is on track. Many other things will happen — content, partnerships, ongoing customer service. Those are not in the Mission Plan because they don't change the destination's trajectory.
Element 3 — Two Forcing Trades
Two specific things the operator is giving up to make the destination possible. The forcing trades are the cost of the destination.

Acceptable forms:

Why two, not three or one:

One trade typically isn't enough — most destinations require multiple things to be given up
Three or more trades signal that the destination is too large, or that the operator hasn't chosen
Two is the empirical sweet spot across cohort

Unacceptable forms:

"I will work harder" — not a trade "I will be more focused" — not a specific behavioral change "I will not do anything that doesn't matter" — not testable
Element 4 — One Kill-Criterion
The single condition under which the destination is abandoned, with the abandonment process specified. The kill-criterion exists because operators who commit to a destination without a kill-criterion reliably stay committed past the point where the commitment is destroying value. The kill-criterion is the formal release valve.

Acceptable form:

The kill-criterion has three required components:

The trigger condition (specific, dated, observable)
The action triggered (abandon, revise, escalate)
The decision authority (operator alone, with instructor, with peer)

Unacceptable forms:

"I will reassess if things aren't working" — not specific, not dated "If I'm struggling, I'll make changes" — not falsifiable

The validator specifically detects soft kill-criteria. The kill-criterion is meant to be enforceable — a binary yes/no test on a specific date that produces a specific action. Soft criteria are theater.
Element 5 — Weekly Review Cadence
The calendar discipline that maintains the Mission Plan over 90 days. Specifically: when the operator will review the plan against current state, what they will check, and how they will adjust.

Acceptable form:

The review cadence is calendar-blocked at the time the Mission Plan is signed, not later. The validator checks for a calendar block in the operator's Calendar reflecting the cadence.

Writing to Supabase users.operator_brief
The Mission Plan is not just filed in Drive — it is written to the Supabase users.operator_brief field. This field is the persistent context every downstream Claude tool reads from. The operator's Priority Brief Agent (Build 7), the content-generation tools (Build 6), the customer-onboarding tools, and the agent fleet all use this context.

The HITL Gate
M9.6 is the only HITL gate in C9. After the Opus 4.7 validator confirms the plan format is structurally sound, the plan is queued for instructor review. The instructor reviews the plan against three specific criteria:

Criterion 1 — Coherence with M9.2 audit. Does the destination address the actual top-three gap domains, or does it address something more comfortable?

Criterion 2 — Coherence with M9.5 drift inventory. Does the Mission Plan correct the consequential drift identified, or does it ignore drift in favor of forward growth?

Criterion 3 — Plausibility against capacity. Does the destination + milestones + forcing trades fit within the operator's honest capacity (M9.5 Surface 5)?

Instructor review is delivered within 48 hours. Possible outcomes:

Approved — M9.7 and M9.8 unlock. The Mission Plan is final.
Approved with revision — Operator addresses specific feedback and resubmits. M9.7 and M9.8 unlock conditional on revision being filed within 7 days.
Returned for substantial revision — The Mission Plan is rewritten. Validator + HITL run again.

The HITL gate is not optional. The Mission Plan is the most consequential artifact in C9; instructor review is the safety check on operator self-deception that the Opus validator may not catch.

Common Failure Modes in M9.6
Failure Mode 1 — Multiple Destinations
The operator splits attention across two or three destinations because choosing one feels like losing the others. The validator returns this for revision: choose one. The others are queued for the next retreat.
Failure Mode 2 — Comfortable Destination
The destination is chosen for its comfort rather than its leverage. The most consequential gap from M9.2 was Pricing Drift; the operator chooses Customer Acquisition as the destination because pricing conversations are uncomfortable. The HITL gate flags this — the instructor compares the destination against the audit gaps and surfaces the misalignment.
Failure Mode 3 — Aspirational Capacity
The operator's forcing trades and milestones assume capacity that does not match the M9.5 Surface 5 forecast. The validator cross-references and flags: "M9.5 Surface 5 forecasts maximum 5 concurrent customers; M9.6 milestones imply 8."
Failure Mode 4 — Soft Kill-Criterion
The kill-criterion is unenforceable theater. "I'll reassess if things aren't working." The validator returns for revision until the kill-criterion is binary, dated, and tied to a specific action.
Failure Mode 5 — No Calendar Block for Review Cadence
The operator commits to a weekly review cadence but does not block the calendar at the time of signing. The validator requires evidence of the calendar block. Operators who do not block the calendar at signing reliably do not maintain the cadence at week 4.
Failure Mode 6 — Unrealistic Forcing Trades
Trades that are not real losses. "I'll stop the podcast I never started." The validator requires the trade to be something the operator was actively doing. The instructor HITL surfaces non-real trades that the validator may have missed.

What You Will Submit for M9.6
Two artifacts, both submitted via the C9 module 9.6 Supabase row:
Deliverable 1 — Signed Next-90-Day Mission Plan (PDF)
A 1-page Mission Plan in the C1 Harbor Launch format, signed (literal signature with date), filed to Drive at Drive/Retreat/[Q-end-date]/M9.6-Mission-Plan-Signed.pdf. Use the template in 02_Resources/Mission-Plan-Template.md.
Deliverable 2 — Supabase users.operator_brief Update
The Mission Plan written to Supabase via the M9.6 helper function. Verification of the write is via assess_c10_readiness(user_id) which reads from users.operator_brief and confirms the plan is present and structurally valid.

What Comes Next
When the validator confirms structural soundness AND the HITL instructor approves:

M9.7 (Reinforcing the Crew) unlocks
The Mission Plan is now active context for every downstream Claude tool
The 90-day clock starts on the operator's signed commitment
The weekly review cadence begins this Sunday

If the HITL gate returns the plan for revision, M9.7 and M9.8 do not unlock until revision is approved. The retreat does not advance on a contaminated Mission Plan.

Reading and References
Primary references:

Brian P. Moran + Michael Lennington, The 12 Week Year (2013) — quarterly cycles as the primary planning unit
John Doerr, Measure What Matters (2018) — OKR construction discipline
Robert Kegan + Lisa Lahey, Immunity to Change (2009) — why renewal is harder than initial commitment
B.J. Fogg, Tiny Habits (2019) — recommitment as reinstallation, not willpower

Connected RISER doctrines:

C1 — Captain's Oath (the Mission Plan is the Captain's Oath rotated forward)
All Stage 1 + Stage 2 doctrines re-locked through the plan
New C9 doctrine — Quarterly Maintenance Is Strategy (encoded in next-quarter plan)

M9.6 of 8. The single highest-stakes artifact in C9. Sign it. Write it to Supabase. Wait for HITL approval before continuing.

Margin-Benchmarks-by-Offer-Type.md

Define the margin before comparing a benchmark

The source calls its ranges illustrative, while imposing doctrine thresholds. First specify revenue period and which costs are included. Gross profit, operating profit, cash flow and a management calculation that charges owner time are different measures. Compare like with like; low overhead or direct owner delivery does not mean labor has no economic cost. The source does not document a consistent cost-classification method across its categories.

Source comparison — Solo consulting (advisory)

In Knowledge-Work Offers (C8 Doctrine: 60% Minimum), the source lists 65-85% for Solo consulting (advisory). Its doctrine column is ≥ 60%. High because operator is direct deliverer; low overhead. Treat this as an unverified source estimate, not a measured market distribution. Compare the actual delivery model, included labor and costs, utilization, customer mix and time period before using it as an orientation point.

Source comparison — Fractional roles (CFO, CMO, CTO)

In Knowledge-Work Offers (C8 Doctrine: 60% Minimum), the source lists 60-80% for Fractional roles (CFO, CMO, CTO). Its doctrine column is ≥ 60%. Time-bounded, deeper engagement. Treat this as an unverified source estimate, not a measured market distribution. Compare the actual delivery model, included labor and costs, utilization, customer mix and time period before using it as an orientation point.

Source comparison — Coaching

In Knowledge-Work Offers (C8 Doctrine: 60% Minimum), the source lists 70-85% for Coaching. Its doctrine column is ≥ 60%. High when operator-only; lower with curriculum dev costs. Treat this as an unverified source estimate, not a measured market distribution. Compare the actual delivery model, included labor and costs, utilization, customer mix and time period before using it as an orientation point.

Source comparison — Custom design / illustration

In Knowledge-Work Offers (C8 Doctrine: 60% Minimum), the source lists 50-70% for Custom design / illustration. Its doctrine column is ≥ 60%. Lower bound when material/software costs are significant. Treat this as an unverified source estimate, not a measured market distribution. Compare the actual delivery model, included labor and costs, utilization, customer mix and time period before using it as an orientation point.

Source comparison — Sprints / fixed-scope projects

In Knowledge-Work Offers (C8 Doctrine: 60% Minimum), the source lists 50-70% for Sprints / fixed-scope projects. Its doctrine column is ≥ 60%. Lower bound when scope-creep is uncompensated. Treat this as an unverified source estimate, not a measured market distribution. Compare the actual delivery model, included labor and costs, utilization, customer mix and time period before using it as an orientation point.

Source comparison — Audits / assessments

In Knowledge-Work Offers (C8 Doctrine: 60% Minimum), the source lists 65-80% for Audits / assessments. Its doctrine column is ≥ 60%. High because deliverable is documentation, not implementation. Treat this as an unverified source estimate, not a measured market distribution. Compare the actual delivery model, included labor and costs, utilization, customer mix and time period before using it as an orientation point.

Source comparison — Strategy services

In Knowledge-Work Offers (C8 Doctrine: 60% Minimum), the source lists 60-80% for Strategy services. Its doctrine column is ≥ 60%. Variable based on workshop vs document-only. Treat this as an unverified source estimate, not a measured market distribution. Compare the actual delivery model, included labor and costs, utilization, customer mix and time period before using it as an orientation point.

Source comparison — Cohort courses

In Cohort / Group Offers (Doctrine: 50-65%), the source lists 50-70% for Cohort courses. Higher when curriculum is reusable; lower when each cohort is bespoke. Treat this as an unverified source estimate, not a measured market distribution. Compare the actual delivery model, included labor and costs, utilization, customer mix and time period before using it as an orientation point.

Source comparison — Group coaching

In Cohort / Group Offers (Doctrine: 50-65%), the source lists 55-70% for Group coaching. Lower when small groups; higher when larger groups. Treat this as an unverified source estimate, not a measured market distribution. Compare the actual delivery model, included labor and costs, utilization, customer mix and time period before using it as an orientation point.

Source comparison — Mastermind

In Cohort / Group Offers (Doctrine: 50-65%), the source lists 60-80% for Mastermind. High because ongoing peer-driven; operator's marginal hours decrease over time. Treat this as an unverified source estimate, not a measured market distribution. Compare the actual delivery model, included labor and costs, utilization, customer mix and time period before using it as an orientation point.

Source comparison — Workshops (1-3 day)

In Cohort / Group Offers (Doctrine: 50-65%), the source lists 40-65% for Workshops (1-3 day). Low end when materials and venue costs are significant. Treat this as an unverified source estimate, not a measured market distribution. Compare the actual delivery model, included labor and costs, utilization, customer mix and time period before using it as an orientation point.

Source comparison — Done-for-you services (logo, website, etc.)

In Productized Service Offers (Doctrine: 55-70%), the source lists 50-65% for Done-for-you services (logo, website, etc.). Variable based on operator vs contractor delivery. Treat this as an unverified source estimate, not a measured market distribution. Compare the actual delivery model, included labor and costs, utilization, customer mix and time period before using it as an orientation point.

Source comparison — Subscription services (retainer-based)

In Productized Service Offers (Doctrine: 55-70%), the source lists 55-70% for Subscription services (retainer-based). Higher when retainer scope is well-bounded. Treat this as an unverified source estimate, not a measured market distribution. Compare the actual delivery model, included labor and costs, utilization, customer mix and time period before using it as an orientation point.

Source comparison — Templated audits / assessments

In Productized Service Offers (Doctrine: 55-70%), the source lists 60-75% for Templated audits / assessments. Higher when reusing audit framework across customers. Treat this as an unverified source estimate, not a measured market distribution. Compare the actual delivery model, included labor and costs, utilization, customer mix and time period before using it as an orientation point.

Source comparison — SaaS (B2B)

In Software / Digital Product Offers (Doctrine: 70-85%), the source lists 75-85% for SaaS (B2B). After amortized development cost. Treat this as an unverified source estimate, not a measured market distribution. Compare the actual delivery model, included labor and costs, utilization, customer mix and time period before using it as an orientation point.

Source comparison — Digital downloads (ebooks, templates)

In Software / Digital Product Offers (Doctrine: 70-85%), the source lists 80-95% for Digital downloads (ebooks, templates). Marginal cost approaches zero. Treat this as an unverified source estimate, not a measured market distribution. Compare the actual delivery model, included labor and costs, utilization, customer mix and time period before using it as an orientation point.

Source comparison — Self-paced courses (digital-only, no live delivery)

In Software / Digital Product Offers (Doctrine: 70-85%), the source lists 75-90% for Self-paced courses (digital-only, no live delivery). After production cost amortization. Treat this as an unverified source estimate, not a measured market distribution. Compare the actual delivery model, included labor and costs, utilization, customer mix and time period before using it as an orientation point.

Source comparison — API / micro-SaaS

In Software / Digital Product Offers (Doctrine: 70-85%), the source lists 80-90% for API / micro-SaaS. Variable based on infrastructure cost. Treat this as an unverified source estimate, not a measured market distribution. Compare the actual delivery model, included labor and costs, utilization, customer mix and time period before using it as an orientation point.

Source comparison — Physical products (made-to-order)

In Physical / Material-Based Offers (Doctrine: 35-55%), the source lists 40-55% for Physical products (made-to-order). After materials, labor, shipping. Treat this as an unverified source estimate, not a measured market distribution. Compare the actual delivery model, included labor and costs, utilization, customer mix and time period before using it as an orientation point.

Source comparison — Physical products (inventory-based)

In Physical / Material-Based Offers (Doctrine: 35-55%), the source lists 35-50% for Physical products (inventory-based). After materials, labor, storage, shrinkage. Treat this as an unverified source estimate, not a measured market distribution. Compare the actual delivery model, included labor and costs, utilization, customer mix and time period before using it as an orientation point.

Source comparison — Print-on-demand

In Physical / Material-Based Offers (Doctrine: 35-55%), the source lists 30-50% for Print-on-demand. Low because POD margins are platform-dependent. Treat this as an unverified source estimate, not a measured market distribution. Compare the actual delivery model, included labor and costs, utilization, customer mix and time period before using it as an orientation point.

Source comparison — Books (self-published)

In Physical / Material-Based Offers (Doctrine: 35-55%), the source lists 50-70% for Books (self-published). Higher for ebook; lower for print. Treat this as an unverified source estimate, not a measured market distribution. Compare the actual delivery model, included labor and costs, utilization, customer mix and time period before using it as an orientation point.

Reconcile the category thresholds

The source proposes knowledge-work 60%; cohorts 50–65% with a practical 55% minimum; productized service 55–70%; software 70–85% with a 75% target; physical products 35–55% with a 40% practical minimum. These are program policies and overlap inconsistently. A productized knowledge service may fall into more than one category. Declare the chosen definition and documented exception instead of changing categories to obtain a pass.

Avoid unsupported causal conclusions

Below 50% does not by itself prove underpricing or bloated scope; below 75% software margin does not uniquely identify infrastructure/licensing as the cause. Cost allocation, stage of development, support, acquisition accounting and utilization also matter. Group fixed costs can be spread over more participants, so cohorts are not inherently lower-margin than one-to-one work. Build a measured cost bridge before choosing a corrective action.

Weight hybrid margins by revenue

For a hybrid, sum component contributions and divide by total component revenue; this equals a revenue-weighted margin if definitions match. The source uses the dominant-revenue category’s threshold and calls for explicit documentation when a lower-margin component exceeds 30% of revenue. Those are policy choices, not accounting laws. Keep shared-cost allocation consistent and avoid double counting.

Use evidence instead of unsupported cohort statistics

The source attributes ranges broadly to ProfitWell, Stripe Atlas, indie-hacker reports and pricing literature, plus roughly 200 RISER operators. It supplies no specific studies or dataset and claims about 70% enter below threshold without evidence. Preserve those as unverified source statements. Document measured gaps, plausible causes, corrective branch, review date and justified exceptions; do not label a business a discipline failure solely from an unsupported range.

Connect the lesson to the direct-marketing promise

Complete original source text

# Margin Benchmarks by Offer Type

**Used as reference, not prescription** · **Anchored in C8 doctrine: 60% gross margin minimum for knowledge-work**

---

## Why This Chart Exists

Operators benchmarking their gross margin to "industry standard" without context tend to import the wrong number. A SaaS founder at 25% gross margin reads SaaS industry benchmarks at 75-85% and panics. A consultant at 65% gross margin reads consulting industry benchmarks at 30-50% and feels comfortable. The numbers are not interchangeable across offer types because the cost structures are different.

This chart names typical gross margin ranges by offer type, with the C8 doctrine threshold marked. It is reference material, not prescription. Your specific offer's economics depend on your specific scope, geography, and operating model.

---

## Knowledge-Work Offers (C8 Doctrine: 60% Minimum)

Knowledge-work offers are operator-time-intensive: consulting, fractional roles, coaching, advisory, custom services where the operator's expertise is the deliverable.

| Offer subtype | Typical range | C8 doctrine | Notes |
|---|---|---|---|
| Solo consulting (advisory) | 65-85% | ≥ 60% | High because operator is direct deliverer; low overhead |
| Fractional roles (CFO, CMO, CTO) | 60-80% | ≥ 60% | Time-bounded, deeper engagement |
| Coaching | 70-85% | ≥ 60% | High when operator-only; lower with curriculum dev costs |
| Custom design / illustration | 50-70% | ≥ 60% | Lower bound when material/software costs are significant |
| Sprints / fixed-scope projects | 50-70% | ≥ 60% | Lower bound when scope-creep is uncompensated |
| Audits / assessments | 65-80% | ≥ 60% | High because deliverable is documentation, not implementation |
| Strategy services | 60-80% | ≥ 60% | Variable based on workshop vs document-only |

**If your knowledge-work offer is below 60%:** M8.3 reality check requires a corrective branch.

**If your knowledge-work offer is below 50%:** The offer is structurally under-priced or scope-bloated. M8.3 must address structurally, not cosmetically.

---

## Cohort / Group Offers (Doctrine: 50-65%)

Cohort offers serve multiple participants per delivery cycle. Margin range is lower than 1:1 knowledge-work because cohort design and facilitation has fixed costs that don't scale with cohort size.

| Offer subtype | Typical range | Notes |
|---|---|---|
| Cohort courses | 50-70% | Higher when curriculum is reusable; lower when each cohort is bespoke |
| Group coaching | 55-70% | Lower when small groups; higher when larger groups |
| Mastermind | 60-80% | High because ongoing peer-driven; operator's marginal hours decrease over time |
| Workshops (1-3 day) | 40-65% | Low end when materials and venue costs are significant |

**Cohort threshold:** Aim for ≥ 55% as practical minimum. Below 55%, cohort delivery doesn't sustain operator capacity.

---

## Productized Service Offers (Doctrine: 55-70%)

Productized services are knowledge-work offers with productized scope: same deliverable specification across customers, repeatable processes, predictable hours.

| Offer subtype | Typical range | Notes |
|---|---|---|
| Done-for-you services (logo, website, etc.) | 50-65% | Variable based on operator vs contractor delivery |
| Subscription services (retainer-based) | 55-70% | Higher when retainer scope is well-bounded |
| Templated audits / assessments | 60-75% | Higher when reusing audit framework across customers |

---

## Software / Digital Product Offers (Doctrine: 70-85%)

Software offers carry low marginal cost per customer once built. Margin is high but build cost is high upfront.

| Offer subtype | Typical range | Notes |
|---|---|---|
| SaaS (B2B) | 75-85% | After amortized development cost |
| Digital downloads (ebooks, templates) | 80-95% | Marginal cost approaches zero |
| Self-paced courses (digital-only, no live delivery) | 75-90% | After production cost amortization |
| API / micro-SaaS | 80-90% | Variable based on infrastructure cost |

**Software threshold:** Aim for ≥ 75% gross margin. Below 75%, infrastructure or licensing cost is eating margin.

---

## Physical / Material-Based Offers (Doctrine: 35-55%)

Physical offers carry material, manufacturing, shipping, and storage costs.

| Offer subtype | Typical range | Notes |
|---|---|---|
| Physical products (made-to-order) | 40-55% | After materials, labor, shipping |
| Physical products (inventory-based) | 35-50% | After materials, labor, storage, shrinkage |
| Print-on-demand | 30-50% | Low because POD margins are platform-dependent |
| Books (self-published) | 50-70% | Higher for ebook; lower for print |

**Physical threshold:** Aim for ≥ 40% as practical minimum for most categories.

---

## Hybrid Offers

Many operator offers combine categories: a knowledge-work offer with a software component, a cohort offer with a physical workbook, a service with a productized template library.

For hybrid offers:
- Compute weighted average gross margin across components
- Use the dominant-revenue component's threshold
- If the lower-margin component is > 30% of revenue, document explicitly in M8.4

---

## Why These Numbers, Not Others

The benchmarks above reflect:
- Practitioner reports from public sources (ProfitWell, Stripe Atlas, indie hackers data)
- C7-C8 RISER cohort data (anonymized, aggregated across ~200 operators)
- Conventional wisdom from pricing literature (Hermann Simon, Patrick Campbell)

They are illustrative, not prescriptive. Your offer's correct margin depends on your offer's specifics. Use these as orientation, not anchor.

---

## When Operating Below Doctrine Threshold

If your measured gross margin is below the doctrine threshold for your offer category:

1. **Don't panic.** Below-threshold operation is common at C8 entry; ~70% of operators arrive at C8 below their threshold.
2. **Don't rationalize.** "My offer is special" or "my market is different" are usually wrong; document specific reasons if deviating.
3. **Do address.** M8.3 reality check requires a corrective branch. M8.4 architecture must specify a path back to threshold within reasonable window.
4. **Do document.** Below-threshold operation with documented path is acceptable; below-threshold operation without a path is not.

---

*This chart is reference, not target. Your target is the C8 doctrine threshold for your category, with documented exceptions where appropriate. Below-threshold operation without correction is a discipline failure.*

Module 061 — Org Chart Architecture & Role Design — Prompt

Turn the org-chart prompt into an accountable design

This Operations prompt asks first for customer, offer and present situation, then the module’s business goal. RISER application: list recurring work, current owners, bottlenecks and decisions before drawing reporting boxes. A role needs an outcome, authority, responsibilities, capacity and escalation path. The source is a generic prompt, not an actual organization chart or implemented engine.

Apply Learn, Build, Do, Scale and Legacy

Learn the work and constraints; Build role definitions and decision rights; Do a trial with named owners and evidence; Scale only after workload and handoffs are stable; Legacy documents continuity, succession and maintainable records. These are RISER applications of the source’s five-stage structure. Avoid adding management layers merely because a template includes them.

Deliver the prompt’s six-part output

Provide context clarification, the business goal, the five-stage solution, a practical checklist, useful assets/automations/metrics, and a short summary with three next moves. Example next moves are inventory unowned work, assign an accountable owner and test one handoff. Track wait time, rework and capacity rather than number of job titles. Use plain language and relevant examples. The source’s closing question is part of its reusable prompt, not an instruction to halt this curriculum build.

Connect the lesson to the direct-marketing promise

Complete original source text

Org Chart Architecture & Role Design





CATEGORY: Operations





---- FULL PROMPT BELOW THIS LINE ----





You are the RISER Nation Org Chart Architecture & Role Design Engine.



Your role is to help me design, implement, and optimize everything related to "Org Chart Architecture & Role Design" as part of my Operations systems.



Use the RISER Journey: LEARN → BUILD → DO → SCALE → LEGACY.



When I ask for help, follow this structure:

1. Clarify my avatar, offer, and current situation.

2. Map the goal of this module inside my business.

3. Break the solution into clear RISER steps (Learn, Build, Do, Scale, Legacy).

4. Give me a practical checklist I can follow right now.

5. Suggest assets, automations, or metrics I should set up for this module.

6. End with a short summary + 3 "Next Best Moves" for me.



Use:

- Fifth-grader language where possible.

- Real-world examples tied to digital marketing and RISER Nation.

- Clear section headers and bullet points.



Always end by asking:

"Would you like me to go deeper on any step of Module 061, or move you to the next RISER module in your journey?"

Native Google Doc text and original links

Control separators are labeled in this readable display. Download exact original text

Org Chart Architecture & Role Design

CATEGORY: Operations

---- FULL PROMPT BELOW THIS LINE ----

You are the RISER Nation Org Chart Architecture & Role Design Engine.
[Source control separator U+000B]

[Source control separator U+000B]
Your role is to help me design, implement, and optimize everything related to "Org Chart Architecture & Role Design" as part of my Operations systems.
[Source control separator U+000B]

[Source control separator U+000B]
Use the RISER Journey: LEARN → BUILD → DO → SCALE → LEGACY.
[Source control separator U+000B]

[Source control separator U+000B]
When I ask for help, follow this structure:
[Source control separator U+000B]
1. Clarify my avatar, offer, and current situation.
[Source control separator U+000B]
2. Map the goal of this module inside my business.
[Source control separator U+000B]
3. Break the solution into clear RISER steps (Learn, Build, Do, Scale, Legacy).
[Source control separator U+000B]
4. Give me a practical checklist I can follow right now.
[Source control separator U+000B]
5. Suggest assets, automations, or metrics I should set up for this module.
[Source control separator U+000B]
6. End with a short summary + 3 "Next Best Moves" for me.
[Source control separator U+000B]

[Source control separator U+000B]
Use:
[Source control separator U+000B]
- Fifth-grader language where possible.
[Source control separator U+000B]
- Real-world examples tied to digital marketing and RISER Nation.
[Source control separator U+000B]
- Clear section headers and bullet points.
[Source control separator U+000B]

[Source control separator U+000B]
Always end by asking:
[Source control separator U+000B]
"Would you like me to go deeper on any step of Module 061, or move you to the next RISER module in your journey?"

NICHE-CORE OFFERS (A-A)

Treat this catalog as offer research, not clinical instruction

The catalog proposes health, recovery and support offers. It supplies ideas, not clinical evidence, practitioner qualifications or treatment protocols. Distinguish general education, peer support and professional care. Do not turn a proposed detox course, medication program or therapy label into instructions for self-treatment or a promise that RISER provides those services. Clinical content and claims need appropriate expertise and evidence.

Use the four delivery formats for their actual purpose

Spoken content includes webinars, podcasts, audiobooks, videos and recordings; written content includes books, guides, checklists and transcripts; physical products include workbooks, manuals, merchandise and tools; experiences include events, workshops, coaching and communities. Choose the format that helps a defined task and account for access, delivery and support. Tangible merchandise does not automatically add therapeutic benefit.

Protect the clinical boundary in the catalog

Alcohol withdrawal can be life-threatening and may require medical care; a marketing course cannot replace that assessment. OCD treatment examples should be reviewed by qualified clinicians; evidence for ERP does not validate every wellness item listed beside it. Therapy transcripts and recovery stories require appropriate permission and privacy protection. Do not fabricate successful case studies or pressure vulnerable people through shame or fear.

Evaluate smoking-cessation ideas by evidence

The catalog places counseling, nicotine replacement, apps, peer support, acupuncture and hypnotherapy together. This is not evidence that they work equally well. CDC describes counseling and medication as established options; NCCIH reports uncertainty or inconsistent evidence for the listed complementary approaches. Product samples are not a substitute for appropriate medication selection or professional advice. Do not claim teas, oils or relaxation kits treat addiction.

Adult Children of Alcoholics — Topic ideas

The source catalog proposes: Emotional Healing Program; Relationship Building Workshop; Self-Care and Mindfulness Course; Parenting Guidance for Break-the-Cycle; Stress and Anxiety Management Series; Communication Skills Training; Building Resilience Course; Setting Boundaries Workshop; Financial Stability Training; Self-Esteem and Confidence Boosting Program; Trauma Recovery Program; Assertiveness Training; Coping with Grief and Loss Workshop; Mind-Body Wellness Program; Conflict Resolution Skills Course; Forgiveness and Letting Go Workshop; Life Coaching for Personal Growth; Anger Management Training; Financial Planning and Management; Personal Empowerment Series. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Adult Children of Alcoholics — proposed core offer

Core Offer: Comprehensive recovery program This is a source brainstorming label. Validate the audience need, evidence, qualifications, delivery capacity and permitted claims before offering it. A name is not a complete service specification.

Adult Children of Alcoholics — The Spoken Word

The source catalog proposes: Webinars: Expert-led discussions on coping strategies and emotional healing.; Podcasts: Stories and advice from individuals who have navigated similar experiences.; Video Courses: Modules covering emotional resilience, relationship building, and self-care.; Audio Books: Narrated books on understanding and overcoming the impact of parental alcoholism.; Q&A Sessions: Recorded sessions where experts answer common questions about dealing with childhood trauma.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Adult Children of Alcoholics — The Written Word

The source catalog proposes: E-books: Comprehensive guides on managing emotions and building healthy relationships.; Guides: Step-by-step processes for breaking dysfunctional family patterns.; Checklists: Tools for identifying and addressing inherited behavioral patterns.; Transcripts: Written versions of expert talks and therapy sessions.; Case Studies: Real-life examples of individuals who have successfully healed from their past.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Adult Children of Alcoholics — The Physical Product

The source catalog proposes: Workbooks: Exercises and reflections to aid in emotional healing.; Printed Books: Self-help books focusing on recovery and personal growth.; Merchandise: Journals, motivational posters, or calming candles.; Tools: Therapy kits including stress balls, mindfulness cards, and affirmation cards.; Product Samples: Samples of calming teas or aromatherapy oils.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Adult Children of Alcoholics — The Experience

The source catalog proposes: Live Events: Access to seminars and workshops on overcoming childhood trauma.; Workshops: Interactive sessions focusing on building self-esteem and emotional intelligence.; Coaching Sessions: Personalized coaching with a focus on recovery and personal development.; Masterminds: Group sessions with peers for shared support and accountability.; Exclusive Communities: Membership in private support groups for ongoing connection and encouragement.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Alcoholism — Topic ideas

The source catalog proposes: Sobriety Maintenance Program; Detoxification Support Course; Emotional Support and Therapy Program; Family Counseling and Education; Healthy Living and Nutrition Guide; Workplace Integration Program; Mental Health and Wellness Training; Relapse Prevention Strategies; Peer Support Group Access; Physical Fitness and Recovery Program; Sober Living Housing Programs; Cognitive Behavioral Therapy (CBT); Mindfulness-Based Sobriety; Family Dynamics and Support Workshops; Nutritional Counseling and Support; Spiritual Counseling and Support; Exercise and Wellness Programs; Community Reintegration Support; Motivational Interviewing Sessions; Holistic Health and Wellness Programs. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Alcoholism — proposed core offer

Core Offer: Alcoholism recovery program This is a source brainstorming label. Validate the audience need, evidence, qualifications, delivery capacity and permitted claims before offering it. A name is not a complete service specification.

Alcoholism — The Spoken Word

The source catalog proposes: Webinars: Educational sessions on the effects of alcoholism and recovery strategies.; Podcasts: Interviews with recovery experts and success stories.; Video Courses: Courses on understanding alcoholism and effective treatment methods.; Audio Books: Narrated recovery memoirs and self-help books.; Q&A Sessions: Live or recorded sessions with addiction specialists.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Alcoholism — The Written Word

The source catalog proposes: E-books: Comprehensive guides to understanding and overcoming alcoholism.; Guides: Step-by-step recovery plans and relapse prevention strategies.; Checklists: Tools for monitoring progress and maintaining sobriety.; Transcripts: Written content from expert talks and recovery meetings.; Case Studies: Detailed recovery journeys of individuals who overcame alcoholism.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Alcoholism — The Physical Product

The source catalog proposes: Workbooks: Exercises and reflections designed to support recovery.; Printed Books: In-depth books on alcoholism recovery and prevention.; Merchandise: Inspirational items like T-shirts, wristbands, or recovery tokens.; Tools: Sobriety tracking tools and mindfulness aids.; Product Samples: Non-alcoholic beverages or relaxation aids.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Alcoholism — The Experience

The source catalog proposes: Live Events: Tickets to conferences and seminars on addiction recovery.; Workshops: Intensive sessions focusing on sobriety skills and relapse prevention.; Coaching Sessions: Personalized coaching from addiction recovery experts.; Masterminds: Support groups with other individuals in recovery.; Exclusive Communities: Access to private forums or social groups for ongoing support.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Drug Dependency — Topic ideas

The source catalog proposes: Comprehensive Detox Program; Long-Term Rehabilitation Plan; Mental Health and Counseling Services; Support for Families of Addicts; Employment and Skills Training; Holistic Wellness Program; Peer Support and Accountability Groups; Life Skills and Personal Development; Crisis Intervention and Management; Educational Workshops on Addiction; Inpatient Treatment Programs; Outpatient Treatment Programs; Dual Diagnosis Treatment (for co-occurring disorders); Relapse Triggers Identification and Management; Life Skills Training Programs; Career Counseling and Job Placement Assistance; Mindfulness and Meditation Classes; Sober Living Arrangements; Creative Arts Therapy; Stress Reduction and Relaxation Workshops. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Drug Dependency — proposed core offer

Core Offer: Drug addiction recovery program This is a source brainstorming label. Validate the audience need, evidence, qualifications, delivery capacity and permitted claims before offering it. A name is not a complete service specification.

Drug Dependency — The Spoken Word

The source catalog proposes: Webinars: Expert-led sessions on drug addiction and recovery methods.; Podcasts: Stories and advice from people who have overcome drug dependency.; Video Courses: Training on understanding addiction and implementing recovery techniques.; Audio Books: Narrated guides and personal stories on drug addiction and recovery.; Q&A Sessions: Interactive sessions with addiction specialists.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Drug Dependency — The Written Word

The source catalog proposes: E-books: In-depth guides on overcoming drug dependency.; Guides: Step-by-step plans for detox and rehabilitation.; Checklists: Tools for tracking recovery progress and avoiding relapse.; Transcripts: Written versions of therapy sessions and expert talks.; Case Studies: Documented success stories and recovery journeys.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Drug Dependency — The Physical Product

The source catalog proposes: Workbooks: Exercises and activities to support drug recovery.; Printed Books: Comprehensive books on addiction treatment and recovery.; Merchandise: Motivational merchandise like journals or wristbands.; Tools: Drug testing kits and mindfulness aids.; Product Samples: Relaxation products like herbal teas or essential oils.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Drug Dependency — The Experience

The source catalog proposes: Live Events: Access to recovery seminars and addiction workshops.; Workshops: Hands-on sessions focusing on sobriety and healthy living.; Coaching Sessions: One-on-one coaching with recovery experts.; Masterminds: Group coaching and support sessions.; Exclusive Communities: Membership in private recovery support groups.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Gambling — blank catalog entry

The source has a blank numbered item 21 after its twenty gambling topics. No additional idea is supplied, so this slot remains blank rather than being invented.

Gambling — Topic ideas

The source catalog proposes: Financial Recovery and Management; Mental Health Counseling; Family and Relationship Support; Behavioral Therapy and Support; Stress Relief and Relaxation Techniques; Peer Support and Group Therapy; Self-Control and Impulse Management; Employment and Career Guidance; Healthy Lifestyle and Habits Program; Legal Advice and Support Services; Debt Management and Financial Counseling; Emotional Regulation Skills Training; Cognitive Behavioral Therapy (CBT) for Gambling; Mindfulness and Meditation for Impulse Control; Family Therapy and Support Programs; Legal Assistance and Advice; Career Counseling and Skill Building; Personal Development Workshops; Financial Literacy and Budgeting; Stress Management and Coping Skills Training. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Gambling — proposed core offer

Core Offer: Gambling addiction recovery program This is a source brainstorming label. Validate the audience need, evidence, qualifications, delivery capacity and permitted claims before offering it. A name is not a complete service specification.

Gambling — The Spoken Word

The source catalog proposes: Webinars: Sessions on understanding and overcoming gambling addiction.; Podcasts: Interviews with recovering gamblers and addiction experts.; Video Courses: Educational videos on gambling addiction and recovery.; Audio Books: Narrated self-help books and recovery stories.; Q&A Sessions: Live or recorded sessions with gambling addiction specialists.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Gambling — The Written Word

The source catalog proposes: E-books: Guides on managing and overcoming gambling addiction.; Guides: Step-by-step recovery plans for gambling addicts.; Checklists: Tools for tracking gambling behavior and recovery progress.; Transcripts: Written content from webinars and therapy sessions.; Case Studies: Real-life examples of successful gambling addiction recovery.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Gambling — The Physical Product

The source catalog proposes: Workbooks: Activities and exercises to support gambling recovery.; Printed Books: Comprehensive books on gambling addiction treatment.; Merchandise: Inspirational items like keychains, bracelets, or recovery tokens.; Tools: Budget planners and mindfulness tools.; Product Samples: Stress relief products like fidget tools or calming teas.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Gambling — The Experience

The source catalog proposes: Live Events: Tickets to gambling addiction recovery seminars.; Workshops: Intensive recovery sessions and skill-building workshops.; Coaching Sessions: Personalized coaching with gambling recovery experts.; Masterminds: Group support and accountability sessions.; Exclusive Communities: Membership in private forums or social groups for gamblers in recovery.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Hoarding — Topic ideas

The source catalog proposes: Comprehensive Decluttering Program; Psychological Therapy and Support; Home Organization Skills Training; Family Support and Education; Self-Control and Behavioral Modification; Emergency Clean-Up Services; Mindfulness and Relaxation Techniques; Peer Support and Group Therapy; Health and Safety Education; Maintenance and Follow-Up Program; Professional Organizing Services; Virtual Decluttering Coaching; Emotional Support and Counseling; Peer Support Groups; Mindfulness Training for Anxiety Management; Cognitive Behavioral Therapy (CBT) for Hoarding; Home Safety Inspections and Recommendations; Motivational Interviewing for Behavior Change; Family Education and Support Programs; Relapse Prevention and Maintenance Programs. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Hoarding — proposed core offer

Core Offer: Hoarding intervention and management program This is a source brainstorming label. Validate the audience need, evidence, qualifications, delivery capacity and permitted claims before offering it. A name is not a complete service specification.

Hoarding — The Spoken Word

The source catalog proposes: Webinars: Sessions on understanding and managing hoarding behavior.; Podcasts: Discussions with experts and personal stories from those overcoming hoarding.; Video Courses: Training on decluttering and maintaining a clutter-free lifestyle.; Audio Books: Narrated guides and personal stories about overcoming hoarding.; Q&A Sessions: Interactive sessions with hoarding specialists.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Hoarding — The Written Word

The source catalog proposes: E-books: Guides on decluttering and managing hoarding tendencies.; Guides: Step-by-step plans for cleaning and organizing.; Checklists: Tools for tracking decluttering progress and maintaining organization.; Transcripts: Written versions of expert talks and therapy sessions.; Case Studies: Real-life examples of successful hoarding interventions.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Hoarding — The Physical Product

The source catalog proposes: Workbooks: Exercises and activities to support decluttering efforts.; Printed Books: Comprehensive books on hoarding treatment and organization.; Merchandise: Motivational items like planners, organizers, or storage solutions.; Tools: Cleaning and organizing kits.; Product Samples: Samples of storage and organizational products.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Hoarding — The Experience

The source catalog proposes: Live Events: Access to seminars and workshops on hoarding recovery.; Workshops: Hands-on decluttering sessions and organization workshops.; Coaching Sessions: Personalized coaching for decluttering and managing hoarding.; Masterminds: Group sessions for shared support and accountability.; Exclusive Communities: Membership in private support groups for hoarders.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Obsessive Compulsive Disorder (OCD) — Topic ideas

The source catalog proposes: Behavioral Therapy and Cognitive Training; Mindfulness and Stress Reduction; Family Support and Education; Medication Management and Support; Self-Help Strategies and Tools; Exposure and Response Prevention Training; Peer Support and Group Therapy; Workplace Accommodation and Support; Coping Mechanisms and Strategies; Holistic Wellness and Lifestyle Program; Dialectical Behavior Therapy (DBT); Support Groups and Peer Networks; Virtual Therapy Sessions; Nutritional Counseling for Mental Health; Exercise Programs for Anxiety Relief; Stress Management and Relaxation Techniques; Family Education and Support Programs; Personal Development and Goal Setting; Art and Music Therapy; Sleep Hygiene and Wellness Programs. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Obsessive Compulsive Disorder (OCD) — proposed core offer

Core Offer: OCD management and treatment program This is a source brainstorming label. Validate the audience need, evidence, qualifications, delivery capacity and permitted claims before offering it. A name is not a complete service specification.

Obsessive Compulsive Disorder (OCD) — The Spoken Word

The source catalog proposes: Webinars: Educational sessions on understanding and managing OCD.; Podcasts: Interviews with OCD specialists and stories from those living with OCD.; Video Courses: Modules on coping strategies and treatment methods for OCD.; Audio Books: Narrated self-help books and personal stories about OCD.; Q&A Sessions: Interactive sessions with OCD specialists.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Obsessive Compulsive Disorder (OCD) — The Written Word

The source catalog proposes: E-books: Guides on understanding and treating OCD.; Guides: Step-by-step plans for managing OCD symptoms.; Checklists: Tools for tracking OCD behaviors and progress.; Transcripts: Written content from expert talks and therapy sessions.; Case Studies: Documented recovery stories and treatment successes.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Obsessive Compulsive Disorder (OCD) — The Physical Product

The source catalog proposes: Workbooks: Exercises and activities designed to help manage OCD.; Printed Books: In-depth books on OCD treatment and management.; Merchandise: Inspirational items like journals, stress balls, or motivational posters.; Tools: Anxiety management kits and mindfulness tools.; Product Samples: Relaxation aids like aromatherapy oils or calming teas.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Obsessive Compulsive Disorder (OCD) — The Experience

The source catalog proposes: Live Events: Tickets to OCD seminars and workshops.; Workshops: Intensive sessions focused on coping strategies and treatment techniques.; Coaching Sessions: One-on-one coaching with OCD treatment experts.; Masterminds: Group support and therapy sessions.; Exclusive Communities: Access to private forums or support groups for those with OCD.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Sexual Addiction — Topic ideas

The source catalog proposes: Behavioral Therapy and Cognitive Training; Relationship Counseling and Support; Self-Control and Impulse Management; Healthy Sexuality Education; Stress and Anxiety Management; Peer Support and Accountability Groups; Mindfulness and Relaxation Techniques; Crisis Management and Intervention; Family Education and Support; Long-Term Recovery and Maintenance; Trauma-Informed Therapy; Mindfulness-Based Stress Reduction; Relationship Repair and Building Workshops; Virtual Support Groups; Healthy Relationship and Communication Skills; Addiction Education and Awareness Programs; Self-Esteem and Confidence Building Workshops; Family and Partner Support Programs; Exercise and Wellness Programs; Meditation and Relaxation Techniques. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Sexual Addiction — proposed core offer

Core Offer: Sexual addiction recovery program This is a source brainstorming label. Validate the audience need, evidence, qualifications, delivery capacity and permitted claims before offering it. A name is not a complete service specification.

Sexual Addiction — The Spoken Word

The source catalog proposes: Webinars: Sessions on understanding and treating sexual addiction.; Podcasts: Interviews with recovery experts and personal stories.; Video Courses: Educational videos on managing and overcoming sexual addiction.; Audio Books: Narrated guides and recovery stories.; Q&A Sessions: Interactive sessions with sexual addiction specialists.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Sexual Addiction — The Written Word

The source catalog proposes: E-books: Comprehensive guides on understanding and treating sexual addiction.; Guides: Step-by-step recovery plans.; Checklists: Tools for tracking recovery progress and maintaining sobriety.; Transcripts: Written versions of expert talks and therapy sessions.; Case Studies: Real-life recovery stories and treatment successes.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Sexual Addiction — The Physical Product

The source catalog proposes: Workbooks: Exercises and activities to support sexual addiction recovery.; Printed Books: Comprehensive books on treatment and recovery.; Merchandise: Motivational items like journals or wristbands.; Tools: Sobriety tracking tools and mindfulness aids.; Product Samples: Relaxation products like herbal teas or essential oils.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Sexual Addiction — The Experience

The source catalog proposes: Live Events: Access to recovery seminars and workshops.; Workshops: Intensive sessions focusing on sobriety and healthy living.; Coaching Sessions: Personalized coaching from sexual addiction recovery experts.; Masterminds: Group support and accountability sessions.; Exclusive Communities: Membership in private forums or support groups.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Tobacco — Topic ideas

The source catalog proposes: Behavioral Therapy for Smoking Cessation; Nicotine Replacement Therapy Support; Healthy Living and Nutrition Guide; Stress Management and Relaxation Techniques; Family and Peer Support; Exercise and Fitness Program; Workplace Support for Quitting; Holistic Wellness and Lifestyle Program; Mental Health Support and Counseling; Relapse Prevention Strategies; Quit Smoking Mobile Apps; Virtual Support Groups and Communities; Acupuncture for Smoking Cessation; Hypnotherapy for Smoking Cessation; Nicotine Replacement Therapy Programs; Personalized Quit Plans and Coaching; Stress Management and Coping Techniques; Nutritional Support for Recovery; Exercise and Fitness Programs; Relapse Prevention and Support Programs. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Tobacco — proposed core offer

Core Offer: Smoking cessation program This is a source brainstorming label. Validate the audience need, evidence, qualifications, delivery capacity and permitted claims before offering it. A name is not a complete service specification.

Tobacco — The Spoken Word

The source catalog proposes: Webinars: Educational sessions on quitting smoking and nicotine addiction.; Podcasts: Interviews with former smokers and addiction experts.; Video Courses: Step-by-step videos on quitting smoking and staying smoke-free.; Audio Books: Narrated self-help books and personal stories about quitting smoking.; Q&A Sessions: Interactive sessions with tobacco cessation specialists.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Tobacco — The Written Word

The source catalog proposes: E-books: Guides on quitting smoking and managing cravings.; Guides: Step-by-step plans for tobacco cessation.; Checklists: Tools for tracking quitting progress and managing withdrawal symptoms.; Transcripts: Written content from expert talks and cessation programs.; Case Studies: Success stories of individuals who quit smoking.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Tobacco — The Physical Product

The source catalog proposes: Workbooks: Exercises and activities to support smoking cessation.; Printed Books: Comprehensive books on quitting smoking.; Merchandise: Inspirational items like stress balls or motivational posters.; Tools: Nicotine replacement therapy samples and mindfulness tools.; Product Samples: Relaxation aids like herbal teas or essential oils.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Tobacco — The Experience

The source catalog proposes: Live Events: Access to smoking cessation seminars and workshops.; Workshops: Hands-on sessions focusing on quitting smoking and maintaining a smoke-free life.; Coaching Sessions: Personalized coaching for tobacco cessation.; Masterminds: Group support and accountability sessions.; Exclusive Communities: Membership in private forums or support groups for former smokers.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Twelve-Step Programs — Topic ideas

The source catalog proposes: Comprehensive Step-by-Step Guide; Peer Support and Accountability Groups; Family Education and Support; Mental Health and Wellness Training; Healthy Living and Nutrition Guide; Behavioral Therapy and Cognitive Training; Stress Management and Relaxation Techniques; Self-Esteem and Confidence Building; Employment and Skills Training; Relapse Prevention and Maintenance Program; Online Twelve-Step Meetings; Step Study Groups; Spiritual Growth and Development Workshops; Service and Volunteer Opportunities; Twelve-Step Retreats and Conferences; Meditation and Mindfulness Training; Sponsorship Training and Support; Literature and Study Materials; Relapse Prevention and Maintenance Programs; Emotional Sobriety Workshops. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Twelve-Step Programs — proposed core offer

Core Offer: Twelve-step recovery program This is a source brainstorming label. Validate the audience need, evidence, qualifications, delivery capacity and permitted claims before offering it. A name is not a complete service specification.

Twelve-Step Programs — The Spoken Word

The source catalog proposes: Webinars: Sessions on the principles and practices of twelve-step programs.; Podcasts: Interviews with twelve-step program participants and recovery stories.; Video Courses: Educational videos on the twelve-step process.; Audio Books: Narrated guides and personal stories about twelve-step recovery.; Q&A Sessions: Interactive sessions with twelve-step program facilitators.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Twelve-Step Programs — The Written Word

The source catalog proposes: E-books: Guides on the twelve-step program and its application.; Guides: Step-by-step plans for each of the twelve steps.; Checklists: Tools for tracking progress through the twelve steps.; Transcripts: Written content from expert talks and program meetings.; Case Studies: Success stories of individuals who completed the twelve-step program.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Twelve-Step Programs — The Physical Product

The source catalog proposes: Workbooks: Exercises and activities for each step of the program.; Printed Books: Comprehensive books on twelve-step recovery.; Merchandise: Inspirational items like journals or recovery tokens.; Tools: Sobriety chips and mindfulness aids.; Product Samples: Relaxation aids like herbal teas or essential oils.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Twelve-Step Programs — The Experience

The source catalog proposes: Live Events: Access to twelve-step program seminars and workshops.; Workshops: Intensive sessions focusing on each step of the program.; Coaching Sessions: Personalized coaching from twelve-step program facilitators.; Masterminds: Group support and accountability sessions.; Exclusive Communities: Membership in private forums or support groups for twelve-step program participants.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Alcoholism — additional holistic example — Topic ideas

Alcoholism — additional holistic example — proposed core offer

Core Offer: Holistic Health and Wellness Programs This is a source brainstorming label. Validate the audience need, evidence, qualifications, delivery capacity and permitted claims before offering it. A name is not a complete service specification.

Alcoholism — additional holistic example — The Spoken Word

The source catalog proposes: Nutritional Counseling Sessions: Provide one-on-one sessions with nutritionists or dieticians to educate and guide individuals on healthy eating habits and nutritional support for recovery.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Alcoholism — additional holistic example — The Written Word

The source catalog proposes: Holistic Health Guides: Offer comprehensive guides or e-books covering various aspects of holistic health, including nutrition, mindfulness, fitness, and alternative therapies.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Alcoholism — additional holistic example — The Physical Product

The source catalog proposes: Holistic Health Kits: Provide curated kits containing essential items for holistic health practices, such as yoga mats, meditation cushions, essential oils, herbal teas, and healthy snacks.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Alcoholism — additional holistic example — The Experience

The source catalog proposes: Wellness Retreats: Organize immersive retreats focused on holistic healing, featuring activities like yoga, meditation, nature walks, nutritional workshops, and holistic therapy sessions.. RISER design exercise: select only a need supported by audience research, define the bounded deliverable and qualified owner, and state what is outside scope. These entries are possibilities, not proven services or treatment recommendations. Preserve distinct ideas without packaging every item into one oversized offer.

Keep the final holistic example distinct

The repeated alcoholism list introduces a different core offer: holistic health and wellness. It proposes individual nutrition counseling, written guides, kits with mats/cushions/oils/teas/snacks, and retreats with movement, meditation, nature and nutrition sessions. Counseling is an interactive service even though the source labels it spoken content. Define evidence, practitioner role, participant suitability and actual inclusion; accessories and alternative-therapy language do not establish a recovery benefit.

Connect the lesson to the direct-marketing promise

Complete original source text

OFFER PACKAGES

. The Spoken Word

* Description: This refers to content delivered through audio or video formats.

* Examples: Webinars, podcasts, audio books, video courses, and live recordings.

2. The Written Word

* Description: This includes any written content that provides valuable information or education.

* Examples: E-books, guides, checklists, transcripts, and printed books.

3. The Physical Product

* Description: Tangible items that can be shipped to customers, adding perceived value.

* Examples: Workbooks, printed manuals, physical books, merchandise, and tools.

4. The Experience

* Description: Opportunities for customers to engage with you or your content in a more immersive way.

* Examples: Live events, workshops, coaching sessions, masterminds, and access to exclusive groups or communities.

Adult Children of Alcoholics

1. Emotional Healing Program

2. Relationship Building Workshop

3. Self-Care and Mindfulness Course

4. Parenting Guidance for Break-the-Cycle

5. Stress and Anxiety Management Series

6. Communication Skills Training

7. Building Resilience Course

8. Setting Boundaries Workshop

9. Financial Stability Training

10. Self-Esteem and Confidence Boosting Program

11. Trauma Recovery Program

12. Assertiveness Training

13. Coping with Grief and Loss Workshop

14. Mind-Body Wellness Program

15. Conflict Resolution Skills Course

16. Forgiveness and Letting Go Workshop

17. Life Coaching for Personal Growth

18. Anger Management Training

19. Financial Planning and Management

20. Personal Empowerment Series

Core Offer: Comprehensive recovery program

The Spoken Word

1. Webinars: Expert-led discussions on coping strategies and emotional healing.

2. Podcasts: Stories and advice from individuals who have navigated similar experiences.

3. Video Courses: Modules covering emotional resilience, relationship building, and self-care.

4. Audio Books: Narrated books on understanding and overcoming the impact of parental alcoholism.

5. Q&A Sessions: Recorded sessions where experts answer common questions about dealing with childhood trauma.

The Written Word

1. E-books: Comprehensive guides on managing emotions and building healthy relationships.

2. Guides: Step-by-step processes for breaking dysfunctional family patterns.

3. Checklists: Tools for identifying and addressing inherited behavioral patterns.

4. Transcripts: Written versions of expert talks and therapy sessions.

5. Case Studies: Real-life examples of individuals who have successfully healed from their past.

The Physical Product

1. Workbooks: Exercises and reflections to aid in emotional healing.

2. Printed Books: Self-help books focusing on recovery and personal growth.

3. Merchandise: Journals, motivational posters, or calming candles.

4. Tools: Therapy kits including stress balls, mindfulness cards, and affirmation cards.

5. Product Samples: Samples of calming teas or aromatherapy oils.

The Experience

1. Live Events: Access to seminars and workshops on overcoming childhood trauma.

2. Workshops: Interactive sessions focusing on building self-esteem and emotional intelligence.

3. Coaching Sessions: Personalized coaching with a focus on recovery and personal development.

4. Masterminds: Group sessions with peers for shared support and accountability.

5. Exclusive Communities: Membership in private support groups for ongoing connection and encouragement.

2. Alcoholism

1. Sobriety Maintenance Program

2. Detoxification Support Course

3. Emotional Support and Therapy Program

4. Family Counseling and Education

5. Healthy Living and Nutrition Guide

6. Workplace Integration Program

7. Mental Health and Wellness Training

8. Relapse Prevention Strategies

9. Peer Support Group Access

10. Physical Fitness and Recovery Program

11. Sober Living Housing Programs

12. Cognitive Behavioral Therapy (CBT)

13. Mindfulness-Based Sobriety

14. Family Dynamics and Support Workshops

15. Nutritional Counseling and Support

16. Spiritual Counseling and Support

17. Exercise and Wellness Programs

18. Community Reintegration Support

19. Motivational Interviewing Sessions

20. Holistic Health and Wellness Programs

Core Offer: Alcoholism recovery program

The Spoken Word

1. Webinars: Educational sessions on the effects of alcoholism and recovery strategies.

2. Podcasts: Interviews with recovery experts and success stories.

3. Video Courses: Courses on understanding alcoholism and effective treatment methods.

4. Audio Books: Narrated recovery memoirs and self-help books.

5. Q&A Sessions: Live or recorded sessions with addiction specialists.

The Written Word

1. E-books: Comprehensive guides to understanding and overcoming alcoholism.

2. Guides: Step-by-step recovery plans and relapse prevention strategies.

3. Checklists: Tools for monitoring progress and maintaining sobriety.

4. Transcripts: Written content from expert talks and recovery meetings.

5. Case Studies: Detailed recovery journeys of individuals who overcame alcoholism.

The Physical Product

1. Workbooks: Exercises and reflections designed to support recovery.

2. Printed Books: In-depth books on alcoholism recovery and prevention.

3. Merchandise: Inspirational items like T-shirts, wristbands, or recovery tokens.

4. Tools: Sobriety tracking tools and mindfulness aids.

5. Product Samples: Non-alcoholic beverages or relaxation aids.

The Experience

1. Live Events: Tickets to conferences and seminars on addiction recovery.

2. Workshops: Intensive sessions focusing on sobriety skills and relapse prevention.

3. Coaching Sessions: Personalized coaching from addiction recovery experts.

4. Masterminds: Support groups with other individuals in recovery.

5. Exclusive Communities: Access to private forums or social groups for ongoing support.

3. Drug Dependency

1. Comprehensive Detox Program

2. Long-Term Rehabilitation Plan

3. Mental Health and Counseling Services

4. Support for Families of Addicts

5. Employment and Skills Training

6. Holistic Wellness Program

7. Peer Support and Accountability Groups

8. Life Skills and Personal Development

9. Crisis Intervention and Management

10. Educational Workshops on Addiction

11. Inpatient Treatment Programs

12. Outpatient Treatment Programs

13. Dual Diagnosis Treatment (for co-occurring disorders)

14. Relapse Triggers Identification and Management

15. Life Skills Training Programs

16. Career Counseling and Job Placement Assistance

17. Mindfulness and Meditation Classes

18. Sober Living Arrangements

19. Creative Arts Therapy

20. Stress Reduction and Relaxation Workshops

Core Offer: Drug addiction recovery program

The Spoken Word

1. Webinars: Expert-led sessions on drug addiction and recovery methods.

2. Podcasts: Stories and advice from people who have overcome drug dependency.

3. Video Courses: Training on understanding addiction and implementing recovery techniques.

4. Audio Books: Narrated guides and personal stories on drug addiction and recovery.

5. Q&A Sessions: Interactive sessions with addiction specialists.

The Written Word

1. E-books: In-depth guides on overcoming drug dependency.

2. Guides: Step-by-step plans for detox and rehabilitation.

3. Checklists: Tools for tracking recovery progress and avoiding relapse.

4. Transcripts: Written versions of therapy sessions and expert talks.

5. Case Studies: Documented success stories and recovery journeys.

The Physical Product

1. Workbooks: Exercises and activities to support drug recovery.

2. Printed Books: Comprehensive books on addiction treatment and recovery.

3. Merchandise: Motivational merchandise like journals or wristbands.

4. Tools: Drug testing kits and mindfulness aids.

5. Product Samples: Relaxation products like herbal teas or essential oils.

The Experience

1. Live Events: Access to recovery seminars and addiction workshops.

2. Workshops: Hands-on sessions focusing on sobriety and healthy living.

3. Coaching Sessions: One-on-one coaching with recovery experts.

4. Masterminds: Group coaching and support sessions.

5. Exclusive Communities: Membership in private recovery support groups.

4. Gambling

1. Financial Recovery and Management

2. Mental Health Counseling

3. Family and Relationship Support

4. Behavioral Therapy and Support

5. Stress Relief and Relaxation Techniques

6. Peer Support and Group Therapy

7. Self-Control and Impulse Management

8. Employment and Career Guidance

9. Healthy Lifestyle and Habits Program

10. Legal Advice and Support Services

11. Debt Management and Financial Counseling

12. Emotional Regulation Skills Training

13. Cognitive Behavioral Therapy (CBT) for Gambling

14. Mindfulness and Meditation for Impulse Control

15. Family Therapy and Support Programs

16. Legal Assistance and Advice

17. Career Counseling and Skill Building

18. Personal Development Workshops

19. Financial Literacy and Budgeting

20. Stress Management and Coping Skills Training

21.

Core Offer: Gambling addiction recovery program

The Spoken Word

1. Webinars: Sessions on understanding and overcoming gambling addiction.

2. Podcasts: Interviews with recovering gamblers and addiction experts.

3. Video Courses: Educational videos on gambling addiction and recovery.

4. Audio Books: Narrated self-help books and recovery stories.

5. Q&A Sessions: Live or recorded sessions with gambling addiction specialists.

The Written Word

1. E-books: Guides on managing and overcoming gambling addiction.

2. Guides: Step-by-step recovery plans for gambling addicts.

3. Checklists: Tools for tracking gambling behavior and recovery progress.

4. Transcripts: Written content from webinars and therapy sessions.

5. Case Studies: Real-life examples of successful gambling addiction recovery.

The Physical Product

1. Workbooks: Activities and exercises to support gambling recovery.

2. Printed Books: Comprehensive books on gambling addiction treatment.

3. Merchandise: Inspirational items like keychains, bracelets, or recovery tokens.

4. Tools: Budget planners and mindfulness tools.

5. Product Samples: Stress relief products like fidget tools or calming teas.

The Experience

1. Live Events: Tickets to gambling addiction recovery seminars.

2. Workshops: Intensive recovery sessions and skill-building workshops.

3. Coaching Sessions: Personalized coaching with gambling recovery experts.

4. Masterminds: Group support and accountability sessions.

5. Exclusive Communities: Membership in private forums or social groups for gamblers in recovery.

5. Hoarding

1. Comprehensive Decluttering Program

2. Psychological Therapy and Support

3. Home Organization Skills Training

4. Family Support and Education

5. Self-Control and Behavioral Modification

6. Emergency Clean-Up Services

7. Mindfulness and Relaxation Techniques

8. Peer Support and Group Therapy

9. Health and Safety Education

10. Maintenance and Follow-Up Program

11. Professional Organizing Services

12. Virtual Decluttering Coaching

13. Emotional Support and Counseling

14. Peer Support Groups

15. Mindfulness Training for Anxiety Management

16. Cognitive Behavioral Therapy (CBT) for Hoarding

17. Home Safety Inspections and Recommendations

18. Motivational Interviewing for Behavior Change

19. Family Education and Support Programs

20. Relapse Prevention and Maintenance Programs

Core Offer: Hoarding intervention and management program

The Spoken Word

1. Webinars: Sessions on understanding and managing hoarding behavior.

2. Podcasts: Discussions with experts and personal stories from those overcoming hoarding.

3. Video Courses: Training on decluttering and maintaining a clutter-free lifestyle.

4. Audio Books: Narrated guides and personal stories about overcoming hoarding.

5. Q&A Sessions: Interactive sessions with hoarding specialists.

The Written Word

1. E-books: Guides on decluttering and managing hoarding tendencies.

2. Guides: Step-by-step plans for cleaning and organizing.

3. Checklists: Tools for tracking decluttering progress and maintaining organization.

4. Transcripts: Written versions of expert talks and therapy sessions.

5. Case Studies: Real-life examples of successful hoarding interventions.

The Physical Product

1. Workbooks: Exercises and activities to support decluttering efforts.

2. Printed Books: Comprehensive books on hoarding treatment and organization.

3. Merchandise: Motivational items like planners, organizers, or storage solutions.

4. Tools: Cleaning and organizing kits.

5. Product Samples: Samples of storage and organizational products.

The Experience

1. Live Events: Access to seminars and workshops on hoarding recovery.

2. Workshops: Hands-on decluttering sessions and organization workshops.

3. Coaching Sessions: Personalized coaching for decluttering and managing hoarding.

4. Masterminds: Group sessions for shared support and accountability.

5. Exclusive Communities: Membership in private support groups for hoarders.

6. Obsessive Compulsive Disorder (OCD)

1. Behavioral Therapy and Cognitive Training

2. Mindfulness and Stress Reduction

3. Family Support and Education

4. Medication Management and Support

5. Self-Help Strategies and Tools

6. Exposure and Response Prevention Training

7. Peer Support and Group Therapy

8. Workplace Accommodation and Support

9. Coping Mechanisms and Strategies

10. Holistic Wellness and Lifestyle Program

11. Dialectical Behavior Therapy (DBT)

12. Support Groups and Peer Networks

13. Virtual Therapy Sessions

14. Nutritional Counseling for Mental Health

15. Exercise Programs for Anxiety Relief

16. Stress Management and Relaxation Techniques

17. Family Education and Support Programs

18. Personal Development and Goal Setting

19. Art and Music Therapy

20. Sleep Hygiene and Wellness Programs

Core Offer: OCD management and treatment program

The Spoken Word

1. Webinars: Educational sessions on understanding and managing OCD.

2. Podcasts: Interviews with OCD specialists and stories from those living with OCD.

3. Video Courses: Modules on coping strategies and treatment methods for OCD.

4. Audio Books: Narrated self-help books and personal stories about OCD.

5. Q&A Sessions: Interactive sessions with OCD specialists.

The Written Word

1. E-books: Guides on understanding and treating OCD.

2. Guides: Step-by-step plans for managing OCD symptoms.

3. Checklists: Tools for tracking OCD behaviors and progress.

4. Transcripts: Written content from expert talks and therapy sessions.

5. Case Studies: Documented recovery stories and treatment successes.

The Physical Product

1. Workbooks: Exercises and activities designed to help manage OCD.

2. Printed Books: In-depth books on OCD treatment and management.

3. Merchandise: Inspirational items like journals, stress balls, or motivational posters.

4. Tools: Anxiety management kits and mindfulness tools.

5. Product Samples: Relaxation aids like aromatherapy oils or calming teas.

The Experience

1. Live Events: Tickets to OCD seminars and workshops.

2. Workshops: Intensive sessions focused on coping strategies and treatment techniques.

3. Coaching Sessions: One-on-one coaching with OCD treatment experts.

4. Masterminds: Group support and therapy sessions.

5. Exclusive Communities: Access to private forums or support groups for those with OCD.

7. Sexual Addiction

1. Behavioral Therapy and Cognitive Training

2. Relationship Counseling and Support

3. Self-Control and Impulse Management

4. Healthy Sexuality Education

5. Stress and Anxiety Management

6. Peer Support and Accountability Groups

7. Mindfulness and Relaxation Techniques

8. Crisis Management and Intervention

9. Family Education and Support

10. Long-Term Recovery and Maintenance

11. Trauma-Informed Therapy

12. Mindfulness-Based Stress Reduction

13. Relationship Repair and Building Workshops

14. Virtual Support Groups

15. Healthy Relationship and Communication Skills

16. Addiction Education and Awareness Programs

17. Self-Esteem and Confidence Building Workshops

18. Family and Partner Support Programs

19. Exercise and Wellness Programs

20. Meditation and Relaxation Techniques

Core Offer: Sexual addiction recovery program

The Spoken Word

1. Webinars: Sessions on understanding and treating sexual addiction.

2. Podcasts: Interviews with recovery experts and personal stories.

3. Video Courses: Educational videos on managing and overcoming sexual addiction.

4. Audio Books: Narrated guides and recovery stories.

5. Q&A Sessions: Interactive sessions with sexual addiction specialists.

The Written Word

1. E-books: Comprehensive guides on understanding and treating sexual addiction.

2. Guides: Step-by-step recovery plans.

3. Checklists: Tools for tracking recovery progress and maintaining sobriety.

4. Transcripts: Written versions of expert talks and therapy sessions.

5. Case Studies: Real-life recovery stories and treatment successes.

The Physical Product

1. Workbooks: Exercises and activities to support sexual addiction recovery.

2. Printed Books: Comprehensive books on treatment and recovery.

3. Merchandise: Motivational items like journals or wristbands.

4. Tools: Sobriety tracking tools and mindfulness aids.

5. Product Samples: Relaxation products like herbal teas or essential oils.

The Experience

1. Live Events: Access to recovery seminars and workshops.

2. Workshops: Intensive sessions focusing on sobriety and healthy living.

3. Coaching Sessions: Personalized coaching from sexual addiction recovery experts.

4. Masterminds: Group support and accountability sessions.

5. Exclusive Communities: Membership in private forums or support groups.

8. Tobacco

1. Behavioral Therapy for Smoking Cessation

2. Nicotine Replacement Therapy Support

3. Healthy Living and Nutrition Guide

4. Stress Management and Relaxation Techniques

5. Family and Peer Support

6. Exercise and Fitness Program

7. Workplace Support for Quitting

8. Holistic Wellness and Lifestyle Program

9. Mental Health Support and Counseling

10. Relapse Prevention Strategies

11. Quit Smoking Mobile Apps

12. Virtual Support Groups and Communities

13. Acupuncture for Smoking Cessation

14. Hypnotherapy for Smoking Cessation

15. Nicotine Replacement Therapy Programs

16. Personalized Quit Plans and Coaching

17. Stress Management and Coping Techniques

18. Nutritional Support for Recovery

19. Exercise and Fitness Programs

20. Relapse Prevention and Support Programs

Core Offer: Smoking cessation program

The Spoken Word

1. Webinars: Educational sessions on quitting smoking and nicotine addiction.

2. Podcasts: Interviews with former smokers and addiction experts.

3. Video Courses: Step-by-step videos on quitting smoking and staying smoke-free.

4. Audio Books: Narrated self-help books and personal stories about quitting smoking.

5. Q&A Sessions: Interactive sessions with tobacco cessation specialists.

The Written Word

1. E-books: Guides on quitting smoking and managing cravings.

2. Guides: Step-by-step plans for tobacco cessation.

3. Checklists: Tools for tracking quitting progress and managing withdrawal symptoms.

4. Transcripts: Written content from expert talks and cessation programs.

5. Case Studies: Success stories of individuals who quit smoking.

The Physical Product

1. Workbooks: Exercises and activities to support smoking cessation.

2. Printed Books: Comprehensive books on quitting smoking.

3. Merchandise: Inspirational items like stress balls or motivational posters.

4. Tools: Nicotine replacement therapy samples and mindfulness tools.

5. Product Samples: Relaxation aids like herbal teas or essential oils.

The Experience

1. Live Events: Access to smoking cessation seminars and workshops.

2. Workshops: Hands-on sessions focusing on quitting smoking and maintaining a smoke-free life.

3. Coaching Sessions: Personalized coaching for tobacco cessation.

4. Masterminds: Group support and accountability sessions.

5. Exclusive Communities: Membership in private forums or support groups for former smokers.

9. Twelve-Step Programs

1. Comprehensive Step-by-Step Guide

2. Peer Support and Accountability Groups

3. Family Education and Support

4. Mental Health and Wellness Training

5. Healthy Living and Nutrition Guide

6. Behavioral Therapy and Cognitive Training

7. Stress Management and Relaxation Techniques

8. Self-Esteem and Confidence Building

9. Employment and Skills Training

10. Relapse Prevention and Maintenance Program

11. Online Twelve-Step Meetings

12. Step Study Groups

13. Spiritual Growth and Development Workshops

14. Service and Volunteer Opportunities

15. Twelve-Step Retreats and Conferences

16. Meditation and Mindfulness Training

17. Sponsorship Training and Support

18. Literature and Study Materials

19. Relapse Prevention and Maintenance Programs

20. Emotional Sobriety Workshops

Core Offer: Twelve-step recovery program

The Spoken Word

1. Webinars: Sessions on the principles and practices of twelve-step programs.

2. Podcasts: Interviews with twelve-step program participants and recovery stories.

3. Video Courses: Educational videos on the twelve-step process.

4. Audio Books: Narrated guides and personal stories about twelve-step recovery.

5. Q&A Sessions: Interactive sessions with twelve-step program facilitators.

The Written Word

1. E-books: Guides on the twelve-step program and its application.

2. Guides: Step-by-step plans for each of the twelve steps.

3. Checklists: Tools for tracking progress through the twelve steps.

4. Transcripts: Written content from expert talks and program meetings.

5. Case Studies: Success stories of individuals who completed the twelve-step program.

The Physical Product

1. Workbooks: Exercises and activities for each step of the program.

2. Printed Books: Comprehensive books on twelve-step recovery.

3. Merchandise: Inspirational items like journals or recovery tokens.

4. Tools: Sobriety chips and mindfulness aids.

5. Product Samples: Relaxation aids like herbal teas or essential oils.

The Experience

1. Live Events: Access to twelve-step program seminars and workshops.

2. Workshops: Intensive sessions focusing on each step of the program.

3. Coaching Sessions: Personalized coaching from twelve-step program facilitators.

4. Masterminds: Group support and accountability sessions.

5. Exclusive Communities: Membership in private forums or support groups for twelve-step program participants.

2. Alcoholism

1. Sobriety Maintenance Program

2. Detoxification Support Course

3. Emotional Support and Therapy Program

4. Family Counseling and Education

5. Healthy Living and Nutrition Guide

6. Workplace Integration Program

7. Mental Health and Wellness Training

8. Relapse Prevention Strategies

9. Peer Support Group Access

10. Physical Fitness and Recovery Program

11. Sober Living Housing Programs

12. Cognitive Behavioral Therapy (CBT)

13. Mindfulness-Based Sobriety

14. Family Dynamics and Support Workshops

15. Nutritional Counseling and Support

16. Spiritual Counseling and Support

17. Exercise and Wellness Programs

18. Community Reintegration Support

19. Motivational Interviewing Sessions

20. Holistic Health and Wellness Programs

Core Offer: Holistic Health and Wellness Programs

The Spoken Word

1. Nutritional Counseling Sessions: Provide one-on-one sessions with nutritionists or dieticians to educate and guide individuals on healthy eating habits and nutritional support for recovery.

The Written Word:

2. Holistic Health Guides: Offer comprehensive guides or e-books covering various aspects of holistic health, including nutrition, mindfulness, fitness, and alternative therapies.

The Physical Product:

3. Holistic Health Kits: Provide curated kits containing essential items for holistic health practices, such as yoga mats, meditation cushions, essential oils, herbal teas, and healthy snacks.

The Experience:

4. Wellness Retreats: Organize immersive retreats focused on holistic healing, featuring activities like yoga, meditation, nature walks, nutritional workshops, and holistic therapy sessions.

Native Google Doc text and original links

OFFER PACKAGES
. The Spoken Word
Description: This refers to content delivered through audio or video formats.
Examples: Webinars, podcasts, audio books, video courses, and live recordings.
2. The Written Word
Description: This includes any written content that provides valuable information or education.
Examples: E-books, guides, checklists, transcripts, and printed books.
3. The Physical Product
Description: Tangible items that can be shipped to customers, adding perceived value.
Examples: Workbooks, printed manuals, physical books, merchandise, and tools.
4. The Experience
Description: Opportunities for customers to engage with you or your content in a more immersive way.
Examples: Live events, workshops, coaching sessions, masterminds, and access to exclusive groups or communities.

Adult Children of Alcoholics
Emotional Healing Program
Relationship Building Workshop
Self-Care and Mindfulness Course
Parenting Guidance for Break-the-Cycle
Stress and Anxiety Management Series
Communication Skills Training
Building Resilience Course
Setting Boundaries Workshop
Financial Stability Training
Self-Esteem and Confidence Boosting Program
Trauma Recovery Program
Assertiveness Training
Coping with Grief and Loss Workshop
Mind-Body Wellness Program
Conflict Resolution Skills Course
Forgiveness and Letting Go Workshop
Life Coaching for Personal Growth
Anger Management Training
Financial Planning and Management
Personal Empowerment Series

Core Offer: Comprehensive recovery program
The Spoken Word
Webinars: Expert-led discussions on coping strategies and emotional healing.
Podcasts: Stories and advice from individuals who have navigated similar experiences.
Video Courses: Modules covering emotional resilience, relationship building, and self-care.
Audio Books: Narrated books on understanding and overcoming the impact of parental alcoholism.
Q&A Sessions: Recorded sessions where experts answer common questions about dealing with childhood trauma.
The Written Word
E-books: Comprehensive guides on managing emotions and building healthy relationships.
Guides: Step-by-step processes for breaking dysfunctional family patterns.
Checklists: Tools for identifying and addressing inherited behavioral patterns.
Transcripts: Written versions of expert talks and therapy sessions.
Case Studies: Real-life examples of individuals who have successfully healed from their past.
The Physical Product
Workbooks: Exercises and reflections to aid in emotional healing.
Printed Books: Self-help books focusing on recovery and personal growth.
Merchandise: Journals, motivational posters, or calming candles.
Tools: Therapy kits including stress balls, mindfulness cards, and affirmation cards.
Product Samples: Samples of calming teas or aromatherapy oils.
The Experience
Live Events: Access to seminars and workshops on overcoming childhood trauma.
Workshops: Interactive sessions focusing on building self-esteem and emotional intelligence.
Coaching Sessions: Personalized coaching with a focus on recovery and personal development.
Masterminds: Group sessions with peers for shared support and accountability.
Exclusive Communities: Membership in private support groups for ongoing connection and encouragement.
2. Alcoholism
Sobriety Maintenance Program
Detoxification Support Course
Emotional Support and Therapy Program
Family Counseling and Education
Healthy Living and Nutrition Guide
Workplace Integration Program
Mental Health and Wellness Training
Relapse Prevention Strategies
Peer Support Group Access
Physical Fitness and Recovery Program
Sober Living Housing Programs
Cognitive Behavioral Therapy (CBT)
Mindfulness-Based Sobriety
Family Dynamics and Support Workshops
Nutritional Counseling and Support
Spiritual Counseling and Support
Exercise and Wellness Programs
Community Reintegration Support
Motivational Interviewing Sessions
Holistic Health and Wellness Programs

Core Offer: Alcoholism recovery program
The Spoken Word
Webinars: Educational sessions on the effects of alcoholism and recovery strategies.
Podcasts: Interviews with recovery experts and success stories.
Video Courses: Courses on understanding alcoholism and effective treatment methods.
Audio Books: Narrated recovery memoirs and self-help books.
Q&A Sessions: Live or recorded sessions with addiction specialists.
The Written Word
E-books: Comprehensive guides to understanding and overcoming alcoholism.
Guides: Step-by-step recovery plans and relapse prevention strategies.
Checklists: Tools for monitoring progress and maintaining sobriety.
Transcripts: Written content from expert talks and recovery meetings.
Case Studies: Detailed recovery journeys of individuals who overcame alcoholism.
The Physical Product
Workbooks: Exercises and reflections designed to support recovery.
Printed Books: In-depth books on alcoholism recovery and prevention.
Merchandise: Inspirational items like T-shirts, wristbands, or recovery tokens.
Tools: Sobriety tracking tools and mindfulness aids.
Product Samples: Non-alcoholic beverages or relaxation aids.
The Experience
Live Events: Tickets to conferences and seminars on addiction recovery.
Workshops: Intensive sessions focusing on sobriety skills and relapse prevention.
Coaching Sessions: Personalized coaching from addiction recovery experts.
Masterminds: Support groups with other individuals in recovery.
Exclusive Communities: Access to private forums or social groups for ongoing support.
3. Drug Dependency
Comprehensive Detox Program
Long-Term Rehabilitation Plan
Mental Health and Counseling Services
Support for Families of Addicts
Employment and Skills Training
Holistic Wellness Program
Peer Support and Accountability Groups
Life Skills and Personal Development
Crisis Intervention and Management
Educational Workshops on Addiction
Inpatient Treatment Programs
Outpatient Treatment Programs
Dual Diagnosis Treatment (for co-occurring disorders)
Relapse Triggers Identification and Management
Life Skills Training Programs
Career Counseling and Job Placement Assistance
Mindfulness and Meditation Classes
Sober Living Arrangements
Creative Arts Therapy
Stress Reduction and Relaxation Workshops

Core Offer: Drug addiction recovery program
The Spoken Word
Webinars: Expert-led sessions on drug addiction and recovery methods.
Podcasts: Stories and advice from people who have overcome drug dependency.
Video Courses: Training on understanding addiction and implementing recovery techniques.
Audio Books: Narrated guides and personal stories on drug addiction and recovery.
Q&A Sessions: Interactive sessions with addiction specialists.
The Written Word
E-books: In-depth guides on overcoming drug dependency.
Guides: Step-by-step plans for detox and rehabilitation.
Checklists: Tools for tracking recovery progress and avoiding relapse.
Transcripts: Written versions of therapy sessions and expert talks.
Case Studies: Documented success stories and recovery journeys.
The Physical Product
Workbooks: Exercises and activities to support drug recovery.
Printed Books: Comprehensive books on addiction treatment and recovery.
Merchandise: Motivational merchandise like journals or wristbands.
Tools: Drug testing kits and mindfulness aids.
Product Samples: Relaxation products like herbal teas or essential oils.
The Experience
Live Events: Access to recovery seminars and addiction workshops.
Workshops: Hands-on sessions focusing on sobriety and healthy living.
Coaching Sessions: One-on-one coaching with recovery experts.
Masterminds: Group coaching and support sessions.
Exclusive Communities: Membership in private recovery support groups.
4. Gambling
Financial Recovery and Management
Mental Health Counseling
Family and Relationship Support
Behavioral Therapy and Support
Stress Relief and Relaxation Techniques
Peer Support and Group Therapy
Self-Control and Impulse Management
Employment and Career Guidance
Healthy Lifestyle and Habits Program
Legal Advice and Support Services
Debt Management and Financial Counseling
Emotional Regulation Skills Training
Cognitive Behavioral Therapy (CBT) for Gambling
Mindfulness and Meditation for Impulse Control
Family Therapy and Support Programs
Legal Assistance and Advice
Career Counseling and Skill Building
Personal Development Workshops
Financial Literacy and Budgeting
Stress Management and Coping Skills Training

Core Offer: Gambling addiction recovery program
The Spoken Word
Webinars: Sessions on understanding and overcoming gambling addiction.
Podcasts: Interviews with recovering gamblers and addiction experts.
Video Courses: Educational videos on gambling addiction and recovery.
Audio Books: Narrated self-help books and recovery stories.
Q&A Sessions: Live or recorded sessions with gambling addiction specialists.
The Written Word
E-books: Guides on managing and overcoming gambling addiction.
Guides: Step-by-step recovery plans for gambling addicts.
Checklists: Tools for tracking gambling behavior and recovery progress.
Transcripts: Written content from webinars and therapy sessions.
Case Studies: Real-life examples of successful gambling addiction recovery.
The Physical Product
Workbooks: Activities and exercises to support gambling recovery.
Printed Books: Comprehensive books on gambling addiction treatment.
Merchandise: Inspirational items like keychains, bracelets, or recovery tokens.
Tools: Budget planners and mindfulness tools.
Product Samples: Stress relief products like fidget tools or calming teas.
The Experience
Live Events: Tickets to gambling addiction recovery seminars.
Workshops: Intensive recovery sessions and skill-building workshops.
Coaching Sessions: Personalized coaching with gambling recovery experts.
Masterminds: Group support and accountability sessions.
Exclusive Communities: Membership in private forums or social groups for gamblers in recovery.
5. Hoarding
Comprehensive Decluttering Program
Psychological Therapy and Support
Home Organization Skills Training
Family Support and Education
Self-Control and Behavioral Modification
Emergency Clean-Up Services
Mindfulness and Relaxation Techniques
Peer Support and Group Therapy
Health and Safety Education
Maintenance and Follow-Up Program
Professional Organizing Services
Virtual Decluttering Coaching
Emotional Support and Counseling
Peer Support Groups
Mindfulness Training for Anxiety Management
Cognitive Behavioral Therapy (CBT) for Hoarding
Home Safety Inspections and Recommendations
Motivational Interviewing for Behavior Change
Family Education and Support Programs
Relapse Prevention and Maintenance Programs

Core Offer: Hoarding intervention and management program
The Spoken Word
Webinars: Sessions on understanding and managing hoarding behavior.
Podcasts: Discussions with experts and personal stories from those overcoming hoarding.
Video Courses: Training on decluttering and maintaining a clutter-free lifestyle.
Audio Books: Narrated guides and personal stories about overcoming hoarding.
Q&A Sessions: Interactive sessions with hoarding specialists.
The Written Word
E-books: Guides on decluttering and managing hoarding tendencies.
Guides: Step-by-step plans for cleaning and organizing.
Checklists: Tools for tracking decluttering progress and maintaining organization.
Transcripts: Written versions of expert talks and therapy sessions.
Case Studies: Real-life examples of successful hoarding interventions.
The Physical Product
Workbooks: Exercises and activities to support decluttering efforts.
Printed Books: Comprehensive books on hoarding treatment and organization.
Merchandise: Motivational items like planners, organizers, or storage solutions.
Tools: Cleaning and organizing kits.
Product Samples: Samples of storage and organizational products.
The Experience
Live Events: Access to seminars and workshops on hoarding recovery.
Workshops: Hands-on decluttering sessions and organization workshops.
Coaching Sessions: Personalized coaching for decluttering and managing hoarding.
Masterminds: Group sessions for shared support and accountability.
Exclusive Communities: Membership in private support groups for hoarders.
6. Obsessive Compulsive Disorder (OCD)
Behavioral Therapy and Cognitive Training
Mindfulness and Stress Reduction
Family Support and Education
Medication Management and Support
Self-Help Strategies and Tools
Exposure and Response Prevention Training
Peer Support and Group Therapy
Workplace Accommodation and Support
Coping Mechanisms and Strategies
Holistic Wellness and Lifestyle Program
Dialectical Behavior Therapy (DBT)
Support Groups and Peer Networks
Virtual Therapy Sessions
Nutritional Counseling for Mental Health
Exercise Programs for Anxiety Relief
Stress Management and Relaxation Techniques
Family Education and Support Programs
Personal Development and Goal Setting
Art and Music Therapy
Sleep Hygiene and Wellness Programs

Core Offer: OCD management and treatment program
The Spoken Word
Webinars: Educational sessions on understanding and managing OCD.
Podcasts: Interviews with OCD specialists and stories from those living with OCD.
Video Courses: Modules on coping strategies and treatment methods for OCD.
Audio Books: Narrated self-help books and personal stories about OCD.
Q&A Sessions: Interactive sessions with OCD specialists.
The Written Word
E-books: Guides on understanding and treating OCD.
Guides: Step-by-step plans for managing OCD symptoms.
Checklists: Tools for tracking OCD behaviors and progress.
Transcripts: Written content from expert talks and therapy sessions.
Case Studies: Documented recovery stories and treatment successes.
The Physical Product
Workbooks: Exercises and activities designed to help manage OCD.
Printed Books: In-depth books on OCD treatment and management.
Merchandise: Inspirational items like journals, stress balls, or motivational posters.
Tools: Anxiety management kits and mindfulness tools.
Product Samples: Relaxation aids like aromatherapy oils or calming teas.
The Experience
Live Events: Tickets to OCD seminars and workshops.
Workshops: Intensive sessions focused on coping strategies and treatment techniques.
Coaching Sessions: One-on-one coaching with OCD treatment experts.
Masterminds: Group support and therapy sessions.
Exclusive Communities: Access to private forums or support groups for those with OCD.
7. Sexual Addiction
Behavioral Therapy and Cognitive Training
Relationship Counseling and Support
Self-Control and Impulse Management
Healthy Sexuality Education
Stress and Anxiety Management
Peer Support and Accountability Groups
Mindfulness and Relaxation Techniques
Crisis Management and Intervention
Family Education and Support
Long-Term Recovery and Maintenance
Trauma-Informed Therapy
Mindfulness-Based Stress Reduction
Relationship Repair and Building Workshops
Virtual Support Groups
Healthy Relationship and Communication Skills
Addiction Education and Awareness Programs
Self-Esteem and Confidence Building Workshops
Family and Partner Support Programs
Exercise and Wellness Programs
Meditation and Relaxation Techniques

Core Offer: Sexual addiction recovery program
The Spoken Word
Webinars: Sessions on understanding and treating sexual addiction.
Podcasts: Interviews with recovery experts and personal stories.
Video Courses: Educational videos on managing and overcoming sexual addiction.
Audio Books: Narrated guides and recovery stories.
Q&A Sessions: Interactive sessions with sexual addiction specialists.
The Written Word
E-books: Comprehensive guides on understanding and treating sexual addiction.
Guides: Step-by-step recovery plans.
Checklists: Tools for tracking recovery progress and maintaining sobriety.
Transcripts: Written versions of expert talks and therapy sessions.
Case Studies: Real-life recovery stories and treatment successes.
The Physical Product
Workbooks: Exercises and activities to support sexual addiction recovery.
Printed Books: Comprehensive books on treatment and recovery.
Merchandise: Motivational items like journals or wristbands.
Tools: Sobriety tracking tools and mindfulness aids.
Product Samples: Relaxation products like herbal teas or essential oils.
The Experience
Live Events: Access to recovery seminars and workshops.
Workshops: Intensive sessions focusing on sobriety and healthy living.
Coaching Sessions: Personalized coaching from sexual addiction recovery experts.
Masterminds: Group support and accountability sessions.
Exclusive Communities: Membership in private forums or support groups.
8. Tobacco
Behavioral Therapy for Smoking Cessation
Nicotine Replacement Therapy Support
Healthy Living and Nutrition Guide
Stress Management and Relaxation Techniques
Family and Peer Support
Exercise and Fitness Program
Workplace Support for Quitting
Holistic Wellness and Lifestyle Program
Mental Health Support and Counseling
Relapse Prevention Strategies
Quit Smoking Mobile Apps
Virtual Support Groups and Communities
Acupuncture for Smoking Cessation
Hypnotherapy for Smoking Cessation
Nicotine Replacement Therapy Programs
Personalized Quit Plans and Coaching
Stress Management and Coping Techniques
Nutritional Support for Recovery
Exercise and Fitness Programs
Relapse Prevention and Support Programs
Core Offer: Smoking cessation program

The Spoken Word
Webinars: Educational sessions on quitting smoking and nicotine addiction.
Podcasts: Interviews with former smokers and addiction experts.
Video Courses: Step-by-step videos on quitting smoking and staying smoke-free.
Audio Books: Narrated self-help books and personal stories about quitting smoking.
Q&A Sessions: Interactive sessions with tobacco cessation specialists.
The Written Word
E-books: Guides on quitting smoking and managing cravings.
Guides: Step-by-step plans for tobacco cessation.
Checklists: Tools for tracking quitting progress and managing withdrawal symptoms.
Transcripts: Written content from expert talks and cessation programs.
Case Studies: Success stories of individuals who quit smoking.
The Physical Product
Workbooks: Exercises and activities to support smoking cessation.
Printed Books: Comprehensive books on quitting smoking.
Merchandise: Inspirational items like stress balls or motivational posters.
Tools: Nicotine replacement therapy samples and mindfulness tools.
Product Samples: Relaxation aids like herbal teas or essential oils.
The Experience
Live Events: Access to smoking cessation seminars and workshops.
Workshops: Hands-on sessions focusing on quitting smoking and maintaining a smoke-free life.
Coaching Sessions: Personalized coaching for tobacco cessation.
Masterminds: Group support and accountability sessions.
Exclusive Communities: Membership in private forums or support groups for former smokers.
9. Twelve-Step Programs
Comprehensive Step-by-Step Guide
Peer Support and Accountability Groups
Family Education and Support
Mental Health and Wellness Training
Healthy Living and Nutrition Guide
Behavioral Therapy and Cognitive Training
Stress Management and Relaxation Techniques
Self-Esteem and Confidence Building
Employment and Skills Training
Relapse Prevention and Maintenance Program
Online Twelve-Step Meetings
Step Study Groups
Spiritual Growth and Development Workshops
Service and Volunteer Opportunities
Twelve-Step Retreats and Conferences
Meditation and Mindfulness Training
Sponsorship Training and Support
Literature and Study Materials
Relapse Prevention and Maintenance Programs
Emotional Sobriety Workshops

Core Offer: Twelve-step recovery program
The Spoken Word
Webinars: Sessions on the principles and practices of twelve-step programs.
Podcasts: Interviews with twelve-step program participants and recovery stories.
Video Courses: Educational videos on the twelve-step process.
Audio Books: Narrated guides and personal stories about twelve-step recovery.
Q&A Sessions: Interactive sessions with twelve-step program facilitators.
The Written Word
E-books: Guides on the twelve-step program and its application.
Guides: Step-by-step plans for each of the twelve steps.
Checklists: Tools for tracking progress through the twelve steps.
Transcripts: Written content from expert talks and program meetings.
Case Studies: Success stories of individuals who completed the twelve-step program.
The Physical Product
Workbooks: Exercises and activities for each step of the program.
Printed Books: Comprehensive books on twelve-step recovery.
Merchandise: Inspirational items like journals or recovery tokens.
Tools: Sobriety chips and mindfulness aids.
Product Samples: Relaxation aids like herbal teas or essential oils.
The Experience
Live Events: Access to twelve-step program seminars and workshops.
Workshops: Intensive sessions focusing on each step of the program.
Coaching Sessions: Personalized coaching from twelve-step program facilitators.
Masterminds: Group support and accountability sessions.
Exclusive Communities: Membership in private forums or support groups for twelve-step program participants.
2. Alcoholism
Sobriety Maintenance Program
Detoxification Support Course
Emotional Support and Therapy Program
Family Counseling and Education
Healthy Living and Nutrition Guide
Workplace Integration Program
Mental Health and Wellness Training
Relapse Prevention Strategies
Peer Support Group Access
Physical Fitness and Recovery Program
Sober Living Housing Programs
Cognitive Behavioral Therapy (CBT)
Mindfulness-Based Sobriety
Family Dynamics and Support Workshops
Nutritional Counseling and Support
Spiritual Counseling and Support
Exercise and Wellness Programs
Community Reintegration Support
Motivational Interviewing Sessions
Holistic Health and Wellness Programs
Core Offer: Holistic Health and Wellness Programs
The Spoken Word
Nutritional Counseling Sessions: Provide one-on-one sessions with nutritionists or dieticians to educate and guide individuals on healthy eating habits and nutritional support for recovery.
The Written Word:
2. Holistic Health Guides: Offer comprehensive guides or e-books covering various aspects of holistic health, including nutrition, mindfulness, fitness, and alternative therapies.
The Physical Product:
3. Holistic Health Kits: Provide curated kits containing essential items for holistic health practices, such as yoga mats, meditation cushions, essential oils, herbal teas, and healthy snacks.
The Experience:
4. Wellness Retreats: Organize immersive retreats focused on holistic healing, featuring activities like yoga, meditation, nature walks, nutritional workshops, and holistic therapy sessions.

offer-architecture-validator-v1.0.0.yaml

Validate integration rather than attachment count alone

The M7.8 prompt proposes a capstone validator for seven attachments: distinction statement, deliverable decomposition, SOP library, lifecycle map, capacity analysis with human sign-off, bandwidth audit with human sign-off, and offer v2 with cohort/instructor review. It says thirteen sections but describes sections 0–10, eleven numbered sections. Preserve this discrepancy and resolve the missing section specification before declaring completeness. A model name and 10–25-minute estimate do not prove deployment or a completed review.

Trace the three cross-document failure patterns

Check that deliverable IDs lead to SOPs and lifecycle stages; that capacity figures, bottlenecks and per-customer hours agree across analysis, audit and offer; and that the structure is not overfitted to the first one to three customers. Compare actual values and references, not just similar prose. A four-customer ceiling needs supporting bottleneck math and representative hours. Link every mismatch to both conflicting records.

Attestation 1 — distinction maintained

For this clause, cite a specific attachment and location, assess whether evidence is present/partial/absent, check cross-references and record pass/revision/fail with notes. A signature alone cannot establish distinction maintained. Section 9 consistency and Section 10 self-check must agree with the external findings; discrepancies become a self-check reliability issue.

Attestation 2 — decomposition atomic

For this clause, cite a specific attachment and location, assess whether evidence is present/partial/absent, check cross-references and record pass/revision/fail with notes. A signature alone cannot establish decomposition atomic. Section 9 consistency and Section 10 self-check must agree with the external findings; discrepancies become a self-check reliability issue.

Attestation 3 — capacity honest

For this clause, cite a specific attachment and location, assess whether evidence is present/partial/absent, check cross-references and record pass/revision/fail with notes. A signature alone cannot establish capacity honest. Section 9 consistency and Section 10 self-check must agree with the external findings; discrepancies become a self-check reliability issue.

Attestation 4 — v2 architectural rather than a hidden pivot

For this clause, cite a specific attachment and location, assess whether evidence is present/partial/absent, check cross-references and record pass/revision/fail with notes. A signature alone cannot establish v2 architectural rather than a hidden pivot. Section 9 consistency and Section 10 self-check must agree with the external findings; discrepancies become a self-check reliability issue.

Attestation 5 — SOPs operable

For this clause, cite a specific attachment and location, assess whether evidence is present/partial/absent, check cross-references and record pass/revision/fail with notes. A signature alone cannot establish SOPs operable. Section 9 consistency and Section 10 self-check must agree with the external findings; discrepancies become a self-check reliability issue.

Attestation 6 — iteration discipline maintained

For this clause, cite a specific attachment and location, assess whether evidence is present/partial/absent, check cross-references and record pass/revision/fail with notes. A signature alone cannot establish iteration discipline maintained. Section 9 consistency and Section 10 self-check must agree with the external findings; discrepancies become a self-check reliability issue.

Attestation 7 — human review gates cleared

For this clause, cite a specific attachment and location, assess whether evidence is present/partial/absent, check cross-references and record pass/revision/fail with notes. A signature alone cannot establish human review gates cleared. Section 9 consistency and Section 10 self-check must agree with the external findings; discrepancies become a self-check reliability issue.

Attestation 8 — honest customer representation continued

For this clause, cite a specific attachment and location, assess whether evidence is present/partial/absent, check cross-references and record pass/revision/fail with notes. A signature alone cannot establish honest customer representation continued. Section 9 consistency and Section 10 self-check must agree with the external findings; discrepancies become a self-check reliability issue.

Read all twelve bespoke indicators

The linked checklist groups indicators into lifecycle L1 specific-customer stage names, L2 external-outcome gates and L3 missing off-path cases; deliverables D1 customer-specific tooling names, D2 more than 20% count variation and D3 time averages without variance; SOPs S1 customer names, S2 one customer’s channel assumptions and S3 identifying examples; capacity C1 average hours without range, C2 assumed identical profiles and C3 customer-specific quality signals. These are flags requiring context, not universal proof that a specialized offer is defective.

Separate the universal structure from bounded customization

Keep deliverable acceptance, SOP sequence, stage purpose and bottleneck-based ceiling in the shared architecture. Parameterize customer examples, preferred channels, cadence and measured variance. The checklist proposes three to five off-path scenarios, one or two example variations, high-end or 75th-percentile hours and a customization budget such as two hours or one variation. Define how the 20% count-variation statistic is calculated; the source does not specify its denominator.

Recover and rescore before deployment

The checklist proposes holding deployment, separating common/customer-specific elements, revising decomposition/SOP/lifecycle/capacity, defining a budget, testing founding-like/moderately different/stretch customers, then resubmitting a versioned rebuild. It scores 0–2 indicators as proceed with documentation, 3–5 as revise, and six or more as rebuild. Its 30–45-minute estimate is planning guidance. Hypothetical tests complement rather than replace actual operating evidence.

Apply the ten honest-capacity commitments

Use at least fourteen calendar days of representative measured hours; include hidden administration/rework/follow-up; name a numeric concurrent ceiling; define quality thresholds and a two-threshold ceiling event; identify the bottleneck; do not inflate capacity to repair pricing; obtain actual human review; investigate more than 15% hours drift within ninety days; use a waitlist instead of redefining capacity under demand pressure; and maintain the discipline as teams/products change. These are source policies, not a guarantee that fourteen days fully captures seasonality or rare failures.

Specify the validator’s structured findings

The proposed output records document status; eight clause evidence/presence/cross-reference/status/notes records; pattern-one reference failures and severity; pattern-two conflicting values and severity; pattern-three codes, rationales, count and threshold; completeness/sign-off fields; self-check agreement and missed issues; a three-to-five-sentence summary; recommended action; and instructor notes. Define actual JSON types and enums instead of copying prose alternatives as runnable JSON.

Resolve incomplete decision logic before automating it

Validated requires all clauses/evidence, no integration/capacity mismatch, at most two bespoke flags, seven attachments and human sign-offs, with consistent self-checks. Revision describes one or two clause issues, low/medium integration issues, low capacity mismatch, three-to-five flags or unclear sign-offs. Rejection describes three-plus substantive clauses, severe mismatch, six-plus flags, multiple missing sign-offs or major rebuild. The lists do not specify AND/OR precedence or every missing-data/medium-capacity case. Define a conservative, explicit decision table; never infer clearance from an unhandled state.

Keep structural validation separate from enrollment approval

VALIDATED routes to mandatory instructor co-sign, which authorizes C8. Revision normally returns findings to the learner with optional instructor involvement; rejection returns module rebuild recommendations. Record the actual reviewer, version and decision. The named database path and output-contract text do not create an enrollment gate, and a regulatory tone does not confer regulatory authority.

Connect the lesson to the direct-marketing promise

Complete original source text

name: offer-architecture-validator
version: 1.0.0
module: M7.8
course: C7 Offer Architecture
model: claude-opus-4-7
role: Capstone validator
review_type: Multi-document cross-referenced validation with HITL handoff

description: |
  Validates the C7 Offer Architecture Document. This is the Opus 4.7
  model rather than Sonnet because the validation requires multi-document
  cross-referencing across 7 attachments (M7.1-M7.7), each with their own
  evidence artifacts, and the validator must detect three failure patterns
  that span documents:
    1. Decomposition without integration
    2. Capacity-claim mismatch
    3. Bespoke architecture indicators

  This validator gates C8 enrollment. Its outputs are forwarded to the
  instructor for human co-sign. A VALIDATED outcome does not constitute
  approval — it constitutes "structural floor cleared, ready for instructor
  co-sign." The instructor co-sign is what authorizes C8 enrollment.

model_string: claude-opus-4-7

system_prompt: |
  You are the Offer Architecture Validator for C7 Module 7.8. You are
  validating a student-submitted Offer Architecture Document, which is
  the capstone artifact of the C7 Offer Architecture course.

  The document has thirteen sections plus seven attachments:
    Attachment 1 — M7.1 Distinction Statement
    Attachment 2 — M7.2 Deliverable Decomposition
    Attachment 3 — M7.3 Fulfillment SOP Library
    Attachment 4 — M7.4 Customer Lifecycle Map
    Attachment 5 — M7.5 Capacity Constraint Analysis (with HITL sign-off)
    Attachment 6 — M7.6 Operator Bandwidth Audit (with HITL sign-off)
    Attachment 7 — M7.7 Offer v2.0 Document (with cohort + instructor sign-offs)

  Your job is to detect three failure patterns:

  FAILURE PATTERN 1 — Decomposition without integration:
    The student has produced the seven attachments, but the attachments
    do not refer to each other. The deliverables in Attachment 2 are not
    cited by the SOPs in Attachment 3. The lifecycle stages in Attachment
    4 do not reference the deliverables from Attachment 2. The capacity
    analysis in Attachment 5 uses a per-customer figure that does not
    match the audit in Attachment 6. The Offer v2.0 in Attachment 7
    states a ceiling that does not match Attachment 5.

    You detect this by cross-referencing artifacts against each other.
    Each attachment should be observably tied to the others.

  FAILURE PATTERN 2 — Capacity-claim mismatch:
    The capacity claim in the Offer v2.0 (Attachment 7, Section 6) does
    not match the capacity analysis in Attachment 5. Or: the capacity
    analysis in Attachment 5 uses a per-customer figure that does not
    match the audit in Attachment 6. Or: the bottleneck identification
    is inconsistent across Attachments 5 and 6. Or: the anti-promise list
    in Attachment 7 does not include the waitlist + 15% drift trigger
    anti-promises that the C7 Honest Capacity Clause requires.

    You detect this by reading the specific numbers in each attachment
    and confirming they match. A capacity claim of "4 concurrent
    customers" must be supported by bottleneck math in Attachment 5
    that produces 4, supported by per-customer hours in Attachment 6
    that the bottleneck math uses correctly.

  FAILURE PATTERN 3 — Bespoke architecture indicators:
    The architecture is over-fitted to the founding 1-3 customers. You
    apply the 12-indicator scan from the C7 Bespoke Architecture Trap
    Recognition Checklist:
      - L-1 through L-3 (Lifecycle over-fitting indicators)
      - D-1 through D-3 (Deliverable over-fitting indicators)
      - S-1 through S-3 (SOP over-fitting indicators)
      - C-1 through C-3 (Capacity over-fitting indicators)
    You count indicators fired and apply the threshold:
      - 0-2 fired: architecture largely universal; proceed
      - 3-5 fired: bespoke contamination; NEEDS_REVISION
      - 6+ fired: substantially bespoke; REJECTED

  You also evaluate Section 0 attestation clauses:
    Clause 1 — Distinction maintained
    Clause 2 — Decomposition is atomic
    Clause 3 — Capacity is honest
    Clause 4 — v2.0 is architectural
    Clause 5 — SOPs are operable
    Clause 6 — Iteration discipline endures
    Clause 7 — HITL gates cleared
    Clause 8 — Honest customer representation continues

  Each clause should be supported by the attached evidence. A signed
  attestation without supporting evidence is a Pattern 1 failure.

  You also verify that the operator's Section 9 internal consistency
  check and Section 10 Bespoke Architecture self-check are documented
  and clean. If the operator's self-checks are clean but your validation
  reveals issues the operator did not catch, flag this as a self-check
  reliability concern.

  Output a structured JSON response with these fields:

    document_status: VALIDATED | NEEDS_REVISION | REJECTED
    attestation_clause_findings:
      - clause: 1
        evidence_pointer_quality: specific / vague / missing
        supporting_evidence_present: yes / partial / absent
        cross_reference_check: pass / partial / fail
        clause_status: pass / needs_revision / fail
        notes: array
      [repeat for clauses 2-8]
    failure_pattern_1_decomposition_without_integration:
      pattern_detected: yes / no
      cross_reference_failures: array, each citing the source attachment and the missing reference
      severity: low / medium / high
    failure_pattern_2_capacity_claim_mismatch:
      pattern_detected: yes / no
      mismatches_found: array, each citing the conflicting values and source attachments
      severity: low / medium / high
    failure_pattern_3_bespoke_architecture:
      indicators_fired: array of indicator codes (L-1, D-2, etc.) with brief rationale
      total_fired: integer
      severity_threshold: 0-2 / 3-5 / 6+
    section_completeness:
      section_0_attestation_signed: yes / no
      section_1_executive_summary_present: yes / partial / no
      sections_2_8_summarize_attachments: yes / partial / no
      section_9_internal_consistency_check_clean: yes / unclear / not_clean
      section_10_bespoke_self_check_clean: yes / unclear / not_clean
      attachments_1_through_7_present: yes / partial / no
      hitl_signoffs_present: yes / partial / no
    self_check_reliability:
      operator_self_checks_align_with_validator_findings: yes / partial / no
      additional_issues_validator_found_that_operator_did_not_flag: array
    overall_validator_summary: 3-5 sentence summary
    recommended_action: PROCEED_TO_INSTRUCTOR_COSIGN | RETURN_TO_STUDENT_WITH_FINDINGS | REJECT_AND_RETURN_TO_MODULE
    instructor_handoff_notes: array of items the instructor should pay attention to

  Tone: precise, formal, careful. This is the gating artifact for C8
  enrollment. Treat it with appropriate gravity. Address the operator
  as "you" but maintain a regulatory rather than coaching tone. Do not
  soften findings; flag clearly. The instructor is the human co-sign;
  your job is to ensure the structural floor is clean before the
  instructor reviews.

decision_thresholds:
  VALIDATED:
    - All 8 attestation clauses pass
    - Failure Pattern 1: not detected
    - Failure Pattern 2: not detected
    - Failure Pattern 3: 0-2 indicators fired
    - All seven attachments present and HITL sign-offs documented
    - Section 9 and Section 10 self-checks clean and align with validator findings
    - Recommended action: PROCEED_TO_INSTRUCTOR_COSIGN
  NEEDS_REVISION:
    - 1-2 clauses have issues (vague evidence, weak cross-reference)
    - Failure Pattern 1: detected with low or medium severity
    - Failure Pattern 2: detected with low severity (single mismatch correctable)
    - Failure Pattern 3: 3-5 indicators fired
    - HITL sign-offs partial or unclear
    - Issues addressable by operator without restarting modules
    - Recommended action: RETURN_TO_STUDENT_WITH_FINDINGS
  REJECTED:
    - 3+ clauses have substantive issues
    - Failure Pattern 1: detected with high severity (artifacts in isolation)
    - Failure Pattern 2: detected with high severity (capacity claim diverges from audit)
    - Failure Pattern 3: 6+ indicators fired (substantially bespoke architecture)
    - Multiple HITL sign-offs missing
    - Major rebuild required at the M7.2, M7.5, or M7.7 module level
    - Recommended action: REJECT_AND_RETURN_TO_MODULE

instructor_handoff:
  - Always required if VALIDATED (instructor co-sign authorizes C8 enrollment)
  - Optional for NEEDS_REVISION (typically returns to student first)
  - Not required for REJECTED (returns directly to student with module rebuild recommendations)

submission_path: c7_offer_architecture_documents
output_format: JSON with the structure specified in system_prompt
expected_response_time: 10-25 minutes (multi-document cross-referencing)

Complete supporting source — Honest capacity clause

# C7 Honest Capacity Clause

**Course:** C7 Offer Architecture
**Document Type:** Clause document — referenced in capacity analysis (M7.5), Offer v2.0 (M7.7), and Offer Architecture Document attestation (M7.8)
**Length:** 1 page

---

## Statement

In all capacity claims, customer commitments, and offer-architecture work undertaken during and after C7, I commit to the following discipline:

**1. Capacity is measured, not aspirational.** The concurrent-customer ceiling stated in my Offer v2.0 derives from observed time-tracking data collected during M7.6 Bandwidth Audit, not from projected efficiency, anticipated improvements, or what I think I should be able to handle. The ceiling is anchored to hours-per-customer figures recorded under representative working conditions over a measurement window of at least 14 calendar days.

**2. Capacity is honest about hidden costs.** The hours-per-customer figure includes administrative overhead, follow-up time, scope-creep recovery, customer-driven rework, and the time spent on activities the offer does not name but the customer expects. I do not present a stripped-down delivery-only number as the operational hours-per-customer figure.

**3. Capacity has named ceilings.** I state a maximum concurrent-customer count in numeric form. I do not state capacity in vague language ("a few clients at a time," "the right number for me"). The number is testable: at this count, quality is preserved; above it, quality degrades.

**4. Capacity has named quality thresholds.** I name the operational signals that indicate I am at or above ceiling: response-time degradation past a stated threshold, error or rework rates rising past a stated threshold, deliverable-quality slippage past a stated threshold, or operator-burnout indicators. When two or more thresholds are crossed concurrently, I treat that as a ceiling event, not a temporary anomaly.

**5. Capacity is bounded by operator constraints.** I name the operator-level bottleneck — the activity that limits concurrent capacity (e.g., synchronous review hours, deep-work blocks for production, customer-facing communication time). The ceiling is set by this bottleneck, not by the most expansive view of available time.

**6. Capacity is not pricing leverage.** I do not raise the stated ceiling in order to justify a lower per-customer price or a higher revenue projection. If my pricing model assumes higher concurrency than my honest ceiling supports, I revise the pricing model in C8, not the ceiling.

**7. Capacity is reviewed.** Capacity claims in my Offer v2.0 receive mandatory HITL review by my instructor at M7.5. The review examines the time-tracking source data, the bottleneck identification, and the ceiling math. I do not deploy a v2.0 offer with capacity claims my instructor has not cleared.

**8. Capacity claims are revised when measurement contradicts them.** If, in the 90 days after Offer v2.0 deployment, my time-tracking continues and reveals that the actual hours-per-customer figure exceeds the figure stated at v2.0 by more than 15%, I treat this as a v2.1 trigger and revise the offer ceiling. I do not silently absorb the gap.

**9. Capacity is independent of demand pressure.** I will not raise the stated ceiling because demand exceeds it. Excess demand is a signal for waitlist construction (in C8 or later), not a signal to redefine the ceiling.

**10. Discipline endures.** This discipline applies through C7, C8, and into the higher stages of operator scaling. The structures may evolve (capacity-by-product-line, capacity-by-team-member, etc.), but the core discipline — measured, named, bottleneck-bounded capacity — endures.

---

## Signature

I have read this clause and commit to its terms in all capacity claims and offer-architecture work undertaken during and after C7.

**Signature:** ___________________________
**Date:** ___________________________

---

*This document is referenced at M7.5 capacity finalization, M7.7 Offer v2.0 production, and M7.8 attestation Clause 3. A signed copy is filed with your Offer Architecture Document.*

Complete supporting source — Bespoke architecture checklist

# C7 Bespoke Architecture Trap Recognition Checklist

**Course:** C7 Offer Architecture
**Module:** Cross-cutting; primary reference at M7.8 self-check
**Document Type:** Diagnostic checklist
**Length:** 3-4 pages

---

## Purpose

The Bespoke Architecture Trap is the C7 failure case. It occurs when an operator over-fits the offer architecture to the first 1-3 customers — encoding their specific needs, accommodations, and circumstances as universal architectural elements. The result is an "architecture" that scales only to identical customers and degrades or fails for customers who differ from the original cohort.

This checklist is a recognition tool. It is run twice during C7: at M7.4 lifecycle map review (to catch lifecycle-stage over-fitting) and at M7.8 capstone self-check (to catch decomposition, SOP, and capacity over-fitting before Opus validation).

The trap is subtle. Operators who fall into it usually do not recognize they have done so until a fourth or fifth customer enrolls and their experience diverges materially from the v1.x cohort.

---

## Part 1: The Trap Pattern

The trap follows a recognizable trajectory:

1. The operator's first 1-3 customers (the "founding cohort") are served. The customers are individuals with specific contexts, needs, and accommodations.
2. The operator iterates the offer in response to founding-cohort feedback, refining deliverables, sessions, and processes around the founding cohort's needs.
3. In C7, the operator decomposes deliverables, authors SOPs, and maps the lifecycle. The decomposition, SOPs, and map encode the founding-cohort experience as the architecture.
4. The architecture is internally consistent and well-documented. It looks complete.
5. Customer 4 enrolls. Customer 4 differs from the founding cohort in some operationally significant way (different industry, different starting point, different time zone, different team structure, different urgency level).
6. The architecture does not fit Customer 4. The operator either accommodates Customer 4 (returning to bespoke delivery) or fails Customer 4 (stranding them in a structure built for someone else).

The trap is hardest to detect at step 4, when the architecture looks complete. By step 6, the trap is no longer detectable — it is being suffered.

---

## Part 2: Recognition Indicators (Lifecycle-Stage Over-Fitting)

Apply at M7.4 lifecycle map review.

### Indicator L-1: Stage Names Reference Specific Customer Activities

**Red flag:** A lifecycle stage is named after a specific activity from the founding cohort (e.g., "Acme Co Implementation Phase," "Series B Readiness Sprint" when the offer is not exclusively about Series B).

**Healthy pattern:** Stage names are role-shaped and customer-agnostic ("Onboarding," "Core Delivery," "Mid-Engagement Check-In").

### Indicator L-2: Gate Criteria Reference Specific Customer Outcomes

**Red flag:** A transition gate criterion reads "customer has signed the licensing deal" or "customer has closed Series A." These are outcome-criteria, and outcomes vary by customer; they cannot be universal gate criteria.

**Healthy pattern:** Gate criteria reference deliverable completion, not external outcome achievement. "Customer has produced the deal-prep kit" is healthy. "Customer has signed a licensing deal" is bespoke.

### Indicator L-3: Off-Path Scenarios Are Underdocumented

**Red flag:** The lifecycle map documents 0-1 off-path scenarios. The founding cohort happened to follow the standard path, so the operator has no model for divergence.

**Healthy pattern:** 3-5 off-path scenarios are documented, each with operator response and re-entry path.

---

## Part 3: Recognition Indicators (Deliverable Over-Fitting)

Apply at M7.2 review and again at M7.8 self-check.

### Indicator D-1: Deliverables Named After Customer-Specific Tools or Frameworks

**Red flag:** A deliverable is named after a tool or framework specific to the founding cohort's industry or context (e.g., "Salesforce CRM Integration Plan" when the offer is not Salesforce-specific).

**Healthy pattern:** Deliverables are named generically ("CRM Integration Plan") and the customer-specific tool is a parameter inside the deliverable, not the deliverable name.

### Indicator D-2: Deliverable Counts Vary by More Than 20% Across Founding Cohort

**Red flag:** Customer A received 22 deliverables. Customer B received 28 deliverables. Customer C received 18 deliverables. The variance reveals that the architecture is improvising per-customer.

**Healthy pattern:** Customers receive the same deliverables. Variance is within a bounded customization budget (e.g., 1-2 customer-specific examples within a generic deliverable).

### Indicator D-3: Deliverable Time Estimates Reflect Founding-Cohort Averages, Not Variance

**Red flag:** Time estimates are based on founding-cohort averages with no consideration of the variance across customers.

**Healthy pattern:** Time estimates include a variance band, and the capacity ceiling accounts for the high-end of the band.

---

## Part 4: Recognition Indicators (SOP Over-Fitting)

Apply at M7.3 review.

### Indicator S-1: SOPs Named After Specific Past Customers

**Red flag:** An SOP filename or title contains a customer name or initials ("Maya-Style Sketch Review," "C-02 Onboarding Playbook").

**Healthy pattern:** SOPs are named generically ("Sketch Review SOP," "Customer Onboarding Playbook").

### Indicator S-2: SOP Steps Reference Customer-Specific Communication Channels or Tools

**Red flag:** An SOP step reads "Send the deliverable via Slack" when only one customer used Slack and other customers prefer email.

**Healthy pattern:** SOP steps reference channel categories ("Send via the customer's preferred async channel, recorded in the customer record").

### Indicator S-3: SOPs Have Customer-Specific Embedded Examples

**Red flag:** An SOP contains the founding cohort's actual deliverables as illustrative examples, with customer-identifying details intact.

**Healthy pattern:** Examples are anonymized or are composite/illustrative rather than from a real customer.

---

## Part 5: Recognition Indicators (Capacity Over-Fitting)

Apply at M7.5 review.

### Indicator C-1: Per-Customer Hours Reflect Founding-Cohort Average Without Variance

**Red flag:** The capacity claim derives from "my customers take 14 hours each" with no acknowledgment that the founding cohort showed a 9-19 hour range.

**Healthy pattern:** The capacity claim uses the high-end or 75th-percentile per-customer hours figure, accounting for variance.

### Indicator C-2: Capacity Math Assumes Customer Profiles Match Founding Cohort

**Red flag:** The bottleneck math is correct only if Customer 4, 5, 6 have the same starting point, urgency, and tooling as Customers 1, 2, 3.

**Healthy pattern:** The capacity math holds across the customer profile range named in the C2 customer definition, including variants the founding cohort did not exhibit.

### Indicator C-3: Quality Thresholds Are Calibrated to Founding-Cohort Behavior

**Red flag:** Quality thresholds reference behaviors specific to the founding cohort ("customers stop replying within 24 hours when they're behind").

**Healthy pattern:** Quality thresholds reference operator-side signals (response time, deep-work blocks missed, revision rounds).

---

## Part 6: Universal-vs-Customer-Specific Separation

When indicators fire, the recovery action is to **separate** universal architecture elements from customer-specific accommodations:

| Architecture Element | Universal | Customer-Specific |
|---------------------|-----------|-------------------|
| Deliverable specification | What the deliverable is, what passes/fails | Specific examples, customer-context references |
| SOP structure | Steps, sequence, time, executor | Communication channel, customer naming conventions |
| Lifecycle stage | Stage purpose, gate criterion | Stage-specific accommodations, customer-decided cadence |
| Capacity ceiling | The ceiling number, the bottleneck activity | Customer-driven variance band |

The universal elements go into the v2.0 architecture. The customer-specific elements go into a **customization budget** that is bounded and named in the v2.0 offer document.

---

## Part 7: Bespoke Architecture Trap Recovery

When the trap is detected (typically at M7.8 self-check or at Opus validator review), recovery follows:

**1. Halt v2.0 deployment.** Do not deploy a v2.0 architecture that has fired multiple bespoke indicators.

**2. Identify universal vs customer-specific.** Walk the architecture and apply the separation table from Part 6.

**3. Rebuild the universal architecture.** Revise the M7.2 decomposition, M7.3 SOP library, M7.4 lifecycle map, and M7.5 capacity analysis to reflect only the universal elements.

**4. Define the customization budget.** State the bounded customization budget in v2.0 (e.g., "up to 2 hours per customer for industry-specific example development" or "up to 1 customer-specific deliverable variation").

**5. Re-test against the 3-Customer Test.** Construct three hypothetical customers — one matching the founding cohort, one moderately different, one stretch profile — and apply the 3-Customer Test from M7.1.

**6. Resubmit to Opus validator.** A revised v2.0, with universal-vs-customer-specific separation, returns to the validator. The version is v2.1 (incremental architecture revision) or v2.0-rebuild, depending on the depth of revision.

---

## Part 8: Self-Check Score

After applying indicators L-1 through C-3:

| Indicator Set | Indicators Fired (out of 3) |
|---------------|------------------------------|
| Lifecycle (L-1, L-2, L-3) | |
| Deliverables (D-1, D-2, D-3) | |
| SOPs (S-1, S-2, S-3) | |
| Capacity (C-1, C-2, C-3) | |
| **Total fired (out of 12)** | |

**0-2 fired:** Architecture is largely universal. Document any minor customer-specific elements in the customization budget. Proceed to Opus validation.

**3-5 fired:** Architecture has bespoke contamination. Apply Part 6 separation, revise affected attachments, then resubmit to operator self-check before Opus validation.

**6+ fired:** Architecture is substantially bespoke. Recovery follows Part 7 fully. v2.0 deployment is halted until rebuild is complete.

---

*This checklist is referenced at M7.4 (after lifecycle map draft), at M7.8 self-check (Section 10 of the Offer Architecture Document Template), and is one of the three failure patterns the Opus 4.7 validator scans for.*

*Estimated application time: 30-45 minutes per pass.*

OP-05 — Economics Truth Enforcer — Custom GPT System Message

Collect the five economics inputs

The OP-05 prompt requests offer pricing/costs, conversion assumptions, traffic costs where relevant, support/delivery load and retention assumptions. Identify the time period and evidence for each. Missing inputs create an unresolved model, not invented zeros. The source’s stop instruction is a behavior specification for its proposed operator; it does not halt unrelated curriculum work.

Build the economics truth table with consistent units

RISER application: define AOV as revenue per order, CAC as included acquisition spend per acquired customer, and distinguish revenue LTV from contribution LTV after delivery/support. Show realized versus assumed retention and the cohort/time window. Payback compares acquisition cost with cumulative contribution over time, not revenue alone. Separate cash burn from accounting profit and one-time build cost from recurring delivery cost.

Test break-even and sensitivity before scaling

For a simple constant-unit model, contribution per unit equals net unit revenue minus variable costs, and break-even volume equals fixed costs divided by positive contribution per unit. If contribution is zero or negative, that formula cannot produce a viable positive break-even volume. Stress-test conversion, retention, support load and cost together; define the scenarios. A model with optimistic inputs is not scale authorization.

Deliver all four outputs and one controlled test

Produce a labeled truth table, break-even/burn analysis, specific pricing/offer-stack/retention improvement hypotheses, and a scale status with reasons. Rank suspected causes by evidence and impact; do not invent probability scores. Test one controlled change at a time where feasible. Escalate missing prerequisites or unstable economics/delivery to the founder with the issue and next step. The prompt’s completion phrase is appropriate only after its actual output contract is delivered; no GPT has been deployed by this lesson.

Connect the lesson to the direct-marketing promise

Complete original source text

OP-05 — Economics Truth Enforcer

RISER Nation | Custom GPT System Message (Production-Ready)

ROLE

You are OP-05 — Economics Truth Enforcer. Forces unit economics truth (AOV/LTV/CAC/payback/margins) and blocks scaling until the math and delivery reality are stable. You are an operator, not a hype machine.

OPERATING CONTEXT

• This operator must follow RISER sequence gates. No skipping prerequisites.

• If required inputs are missing, you must STOP and request them before producing outputs.

• Your outputs must be copy/paste-ready for a founder or VA to execute.

PRIMARY OBJECTIVE

You must:

• Economics truth table

• Break-even + burn rate logic

• Levers to improve (pricing/stack/retention)

• Scale authorization status

REQUIRED INPUTS (CONFIRM FIRST)

• Offer pricing + costs

• Conversion assumptions

• Traffic costs (if any)

• Support/delivery load

• Retention assumptions

CORE OUTPUTS (YOU MUST PRODUCE ALL)

• Economics truth table

• Break-even + burn rate logic

• Levers to improve (pricing/stack/retention)

• Scale authorization status

QUALITY RULES (NON-NEGOTIABLE)

• Assumptions are explicit

• Sensitivity checks exist

• No scaling without margin-after-support

• No manipulation. No shame. No pressure.

• Calm authority. Truth-first. Proof-first.

DIAGNOSTICS (WHAT IT MEANS WHEN IT BREAKS)

If performance degrades, you must diagnose before prescribing.

• Identify likely root causes.

• Rank causes by probability and impact.

• Recommend ONE controlled test at a time.

ESCALATION LOGIC

Trigger an escalation when:

• A prerequisite is missing but execution is being requested anyway.

• Economics, culture, compliance, or delivery stability is at risk.

Use explicit language: “RISER escalation triggered: [reason].”

HANDOFF

Owner: Founder

• Deliver outputs as labeled sections.

• Include a final ‘Next Step’ directive aligned to RISER sequence.

TONE

Calm, precise, protective, execution-focused, buyer-respectful.

When complete, end with: “OP-05 complete. Output contract delivered.”

NOTES

This operator protects you from ‘growing into bankruptcy.’

Native Google Doc text and original links

Control separators are labeled in this readable display. Download exact original text

OP-05 — Economics Truth Enforcer
[Source control separator U+000B]
RISER Nation | Custom GPT System Message (Production-Ready)
ROLE
You are OP-05 — Economics Truth Enforcer. Forces unit economics truth (AOV/LTV/CAC/payback/margins) and blocks scaling until the math and delivery reality are stable. You are an operator, not a hype machine.
OPERATING CONTEXT
• This operator must follow RISER sequence gates. No skipping prerequisites.
• If required inputs are missing, you must STOP and request them before producing outputs.
• Your outputs must be copy/paste-ready for a founder or VA to execute.
PRIMARY OBJECTIVE
You must:
• Economics truth table
• Break-even + burn rate logic
• Levers to improve (pricing/stack/retention)
• Scale authorization status
REQUIRED INPUTS (CONFIRM FIRST)
• Offer pricing + costs
• Conversion assumptions
• Traffic costs (if any)
• Support/delivery load
• Retention assumptions
CORE OUTPUTS (YOU MUST PRODUCE ALL)
• Economics truth table
• Break-even + burn rate logic
• Levers to improve (pricing/stack/retention)
• Scale authorization status
QUALITY RULES (NON-NEGOTIABLE)
• Assumptions are explicit
• Sensitivity checks exist
• No scaling without margin-after-support
• No manipulation. No shame. No pressure.
• Calm authority. Truth-first. Proof-first.
DIAGNOSTICS (WHAT IT MEANS WHEN IT BREAKS)
If performance degrades, you must diagnose before prescribing.
• Identify likely root causes.
• Rank causes by probability and impact.
• Recommend ONE controlled test at a time.
ESCALATION LOGIC
Trigger an escalation when:
• A prerequisite is missing but execution is being requested anyway.
• Economics, culture, compliance, or delivery stability is at risk.
Use explicit language: “RISER escalation triggered: [reason].”
HANDOFF
Owner: Founder
• Deliver outputs as labeled sections.
• Include a final ‘Next Step’ directive aligned to RISER sequence.
TONE
Calm, precise, protective, execution-focused, buyer-respectful.
CLOSE
When complete, end with: “OP-05 complete. Output contract delivered.”
NOTES
This operator protects you from ‘growing into bankruptcy.’

OP-28 — Delivery Optimization Engine

Start optimization from a stable baseline

OP-28 assumes validated economics, locked offer scope and clear delivery, with stable foundational operators. Inputs are the current offer stack/model, verified retention/LTV/churn/engagement, support capacity/automation maturity and governance owner. Describe these as required evidence, not as already satisfied facts. Define which outcome must be preserved before simplifying a process.

Map the work and test a simpler delivery path

Produce a current/proposed system map, allowed/blocked decision rules, escalation triggers and downstream handoff artifacts. Identify waiting, repeated data entry, avoidable rework and confusing instructions. Test one change against outcome quality, support demand, cycle time and cost. Added complexity needs a measured benefit and maintenance owner; automation alone is not evidence of durability.

Treat delivery diagnostics as hypotheses

Rising support may reflect delivery defects, growth, onboarding or customer mix; flat LTV may reflect retention, pricing or measurement; burnout may reflect capacity or other pressures; revenue volatility may have many causes. The source’s arrows are investigation prompts, not proof of a single cause. Define evidence and responsible reviewer before prescribing a fix.

Make a freeze and handoff operationally precise

When evidence warrants a pause, name the scaling activity paused, owner, conditions for reopening and review time. Preserve existing customer service and necessary corrections. Send decision rules to governance, tested automation opportunities to the automation owner, and readiness evidence to scale planning. Use calm, buyer-respectful language without urgency manipulation; the source’s completion line does not establish that any enforcement system exists.

Connect the lesson to the direct-marketing promise

Complete original source text

OP-28 — Delivery Optimization Engine

RISER Nation | Custom GPT System Message (Production-Ready)

ROLE

You are OP-28 — Delivery Optimization Engine. Simplifies delivery systems to reduce friction, refunds, and confusion while preserving outcomes. You operate as a systems enforcement operator, not a creative brainstormer.

OPERATING CONTEXT

• Runs only after foundational operators are stable.

• Interfaces with Retention, Automation, Governance, and Scale systems.

• Assumes economics, offer lock, and delivery clarity are already validated.

PRIMARY OBJECTIVES

• Increase durability of the business.

• Remove fragility caused by growth pressure.

• Protect trust, margins, and system clarity while scaling.

REQUIRED INPUTS (CONFIRM BEFORE EXECUTION)

• Current offer stack and delivery model.

• Verified retention metrics (LTV, churn, engagement).

• Support capacity and automation maturity.

• Governance owner and escalation authority.

CORE OUTPUTS (MANDATORY)

• Clear system maps relevant to this operator.

• Decision rules (what is allowed vs blocked).

• Escalation triggers and enforcement language.

• Handoff artifacts to downstream operators.

STRATEGIC LOGIC

This operator exists to prevent growth from degrading outcomes. All recommendations must reduce cognitive load, operational stress, or economic fragility. If an action increases complexity, it must also increase leverage.

FAILURE MODES & DIAGNOSTICS

• Rising support → delivery or automation failure.

• Flat LTV → misaligned continuity or expansion logic.

• Burnout signals → founder or team firewall breach.

• Revenue volatility → scale before readiness.

ESCALATION & FREEZE RULES

If integrity, economics, or culture degrade, you must issue a freeze. Scaling is paused until root causes are resolved and revalidated.

HANDOFF REQUIREMENTS

• Send enforcement logic to Governance operators.

• Send automation opportunities to Automation OS.

• Send scale readiness outputs to Scale Playbooks.

TONE & CONSTRAINTS

Calm. Disciplined. Long-term oriented. No hype. No urgency manipulation. No optimism bias.

OP-28 complete. Output contract delivered.

Native Google Doc text and original links

Control separators are labeled in this readable display. Download exact original text

OP-28 — Delivery Optimization Engine
RISER Nation | Custom GPT System Message (Production-Ready)

[Source control separator U+000B]
ROLE
You are OP-28 — Delivery Optimization Engine. Simplifies delivery systems to reduce friction, refunds, and confusion while preserving outcomes. You operate as a systems enforcement operator, not a creative brainstormer.

[Source control separator U+000B]
OPERATING CONTEXT
• Runs only after foundational operators are stable.
[Source control separator U+000B]
• Interfaces with Retention, Automation, Governance, and Scale systems.
[Source control separator U+000B]
• Assumes economics, offer lock, and delivery clarity are already validated.

[Source control separator U+000B]
PRIMARY OBJECTIVES
• Increase durability of the business.
[Source control separator U+000B]
• Remove fragility caused by growth pressure.
[Source control separator U+000B]
• Protect trust, margins, and system clarity while scaling.

[Source control separator U+000B]
REQUIRED INPUTS (CONFIRM BEFORE EXECUTION)
• Current offer stack and delivery model.
[Source control separator U+000B]
• Verified retention metrics (LTV, churn, engagement).
[Source control separator U+000B]
• Support capacity and automation maturity.
[Source control separator U+000B]
• Governance owner and escalation authority.

[Source control separator U+000B]
CORE OUTPUTS (MANDATORY)
• Clear system maps relevant to this operator.
[Source control separator U+000B]
• Decision rules (what is allowed vs blocked).
[Source control separator U+000B]
• Escalation triggers and enforcement language.
[Source control separator U+000B]
• Handoff artifacts to downstream operators.

[Source control separator U+000B]
STRATEGIC LOGIC
This operator exists to prevent growth from degrading outcomes. All recommendations must reduce cognitive load, operational stress, or economic fragility. If an action increases complexity, it must also increase leverage.

[Source control separator U+000B]
FAILURE MODES & DIAGNOSTICS
• Rising support → delivery or automation failure.
[Source control separator U+000B]
• Flat LTV → misaligned continuity or expansion logic.
[Source control separator U+000B]
• Burnout signals → founder or team firewall breach.
[Source control separator U+000B]
• Revenue volatility → scale before readiness.

[Source control separator U+000B]
ESCALATION & FREEZE RULES
If integrity, economics, or culture degrade, you must issue a freeze. Scaling is paused until root causes are resolved and revalidated.

[Source control separator U+000B]
HANDOFF REQUIREMENTS
• Send enforcement logic to Governance operators.
[Source control separator U+000B]
• Send automation opportunities to Automation OS.
[Source control separator U+000B]
• Send scale readiness outputs to Scale Playbooks.

[Source control separator U+000B]
TONE & CONSTRAINTS
Calm. Disciplined. Long-term oriented. No hype. No urgency manipulation. No optimism bias.

[Source control separator U+000B]
CLOSE
OP-28 complete. Output contract delivered.

Portfolio Governor — Offer Wall Engine™ (v1.0)

Evaluate all five new-offer signals

The Offer Wall Engine lists demand pressure from Buoy/Social, a portfolio-LTV plateau, underused Rigging capacity, Shark Radar risk and an Anchor Point alignment opportunity. These are named conceptual inputs, not verified integrations. Demand may warrant improving an existing offer; a plateau may reflect measurement or retention; unused capacity may not mean demand exists. Investigate the signal before authorizing another product.

Write the three handoff artifacts

Create an Offer Request Brief with audience/problem/evidence/outcome, mutation constraints preserving current promises and capacity, and a routing ticket naming the decision owner and next Sonar stage. The source does not define thresholds or schemas; label these fields as RISER implementation guidance. Record pass, revise or hold with reasons and keep existing offers versioned. Do not claim an automatic portfolio governor has been installed.

Connect the lesson to the direct-marketing promise

Complete original source text

Portfolio Governor — Offer Wall Engine™ (v1.0)

Offer Wall Engine™ (Portfolio Governor subsystem)

Purpose: detect when a new offer must be created up the value ladder, then route creation through the Sonars.



Trigger categories:

- Demand pressure (Buoy/Social)

- Saturation (portfolio LTV plateau)

- Capacity (Rigging underutilized)

- Risk (Shark Radar)

- Alignment unlock (Anchor Point)



Outputs:

- Offer Request Brief

- Mutation constraints

- Routing ticket

Native Google Doc text and original links

Control separators are labeled in this readable display. Download exact original text

Portfolio Governor — Offer Wall Engine™ (v1.0)
Offer Wall Engine™ (Portfolio Governor subsystem)
Purpose: detect when a new offer must be created up the value ladder, then route creation through the Sonars.
[Source control separator U+000B]

[Source control separator U+000B]
Trigger categories:
[Source control separator U+000B]
- Demand pressure (Buoy/Social)
[Source control separator U+000B]
- Saturation (portfolio LTV plateau)
[Source control separator U+000B]
- Capacity (Rigging underutilized)
[Source control separator U+000B]
- Risk (Shark Radar)
[Source control separator U+000B]
- Alignment unlock (Anchor Point)
[Source control separator U+000B]

[Source control separator U+000B]
Outputs:
[Source control separator U+000B]
- Offer Request Brief
[Source control separator U+000B]
- Mutation constraints
[Source control separator U+000B]
- Routing ticket

Price-Raise-Schedule-Template.md

Start the raise schedule from measured economics

The template requests 1,000–1,500 words across seven sections, filed in Drive and linked from M8.8. Record measured and target margins under the same cost definition, the gap in percentage points and the intended quarter for review. A schedule is a proposed policy, not evidence of affordability, market acceptance or permission to change an existing contract.

Schedule trigger — Capacity

The example is at least 80% utilization over a rolling ninety-day window, with a 10% raise on new bookings. Define usable capacity and measured delivery hours. High utilization can motivate a pricing test, but does not prove price is below market-clearing. For each trigger record threshold, measurement window, magnitude, effective date and treatment of current commitments.

Schedule trigger — Waitlist

The example is at least six weeks of backlog, measured at month end, with a 15% raise on new bookings. Distinguish confirmed bookings from unqualified interest and estimate service capacity. A queue does not alone reveal willingness to pay a higher price. For each trigger record threshold, measurement window, magnitude, effective date and treatment of current commitments.

Schedule trigger — Demand

The example is at least twelve qualified inbound inquiries per month for at least three consecutive months, with a 10% raise. Define qualification consistently and inspect conversion and capacity. High inquiry volume may coexist with poor fit. For each trigger record threshold, measurement window, magnitude, effective date and treatment of current commitments.

Schedule trigger — Annual indexing

The example uses January 15 and 4–7%, with sixty days’ notice and existing-customer effect at renewal. Inflation, skill and willingness to pay are separate inputs; elapsed time does not prove improved customer value. A fixed annual increase is a chosen policy, not a universal economic requirement. For each trigger record threshold, measurement window, magnitude, effective date and treatment of current commitments.

Test thresholds without forcing the answer

Section 3 projects each trigger over twelve months. The source says to tighten any threshold until it will fire and claims roughly half of first submissions are too loose, without supporting data. Do not manipulate thresholds merely to guarantee a raise. Use credible demand/capacity scenarios, document a valid no-trigger result and revise the business hypothesis when evidence warrants it.

Resolve the cap and indexing conflict

The example caps raises at 25% over a rolling twelve months yet says a 4% annual floor always fires regardless of the cap. Those rules conflict unless indexing is reserved inside the cap or explicitly exempt with a different total limit. Define the baseline, effective dates and order. Sequential 10% and 15% raises compound to 26.5%, not 25%. Model the actual rolling window before queuing another change.

Communicate effective terms accurately

The template specifies old/new prices, date, reason, channel, notice, grandfathering and structural loyalty rules. Preserve current commitments and explain renewal treatment clearly. Its example offers sixty days’ notice while execution is required within thirty days; distinguish scheduling/notification from the effective increase. The sample invitation to discuss also differs from the no-negotiation clause: allow questions without promising discretionary terms. An apology does not inherently make a price negotiable.

Operate the five-part discipline clause

The proposed twelve-month commitment is to update Tab 4 monthly, act on triggers within thirty days, communicate clearly, apply the selected annual indexing policy, and log deferred raises with reasons within forty-eight hours. Resolve policy conflicts first, name the accountable owner and keep actual evidence. The referenced Supabase deviation log is not created by this template, and no customer email has been sent.

Run all three schedule coherence checks

Check whether the cap permits the chosen margin path, whether grandfathering/loyalty aligns with the anti-discount policy, and what supports the chosen indexing rate. The source’s inflation-plus-one-to-three-percent skill rule is a policy assumption, not proof of real customer value. If volume or costs change after a raise, update the model rather than treating price alone as guaranteed sustainability.

Connect the lesson to the direct-marketing promise

Complete original source text

# Price-Raise Schedule Template

**Used in:** M8.7 deliverable · **Length target:** 1,000-1,500 words · **Filed in:** Drive + linked from M8.8 Attestation

---

## Section 1 — Schedule Foundation

State the M8.4 architecture sustainability target margin and the M8.2 current measured margin. The gap between them is what this schedule is designed to close, in addition to handling capacity-driven raises and annual indexing.

| Metric | Value |
|---|---|
| M8.2 measured gross margin | % |
| M8.4 target sustainability margin | % |
| Gap to close | % |
| Target close-out window | Q+N |

---

## Section 2 — The Four Triggers

The schedule operates against four canonical trigger types. Each trigger has a threshold, a window, and a magnitude.

### Trigger 1 — Capacity Utilization

| Field | Value |
|---|---|
| Threshold | (e.g., ≥ 80% utilization across rolling 90-day window) |
| Measurement window | Rolling 90 days |
| Magnitude when fired | (e.g., +10% on new bookings) |
| Existing customer treatment | (Grandfathered through current commitment / next renewal at new price) |

Capacity utilization is the strongest signal that pricing is below market-clearing. When the operator runs at high utilization for extended periods, the price is too low. Raise the price.

### Trigger 2 — Waitlist Depth

| Field | Value |
|---|---|
| Threshold | (e.g., ≥ 6 weeks of bookings backlog) |
| Measurement window | Snapshot end-of-month |
| Magnitude when fired | (e.g., +15% on new bookings) |
| Existing customer treatment | |

Waitlist depth is the secondary capacity signal; it complements Trigger 1. When customers are waiting weeks to be served, price is below willingness-to-pay.

### Trigger 3 — Demand Signal

| Field | Value |
|---|---|
| Threshold | (e.g., ≥ 12 inbound qualified inquiries per month for ≥ 3 consecutive months) |
| Measurement window | Rolling 3 months |
| Magnitude when fired | (e.g., +10% on new bookings) |
| Existing customer treatment | |

Demand signal captures elevated inbound interest independent of capacity. When inbound is high but utilization is moderate (perhaps because the operator is throttling acceptance), the price can rise.

### Trigger 4 — Annual Indexing

| Field | Value |
|---|---|
| Threshold | Calendar date (e.g., January 15 each year) |
| Measurement window | N/A (date-based) |
| Magnitude when fired | (e.g., +4-7% covering inflation + skill compounding) |
| Existing customer treatment | (Communicated 60 days in advance; takes effect on next renewal) |

Annual indexing is the structural floor. It fires regardless of demand conditions. The function is to compensate for inflation and operator skill compounding (the operator at 12 months is more skilled than at 0 months and should price accordingly).

---

## Section 3 — Tightness Verification

For each trigger, project realistic Stage 2-3 conditions and verify the trigger fires within 12 months.

| Trigger | 12-month projected reading | Threshold | Will fire? |
|---|---|---|---|
| T1 — Capacity utilization | | | |
| T2 — Waitlist depth | | | |
| T3 — Demand signal | | | |
| T4 — Annual indexing | January 15, [year+1] | January 15 | Yes |

If any of T1-T3 are projected NOT to fire within 12 months, tighten the threshold until projection shows fire. Loose triggers are the most common M8.7 review failure (~50% of first submissions).

---

## Section 4 — Cumulative Cap

State the cumulative cap on raises within any rolling 12-month window.

| Field | Value |
|---|---|
| Cumulative cap | (e.g., +25% rolling 12-month) |
| Floor below cap | (e.g., +4% annual indexing always fires regardless of cumulative) |
| Behavior at cap | (Subsequent triggered raises queue to next 12-month window) |

The cap exists because aggressive cumulative raises damage customer perception. The floor exists because annual indexing must fire even in cap years.

---

## Section 5 — Existing Customer Communication Pattern

State the communication template for existing customers when raises fire.

| Element | Specification |
|---|---|
| Lead time | (e.g., 60 days advance notice for renewals; 30 days for new engagements) |
| Channel | (e.g., direct email, not bulk) |
| Template | (Provide template) |
| Grandfathering rules | (e.g., current commitment honored at original price; renewal at new price) |
| Loyalty exception | (Per M8.6 Section 2, not per ad-hoc decision) |

Provide a sample email template:

> *Subject: Pricing update for [offer name] effective [date]*
>
> *Hi [name],*
>
> *I'm writing to let you know that [offer name] pricing will increase from $[old] to $[new] effective [date]. The change reflects [trigger reason: capacity utilization / annual indexing / etc.]. Your current engagement at $[old] is honored through completion. Future engagements will be at $[new].*
>
> *I wanted to give you 60 days notice so you can plan accordingly. If you'd like to discuss, I'm available.*
>
> *[signature]*

The template is direct, specific, and does not apologize for the raise. Apologetic raise communications signal to customers that the raise is negotiable.

---

## Section 6 — Discipline Clause

The operator commits to specific behaviors:

> *I commit to operating this Price-Raise Schedule for the 12 months beginning [date]. I will:*
>
> *1. Update Pricing Math Spreadsheet Tab 4 monthly with current readings of T1-T3 and verify cumulative cap status.*
>
> *2. Execute fired raises within 30 days of fire-date, on new engagements first and existing-customer communications immediately following.*
>
> *3. Communicate raises to existing customers using the Section 5 template, with no apology and no negotiation invitation.*
>
> *4. File annual indexing on [date] regardless of demand conditions.*
>
> *5. Log any deferred raise with documented reason in Supabase deviation_log within 48 hours of the deferral.*
>
> *I understand that pricing discipline includes raising prices when conditions trigger raises, not only holding prices when conditions pressure discounts. The discipline is symmetric.*

---

## Section 7 — Schedule Coherence Check

State explicitly:

- Does the cumulative cap (Section 4) leave room for the M8.4 sustainability margin path (M8.4 Section 8)? If no, the schedule cannot deliver the architecture.
- Do the existing-customer communications (Section 5) align with the M8.6 anti-discount policy? Specifically, is grandfathering treated as a structural exception per M8.6 Section 2 or is it inadvertently treated as an ongoing discount?
- Does the annual indexing rate (Section 2 Trigger 4) at minimum cover inflation + 1-3% operator skill compounding? If not, indexing is a real-terms price decline.

These coherence questions are also asked at M8.8 Section 8.

---

*This schedule is the forward-looking commitment that enables M8.4 architecture to reach sustainability. Architecture without schedule is a frozen number that decays in real terms. Schedule with discipline is how price holds against time.*

Lesson 03.2 — sources for the added teaching sections

Pricing-Architecture-Document-Template.md

Use the ten-section pricing template as its own version

This M8.4 template targets 1,200–1,800 words and feeds M8.5 tiers, M8.6 discount policy, M8.7 raises and M8.8 attestation. It differs from the eight-section written lesson and its word ranges. Keep a crosswalk of every required field instead of silently treating the versions as identical. Link C7 architecture, measured M8.2 economics and the selected M8.3 branch; declare the chosen margin definition and any approved exception.

Specify the price, unit and exchange policy

Section 2 asks for base amount, what one purchase covers, currency/exchange treatment and a cost-grounded rationale. Its $5,625/35%/52-hour example needs an included-cost figure and loaded rate to substantiate the margin. At 35%, included cost would be $3,656.25; holding that cost fixed, 60% margin would require $9,140.625 before a stated rounding policy, a 62.5% increase. The example’s eighteen-month path exceeds the later four-quarter target and needs an explicit exception. This arithmetic is illustrative, not a price recommendation.

Make payment and refund terms complete

Sections 3–4 request deposit percentage/due date, final percentage/due date, late and failed-payment handling, refund length/start event, covered triggers and exclusions. The 25% deposit above $500 is a source policy, not universal law or proof risk should always rest with the buyer. Ensure installments sum to the actual price and terms match the offer. Clear exclusions do not override applicable obligations or automatically make a policy fair.

Define structural segmentation and resolve the matrix

Section 5 covers standard, bulk/cohort, long-tenure and partnership pricing with objective eligibility and approval rules. Its example grants 10% loyalty after three deliveries with renewal within thirty days. Section 6 crosses new/existing customers with standard/custom scope; it omits loyalty in the existing/custom cell, while the related framework applies loyalty to base plus a premium on original base. Resolve the actual policy before quoting, and retain evidence of eligibility.

Cost and disambiguate the scope-premium schedule

The illustrative schedule assigns 10% of base to an added deliverable of at most four hours, 20% for four-to-eight hours, a re-quote above eight hours, 15% for compressed timing and a re-quote for one-off integration. Exactly four hours appears in both first bands; define a non-overlapping boundary. Specify whether simultaneous additions combine, which base applies and what capacity permits. A percentage is not adequate merely because it appears in the template.

Build the quarterly margin path and coherence checks

Section 8 starts with current actual margin and Q+1 through Q+4 projections, with reasons for changes and an approved alternative if the target is not reached. Section 9 checks base-price margin, weighted effective price at least 92% of base under segmentation, and premiums covering measured extra work. Use a stable cost definition and realistic volume/mix; do not average prices without weighting or assume a future raise guarantees margin.

Sign and version an executable pricing policy

Section 10 proposes a twelve-month version commitment with triggered changes and a deviation log. Record actual effective dates, owner, approvals and change history. A signature cannot cure inconsistent rules or unmeasured costs. Keep the chosen architecture linked wherever tiers, discounts, raises or customer terms depend on it.

Connect the lesson to the direct-marketing promise

RISER application: use a truthful hook, an evidence-backed story and a clearly scoped offer in the Brunson sequence. Apply the Hormozi value lens to reduce avoidable effort and delay while improving credible usefulness. Preserve customer choice and delivery limits. Neither marketing framework substitutes for operational proof.

Complete original source text

# Pricing Architecture Document Template

**Used in:** M8.4 deliverable · **Length target:** 1,200-1,800 words · **Filed in:** Drive + linked from M8.8 Attestation

---

## Section 1 — Architecture Inputs

Reference the prior artifacts this architecture is built upon:

- C7 Offer Architecture Document (link)
- M8.2 Unit Economics Document (link, including measured gross margin and effective rate)
- M8.3 Pricing Reality Check Decision Memo (link, including selected decision branch)

State the C8 doctrine threshold the architecture targets: **60% gross margin minimum for knowledge-work offers** (or document the deviation if targeting lower with instructor approval).

---

## Section 2 — Base Price Specification

| Field | Value | Rationale |
|---|---|---|
| Base price | $ | Why this number specifically |
| Base unit | (e.g., "per Sprint", "per individual seat") | What the price covers |
| Currency and exchange policy | | If serving multi-currency markets |

The rationale must reference unit economics. Acceptable rationale: "Base price of $5,625 produces 35% gross margin against measured 52-hour delivery cost; M8.7 schedule fires path to 60% margin within 18 months." Unacceptable rationale: "Competitive pricing in the market." Pricing is not set against competitor pricing without reference to your unit economics; that is anchor-to-other not anchor-to-cost.

---

## Section 3 — Payment Terms

| Field | Value |
|---|---|
| Deposit % | |
| Deposit due | |
| Final payment % | |
| Final payment due | |
| Late payment treatment | |
| Failure-to-pay treatment | |

The deposit serves two functions: cash-flow management and customer commitment device. C8 doctrine: deposits ≥ 25% for offers > $500. Below-25% deposits leave the operator carrying customer risk that should sit with the customer.

---

## Section 4 — Refund Window and Triggers

| Field | Value |
|---|---|
| Refund window length | (e.g., 14 days from start) |
| Refund window start condition | (e.g., "from kickoff call") |
| Refund triggers | List specific operator failures that trigger refund |
| Non-trigger conditions | List conditions that explicitly do NOT trigger refund |

The refund non-trigger list is critical. Operators with vague refund policies grant refunds under customer pressure. Specifying non-triggers in advance ("change of customer business priorities does not trigger refund") prevents pressure-based refunds.

---

## Section 5 — Segmentation Rules

| Customer type | Pricing treatment |
|---|---|
| Standard | Base price as specified Section 2 |
| Bulk / cohort | If applicable; specify threshold and discount |
| Long-tenure existing | If applicable; specify treatment |
| Strategic / partnership | If applicable; specify approval workflow |

Segmentation must be **rules-based**, not discretionary. "I might offer a discount to long-time customers" is not a rule. "Customers with ≥ 3 prior deliveries who renew within 30 days of last delivery receive 10% loyalty pricing" is a rule. Rules-based segmentation is auditable and defensible; discretionary segmentation is not.

---

## Section 6 — Four-Quadrant Pricing Matrix

| | New customer | Existing customer |
|---|---|---|
| **Standard scope** | Base price (Section 2) | Base price or loyalty pricing per Section 5 |
| **Custom scope** | Base price + scope premium per Section 7 | Base price + scope premium |

Specify what falls in each quadrant. The matrix prevents the most common pricing failure: existing customers paying legacy rates while new customers pay current rates, with the operator having no documented policy for when the legacy rate ends.

---

## Section 7 — Scope Premium Schedule

When custom scope is requested, the premium is calculated:

| Custom scope category | Premium |
|---|---|
| Additional deliverable (≤ 4 hours added) | +10% base price |
| Additional deliverable (4-8 hours added) | +20% base price |
| Major scope expansion (> 8 hours added) | Re-quote required, not a premium |
| Timeline compression (< standard timeline) | +15% base price |
| Custom integration / one-off requirement | Re-quote required |

The schedule is illustrative. Each operator builds their own based on M8.2 actual hours data. The function of the schedule is to make scope-creep pricing automatic rather than negotiated.

---

## Section 8 — Sustainability Margin Path

State the current margin (M8.2) and the target margin (60% minimum). State the path:

| Quarter | Projected margin | How achieved |
|---|---|---|
| Q current | (M8.2 actual) | — |
| Q+1 | | (e.g., scope tightening per C7 v2.0 specification) |
| Q+2 | | |
| Q+3 | | |
| Q+4 | | (M8.7 annual indexing fires) |

If the path does not reach 60% within 4 quarters, document the reason and the alternative target with instructor approval.

---

## Section 9 — Architecture Coherence Check

State explicitly:

- Does the base price (Section 2) produce ≥ 60% margin against M8.2 unit economics? If no, what is the bridge?
- Do the segmentation rules (Section 5) produce average effective price ≥ base price × 0.92? If no, the segmentation system erodes the base price.
- Does the scope premium schedule (Section 7) cover the average scope-creep load measured in C7? If no, the schedule under-prices scope.

These three coherence questions are also asked at M8.8 Section 8 (cross-artifact coherence). Answering them at M8.4 prevents M8.8 surprises.

---

## Section 10 — Operator Sign-Off

Suggested:

> *This Pricing Architecture v1.0 will operate from [date] through the next 12 months absent triggered changes per M8.7 schedule. I understand that this architecture is the price I charge, not the price I sometimes charge. Deviations will be logged per M8.8 Section 9.*

---

*This template produces the structural foundation that M8.5 (tiers), M8.6 (anti-discount), and M8.7 (raises) all reference. Subsequent modules cannot succeed against a vague Architecture Document.*

pricing-architecture-reviewer-v1.0.0.yaml

Read the alternate ten-section pricing review

Apply pricing review numbers as declared policy

Resolve the reviewer’s incompatible thresholds

Produce an auditable pricing review and handoff

Connect the lesson to the direct-marketing promise

Complete original source text

name: pricing-architecture-reviewer
version: 1.0.0
module: M8.4
course: C8 Pricing Discipline
model: claude-sonnet-4-6
role: Pricing Architecture Reviewer
review_type: artifact_review
description: >
  Reviews the M8.4 Pricing Architecture Document. Verifies that base price,
  payment terms, refund window/triggers, segmentation rules, four-quadrant
  matrix, and scope premium schedule are specified rules-based (not
  discretionary), grounded in M8.2 unit economics and M8.3 decision branch,
  and architected toward the C8 doctrine 60% sustainability margin.

system_prompt: |
  You are the Pricing Architecture Reviewer for the RISER Nation Maritime
  Academy C8 Pricing Discipline course, Module 8.4. You review Pricing
  Architecture Documents.

  This module turns the M8.3 decision into a structural pricing system. The
  architecture is what M8.5-M8.7 build against and what M8.6 anti-discount
  policy enforces. Architectural ambiguity propagates into every downstream
  artifact.

  ## What to evaluate

  Read the submitted Pricing Architecture Document plus the linked M8.2
  Unit Economics Document and M8.3 Decision Memo. The Architecture must
  be coherent with both upstream artifacts.

  Score against ten criteria. Pass threshold: average ≥ 7.0 AND no
  individual criterion below 5.0.

  **Criterion 1 — Architecture inputs documented**
  Section 1 must reference C7 Offer Architecture, M8.2 Unit Economics, and
  M8.3 Decision Memo with links. Architecture cannot be built in isolation
  from upstream artifacts.

  **Criterion 2 — Base price specified with cost-anchored rationale**
  Section 2 base price must reference M8.2 unit economics in its rationale.
  Rationale that anchors only to "competitive pricing" or "what feels right"
  fails this criterion. Acceptable rationale ties price to measured cost
  and target margin.

  **Criterion 3 — Payment terms specify deposit ≥ 25% for offers > $500**
  Section 3 must specify deposit percentage. Below-25% deposits on offers
  > $500 are flagged as customer-risk-on-operator failures. Documents may
  specify lower deposits with explicit rationale (e.g., compliance with
  customer procurement requirements).

  **Criterion 4 — Refund window with non-trigger list**
  Section 4 must specify refund window AND non-trigger list. Refund policies
  without non-triggers ("we'll evaluate refund requests case by case") fail
  this criterion because they enable pressure-based refunds.

  **Criterion 5 — Segmentation rules are rules-based, not discretionary**
  Section 5 must specify customer segments with structural criteria (e.g.,
  "≥ 3 prior deliveries renewing within 30 days"). Discretionary segmentation
  ("long-time customers may receive loyalty pricing") fails this criterion.

  **Criterion 6 — Four-quadrant matrix populated**
  Section 6 must show the four-quadrant matrix with pricing rules per
  quadrant. Empty quadrants or vague quadrant entries ("TBD" or "case-by-case")
  fail this criterion.

  **Criterion 7 — Scope premium schedule specified**
  Section 7 must specify scope premium magnitudes (e.g., "+10% for ≤ 4
  hour additions"). Generic language ("custom scope priced separately")
  without magnitudes fails this criterion. The schedule's function is
  to make scope-creep pricing automatic.

  **Criterion 8 — Sustainability margin path specified**
  Section 8 must show quarterly margin trajectory from current (M8.2
  measured) to target (60% knowledge-work doctrine, or documented exception).
  Targets without a path ("we'll get to 60% eventually") fail this
  criterion.

  **Criterion 9 — Architecture coherence check addressed**
  Section 9 must answer the three coherence questions:
  - Does base price produce target margin against M8.2 unit economics?
  - Do segmentation rules produce average effective price ≥ base × 0.92?
  - Does scope premium schedule cover measured C7 scope-creep load?

  Hand-waving on these questions ("yes" without computation) fails this
  criterion.

  **Criterion 10 — Operator sign-off binding for 12 months**
  Section 10 must include operator's sign-off committing to the architecture
  for 12 months absent M8.7 schedule-triggered changes. Sign-offs with
  weakening language ("subject to circumstances") fail this criterion.

  ## How to write the review

  Same structure as prior reviewers:
  1. Score summary table
  2. Decision (CLEARED / NEEDS_REVISION / NOT_CLEARED)
  3. Per-criterion notes with specific section references
  4. Coherence-with-upstream flags (M8.2, M8.3 inconsistencies)
  5. M8.5 hand-off readiness assessment
  6. Final paragraph

  ## Decision thresholds

  - CLEARED: average ≥ 8.0, no criterion below 6.0
  - NEEDS_REVISION: average 6.0-7.9, OR any criterion 4.0-5.9
  - NOT_CLEARED: average < 6.0 OR any criterion < 4.0

  Sustainability margin path criterion (8) is weighted: failure on
  Criterion 8 alone routes to NEEDS_REVISION minimum, even if other
  criteria score well.

  ## Tone and discipline

  M8.4 is the most technical C8 module. Operators may produce well-formed
  documents that nonetheless fail coherence checks. Be specific in
  feedback: name the section, name the issue, name the correction.

  Architecture is rules-based, but the rules don't have to be the same as
  the C7 reference rules. Operators can deviate (e.g., specifying lower
  doctrine threshold than 60%) with documented rationale.

review_criteria:
  - architecture_inputs_documented
  - base_price_specified_with_cost_anchored_rationale
  - payment_terms_specify_deposit_threshold
  - refund_window_with_non_trigger_list
  - segmentation_rules_rules_based
  - four_quadrant_matrix_populated
  - scope_premium_schedule_specified
  - sustainability_margin_path_specified
  - architecture_coherence_check_addressed
  - operator_signoff_binding_12_months

decision_thresholds:
  CLEARED:
    average_min: 8.0
    no_criterion_below: 6.0
  NEEDS_REVISION:
    average_range: [6.0, 7.9]
    or_any_criterion_range: [4.0, 5.9]
    or_criterion_8_below: 6.0
  NOT_CLEARED:
    average_below: 6.0
    or_any_criterion_below: 4.0

instructor_handoff:
  triggered_when: NOT_CLEARED OR coherence_check_failure_persistent
  routing: C8 instructor queue, priority normal
  expected_resolution_window: 14 days from handoff

cooling_period_after_clearance:
  hours: 48
  rationale: >
    Architecture commits the operator to a 12-month system. The 48-hour
    cooling period before M8.5 ensures the operator has confirmed the
    architecture before building tier or scope-premium structures against it.

Pricing-Math-Spreadsheet-Template.md

Build the five-tab pricing workbook deliberately

Correct the delivery formulas before using them

Separate architecture rules from observed results

Correct the exception-log compliance calculation

Track trigger decisions without silently executing raises

Use weighted and time-consistent quarterly summaries

Connect the lesson to the direct-marketing promise

Complete original source text

# Pricing Math Spreadsheet Template

**Version:** 1.0 · **Last updated:** April 25, 2026 · **Used in:** M8.2, M8.3, M8.4, M8.7, M8.8 quarterly reconciliation

---

## Purpose

A single spreadsheet that holds all pricing math for one offer through its first 12 months of operation. The operator opens this spreadsheet at M8.2, populates it with measured C7 data, and updates it quarterly thereafter. The spreadsheet is the live source of truth that feeds every C8 deliverable.

This is a markdown specification of the spreadsheet structure. The operator builds the spreadsheet in Google Sheets or Excel using the named columns, formulas, and tabs below. RISER does not provide a pre-built spreadsheet because operators who build their own internalize the math; operators who paste numbers into a pre-built template often do not.

---

## Tab 1 — Unit Economics

Column structure:

| Column | Purpose | Source |
|---|---|---|
| A: Delivery ID | Unique identifier per delivery (e.g., Sprint-001) | Operator-assigned |
| B: Customer | Customer name | Operator |
| C: Start date | Delivery start | Operator |
| D: End date | Delivery end | Operator |
| E: Stated price | Price quoted to customer | C4 / C7 |
| F: Stated hours | Hours estimated at quote time | C7 |
| G: Actual hours | Measured hours from delivery | C7 measurement system |
| H: Hidden hours | Pre-quote, scope-creep, post-delivery support | M8.2 audit |
| I: Total hours | F + H | Formula |
| J: Hourly cost | Operator-self loaded rate | M8.2 |
| K: Direct costs | Software, contractors, materials | M8.2 |
| L: Total cost | (I × J) + K | Formula |
| M: Gross margin $ | E - L | Formula |
| N: Gross margin % | M / E | Formula |
| O: Effective rate | E / I | Formula |

Target rows: one per delivery. Minimum 6 deliveries before M8.2 unit economics calculation reads as statistically meaningful. C7 capacity constraint analysis should have produced ≥ 8 deliveries; copy them all here.

---

## Tab 2 — Pricing Architecture

| Field | Value | Notes |
|---|---|---|
| Base price | | M8.4 architecture |
| Payment terms | | e.g., 50% deposit, 50% on delivery |
| Refund window | | e.g., 14 days |
| Refund triggers | | Specific behaviors that trigger refund |
| Standard tier price | | If three-tier; else N/A |
| Entry tier price | | If three-tier |
| Premium tier price | | If three-tier |
| Tier mix target | | e.g., 60/30/10 for std/entry/premium |
| Sustainability margin target | | M8.4; doctrine threshold 60% knowledge-work |

---

## Tab 3 — Anti-Discount Policy Compliance

| Column | Purpose |
|---|---|
| A: Date | When request received |
| B: Customer | Who asked |
| C: Request type | Discount sought (e.g., "remove deliverable", "first-customer rate") |
| D: Policy classification | Exception / Non-exception |
| E: Action taken | Decline / Discount granted |
| F: If granted, justification | Required if E=granted; should be empty in disciplined operation |
| G: Compliance score | 1 if action matched policy, 0 if deviated |

Quarterly: count deviations, divide by total requests, calculate compliance rate. Target: 100%. Below 95% triggers M8.6 policy review.

---

## Tab 4 — Price-Raise Trigger Tracker

| Column | Purpose |
|---|---|
| A: Trigger ID | T1-T4 (capacity, waitlist, demand, indexing) |
| B: Threshold | The trigger condition |
| C: Current reading | Updated monthly |
| D: Fired? | Y/N |
| E: Fired date | If Y |
| F: Raise executed date | Within 30 days of fire |
| G: Raise magnitude | % |
| H: Cumulative cap status | Used / remaining |

This tab enforces M8.7 discipline. The operator updates monthly; the Quarterly Reconciliation reads from it.

---

## Tab 5 — Quarterly Reconciliation

One row per quarter.

| Field | Computed from |
|---|---|
| Quarter | e.g., Q3-2026 |
| Avg gross margin % | Tab 1 N column avg |
| Avg effective rate | Tab 1 O column avg |
| Tier mix actual | Tab 1 customer breakdown |
| Tier mix variance | Actual vs Tab 2 target |
| Anti-discount compliance % | Tab 3 G avg |
| Triggers fired | Tab 4 D Y count |
| Raises executed | Tab 4 F populated count |
| Cumulative raise % | Tab 4 G sum |
| Deviation log entries | From Supabase deviation_log |
| Reconciliation memo link | Drive link |

---

## Setup Time

First-time setup: 2-3 hours including data import from C7. Quarterly maintenance: 60-90 minutes. Total annual time: ~10 hours. This is part of the operating cost of pricing discipline; budget it against operator overhead.

---

*This template is an output of M8.2 and an input to every subsequent C8 module and to all C9 distribution decisions.*

Problem-Solution-Demonstration

Identify the problem

Name a recognizable customer task and the specific obstacle the offer addresses. Use actual audience evidence; avoid exaggerating harm or making viewers feel inadequate.

Introduce the solution

Explain the relevant mechanism, features and benefits with fit and limitations. The product is a candidate solution, not automatically the best or only answer.

Demonstrate the work

Show a representative input, real steps, output and acceptance check using a recording, visual or animation. Label simulations and edits; do not imply a mockup is functioning software.

Reinforce supported benefits

Connect each demonstrated action to a useful result. Time, money or efficiency claims need a defined comparison and evidence; one selected example is not a universal outcome.

Use authentic social proof

Obtain appropriate permission for genuine testimonials or case studies and retain relevant context. Do not invent customers, endorsements, before/after outcomes or implied typical results.

Offer one clear next action

Choose the appropriate next step—learn more, try an available demo, contact the team or buy an accurately described offer. State commitment and terms clearly; the existence of a CTA does not prove a trial or product is live.

Link useful follow-on resources

Place the relevant guide, checklist, related lesson or event link next to the point it supports. Verify destination, access and currency. Do not pad the page with unrelated resources.

Follow up appropriately

Define consent, channel preferences and the useful reason for contact before email, retargeting or personal messaging. Engagement with a video alone does not authorize every kind of follow-up. Measure fit and outcomes as well as conversions; no outreach is performed by this lesson.

Connect the lesson to the direct-marketing promise

Complete original source text

Problem-Solution-Demonstration

Steps:

1. Problem Identification: Begin by identifying a common problem or pain point that your target audience faces and that your product or service solves. Clearly articulate the problem to resonate with viewers and make them feel understood.

2. Solution Introduction: Introduce your product or service as the solution to the problem identified. Highlight the key features and benefits that address the problem and explain how it can improve the viewer's life or situation.

3. Demonstration: Provide a detailed demonstration of your product or service in action. Show how it works, its ease of use, and how it specifically solves the problem identified. Use visuals, animations, or screen recordings to illustrate key points.

4. Benefits Reinforcement: Throughout the demonstration, continue to reinforce the benefits of your product or service. Highlight how it saves time, increases efficiency, saves money, or enhances the viewer's overall experience.

5. Social Proof: Incorporate testimonials, case studies, or endorsements from satisfied customers to build credibility and trust. Share real-life examples of how others have successfully used your product or service to solve similar problems.

6. Call to Action (CTA): Encourage viewers to take action after watching the demonstration. Direct them to visit your website, sign up for a free trial, make a purchase, or contact your sales team for more information. Make the CTA clear and compelling.

7. Additional Resources: Provide viewers with additional resources or next steps to further engage with your brand or product. This could include links to related content, downloadable resources, or information on upcoming events or promotions.

8. Follow-Up: After the video, follow up with viewers who have engaged with your content. Send follow-up emails, retargeting ads, or personalized messages to nurture leads and encourage them to take the next step in the buying journey.

By following the Problem-Solution-Demonstration framework, you can create engaging and persuasive product demonstration videos that effectively showcase the value of your offering and drive conversions. Tailor your message to resonate with your target audience's needs and preferences, and use visuals and storytelling to captivate and educate viewers.

Native Google Doc text and original links

Problem-Solution-Demonstration
Steps:
Problem Identification: Begin by identifying a common problem or pain point that your target audience faces and that your product or service solves. Clearly articulate the problem to resonate with viewers and make them feel understood.
Solution Introduction: Introduce your product or service as the solution to the problem identified. Highlight the key features and benefits that address the problem and explain how it can improve the viewer's life or situation.
Demonstration: Provide a detailed demonstration of your product or service in action. Show how it works, its ease of use, and how it specifically solves the problem identified. Use visuals, animations, or screen recordings to illustrate key points.
Benefits Reinforcement: Throughout the demonstration, continue to reinforce the benefits of your product or service. Highlight how it saves time, increases efficiency, saves money, or enhances the viewer's overall experience.
Social Proof: Incorporate testimonials, case studies, or endorsements from satisfied customers to build credibility and trust. Share real-life examples of how others have successfully used your product or service to solve similar problems.
Call to Action (CTA): Encourage viewers to take action after watching the demonstration. Direct them to visit your website, sign up for a free trial, make a purchase, or contact your sales team for more information. Make the CTA clear and compelling.
Additional Resources: Provide viewers with additional resources or next steps to further engage with your brand or product. This could include links to related content, downloadable resources, or information on upcoming events or promotions.
Follow-Up: After the video, follow up with viewers who have engaged with your content. Send follow-up emails, retargeting ads, or personalized messages to nurture leads and encourage them to take the next step in the buying journey.
By following the Problem-Solution-Demonstration framework, you can create engaging and persuasive product demonstration videos that effectively showcase the value of your offering and drive conversions. Tailor your message to resonate with your target audience's needs and preferences, and use visuals and storytelling to captivate and educate viewers.

QM-Audit-C7-Scorecard.xlsx

Read this as a historical internal audit

The C7 file is dated 2026-04-25 and labeled manual-apply version 1.0.0. It reports 92/94 points, about 97.9%, and 15/16 source-defined essentials, with NOT_CERTIFIED status. The row totals reconcile internally. These are the document’s claims, not an official review of the current RISER website. Course numbering belongs to this legacy curriculum and must not overwrite spreadsheet assignments.

Correct the rubric identity before rescoring

The source’s forty-two-row rubric does not match the official seventh-edition overview, which lists forty-four standards and identifies three-point standards as essential. Several source labels, weights and essential flags differ. Version 2.0 did not replace the underlying standards. Rebuild an authorized, correctly mapped assessment before using a score for a certification claim; changing a local status cell cannot certify a course.

Keep source findings distinct from verified evidence

For each row below, the score and evidence paragraph are preserved as the source reviewer’s assessment. Inspect the cited artifact and actual learner-facing behavior before accepting it. A file named as evidence is not proof of its content, a promised service is not a delivered service, and a prompt is not an installed reviewer. Record reviewed version, test, result and any unresolved dependency.

C7 audit row 1.1 — Instructions make clear how to get started

Source row 1.1, Instructions make clear how to get started: awarded 3 of 3; status MET; essential flag True; gap severity NONE. The source cites: C7-Course-README has explicit 'How to Use This Course' guidance with module-by-module navigation; C7-Module-Map provides Mermaid diagram with serial unlock structure (M7.5 || M7.6 parallel); C7-Prerequisites-Checklist gates enrollment with 7-section validation referencing C6 Sailboat Ready Attestation co-sign; M7.1 written lesson opens with course-positioning summary and the 3-Customer Test diagnostic RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 1.2 — Learners introduced to course purpose and structure

Source row 1.2, Learners introduced to course purpose and structure: awarded 3 of 3; status MET; essential flag True; gap severity NONE. The source cites: C7-Course-README and M7.1 establish the Document vs Architecture distinction and Honest Capacity doctrine; C7-Learning-Outcomes maps 8 CLOs to module-level objectives; C7-Time-Estimate provides 50hr active / 5-7 weeks elapsed pacing with three named non-negotiable calendar windows; the Stage 2 second-course position is explicitly named RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 1.3 — Communication expectations stated clearly

Source row 1.3, Communication expectations stated clearly: awarded 2 of 2; status MET; essential flag True; gap severity NONE. The source cites: Communication norms specified in C7-Lifecycle-Gate-Transition-Script and Lifecycle-Gate-Language-Swipe-File; cohort communication framed in 08_Community-Prompts; instructor turnaround SLAs (72hr for M7.5/M7.6 HITL, 24-72hr for M7.8 Opus + co-sign) documented in All-Module-Checkpoints RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 1.4 — Institutional policies clearly stated

Source row 1.4, Institutional policies clearly stated: awarded 2 of 2; status MET; essential flag False; gap severity NONE. The source cites: Resubmission policy documented in All-Module-Checkpoints; three new C7 integrity clauses (Honest Capacity, Architecture-vs-Pivot Distinction, SOP Operability) ground course-level policies; C6 Iteration Discipline and Honest Customer Representation continued RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 1.5 — Technology requirements stated

Source row 1.5, Technology requirements stated: awarded 1 of 1; status MET; essential flag False; gap severity NONE. The source cites: Tooling requirements specified in Time-Tracking-Tool-Setup-Guide and Time-Tracking-Tool-Integration walkthrough; Supabase-C7-Schema documents required infrastructure; M7.6 setup worksheet enumerates tool selection criteria RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 1.6 — Prerequisite knowledge stated

Source row 1.6, Prerequisite knowledge stated: awarded 1 of 1; status MET; essential flag False; gap severity NONE. The source cites: C7-Prerequisites-Checklist explicitly references C1-C6 completion with specific artifact requirements; Sailboat Ready Attestation co-sign required as enrollment gate; per-section verification of C6 outputs (Offer v1.1, Customer Feedback Loop, Onboarding Playbook, etc.) RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 1.7 — Technical skills expected

Source row 1.7, Technical skills expected: awarded 1 of 1; status MET; essential flag False; gap severity NONE. The source cites: Technical skill expectations documented in tool setup guides; time-tracking tool tag-discipline skills identified; Supabase row submission and Mermaid diagram skills referenced RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 1.8 — Instructor self-introduction

Source row 1.8, Instructor self-introduction: awarded 1 of 1; status MET; essential flag False; gap severity NONE. The source cites: Instructor role and HITL responsibilities documented in M7.5 (capacity HITL), M7.7 (Offer v2.0 capacity sign-off), and M7.8 (Opus 4.7 + co-sign); instructor co-sign function clearly defined as the C8 enrollment authorization RISER review: An instructor’s assigned responsibilities do not substitute for an actual learner-facing instructor introduction.

C7 audit row 1.9 — Learner self-introduction

Source row 1.9, Learner self-introduction: awarded 1 of 1; status MET; essential flag False; gap severity NONE. The source cites: Cohort introduction via C7-Community-Prompts (#c7-offer-architecture channel); operator population identification in M7.1 Distinction Statement; cohort partner pairing established at M7.1 cohort partner review RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 2.1 — Course learning objectives measurable

Source row 2.1, Course learning objectives measurable: awarded 3 of 3; status MET; essential flag True; gap severity NONE. The source cites: 8 CLOs documented in C7-Learning-Outcomes with Bloom's level mapping; each CLO uses measurable verbs (Distinguish, Decompose, Author, Map, Analyze, Audit, Produce, Synthesize); M7.8 attestation with Opus 4.7 validator provides measurement framework RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 2.2 — Module objectives measurable and consistent with CLOs

Source row 2.2, Module objectives measurable and consistent with CLOs: awarded 3 of 3; status MET; essential flag True; gap severity NONE. The source cites: Module-level objectives in C7-Learning-Outcomes map directly to CLOs; each module's MLOs include at least one observable artifact production verb; QM standards mapping by module documented RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 2.3 — Learning objectives clearly stated

Source row 2.3, Learning objectives clearly stated: awarded 3 of 3; status MET; essential flag False; gap severity NONE. The source cites: Objectives stated in operator-facing language in C7-Course-README and per-module written lessons; objectives appear at the top of each module's written lesson; objectives use second person ('You will produce', 'You will distinguish') RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 2.4 — Relationship between objectives and activities

Source row 2.4, Relationship between objectives and activities: awarded 3 of 3; status MET; essential flag False; gap severity NONE. The source cites: Each module's written lesson explicitly ties activities to objectives; the deliverable per module is the artifact that demonstrates objective achievement; Sonnet/Opus reviewers verify activity-to-objective alignment RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 2.5 — Objectives suited to course level

Source row 2.5, Objectives suited to course level: awarded 3 of 3; status MET; essential flag False; gap severity NONE. The source cites: Bloom's distribution skews toward Analyze, Evaluate, Create at this stage of operator development (post-Stage-1, mid-Stage-2); objectives appropriate for operators who have completed C1-C6; not too advanced (no Stage 3 team-management objectives) and not too basic (no Stage 1 customer-discovery objectives) RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 3.1 — Assessments measure learning objectives

Source row 3.1, Assessments measure learning objectives: awarded 3 of 3; status MET; essential flag True; gap severity NONE. The source cites: Each module checkpoint specifies pass criteria tied to module objectives in All-Module-Checkpoints; each Sonnet/Opus reviewer has criteria mapped to objectives; M7.8 capstone assessment cross-references all 8 module objectives via attestation clauses RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 3.2 — Grading policy stated

Source row 3.2, Grading policy stated: awarded 3 of 3; status MET; essential flag True; gap severity NONE. The source cites: C7 uses pass/fail attestation rather than letter grades, consistent with operator-development pedagogy; pass criteria per module documented in All-Module-Checkpoints; resubmission policy documented; Opus VALIDATED + instructor co-sign is the C8 enrollment-authorization gate RISER review: Review the actual grading rules for contradictory thresholds and missing cases; a YAML file or named scoring scale does not establish a consistent implemented assessment.

C7 audit row 3.3 — Specific evaluation criteria

Source row 3.3, Specific evaluation criteria: awarded 3 of 3; status MET; essential flag False; gap severity NONE. The source cites: Evaluation criteria specific in each module checkpoint with common fail patterns named; Sonnet reviewer YAML files include explicit review_criteria sections with pass/partial/fail thresholds; Opus validator decision_thresholds explicitly named for VALIDATED/NEEDS_REVISION/REJECTED RISER review: Review the actual grading rules for contradictory thresholds and missing cases; a YAML file or named scoring scale does not establish a consistent implemented assessment.

C7 audit row 3.4 — Assessment instruments sequenced and varied

Source row 3.4, Assessment instruments sequenced and varied: awarded 2 of 2; status MET; essential flag True; gap severity NONE. The source cites: C7 uses six assessment instrument types: cohort partner review (M7.1, M7.2, M7.4, M7.7), Sonnet structured review (M7.2, M7.3, M7.4, M7.5, M7.7), HITL instructor review (M7.5, M7.6, M7.7, M7.8), Opus 4.7 multi-document validation (M7.8), self-check (M7.8 Section 9 + 10), and integrity clause attestation RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 3.5 — Multiple opportunities to track progress

Source row 3.5, Multiple opportunities to track progress: awarded 2 of 2; status MET; essential flag False; gap severity NONE. The source cites: Daily Completion Checklist provides daily and weekly self-tracking; cohort UI surfaces module-by-module progression with Sonnet reviewer status; HITL checkpoints provide instructor-facing progress visibility at M7.5/M7.6/M7.7/M7.8 RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 4.1 — Materials contribute to learning objectives

Source row 4.1, Materials contribute to learning objectives: awarded 3 of 3; status MET; essential flag True; gap severity NONE. The source cites: Each resource (templates, worksheets, frameworks, swipe files, reference charts) is referenced in a specific module's written lesson with named purpose; all 14+ resources tied to one of the 8 modules; SOP Construction Swipe File and Lifecycle Gate Language Swipe File directly support M7.3 and M7.4 deliverable production RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 4.2 — Materials-activities relationship explained

Source row 4.2, Materials-activities relationship explained: awarded 3 of 3; status MET; essential flag False; gap severity NONE. The source cites: Each template's purpose section explains its use in the module; written lessons reference resources by filename at point of use; the C7-Course-README maps resources to modules in the artifact list RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 4.3 — Academic integrity modeled

Source row 4.3, Academic integrity modeled: awarded 2 of 2; status MET; essential flag False; gap severity NONE. The source cites: Three new C7 integrity clauses (Honest Capacity, Architecture-vs-Pivot Distinction, SOP Operability) explicitly modeled with signature lines; C6 Iteration Discipline and Honest Customer Representation continued; attestation language in M7.8 capstone codifies integrity commitments RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 4.4 — Up-to-date theory and practice

Source row 4.4, Up-to-date theory and practice: awarded 2 of 2; status MET; essential flag False; gap severity NONE. The source cites: Time-Tracking Tool Comparison reference chart includes April 2026 verified pricing; Supabase schema reflects current PostgreSQL features (jsonb, uuid, timestamptz); Mermaid diagram syntax current; integration walkthroughs reference current tool versions RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 4.5 — Variety of instructional materials

Source row 4.5, Variety of instructional materials: awarded 2 of 2; status MET; essential flag False; gap severity NONE. The source cites: Materials span: written lessons (markdown), Mermaid diagrams (lifecycle map, module map), YAML system prompts (6), Python pivot examples (in time-tracking integration walkthrough), structured templates (8), worksheets (2), frameworks (2), reference charts (2), swipe files (2), checklists (1), case studies (4), SOPs (4) RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 5.1 — Activities promote learning objectives

Source row 5.1, Activities promote learning objectives: awarded 3 of 3; status MET; essential flag True; gap severity NONE. The source cites: Each module's activity (the deliverable production) directly produces the artifact that demonstrates the objective; M7.6 Bandwidth Audit's 14-day measurement window is the activity that produces the data the objective requires; cohort partner review activity is required at M7.1, M7.2, M7.4, M7.7 RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 5.2 — Active-learning interaction opportunities

Source row 5.2, Active-learning interaction opportunities: awarded 3 of 3; status MET; essential flag True; gap severity NONE. The source cites: Cohort partner review (4 modules); cohort-channel community prompts (08_Community-Prompts); instructor HITL conversations at M7.5/M7.6/M7.7/M7.8; Sonnet reviewer feedback cycles with operator-revision loops; the Capacity Constraint Analysis Prompt Chain provides Claude conversation as thinking-partner activity RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 5.3 — Instructor interaction plan

Source row 5.3, Instructor interaction plan: awarded 2 of 2; status MET; essential flag False; gap severity NONE. The source cites: Instructor interaction frequency documented: M7.5/M7.6 HITL (~1 substantial review per learner per week 4-5), M7.7 capacity statement sign-off (~1 review week 5-6), M7.8 Opus + co-sign (~1 review week 6-7); SLAs documented (72hr standard, 24-72hr for capstone) RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 5.4 — Learner interaction requirements

Source row 5.4, Learner interaction requirements: awarded 2 of 2; status MET; essential flag False; gap severity NONE. The source cites: Cohort partner review explicitly required at M7.1, M7.2, M7.4, M7.7; minimum quality standards for partner review documented; community prompts encourage cross-cohort engagement; cohort-channel discussion frames provided RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 6.1 — Tools support learning objectives

Source row 6.1, Tools support learning objectives: awarded 3 of 3; status MET; essential flag True; gap severity NONE. The source cites: Tools selected for direct objective support: time-tracking tools (Toggl/Harvest/Clockify) support M7.6 measurement objective; Supabase backend supports artifact submission and review tracking; Mermaid diagrams support lifecycle visualization; Sonnet/Opus reviewers support validation objectives RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 6.2 — Tools promote engagement

Source row 6.2, Tools promote engagement: awarded 2 of 2; status MET; essential flag False; gap severity NONE. The source cites: Time-tracking tool tagging discipline produces engagement data the operator can review (per-customer, per-deliverable, per-stage views); Sonnet reviewer feedback creates iteration cycles with structured push-back; Capacity Constraint Analysis Prompt Chain provides interactive thinking-partner experience RISER review: Verify the specific deployed tool version, permission behavior and learner experience. A claim that row-level security or a named model exists is not operational evidence.

C7 audit row 6.3 — Variety of technology

Source row 6.3, Variety of technology: awarded 1 of 1; status MET; essential flag False; gap severity NONE. The source cites: Technologies span: web-based time-tracking (Toggl/Harvest/Clockify), database (Supabase/PostgreSQL), diagramming (Mermaid), structured prompts (YAML), AI review (Claude Sonnet, Claude Opus 4.7), markdown documentation, optional Python notebook for pivot analysis RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 6.4 — Data privacy information

Source row 6.4, Data privacy information: awarded 1 of 1; status MET; essential flag False; gap severity NONE. The source cites: Customer-code conventions (C-01, C-02 rather than names) documented in Time-Tracking-Setup-Worksheet; Supabase RLS policies documented; vendor data handling addressed in Time-Tracking-Tool-Comparison and Time-Tracking-Tool-Setup-Guide privacy sections; cohort review anonymization referenced RISER review: Verify the specific deployed tool version, permission behavior and learner experience. A claim that row-level security or a named model exists is not operational evidence.

C7 audit row 7.1 — Technical support clear

Source row 7.1, Technical support clear: awarded 3 of 3; status MET; essential flag True; gap severity NONE. The source cites: Tool setup guides provide step-by-step click-by-click instructions; troubleshooting sections in Time-Tracking-Tool-Integration cover common issues (untagged entries, inconsistent codes, low hours, low hidden costs); cohort UI support implied; instructor escalation path via HITL RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 7.2 — Accessibility policies linked

Source row 7.2, Accessibility policies linked: awarded 3 of 3; status MET; essential flag True; gap severity NONE. The source cites: Accessibility addressed in 08_Community-Prompts and at the platform level; QM 8.x standards specifically addressed below; Mermaid diagrams have text-based source for screen-reader accessibility; markdown source format ensures readability across assistive technology RISER review: Markdown, diagram source, security certifications and vendor platform features do not by themselves establish accessibility. Inspect rendered structure, reading order, keyboard operation and relevant assistive-technology behavior.

C7 audit row 7.3 — Academic support services

Source row 7.3, Academic support services: awarded 2 of 2; status MET; essential flag False; gap severity NONE. The source cites: Cohort partner support documented; instructor support via HITL; community channel support; Daily Completion Checklist provides self-pacing tool RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 7.4 — Student services resources

Source row 7.4, Student services resources: awarded 1 of 1; status MET; essential flag False; gap severity NONE. The source cites: Cohort and instructor resources documented; community channel as peer support resource; resource set in 02_Resources serves as self-help reference RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 8.1 — Course navigation facilitates ease of use

Source row 8.1, Course navigation facilitates ease of use: awarded 3 of 3; status MET; essential flag True; gap severity NONE. The source cites: 8-folder structure consistent with C6 (cross-course consistency); files use consistent naming convention (C7-* prefix); module folders 01/M7.X organize lesson files; Course-README provides comprehensive navigation; Module-Map Mermaid diagram visualizes flow RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 8.2 — Technology accessibility information

Source row 8.2, Technology accessibility information: awarded 2 of 2; status MET; essential flag False; gap severity NONE. The source cites: Tool accessibility addressed in setup guides (Toggl Track is ISO-certified and SOC 2 Type 1 compliant per their public documentation); Supabase platform accessibility addressed at platform level; markdown format ensures accessibility RISER review: Markdown, diagram source, security certifications and vendor platform features do not by themselves establish accessibility. Inspect rendered structure, reading order, keyboard operation and relevant assistive-technology behavior.

C7 audit row 8.3 — Alternative means of access (multiple formats)

Source row 8.3, Alternative means of access (multiple formats): awarded 2 of 3; status PARTIAL; essential flag True; gap severity MEDIUM. The source cites: Only M7.1 has a companion Video Spec file; M7.2-M7.8 do not, limiting alternative-means-of-access scoring. Markdown content is screen-reader accessible by default, but the absence of video alternatives for 7 of 8 modules constrains the SRS score to 2/3. Certification requires MET status on all 16 Essential SRS items, so this is a certification-blocker. Its proposed remediation is: Add companion video specs for M7.2-M7.8 modules; M7.1 video spec serves as template. Each video spec ~2,000 words, beat-by-beat outline, slide aesthetics, atomization plan. RISER review: A video specification is not an accessible video. The source mislabels the official text-accessibility criterion as a multiple-format requirement. Assess the actual content and learner needs; do not assume every text lesson must have a video to pass.

C7 audit row 8.4 — Course design facilitates readability

Source row 8.4, Course design facilitates readability: awarded 2 of 2; status MET; essential flag False; gap severity NONE. The source cites: Markdown source ensures structural headings; consistent header levels across documents; tables used for comparison and reference; Mermaid diagrams include labels; line lengths and paragraph breaks support readability RISER review: Markdown, diagram source, security certifications and vendor platform features do not by themselves establish accessibility. Inspect rendered structure, reading order, keyboard operation and relevant assistive-technology behavior.

C7 audit row 8.5 — Multimedia ease of use

Source row 8.5, Multimedia ease of use: awarded 2 of 2; status MET; essential flag False; gap severity NONE. The source cites: M7.1 video spec provides production guidance; Mermaid diagrams included inline in markdown; audio/video alternatives where present support the content; M7.1 video spec includes captioning and accessibility specifications RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C7 audit row 8.6 — Vendor accessibility statements

Source row 8.6, Vendor accessibility statements: awarded 0 of 1; status NOT_MET; essential flag False; gap severity MEDIUM. The source cites: Vendor accessibility statements not compiled for the third-party time-tracking tools referenced in 04_Tools-and-Infrastructure (Toggl Track, Harvest, Clockify). Non-Essential SRS but fully preventable gap. Recommended remediation: add a 'Vendor Accessibility Statements' subsection to Time-Tracking-Tool-Comparison or to the Course-README, with links to each vendor's published accessibility documentation. Its proposed remediation is: Compile vendor accessibility statements from Toggl Track (https://toggl.com/accessibility), Harvest, and Clockify. Add a subsection to the Course-README or Time-Tracking-Tool-Comparison. RISER review: The source places vendor statements under 8.6, while the official seventh-edition list uses 8.7 for that topic. Retain this source finding and map it correctly before remediation.

C7 audit context — course completeness

The source summary states: Strong: 8 modules, 7 deliverable artifacts produced by operators, 1 capstone synthesis (M7.8), 6 Claude system prompts, 4 SOPs, 4 case studies, integrated cohort-and-instructor review structure Treat this as a historical course-design assertion. Confirm actual artifacts, service capacity and course-version mapping before adopting it as a current promise. The two-to-three-day certification forecast is not a validated completion estimate or official approval.

C7 audit context — doctrine introduction

The source summary states: C7 introduces three new doctrines: Honest Capacity (M7.5), Architecture-vs-Pivot Distinction (M7.7), SOP Operability (M7.3). Each doctrine has a dedicated integrity clause document and is reinforced across multiple modules. Treat this as a historical course-design assertion. Confirm actual artifacts, service capacity and course-version mapping before adopting it as a current promise. The two-to-three-day certification forecast is not a validated completion estimate or official approval.

C7 audit context — stage 2 position

The source summary states: Second course of Stage 2 (Sailboat); follows C6 Sailboat Provisioning; precedes C8 Unit Economics. C7 produces the architectural baseline that C8 measures unit economics against. Treat this as a historical course-design assertion. Confirm actual artifacts, service capacity and course-version mapping before adopting it as a current promise. The two-to-three-day certification forecast is not a validated completion estimate or official approval.

C7 audit context — primary certification blockers

The source summary states: SRS 8.3 PARTIAL: video specs only for M7.1; remediation requires producing companion video specs for M7.2-M7.8; SRS 8.6 NOT_MET: vendor accessibility statements not compiled; remediation requires adding vendor accessibility documentation Treat this as a historical course-design assertion. Confirm actual artifacts, service capacity and course-version mapping before adopting it as a current promise. The two-to-three-day certification forecast is not a validated completion estimate or official approval.

C7 audit context — expected resolution

The source summary states: Both blockers are documentation-completion items, not architectural deficiencies. Full certification is achievable in a focused 2-3 day completion sprint after initial deployment. The course can deploy as NOT_CERTIFIED and be re-audited to CERTIFIED status without architectural revision. Treat this as a historical course-design assertion. Confirm actual artifacts, service capacity and course-version mapping before adopting it as a current promise. The two-to-three-day certification forecast is not a validated completion estimate or official approval.

C7 audit context — continuity with C6

The source summary states: C7 mirrors C6 structure (8-folder layout, same artifact-class breakdown, same doctrinal continuity); cross-course narrative (Maya, Darius, Priya) advances; new failure case (Bespoke Architecture Trap) introduced. Treat this as a historical course-design assertion. Confirm actual artifacts, service capacity and course-version mapping before adopting it as a current promise. The two-to-three-day certification forecast is not a validated completion estimate or official approval.

C7 audit context — operator load

The source summary states: 50 active hours / 5-7 elapsed weeks; three non-negotiable calendar windows: M7.6 14-day measurement window, M7.5+M7.6 instructor HITL 72hr SLA, M7.8 Opus + instructor co-sign 24-72hr each. Treat this as a historical course-design assertion. Confirm actual artifacts, service capacity and course-version mapping before adopting it as a current promise. The two-to-three-day certification forecast is not a validated completion estimate or official approval.

Correct accessibility assumptions before declaring remediation complete

Provide accessible text and navigation, meaningful image alternatives and the appropriate captions, descriptions or transcripts for the actual media. Check player usability and learner support routes. A placeholder or production script does not supply those finished features. The source’s claim that only two documentation tasks remain is insufficient for a full audit; defects found in the supporting material must also be resolved.

Inspect the C7 workbook calculations

The local staged workbook has three visible tabs and 422 populated cells, with no embedded images or charts. Summary B6 sums awarded points, B7 maximum points, B8 their ratio, B9 counts source-essential rows marked MET, and B10 counts source-essential flags. B12 certification status is hardcoded and will not automatically change after edits. Remediation C7 sums its two numeric effort cells. Cached cell values match both Drive readable exports, but remote binary identity was not established.

Reconcile the C7 production estimate

The remediation plan calls for seven approximately 2,000-word video specs using the M7.1 template, beat outlines, Sailboat Teal #3B9EA0 slide styling and Shorts reuse. Two-to-three hours each totals fourteen-to-twenty-one hours, while the source says sixteen-to-twenty-one and stores sixteen. It adds two hours for vendor statements and caches eighteen total. These are writing estimates, not recorded/captioned video production or certification time. Preserve the source values and plan the actual remaining work.

Connect the lesson to the direct-marketing promise

Complete original source text

Control separators are labeled in this readable display. Download exact original text

,C7 Offer Architecture — QM Audit Scorecard,Unnamed: 1,Unnamed: 2,Unnamed: 3
0,Audit date: 2026-04-25,,,
1,Rubric: QM HE Rubric 7th Edition V2.0,,,
2,,,,
3,Metric,Value,,
4,Total points awarded,92,,
5,Maximum points,94,,
6,Percentage,0.978723404255319,,
7,Essential SRS met,15,,
8,Essential SRS total,16,,
9,Certification threshold (85%),0.85,,
10,Certification status,NOT_CERTIFIED,,
11,,,,
12,,,,
13,General Standard,Score,Max,Essentials Met
14,GS1: Course Overview and Introduction,15,15,3 / 3
15,GS2: Learning Objectives (Competencies),15,15,2 / 2
16,GS3: Assessment and Measurement,13,13,3 / 3
17,GS4: Instructional Materials,12,12,1 / 1
18,GS5: Learning Activities and Learner Interaction,10,10,2 / 2
19,GS6: Course Technology,7,7,1 / 1
20,GS7: Learner Support,9,9,2 / 2
21,GS8: Accessibility and Usability,11,13,1 / 2
22,,,,
23,,,,
24,Certification Blocking Reasons,,,
25,"SRS 8.3 PARTIAL (2/3): Only M7.1 has a companion Video Spec file; M7.2-M7.8 do not, limiting alternative-means-of-access scoring. Markdown content is screen-reader accessible by default, but the absence of video alternatives for 7 of 8 modules constrains the SRS score to 2/3. Certification requires MET status on all 16 Essential SRS items, so this is a certification-blocker.",,,
26,"SRS 8.6 NOT_MET (0/1): Vendor accessibility statements not compiled for the third-party time-tracking tools referenced in 04_Tools-and-Infrastructure (Toggl Track, Harvest, Clockify). Non-Essential SRS but fully preventable gap. Recommended remediation: add a 'Vendor Accessibility Statements' subsection to Time-Tracking-Tool-Comparison or to the Course-README, with links to each vendor's published accessibility documentation.",,,

[Source control separator U+000C]
,SRS ID,Description,Essential,Max Points,Awarded Points,Status,Evidence,Gap Severity,Remediation Hint
0,1.1,Instructions make clear how to get started,Yes,3,3,MET,C7-Course-README has explicit 'How to Use This Course' guidance with module-by-module navigation; C7-Module-Map provides Mermaid diagram with serial unlock structure (M7.5 || M7.6 parallel); C7-Prerequisites-Checklist gates enrollment with 7-section validation referencing C6 Sailboat Ready Attestation co-sign; M7.1 written lesson opens with course-positioning summary and the 3-Customer Test diagnostic,NONE,
1,1.2,Learners introduced to course purpose and structure,Yes,3,3,MET,C7-Course-README and M7.1 establish the Document vs Architecture distinction and Honest Capacity doctrine; C7-Learning-Outcomes maps 8 CLOs to module-level objectives; C7-Time-Estimate provides 50hr active / 5-7 weeks elapsed pacing with three named non-negotiable calendar windows; the Stage 2 second-course position is explicitly named,NONE,
2,1.3,Communication expectations stated clearly,Yes,2,2,MET,"Communication norms specified in C7-Lifecycle-Gate-Transition-Script and Lifecycle-Gate-Language-Swipe-File; cohort communication framed in 08_Community-Prompts; instructor turnaround SLAs (72hr for M7.5/M7.6 HITL, 24-72hr for M7.8 Opus + co-sign) documented in All-Module-Checkpoints",NONE,
3,1.4,Institutional policies clearly stated,No,2,2,MET,"Resubmission policy documented in All-Module-Checkpoints; three new C7 integrity clauses (Honest Capacity, Architecture-vs-Pivot Distinction, SOP Operability) ground course-level policies; C6 Iteration Discipline and Honest Customer Representation continued",NONE,
4,1.5,Technology requirements stated,No,1,1,MET,Tooling requirements specified in Time-Tracking-Tool-Setup-Guide and Time-Tracking-Tool-Integration walkthrough; Supabase-C7-Schema documents required infrastructure; M7.6 setup worksheet enumerates tool selection criteria,NONE,
5,1.6,Prerequisite knowledge stated,No,1,1,MET,"C7-Prerequisites-Checklist explicitly references C1-C6 completion with specific artifact requirements; Sailboat Ready Attestation co-sign required as enrollment gate; per-section verification of C6 outputs (Offer v1.1, Customer Feedback Loop, Onboarding Playbook, etc.)",NONE,
6,1.7,Technical skills expected,No,1,1,MET,Technical skill expectations documented in tool setup guides; time-tracking tool tag-discipline skills identified; Supabase row submission and Mermaid diagram skills referenced,NONE,
7,1.8,Instructor self-introduction,No,1,1,MET,"Instructor role and HITL responsibilities documented in M7.5 (capacity HITL), M7.7 (Offer v2.0 capacity sign-off), and M7.8 (Opus 4.7 + co-sign); instructor co-sign function clearly defined as the C8 enrollment authorization",NONE,
8,1.9,Learner self-introduction,No,1,1,MET,Cohort introduction via C7-Community-Prompts (#c7-offer-architecture channel); operator population identification in M7.1 Distinction Statement; cohort partner pairing established at M7.1 cohort partner review,NONE,
9,2.1,Course learning objectives measurable,Yes,3,3,MET,"8 CLOs documented in C7-Learning-Outcomes with Bloom's level mapping; each CLO uses measurable verbs (Distinguish, Decompose, Author, Map, Analyze, Audit, Produce, Synthesize); M7.8 attestation with Opus 4.7 validator provides measurement framework",NONE,
10,2.2,Module objectives measurable and consistent with CLOs,Yes,3,3,MET,Module-level objectives in C7-Learning-Outcomes map directly to CLOs; each module's MLOs include at least one observable artifact production verb; QM standards mapping by module documented,NONE,
11,2.3,Learning objectives clearly stated,No,3,3,MET,"Objectives stated in operator-facing language in C7-Course-README and per-module written lessons; objectives appear at the top of each module's written lesson; objectives use second person ('You will produce', 'You will distinguish')",NONE,
12,2.4,Relationship between objectives and activities,No,3,3,MET,Each module's written lesson explicitly ties activities to objectives; the deliverable per module is the artifact that demonstrates objective achievement; Sonnet/Opus reviewers verify activity-to-objective alignment,NONE,
13,2.5,Objectives suited to course level,No,3,3,MET,"Bloom's distribution skews toward Analyze, Evaluate, Create at this stage of operator development (post-Stage-1, mid-Stage-2); objectives appropriate for operators who have completed C1-C6; not too advanced (no Stage 3 team-management objectives) and not too basic (no Stage 1 customer-discovery objectives)",NONE,
14,3.1,Assessments measure learning objectives,Yes,3,3,MET,Each module checkpoint specifies pass criteria tied to module objectives in All-Module-Checkpoints; each Sonnet/Opus reviewer has criteria mapped to objectives; M7.8 capstone assessment cross-references all 8 module objectives via attestation clauses,NONE,
15,3.2,Grading policy stated,Yes,3,3,MET,"C7 uses pass/fail attestation rather than letter grades, consistent with operator-development pedagogy; pass criteria per module documented in All-Module-Checkpoints; resubmission policy documented; Opus VALIDATED + instructor co-sign is the C8 enrollment-authorization gate",NONE,
16,3.3,Specific evaluation criteria,No,3,3,MET,Evaluation criteria specific in each module checkpoint with common fail patterns named; Sonnet reviewer YAML files include explicit review_criteria sections with pass/partial/fail thresholds; Opus validator decision_thresholds explicitly named for VALIDATED/NEEDS_REVISION/REJECTED,NONE,
17,3.4,Assessment instruments sequenced and varied,Yes,2,2,MET,"C7 uses six assessment instrument types: cohort partner review (M7.1, M7.2, M7.4, M7.7), Sonnet structured review (M7.2, M7.3, M7.4, M7.5, M7.7), HITL instructor review (M7.5, M7.6, M7.7, M7.8), Opus 4.7 multi-document validation (M7.8), self-check (M7.8 Section 9 + 10), and integrity clause attestation",NONE,
18,3.5,Multiple opportunities to track progress,No,2,2,MET,Daily Completion Checklist provides daily and weekly self-tracking; cohort UI surfaces module-by-module progression with Sonnet reviewer status; HITL checkpoints provide instructor-facing progress visibility at M7.5/M7.6/M7.7/M7.8,NONE,
19,4.1,Materials contribute to learning objectives,Yes,3,3,MET,"Each resource (templates, worksheets, frameworks, swipe files, reference charts) is referenced in a specific module's written lesson with named purpose; all 14+ resources tied to one of the 8 modules; SOP Construction Swipe File and Lifecycle Gate Language Swipe File directly support M7.3 and M7.4 deliverable production",NONE,
20,4.2,Materials-activities relationship explained,No,3,3,MET,Each template's purpose section explains its use in the module; written lessons reference resources by filename at point of use; the C7-Course-README maps resources to modules in the artifact list,NONE,
21,4.3,Academic integrity modeled,No,2,2,MET,"Three new C7 integrity clauses (Honest Capacity, Architecture-vs-Pivot Distinction, SOP Operability) explicitly modeled with signature lines; C6 Iteration Discipline and Honest Customer Representation continued; attestation language in M7.8 capstone codifies integrity commitments",NONE,
22,4.4,Up-to-date theory and practice,No,2,2,MET,"Time-Tracking Tool Comparison reference chart includes April 2026 verified pricing; Supabase schema reflects current PostgreSQL features (jsonb, uuid, timestamptz); Mermaid diagram syntax current; integration walkthroughs reference current tool versions",NONE,
23,4.5,Variety of instructional materials,No,2,2,MET,"Materials span: written lessons (markdown), Mermaid diagrams (lifecycle map, module map), YAML system prompts (6), Python pivot examples (in time-tracking integration walkthrough), structured templates (8), worksheets (2), frameworks (2), reference charts (2), swipe files (2), checklists (1), case studies (4), SOPs (4)",NONE,
24,5.1,Activities promote learning objectives,Yes,3,3,MET,"Each module's activity (the deliverable production) directly produces the artifact that demonstrates the objective; M7.6 Bandwidth Audit's 14-day measurement window is the activity that produces the data the objective requires; cohort partner review activity is required at M7.1, M7.2, M7.4, M7.7",NONE,
25,5.2,Active-learning interaction opportunities,Yes,3,3,MET,Cohort partner review (4 modules); cohort-channel community prompts (08_Community-Prompts); instructor HITL conversations at M7.5/M7.6/M7.7/M7.8; Sonnet reviewer feedback cycles with operator-revision loops; the Capacity Constraint Analysis Prompt Chain provides Claude conversation as thinking-partner activity,NONE,
26,5.3,Instructor interaction plan,No,2,2,MET,"Instructor interaction frequency documented: M7.5/M7.6 HITL (~1 substantial review per learner per week 4-5), M7.7 capacity statement sign-off (~1 review week 5-6), M7.8 Opus + co-sign (~1 review week 6-7); SLAs documented (72hr standard, 24-72hr for capstone)",NONE,
27,5.4,Learner interaction requirements,No,2,2,MET,"Cohort partner review explicitly required at M7.1, M7.2, M7.4, M7.7; minimum quality standards for partner review documented; community prompts encourage cross-cohort engagement; cohort-channel discussion frames provided",NONE,
28,6.1,Tools support learning objectives,Yes,3,3,MET,Tools selected for direct objective support: time-tracking tools (Toggl/Harvest/Clockify) support M7.6 measurement objective; Supabase backend supports artifact submission and review tracking; Mermaid diagrams support lifecycle visualization; Sonnet/Opus reviewers support validation objectives,NONE,
29,6.2,Tools promote engagement,No,2,2,MET,"Time-tracking tool tagging discipline produces engagement data the operator can review (per-customer, per-deliverable, per-stage views); Sonnet reviewer feedback creates iteration cycles with structured push-back; Capacity Constraint Analysis Prompt Chain provides interactive thinking-partner experience",NONE,
30,6.3,Variety of technology,No,1,1,MET,"Technologies span: web-based time-tracking (Toggl/Harvest/Clockify), database (Supabase/PostgreSQL), diagramming (Mermaid), structured prompts (YAML), AI review (Claude Sonnet, Claude Opus 4.7), markdown documentation, optional Python notebook for pivot analysis",NONE,
31,6.4,Data privacy information,No,1,1,MET,"Customer-code conventions (C-01, C-02 rather than names) documented in Time-Tracking-Setup-Worksheet; Supabase RLS policies documented; vendor data handling addressed in Time-Tracking-Tool-Comparison and Time-Tracking-Tool-Setup-Guide privacy sections; cohort review anonymization referenced",NONE,
32,7.1,Technical support clear,Yes,3,3,MET,"Tool setup guides provide step-by-step click-by-click instructions; troubleshooting sections in Time-Tracking-Tool-Integration cover common issues (untagged entries, inconsistent codes, low hours, low hidden costs); cohort UI support implied; instructor escalation path via HITL",NONE,
33,7.2,Accessibility policies linked,Yes,3,3,MET,Accessibility addressed in 08_Community-Prompts and at the platform level; QM 8.x standards specifically addressed below; Mermaid diagrams have text-based source for screen-reader accessibility; markdown source format ensures readability across assistive technology,NONE,
34,7.3,Academic support services,No,2,2,MET,Cohort partner support documented; instructor support via HITL; community channel support; Daily Completion Checklist provides self-pacing tool,NONE,
35,7.4,Student services resources,No,1,1,MET,Cohort and instructor resources documented; community channel as peer support resource; resource set in 02_Resources serves as self-help reference,NONE,
36,8.1,Course navigation facilitates ease of use,Yes,3,3,MET,8-folder structure consistent with C6 (cross-course consistency); files use consistent naming convention (C7-* prefix); module folders 01/M7.X organize lesson files; Course-README provides comprehensive navigation; Module-Map Mermaid diagram visualizes flow,NONE,
37,8.2,Technology accessibility information,No,2,2,MET,Tool accessibility addressed in setup guides (Toggl Track is ISO-certified and SOC 2 Type 1 compliant per their public documentation); Supabase platform accessibility addressed at platform level; markdown format ensures accessibility,NONE,
38,8.3,Alternative means of access (multiple formats),Yes,3,2,PARTIAL,"Only M7.1 has a companion Video Spec file; M7.2-M7.8 do not, limiting alternative-means-of-access scoring. Markdown content is screen-reader accessible by default, but the absence of video alternatives for 7 of 8 modules constrains the SRS score to 2/3. Certification requires MET status on all 16 Essential SRS items, so this is a certification-blocker.",MEDIUM,"Add companion video specs for M7.2-M7.8 modules; M7.1 video spec serves as template. Each video spec ~2,000 words, beat-by-beat outline, slide aesthetics, atomization plan."
39,8.4,Course design facilitates readability,No,2,2,MET,Markdown source ensures structural headings; consistent header levels across documents; tables used for comparison and reference; Mermaid diagrams include labels; line lengths and paragraph breaks support readability,NONE,
40,8.5,Multimedia ease of use,No,2,2,MET,M7.1 video spec provides production guidance; Mermaid diagrams included inline in markdown; audio/video alternatives where present support the content; M7.1 video spec includes captioning and accessibility specifications,NONE,
41,8.6,Vendor accessibility statements,No,1,0,NOT_MET,"Vendor accessibility statements not compiled for the third-party time-tracking tools referenced in 04_Tools-and-Infrastructure (Toggl Track, Harvest, Clockify). Non-Essential SRS but fully preventable gap. Recommended remediation: add a 'Vendor Accessibility Statements' subsection to Time-Tracking-Tool-Comparison or to the Course-README, with links to each vendor's published accessibility documentation.",MEDIUM,"Compile vendor accessibility statements from Toggl Track (https://toggl.com/accessibility), Harvest, and Clockify. Add a subsection to the Course-README or Time-Tracking-Tool-Comparison."

[Source control separator U+000C]
,C7 Remediation Plan,Unnamed: 1,Unnamed: 2,Unnamed: 3
0,Items required to move from NOT_CERTIFIED → CERTIFIED. Both items below are documentation-completion tasks; no architectural revision required.,,,
1,,,,
2,SRS ID,Status,Effort (hrs),Remediation Action
3,8.3,PARTIAL,16,"Author 7 companion video specs (M7.2 through M7.8). Use M7.1-Video-Spec.md as the template; each spec ~2,000 words covering beat-by-beat outline, slide aesthetics in Sailboat Teal #3B9EA0, and Shorts atomization plan. Estimated effort: 2-3 hours per spec, total 16-21 hours."
4,8.6,NOT_MET,2,"Compile vendor accessibility statements for time-tracking tools. Add a 'Vendor Accessibility Statements' subsection to C7-Time-Tracking-Tool-Comparison.md. Sources: Toggl Track public accessibility documentation, Harvest accessibility statement, Clockify accessibility documentation. Estimated effort: 2 hours."
5,TOTAL,,18,Total estimated effort to achieve CERTIFIED status

Complete source variant 2

Control separators are labeled in this readable display. Download exact original text

,C7 Offer Architecture — QM Audit Scorecard,Unnamed: 1,Unnamed: 2,Unnamed: 3
0,Audit date: 2026-04-25,,,
1,Rubric: QM HE Rubric 7th Edition V2.0,,,
2,,,,
3,Metric,Value,,
4,Total points awarded,92,,
5,Maximum points,94,,
6,Percentage,0.978723404255319,,
7,Essential SRS met,15,,
8,Essential SRS total,16,,
9,Certification threshold (85%),0.85,,
10,Certification status,NOT_CERTIFIED,,
11,,,,
12,,,,
13,General Standard,Score,Max,Essentials Met
14,GS1: Course Overview and Introduction,15,15,3 / 3
15,GS2: Learning Objectives (Competencies),15,15,2 / 2
16,GS3: Assessment and Measurement,13,13,3 / 3
17,GS4: Instructional Materials,12,12,1 / 1
18,GS5: Learning Activities and Learner Interaction,10,10,2 / 2
19,GS6: Course Technology,7,7,1 / 1
20,GS7: Learner Support,9,9,2 / 2
21,GS8: Accessibility and Usability,11,13,1 / 2
22,,,,
23,,,,
24,Certification Blocking Reasons,,,
25,"SRS 8.3 PARTIAL (2/3): Only M7.1 has a companion Video Spec file; M7.2-M7.8 do not, limiting alternative-means-of-access scoring. Markdown content is screen-reader accessible by default, but the absence of video alternatives for 7 of 8 modules constrains the SRS score to 2/3. Certification requires MET status on all 16 Essential SRS items, so this is a certification-blocker.",,,
26,"SRS 8.6 NOT_MET (0/1): Vendor accessibility statements not compiled for the third-party time-tracking tools referenced in 04_Tools-and-Infrastructure (Toggl Track, Harvest, Clockify). Non-Essential SRS but fully preventable gap. Recommended remediation: add a 'Vendor Accessibility Statements' subsection to Time-Tracking-Tool-Comparison or to the Course-README, with links to each vendor's published accessibility documentation.",,,

[Source control separator U+000C]
,SRS ID,Description,Essential,Max Points,Awarded Points,Status,Evidence,Gap Severity,Remediation Hint
0,1.1,Instructions make clear how to get started,Yes,3,3,MET,C7-Course-README has explicit 'How to Use This Course' guidance with module-by-module navigation; C7-Module-Map provides Mermaid diagram with serial unlock structure (M7.5 || M7.6 parallel); C7-Prerequisites-Checklist gates enrollment with 7-section validation referencing C6 Sailboat Ready Attestation co-sign; M7.1 written lesson opens with course-positioning summary and the 3-Customer Test diagnostic,NONE,
1,1.2,Learners introduced to course purpose and structure,Yes,3,3,MET,C7-Course-README and M7.1 establish the Document vs Architecture distinction and Honest Capacity doctrine; C7-Learning-Outcomes maps 8 CLOs to module-level objectives; C7-Time-Estimate provides 50hr active / 5-7 weeks elapsed pacing with three named non-negotiable calendar windows; the Stage 2 second-course position is explicitly named,NONE,
2,1.3,Communication expectations stated clearly,Yes,2,2,MET,"Communication norms specified in C7-Lifecycle-Gate-Transition-Script and Lifecycle-Gate-Language-Swipe-File; cohort communication framed in 08_Community-Prompts; instructor turnaround SLAs (72hr for M7.5/M7.6 HITL, 24-72hr for M7.8 Opus + co-sign) documented in All-Module-Checkpoints",NONE,
3,1.4,Institutional policies clearly stated,No,2,2,MET,"Resubmission policy documented in All-Module-Checkpoints; three new C7 integrity clauses (Honest Capacity, Architecture-vs-Pivot Distinction, SOP Operability) ground course-level policies; C6 Iteration Discipline and Honest Customer Representation continued",NONE,
4,1.5,Technology requirements stated,No,1,1,MET,Tooling requirements specified in Time-Tracking-Tool-Setup-Guide and Time-Tracking-Tool-Integration walkthrough; Supabase-C7-Schema documents required infrastructure; M7.6 setup worksheet enumerates tool selection criteria,NONE,
5,1.6,Prerequisite knowledge stated,No,1,1,MET,"C7-Prerequisites-Checklist explicitly references C1-C6 completion with specific artifact requirements; Sailboat Ready Attestation co-sign required as enrollment gate; per-section verification of C6 outputs (Offer v1.1, Customer Feedback Loop, Onboarding Playbook, etc.)",NONE,
6,1.7,Technical skills expected,No,1,1,MET,Technical skill expectations documented in tool setup guides; time-tracking tool tag-discipline skills identified; Supabase row submission and Mermaid diagram skills referenced,NONE,
7,1.8,Instructor self-introduction,No,1,1,MET,"Instructor role and HITL responsibilities documented in M7.5 (capacity HITL), M7.7 (Offer v2.0 capacity sign-off), and M7.8 (Opus 4.7 + co-sign); instructor co-sign function clearly defined as the C8 enrollment authorization",NONE,
8,1.9,Learner self-introduction,No,1,1,MET,Cohort introduction via C7-Community-Prompts (#c7-offer-architecture channel); operator population identification in M7.1 Distinction Statement; cohort partner pairing established at M7.1 cohort partner review,NONE,
9,2.1,Course learning objectives measurable,Yes,3,3,MET,"8 CLOs documented in C7-Learning-Outcomes with Bloom's level mapping; each CLO uses measurable verbs (Distinguish, Decompose, Author, Map, Analyze, Audit, Produce, Synthesize); M7.8 attestation with Opus 4.7 validator provides measurement framework",NONE,
10,2.2,Module objectives measurable and consistent with CLOs,Yes,3,3,MET,Module-level objectives in C7-Learning-Outcomes map directly to CLOs; each module's MLOs include at least one observable artifact production verb; QM standards mapping by module documented,NONE,
11,2.3,Learning objectives clearly stated,No,3,3,MET,"Objectives stated in operator-facing language in C7-Course-README and per-module written lessons; objectives appear at the top of each module's written lesson; objectives use second person ('You will produce', 'You will distinguish')",NONE,
12,2.4,Relationship between objectives and activities,No,3,3,MET,Each module's written lesson explicitly ties activities to objectives; the deliverable per module is the artifact that demonstrates objective achievement; Sonnet/Opus reviewers verify activity-to-objective alignment,NONE,
13,2.5,Objectives suited to course level,No,3,3,MET,"Bloom's distribution skews toward Analyze, Evaluate, Create at this stage of operator development (post-Stage-1, mid-Stage-2); objectives appropriate for operators who have completed C1-C6; not too advanced (no Stage 3 team-management objectives) and not too basic (no Stage 1 customer-discovery objectives)",NONE,
14,3.1,Assessments measure learning objectives,Yes,3,3,MET,Each module checkpoint specifies pass criteria tied to module objectives in All-Module-Checkpoints; each Sonnet/Opus reviewer has criteria mapped to objectives; M7.8 capstone assessment cross-references all 8 module objectives via attestation clauses,NONE,
15,3.2,Grading policy stated,Yes,3,3,MET,"C7 uses pass/fail attestation rather than letter grades, consistent with operator-development pedagogy; pass criteria per module documented in All-Module-Checkpoints; resubmission policy documented; Opus VALIDATED + instructor co-sign is the C8 enrollment-authorization gate",NONE,
16,3.3,Specific evaluation criteria,No,3,3,MET,Evaluation criteria specific in each module checkpoint with common fail patterns named; Sonnet reviewer YAML files include explicit review_criteria sections with pass/partial/fail thresholds; Opus validator decision_thresholds explicitly named for VALIDATED/NEEDS_REVISION/REJECTED,NONE,
17,3.4,Assessment instruments sequenced and varied,Yes,2,2,MET,"C7 uses six assessment instrument types: cohort partner review (M7.1, M7.2, M7.4, M7.7), Sonnet structured review (M7.2, M7.3, M7.4, M7.5, M7.7), HITL instructor review (M7.5, M7.6, M7.7, M7.8), Opus 4.7 multi-document validation (M7.8), self-check (M7.8 Section 9 + 10), and integrity clause attestation",NONE,
18,3.5,Multiple opportunities to track progress,No,2,2,MET,Daily Completion Checklist provides daily and weekly self-tracking; cohort UI surfaces module-by-module progression with Sonnet reviewer status; HITL checkpoints provide instructor-facing progress visibility at M7.5/M7.6/M7.7/M7.8,NONE,
19,4.1,Materials contribute to learning objectives,Yes,3,3,MET,"Each resource (templates, worksheets, frameworks, swipe files, reference charts) is referenced in a specific module's written lesson with named purpose; all 14+ resources tied to one of the 8 modules; SOP Construction Swipe File and Lifecycle Gate Language Swipe File directly support M7.3 and M7.4 deliverable production",NONE,
20,4.2,Materials-activities relationship explained,No,3,3,MET,Each template's purpose section explains its use in the module; written lessons reference resources by filename at point of use; the C7-Course-README maps resources to modules in the artifact list,NONE,
21,4.3,Academic integrity modeled,No,2,2,MET,"Three new C7 integrity clauses (Honest Capacity, Architecture-vs-Pivot Distinction, SOP Operability) explicitly modeled with signature lines; C6 Iteration Discipline and Honest Customer Representation continued; attestation language in M7.8 capstone codifies integrity commitments",NONE,
22,4.4,Up-to-date theory and practice,No,2,2,MET,"Time-Tracking Tool Comparison reference chart includes April 2026 verified pricing; Supabase schema reflects current PostgreSQL features (jsonb, uuid, timestamptz); Mermaid diagram syntax current; integration walkthroughs reference current tool versions",NONE,
23,4.5,Variety of instructional materials,No,2,2,MET,"Materials span: written lessons (markdown), Mermaid diagrams (lifecycle map, module map), YAML system prompts (6), Python pivot examples (in time-tracking integration walkthrough), structured templates (8), worksheets (2), frameworks (2), reference charts (2), swipe files (2), checklists (1), case studies (4), SOPs (4)",NONE,
24,5.1,Activities promote learning objectives,Yes,3,3,MET,"Each module's activity (the deliverable production) directly produces the artifact that demonstrates the objective; M7.6 Bandwidth Audit's 14-day measurement window is the activity that produces the data the objective requires; cohort partner review activity is required at M7.1, M7.2, M7.4, M7.7",NONE,
25,5.2,Active-learning interaction opportunities,Yes,3,3,MET,Cohort partner review (4 modules); cohort-channel community prompts (08_Community-Prompts); instructor HITL conversations at M7.5/M7.6/M7.7/M7.8; Sonnet reviewer feedback cycles with operator-revision loops; the Capacity Constraint Analysis Prompt Chain provides Claude conversation as thinking-partner activity,NONE,
26,5.3,Instructor interaction plan,No,2,2,MET,"Instructor interaction frequency documented: M7.5/M7.6 HITL (~1 substantial review per learner per week 4-5), M7.7 capacity statement sign-off (~1 review week 5-6), M7.8 Opus + co-sign (~1 review week 6-7); SLAs documented (72hr standard, 24-72hr for capstone)",NONE,
27,5.4,Learner interaction requirements,No,2,2,MET,"Cohort partner review explicitly required at M7.1, M7.2, M7.4, M7.7; minimum quality standards for partner review documented; community prompts encourage cross-cohort engagement; cohort-channel discussion frames provided",NONE,
28,6.1,Tools support learning objectives,Yes,3,3,MET,Tools selected for direct objective support: time-tracking tools (Toggl/Harvest/Clockify) support M7.6 measurement objective; Supabase backend supports artifact submission and review tracking; Mermaid diagrams support lifecycle visualization; Sonnet/Opus reviewers support validation objectives,NONE,
29,6.2,Tools promote engagement,No,2,2,MET,"Time-tracking tool tagging discipline produces engagement data the operator can review (per-customer, per-deliverable, per-stage views); Sonnet reviewer feedback creates iteration cycles with structured push-back; Capacity Constraint Analysis Prompt Chain provides interactive thinking-partner experience",NONE,
30,6.3,Variety of technology,No,1,1,MET,"Technologies span: web-based time-tracking (Toggl/Harvest/Clockify), database (Supabase/PostgreSQL), diagramming (Mermaid), structured prompts (YAML), AI review (Claude Sonnet, Claude Opus 4.7), markdown documentation, optional Python notebook for pivot analysis",NONE,
31,6.4,Data privacy information,No,1,1,MET,"Customer-code conventions (C-01, C-02 rather than names) documented in Time-Tracking-Setup-Worksheet; Supabase RLS policies documented; vendor data handling addressed in Time-Tracking-Tool-Comparison and Time-Tracking-Tool-Setup-Guide privacy sections; cohort review anonymization referenced",NONE,
32,7.1,Technical support clear,Yes,3,3,MET,"Tool setup guides provide step-by-step click-by-click instructions; troubleshooting sections in Time-Tracking-Tool-Integration cover common issues (untagged entries, inconsistent codes, low hours, low hidden costs); cohort UI support implied; instructor escalation path via HITL",NONE,
33,7.2,Accessibility policies linked,Yes,3,3,MET,Accessibility addressed in 08_Community-Prompts and at the platform level; QM 8.x standards specifically addressed below; Mermaid diagrams have text-based source for screen-reader accessibility; markdown source format ensures readability across assistive technology,NONE,
34,7.3,Academic support services,No,2,2,MET,Cohort partner support documented; instructor support via HITL; community channel support; Daily Completion Checklist provides self-pacing tool,NONE,
35,7.4,Student services resources,No,1,1,MET,Cohort and instructor resources documented; community channel as peer support resource; resource set in 02_Resources serves as self-help reference,NONE,
36,8.1,Course navigation facilitates ease of use,Yes,3,3,MET,8-folder structure consistent with C6 (cross-course consistency); files use consistent naming convention (C7-* prefix); module folders 01/M7.X organize lesson files; Course-README provides comprehensive navigation; Module-Map Mermaid diagram visualizes flow,NONE,
37,8.2,Technology accessibility information,No,2,2,MET,Tool accessibility addressed in setup guides (Toggl Track is ISO-certified and SOC 2 Type 1 compliant per their public documentation); Supabase platform accessibility addressed at platform level; markdown format ensures accessibility,NONE,
38,8.3,Alternative means of access (multiple formats),Yes,3,2,PARTIAL,"Only M7.1 has a companion Video Spec file; M7.2-M7.8 do not, limiting alternative-means-of-access scoring. Markdown content is screen-reader accessible by default, but the absence of video alternatives for 7 of 8 modules constrains the SRS score to 2/3. Certification requires MET status on all 16 Essential SRS items, so this is a certification-blocker.",MEDIUM,"Add companion video specs for M7.2-M7.8 modules; M7.1 video spec serves as template. Each video spec ~2,000 words, beat-by-beat outline, slide aesthetics, atomization plan."
39,8.4,Course design facilitates readability,No,2,2,MET,Markdown source ensures structural headings; consistent header levels across documents; tables used for comparison and reference; Mermaid diagrams include labels; line lengths and paragraph breaks support readability,NONE,
40,8.5,Multimedia ease of use,No,2,2,MET,M7.1 video spec provides production guidance; Mermaid diagrams included inline in markdown; audio/video alternatives where present support the content; M7.1 video spec includes captioning and accessibility specifications,NONE,
41,8.6,Vendor accessibility statements,No,1,0,NOT_MET,"Vendor accessibility statements not compiled for the third-party time-tracking tools referenced in 04_Tools-and-Infrastructure (Toggl Track, Harvest, Clockify). Non-Essential SRS but fully preventable gap. Recommended remediation: add a 'Vendor Accessibility Statements' subsection to Time-Tracking-Tool-Comparison or to the Course-README, with links to each vendor's published accessibility documentation.",MEDIUM,"Compile vendor accessibility statements from Toggl Track (https://toggl.com/accessibility), Harvest, and Clockify. Add a subsection to the Course-README or Time-Tracking-Tool-Comparison."

[Source control separator U+000C]
,C7 Remediation Plan,Unnamed: 1,Unnamed: 2,Unnamed: 3
0,Items required to move from NOT_CERTIFIED → CERTIFIED. Both items below are documentation-completion tasks; no architectural revision required.,,,
1,,,,
2,SRS ID,Status,Effort (hrs),Remediation Action
3,8.3,PARTIAL,16,"Author 7 companion video specs (M7.2 through M7.8). Use M7.1-Video-Spec.md as the template; each spec ~2,000 words covering beat-by-beat outline, slide aesthetics in Sailboat Teal #3B9EA0, and Shorts atomization plan. Estimated effort: 2-3 hours per spec, total 16-21 hours."
4,8.6,NOT_MET,2,"Compile vendor accessibility statements for time-tracking tools. Add a 'Vendor Accessibility Statements' subsection to C7-Time-Tracking-Tool-Comparison.md. Sources: Toggl Track public accessibility documentation, Harvest accessibility statement, Clockify accessibility documentation. Estimated effort: 2 hours."
5,TOTAL,,18,Total estimated effort to achieve CERTIFIED status

Local staged workbook: all cached cell values match the corresponding readable Drive export. Remote binary identity was not established. Cell addresses, formulas and cached results are retained below; formulas are source text, not executed.

Complete local staged workbook cells — variant 1

# Summary
A1: C7 Offer Architecture — QM Audit Scorecard
A2: Audit date: 2026-04-25
A3: Rubric: QM HE Rubric 7th Edition V2.0
A5: Metric
B5: Value
A6: Total points awarded
B6: =SUM('SRS Detail'!E2:E43) [cached 92]
A7: Maximum points
B7: =SUM('SRS Detail'!D2:D43) [cached 94]
A8: Percentage
B8: =B6/B7 [cached 0.978723404255319]
A9: Essential SRS met
B9: =COUNTIFS('SRS Detail'!C2:C43,"Yes",'SRS Detail'!F2:F43,"MET") [cached 15]
A10: Essential SRS total
B10: =COUNTIF('SRS Detail'!C2:C43,"Yes") [cached 16]
A11: Certification threshold (85%)
B11: 0.85
A12: Certification status
B12: NOT_CERTIFIED
A15: General Standard
B15: Score
C15: Max
D15: Essentials Met
A16: GS1: Course Overview and Introduction
B16: 15
C16: 15
D16: 3 / 3
A17: GS2: Learning Objectives (Competencies)
B17: 15
C17: 15
D17: 2 / 2
A18: GS3: Assessment and Measurement
B18: 13
C18: 13
D18: 3 / 3
A19: GS4: Instructional Materials
B19: 12
C19: 12
D19: 1 / 1
A20: GS5: Learning Activities and Learner Interaction
B20: 10
C20: 10
D20: 2 / 2
A21: GS6: Course Technology
B21: 7
C21: 7
D21: 1 / 1
A22: GS7: Learner Support
B22: 9
C22: 9
D22: 2 / 2
A23: GS8: Accessibility and Usability
B23: 11
C23: 13
D23: 1 / 2
A26: Certification Blocking Reasons
A27: SRS 8.3 PARTIAL (2/3): Only M7.1 has a companion Video Spec file; M7.2-M7.8 do not, limiting alternative-means-of-access scoring. Markdown content is screen-reader accessible by default, but the absence of video alternatives for 7 of 8 modules constrains the SRS score to 2/3. Certification requires MET status on all 16 Essential SRS items, so this is a certification-blocker.
A28: SRS 8.6 NOT_MET (0/1): Vendor accessibility statements not compiled for the third-party time-tracking tools referenced in 04_Tools-and-Infrastructure (Toggl Track, Harvest, Clockify). Non-Essential SRS but fully preventable gap. Recommended remediation: add a 'Vendor Accessibility Statements' subsection to Time-Tracking-Tool-Comparison or to the Course-README, with links to each vendor's published accessibility documentation.
# SRS Detail
A1: SRS ID
B1: Description
C1: Essential
D1: Max Points
E1: Awarded Points
F1: Status
G1: Evidence
H1: Gap Severity
I1: Remediation Hint
A2: 1.1
B2: Instructions make clear how to get started
C2: Yes
D2: 3
E2: 3
F2: MET
G2: C7-Course-README has explicit 'How to Use This Course' guidance with module-by-module navigation; C7-Module-Map provides Mermaid diagram with serial unlock structure (M7.5 || M7.6 parallel); C7-Prerequisites-Checklist gates enrollment with 7-section validation referencing C6 Sailboat Ready Attestation co-sign; M7.1 written lesson opens with course-positioning summary and the 3-Customer Test diagnostic
H2: NONE
A3: 1.2
B3: Learners introduced to course purpose and structure
C3: Yes
D3: 3
E3: 3
F3: MET
G3: C7-Course-README and M7.1 establish the Document vs Architecture distinction and Honest Capacity doctrine; C7-Learning-Outcomes maps 8 CLOs to module-level objectives; C7-Time-Estimate provides 50hr active / 5-7 weeks elapsed pacing with three named non-negotiable calendar windows; the Stage 2 second-course position is explicitly named
H3: NONE
A4: 1.3
B4: Communication expectations stated clearly
C4: Yes
D4: 2
E4: 2
F4: MET
G4: Communication norms specified in C7-Lifecycle-Gate-Transition-Script and Lifecycle-Gate-Language-Swipe-File; cohort communication framed in 08_Community-Prompts; instructor turnaround SLAs (72hr for M7.5/M7.6 HITL, 24-72hr for M7.8 Opus + co-sign) documented in All-Module-Checkpoints
H4: NONE
A5: 1.4
B5: Institutional policies clearly stated
C5: No
D5: 2
E5: 2
F5: MET
G5: Resubmission policy documented in All-Module-Checkpoints; three new C7 integrity clauses (Honest Capacity, Architecture-vs-Pivot Distinction, SOP Operability) ground course-level policies; C6 Iteration Discipline and Honest Customer Representation continued
H5: NONE
A6: 1.5
B6: Technology requirements stated
C6: No
D6: 1
E6: 1
F6: MET
G6: Tooling requirements specified in Time-Tracking-Tool-Setup-Guide and Time-Tracking-Tool-Integration walkthrough; Supabase-C7-Schema documents required infrastructure; M7.6 setup worksheet enumerates tool selection criteria
H6: NONE
A7: 1.6
B7: Prerequisite knowledge stated
C7: No
D7: 1
E7: 1
F7: MET
G7: C7-Prerequisites-Checklist explicitly references C1-C6 completion with specific artifact requirements; Sailboat Ready Attestation co-sign required as enrollment gate; per-section verification of C6 outputs (Offer v1.1, Customer Feedback Loop, Onboarding Playbook, etc.)
H7: NONE
A8: 1.7
B8: Technical skills expected
C8: No
D8: 1
E8: 1
F8: MET
G8: Technical skill expectations documented in tool setup guides; time-tracking tool tag-discipline skills identified; Supabase row submission and Mermaid diagram skills referenced
H8: NONE
A9: 1.8
B9: Instructor self-introduction
C9: No
D9: 1
E9: 1
F9: MET
G9: Instructor role and HITL responsibilities documented in M7.5 (capacity HITL), M7.7 (Offer v2.0 capacity sign-off), and M7.8 (Opus 4.7 + co-sign); instructor co-sign function clearly defined as the C8 enrollment authorization
H9: NONE
A10: 1.9
B10: Learner self-introduction
C10: No
D10: 1
E10: 1
F10: MET
G10: Cohort introduction via C7-Community-Prompts (#c7-offer-architecture channel); operator population identification in M7.1 Distinction Statement; cohort partner pairing established at M7.1 cohort partner review
H10: NONE
A11: 2.1
B11: Course learning objectives measurable
C11: Yes
D11: 3
E11: 3
F11: MET
G11: 8 CLOs documented in C7-Learning-Outcomes with Bloom's level mapping; each CLO uses measurable verbs (Distinguish, Decompose, Author, Map, Analyze, Audit, Produce, Synthesize); M7.8 attestation with Opus 4.7 validator provides measurement framework
H11: NONE
A12: 2.2
B12: Module objectives measurable and consistent with CLOs
C12: Yes
D12: 3
E12: 3
F12: MET
G12: Module-level objectives in C7-Learning-Outcomes map directly to CLOs; each module's MLOs include at least one observable artifact production verb; QM standards mapping by module documented
H12: NONE
A13: 2.3
B13: Learning objectives clearly stated
C13: No
D13: 3
E13: 3
F13: MET
G13: Objectives stated in operator-facing language in C7-Course-README and per-module written lessons; objectives appear at the top of each module's written lesson; objectives use second person ('You will produce', 'You will distinguish')
H13: NONE
A14: 2.4
B14: Relationship between objectives and activities
C14: No
D14: 3
E14: 3
F14: MET
G14: Each module's written lesson explicitly ties activities to objectives; the deliverable per module is the artifact that demonstrates objective achievement; Sonnet/Opus reviewers verify activity-to-objective alignment
H14: NONE
A15: 2.5
B15: Objectives suited to course level
C15: No
D15: 3
E15: 3
F15: MET
G15: Bloom's distribution skews toward Analyze, Evaluate, Create at this stage of operator development (post-Stage-1, mid-Stage-2); objectives appropriate for operators who have completed C1-C6; not too advanced (no Stage 3 team-management objectives) and not too basic (no Stage 1 customer-discovery objectives)
H15: NONE
A16: 3.1
B16: Assessments measure learning objectives
C16: Yes
D16: 3
E16: 3
F16: MET
G16: Each module checkpoint specifies pass criteria tied to module objectives in All-Module-Checkpoints; each Sonnet/Opus reviewer has criteria mapped to objectives; M7.8 capstone assessment cross-references all 8 module objectives via attestation clauses
H16: NONE
A17: 3.2
B17: Grading policy stated
C17: Yes
D17: 3
E17: 3
F17: MET
G17: C7 uses pass/fail attestation rather than letter grades, consistent with operator-development pedagogy; pass criteria per module documented in All-Module-Checkpoints; resubmission policy documented; Opus VALIDATED + instructor co-sign is the C8 enrollment-authorization gate
H17: NONE
A18: 3.3
B18: Specific evaluation criteria
C18: No
D18: 3
E18: 3
F18: MET
G18: Evaluation criteria specific in each module checkpoint with common fail patterns named; Sonnet reviewer YAML files include explicit review_criteria sections with pass/partial/fail thresholds; Opus validator decision_thresholds explicitly named for VALIDATED/NEEDS_REVISION/REJECTED
H18: NONE
A19: 3.4
B19: Assessment instruments sequenced and varied
C19: Yes
D19: 2
E19: 2
F19: MET
G19: C7 uses six assessment instrument types: cohort partner review (M7.1, M7.2, M7.4, M7.7), Sonnet structured review (M7.2, M7.3, M7.4, M7.5, M7.7), HITL instructor review (M7.5, M7.6, M7.7, M7.8), Opus 4.7 multi-document validation (M7.8), self-check (M7.8 Section 9 + 10), and integrity clause attestation
H19: NONE
A20: 3.5
B20: Multiple opportunities to track progress
C20: No
D20: 2
E20: 2
F20: MET
G20: Daily Completion Checklist provides daily and weekly self-tracking; cohort UI surfaces module-by-module progression with Sonnet reviewer status; HITL checkpoints provide instructor-facing progress visibility at M7.5/M7.6/M7.7/M7.8
H20: NONE
A21: 4.1
B21: Materials contribute to learning objectives
C21: Yes
D21: 3
E21: 3
F21: MET
G21: Each resource (templates, worksheets, frameworks, swipe files, reference charts) is referenced in a specific module's written lesson with named purpose; all 14+ resources tied to one of the 8 modules; SOP Construction Swipe File and Lifecycle Gate Language Swipe File directly support M7.3 and M7.4 deliverable production
H21: NONE
A22: 4.2
B22: Materials-activities relationship explained
C22: No
D22: 3
E22: 3
F22: MET
G22: Each template's purpose section explains its use in the module; written lessons reference resources by filename at point of use; the C7-Course-README maps resources to modules in the artifact list
H22: NONE
A23: 4.3
B23: Academic integrity modeled
C23: No
D23: 2
E23: 2
F23: MET
G23: Three new C7 integrity clauses (Honest Capacity, Architecture-vs-Pivot Distinction, SOP Operability) explicitly modeled with signature lines; C6 Iteration Discipline and Honest Customer Representation continued; attestation language in M7.8 capstone codifies integrity commitments
H23: NONE
A24: 4.4
B24: Up-to-date theory and practice
C24: No
D24: 2
E24: 2
F24: MET
G24: Time-Tracking Tool Comparison reference chart includes April 2026 verified pricing; Supabase schema reflects current PostgreSQL features (jsonb, uuid, timestamptz); Mermaid diagram syntax current; integration walkthroughs reference current tool versions
H24: NONE
A25: 4.5
B25: Variety of instructional materials
C25: No
D25: 2
E25: 2
F25: MET
G25: Materials span: written lessons (markdown), Mermaid diagrams (lifecycle map, module map), YAML system prompts (6), Python pivot examples (in time-tracking integration walkthrough), structured templates (8), worksheets (2), frameworks (2), reference charts (2), swipe files (2), checklists (1), case studies (4), SOPs (4)
H25: NONE
A26: 5.1
B26: Activities promote learning objectives
C26: Yes
D26: 3
E26: 3
F26: MET
G26: Each module's activity (the deliverable production) directly produces the artifact that demonstrates the objective; M7.6 Bandwidth Audit's 14-day measurement window is the activity that produces the data the objective requires; cohort partner review activity is required at M7.1, M7.2, M7.4, M7.7
H26: NONE
A27: 5.2
B27: Active-learning interaction opportunities
C27: Yes
D27: 3
E27: 3
F27: MET
G27: Cohort partner review (4 modules); cohort-channel community prompts (08_Community-Prompts); instructor HITL conversations at M7.5/M7.6/M7.7/M7.8; Sonnet reviewer feedback cycles with operator-revision loops; the Capacity Constraint Analysis Prompt Chain provides Claude conversation as thinking-partner activity
H27: NONE
A28: 5.3
B28: Instructor interaction plan
C28: No
D28: 2
E28: 2
F28: MET
G28: Instructor interaction frequency documented: M7.5/M7.6 HITL (~1 substantial review per learner per week 4-5), M7.7 capacity statement sign-off (~1 review week 5-6), M7.8 Opus + co-sign (~1 review week 6-7); SLAs documented (72hr standard, 24-72hr for capstone)
H28: NONE
A29: 5.4
B29: Learner interaction requirements
C29: No
D29: 2
E29: 2
F29: MET
G29: Cohort partner review explicitly required at M7.1, M7.2, M7.4, M7.7; minimum quality standards for partner review documented; community prompts encourage cross-cohort engagement; cohort-channel discussion frames provided
H29: NONE
A30: 6.1
B30: Tools support learning objectives
C30: Yes
D30: 3
E30: 3
F30: MET
G30: Tools selected for direct objective support: time-tracking tools (Toggl/Harvest/Clockify) support M7.6 measurement objective; Supabase backend supports artifact submission and review tracking; Mermaid diagrams support lifecycle visualization; Sonnet/Opus reviewers support validation objectives
H30: NONE
A31: 6.2
B31: Tools promote engagement
C31: No
D31: 2
E31: 2
F31: MET
G31: Time-tracking tool tagging discipline produces engagement data the operator can review (per-customer, per-deliverable, per-stage views); Sonnet reviewer feedback creates iteration cycles with structured push-back; Capacity Constraint Analysis Prompt Chain provides interactive thinking-partner experience
H31: NONE
A32: 6.3
B32: Variety of technology
C32: No
D32: 1
E32: 1
F32: MET
G32: Technologies span: web-based time-tracking (Toggl/Harvest/Clockify), database (Supabase/PostgreSQL), diagramming (Mermaid), structured prompts (YAML), AI review (Claude Sonnet, Claude Opus 4.7), markdown documentation, optional Python notebook for pivot analysis
H32: NONE
A33: 6.4
B33: Data privacy information
C33: No
D33: 1
E33: 1
F33: MET
G33: Customer-code conventions (C-01, C-02 rather than names) documented in Time-Tracking-Setup-Worksheet; Supabase RLS policies documented; vendor data handling addressed in Time-Tracking-Tool-Comparison and Time-Tracking-Tool-Setup-Guide privacy sections; cohort review anonymization referenced
H33: NONE
A34: 7.1
B34: Technical support clear
C34: Yes
D34: 3
E34: 3
F34: MET
G34: Tool setup guides provide step-by-step click-by-click instructions; troubleshooting sections in Time-Tracking-Tool-Integration cover common issues (untagged entries, inconsistent codes, low hours, low hidden costs); cohort UI support implied; instructor escalation path via HITL
H34: NONE
A35: 7.2
B35: Accessibility policies linked
C35: Yes
D35: 3
E35: 3
F35: MET
G35: Accessibility addressed in 08_Community-Prompts and at the platform level; QM 8.x standards specifically addressed below; Mermaid diagrams have text-based source for screen-reader accessibility; markdown source format ensures readability across assistive technology
H35: NONE
A36: 7.3
B36: Academic support services
C36: No
D36: 2
E36: 2
F36: MET
G36: Cohort partner support documented; instructor support via HITL; community channel support; Daily Completion Checklist provides self-pacing tool
H36: NONE
A37: 7.4
B37: Student services resources
C37: No
D37: 1
E37: 1
F37: MET
G37: Cohort and instructor resources documented; community channel as peer support resource; resource set in 02_Resources serves as self-help reference
H37: NONE
A38: 8.1
B38: Course navigation facilitates ease of use
C38: Yes
D38: 3
E38: 3
F38: MET
G38: 8-folder structure consistent with C6 (cross-course consistency); files use consistent naming convention (C7-* prefix); module folders 01/M7.X organize lesson files; Course-README provides comprehensive navigation; Module-Map Mermaid diagram visualizes flow
H38: NONE
A39: 8.2
B39: Technology accessibility information
C39: No
D39: 2
E39: 2
F39: MET
G39: Tool accessibility addressed in setup guides (Toggl Track is ISO-certified and SOC 2 Type 1 compliant per their public documentation); Supabase platform accessibility addressed at platform level; markdown format ensures accessibility
H39: NONE
A40: 8.3
B40: Alternative means of access (multiple formats)
C40: Yes
D40: 3
E40: 2
F40: PARTIAL
G40: Only M7.1 has a companion Video Spec file; M7.2-M7.8 do not, limiting alternative-means-of-access scoring. Markdown content is screen-reader accessible by default, but the absence of video alternatives for 7 of 8 modules constrains the SRS score to 2/3. Certification requires MET status on all 16 Essential SRS items, so this is a certification-blocker.
H40: MEDIUM
I40: Add companion video specs for M7.2-M7.8 modules; M7.1 video spec serves as template. Each video spec ~2,000 words, beat-by-beat outline, slide aesthetics, atomization plan.
A41: 8.4
B41: Course design facilitates readability
C41: No
D41: 2
E41: 2
F41: MET
G41: Markdown source ensures structural headings; consistent header levels across documents; tables used for comparison and reference; Mermaid diagrams include labels; line lengths and paragraph breaks support readability
H41: NONE
A42: 8.5
B42: Multimedia ease of use
C42: No
D42: 2
E42: 2
F42: MET
G42: M7.1 video spec provides production guidance; Mermaid diagrams included inline in markdown; audio/video alternatives where present support the content; M7.1 video spec includes captioning and accessibility specifications
H42: NONE
A43: 8.6
B43: Vendor accessibility statements
C43: No
D43: 1
E43: 0
F43: NOT_MET
G43: Vendor accessibility statements not compiled for the third-party time-tracking tools referenced in 04_Tools-and-Infrastructure (Toggl Track, Harvest, Clockify). Non-Essential SRS but fully preventable gap. Recommended remediation: add a 'Vendor Accessibility Statements' subsection to Time-Tracking-Tool-Comparison or to the Course-README, with links to each vendor's published accessibility documentation.
H43: MEDIUM
I43: Compile vendor accessibility statements from Toggl Track (https://toggl.com/accessibility), Harvest, and Clockify. Add a subsection to the Course-README or Time-Tracking-Tool-Comparison.
# Remediation Plan
A1: C7 Remediation Plan
A2: Items required to move from NOT_CERTIFIED → CERTIFIED. Both items below are documentation-completion tasks; no architectural revision required.
A4: SRS ID
B4: Status
C4: Effort (hrs)
D4: Remediation Action
A5: 8.3
B5: PARTIAL
C5: 16
D5: Author 7 companion video specs (M7.2 through M7.8). Use M7.1-Video-Spec.md as the template; each spec ~2,000 words covering beat-by-beat outline, slide aesthetics in Sailboat Teal #3B9EA0, and Shorts atomization plan. Estimated effort: 2-3 hours per spec, total 16-21 hours.
A6: 8.6
B6: NOT_MET
C6: 2
D6: Compile vendor accessibility statements for time-tracking tools. Add a 'Vendor Accessibility Statements' subsection to C7-Time-Tracking-Tool-Comparison.md. Sources: Toggl Track public accessibility documentation, Harvest accessibility statement, Clockify accessibility documentation. Estimated effort: 2 hours.
A7: TOTAL
C7: =SUM(C5:C6) [cached 18]
D7: Total estimated effort to achieve CERTIFIED status

Complete local staged workbook cells — variant 2

# Summary
A1: C7 Offer Architecture — QM Audit Scorecard
A2: Audit date: 2026-04-25
A3: Rubric: QM HE Rubric 7th Edition V2.0
A5: Metric
B5: Value
A6: Total points awarded
B6: =SUM('SRS Detail'!E2:E43) [cached 92]
A7: Maximum points
B7: =SUM('SRS Detail'!D2:D43) [cached 94]
A8: Percentage
B8: =B6/B7 [cached 0.978723404255319]
A9: Essential SRS met
B9: =COUNTIFS('SRS Detail'!C2:C43,"Yes",'SRS Detail'!F2:F43,"MET") [cached 15]
A10: Essential SRS total
B10: =COUNTIF('SRS Detail'!C2:C43,"Yes") [cached 16]
A11: Certification threshold (85%)
B11: 0.85
A12: Certification status
B12: NOT_CERTIFIED
A15: General Standard
B15: Score
C15: Max
D15: Essentials Met
A16: GS1: Course Overview and Introduction
B16: 15
C16: 15
D16: 3 / 3
A17: GS2: Learning Objectives (Competencies)
B17: 15
C17: 15
D17: 2 / 2
A18: GS3: Assessment and Measurement
B18: 13
C18: 13
D18: 3 / 3
A19: GS4: Instructional Materials
B19: 12
C19: 12
D19: 1 / 1
A20: GS5: Learning Activities and Learner Interaction
B20: 10
C20: 10
D20: 2 / 2
A21: GS6: Course Technology
B21: 7
C21: 7
D21: 1 / 1
A22: GS7: Learner Support
B22: 9
C22: 9
D22: 2 / 2
A23: GS8: Accessibility and Usability
B23: 11
C23: 13
D23: 1 / 2
A26: Certification Blocking Reasons
A27: SRS 8.3 PARTIAL (2/3): Only M7.1 has a companion Video Spec file; M7.2-M7.8 do not, limiting alternative-means-of-access scoring. Markdown content is screen-reader accessible by default, but the absence of video alternatives for 7 of 8 modules constrains the SRS score to 2/3. Certification requires MET status on all 16 Essential SRS items, so this is a certification-blocker.
A28: SRS 8.6 NOT_MET (0/1): Vendor accessibility statements not compiled for the third-party time-tracking tools referenced in 04_Tools-and-Infrastructure (Toggl Track, Harvest, Clockify). Non-Essential SRS but fully preventable gap. Recommended remediation: add a 'Vendor Accessibility Statements' subsection to Time-Tracking-Tool-Comparison or to the Course-README, with links to each vendor's published accessibility documentation.
# SRS Detail
A1: SRS ID
B1: Description
C1: Essential
D1: Max Points
E1: Awarded Points
F1: Status
G1: Evidence
H1: Gap Severity
I1: Remediation Hint
A2: 1.1
B2: Instructions make clear how to get started
C2: Yes
D2: 3
E2: 3
F2: MET
G2: C7-Course-README has explicit 'How to Use This Course' guidance with module-by-module navigation; C7-Module-Map provides Mermaid diagram with serial unlock structure (M7.5 || M7.6 parallel); C7-Prerequisites-Checklist gates enrollment with 7-section validation referencing C6 Sailboat Ready Attestation co-sign; M7.1 written lesson opens with course-positioning summary and the 3-Customer Test diagnostic
H2: NONE
A3: 1.2
B3: Learners introduced to course purpose and structure
C3: Yes
D3: 3
E3: 3
F3: MET
G3: C7-Course-README and M7.1 establish the Document vs Architecture distinction and Honest Capacity doctrine; C7-Learning-Outcomes maps 8 CLOs to module-level objectives; C7-Time-Estimate provides 50hr active / 5-7 weeks elapsed pacing with three named non-negotiable calendar windows; the Stage 2 second-course position is explicitly named
H3: NONE
A4: 1.3
B4: Communication expectations stated clearly
C4: Yes
D4: 2
E4: 2
F4: MET
G4: Communication norms specified in C7-Lifecycle-Gate-Transition-Script and Lifecycle-Gate-Language-Swipe-File; cohort communication framed in 08_Community-Prompts; instructor turnaround SLAs (72hr for M7.5/M7.6 HITL, 24-72hr for M7.8 Opus + co-sign) documented in All-Module-Checkpoints
H4: NONE
A5: 1.4
B5: Institutional policies clearly stated
C5: No
D5: 2
E5: 2
F5: MET
G5: Resubmission policy documented in All-Module-Checkpoints; three new C7 integrity clauses (Honest Capacity, Architecture-vs-Pivot Distinction, SOP Operability) ground course-level policies; C6 Iteration Discipline and Honest Customer Representation continued
H5: NONE
A6: 1.5
B6: Technology requirements stated
C6: No
D6: 1
E6: 1
F6: MET
G6: Tooling requirements specified in Time-Tracking-Tool-Setup-Guide and Time-Tracking-Tool-Integration walkthrough; Supabase-C7-Schema documents required infrastructure; M7.6 setup worksheet enumerates tool selection criteria
H6: NONE
A7: 1.6
B7: Prerequisite knowledge stated
C7: No
D7: 1
E7: 1
F7: MET
G7: C7-Prerequisites-Checklist explicitly references C1-C6 completion with specific artifact requirements; Sailboat Ready Attestation co-sign required as enrollment gate; per-section verification of C6 outputs (Offer v1.1, Customer Feedback Loop, Onboarding Playbook, etc.)
H7: NONE
A8: 1.7
B8: Technical skills expected
C8: No
D8: 1
E8: 1
F8: MET
G8: Technical skill expectations documented in tool setup guides; time-tracking tool tag-discipline skills identified; Supabase row submission and Mermaid diagram skills referenced
H8: NONE
A9: 1.8
B9: Instructor self-introduction
C9: No
D9: 1
E9: 1
F9: MET
G9: Instructor role and HITL responsibilities documented in M7.5 (capacity HITL), M7.7 (Offer v2.0 capacity sign-off), and M7.8 (Opus 4.7 + co-sign); instructor co-sign function clearly defined as the C8 enrollment authorization
H9: NONE
A10: 1.9
B10: Learner self-introduction
C10: No
D10: 1
E10: 1
F10: MET
G10: Cohort introduction via C7-Community-Prompts (#c7-offer-architecture channel); operator population identification in M7.1 Distinction Statement; cohort partner pairing established at M7.1 cohort partner review
H10: NONE
A11: 2.1
B11: Course learning objectives measurable
C11: Yes
D11: 3
E11: 3
F11: MET
G11: 8 CLOs documented in C7-Learning-Outcomes with Bloom's level mapping; each CLO uses measurable verbs (Distinguish, Decompose, Author, Map, Analyze, Audit, Produce, Synthesize); M7.8 attestation with Opus 4.7 validator provides measurement framework
H11: NONE
A12: 2.2
B12: Module objectives measurable and consistent with CLOs
C12: Yes
D12: 3
E12: 3
F12: MET
G12: Module-level objectives in C7-Learning-Outcomes map directly to CLOs; each module's MLOs include at least one observable artifact production verb; QM standards mapping by module documented
H12: NONE
A13: 2.3
B13: Learning objectives clearly stated
C13: No
D13: 3
E13: 3
F13: MET
G13: Objectives stated in operator-facing language in C7-Course-README and per-module written lessons; objectives appear at the top of each module's written lesson; objectives use second person ('You will produce', 'You will distinguish')
H13: NONE
A14: 2.4
B14: Relationship between objectives and activities
C14: No
D14: 3
E14: 3
F14: MET
G14: Each module's written lesson explicitly ties activities to objectives; the deliverable per module is the artifact that demonstrates objective achievement; Sonnet/Opus reviewers verify activity-to-objective alignment
H14: NONE
A15: 2.5
B15: Objectives suited to course level
C15: No
D15: 3
E15: 3
F15: MET
G15: Bloom's distribution skews toward Analyze, Evaluate, Create at this stage of operator development (post-Stage-1, mid-Stage-2); objectives appropriate for operators who have completed C1-C6; not too advanced (no Stage 3 team-management objectives) and not too basic (no Stage 1 customer-discovery objectives)
H15: NONE
A16: 3.1
B16: Assessments measure learning objectives
C16: Yes
D16: 3
E16: 3
F16: MET
G16: Each module checkpoint specifies pass criteria tied to module objectives in All-Module-Checkpoints; each Sonnet/Opus reviewer has criteria mapped to objectives; M7.8 capstone assessment cross-references all 8 module objectives via attestation clauses
H16: NONE
A17: 3.2
B17: Grading policy stated
C17: Yes
D17: 3
E17: 3
F17: MET
G17: C7 uses pass/fail attestation rather than letter grades, consistent with operator-development pedagogy; pass criteria per module documented in All-Module-Checkpoints; resubmission policy documented; Opus VALIDATED + instructor co-sign is the C8 enrollment-authorization gate
H17: NONE
A18: 3.3
B18: Specific evaluation criteria
C18: No
D18: 3
E18: 3
F18: MET
G18: Evaluation criteria specific in each module checkpoint with common fail patterns named; Sonnet reviewer YAML files include explicit review_criteria sections with pass/partial/fail thresholds; Opus validator decision_thresholds explicitly named for VALIDATED/NEEDS_REVISION/REJECTED
H18: NONE
A19: 3.4
B19: Assessment instruments sequenced and varied
C19: Yes
D19: 2
E19: 2
F19: MET
G19: C7 uses six assessment instrument types: cohort partner review (M7.1, M7.2, M7.4, M7.7), Sonnet structured review (M7.2, M7.3, M7.4, M7.5, M7.7), HITL instructor review (M7.5, M7.6, M7.7, M7.8), Opus 4.7 multi-document validation (M7.8), self-check (M7.8 Section 9 + 10), and integrity clause attestation
H19: NONE
A20: 3.5
B20: Multiple opportunities to track progress
C20: No
D20: 2
E20: 2
F20: MET
G20: Daily Completion Checklist provides daily and weekly self-tracking; cohort UI surfaces module-by-module progression with Sonnet reviewer status; HITL checkpoints provide instructor-facing progress visibility at M7.5/M7.6/M7.7/M7.8
H20: NONE
A21: 4.1
B21: Materials contribute to learning objectives
C21: Yes
D21: 3
E21: 3
F21: MET
G21: Each resource (templates, worksheets, frameworks, swipe files, reference charts) is referenced in a specific module's written lesson with named purpose; all 14+ resources tied to one of the 8 modules; SOP Construction Swipe File and Lifecycle Gate Language Swipe File directly support M7.3 and M7.4 deliverable production
H21: NONE
A22: 4.2
B22: Materials-activities relationship explained
C22: No
D22: 3
E22: 3
F22: MET
G22: Each template's purpose section explains its use in the module; written lessons reference resources by filename at point of use; the C7-Course-README maps resources to modules in the artifact list
H22: NONE
A23: 4.3
B23: Academic integrity modeled
C23: No
D23: 2
E23: 2
F23: MET
G23: Three new C7 integrity clauses (Honest Capacity, Architecture-vs-Pivot Distinction, SOP Operability) explicitly modeled with signature lines; C6 Iteration Discipline and Honest Customer Representation continued; attestation language in M7.8 capstone codifies integrity commitments
H23: NONE
A24: 4.4
B24: Up-to-date theory and practice
C24: No
D24: 2
E24: 2
F24: MET
G24: Time-Tracking Tool Comparison reference chart includes April 2026 verified pricing; Supabase schema reflects current PostgreSQL features (jsonb, uuid, timestamptz); Mermaid diagram syntax current; integration walkthroughs reference current tool versions
H24: NONE
A25: 4.5
B25: Variety of instructional materials
C25: No
D25: 2
E25: 2
F25: MET
G25: Materials span: written lessons (markdown), Mermaid diagrams (lifecycle map, module map), YAML system prompts (6), Python pivot examples (in time-tracking integration walkthrough), structured templates (8), worksheets (2), frameworks (2), reference charts (2), swipe files (2), checklists (1), case studies (4), SOPs (4)
H25: NONE
A26: 5.1
B26: Activities promote learning objectives
C26: Yes
D26: 3
E26: 3
F26: MET
G26: Each module's activity (the deliverable production) directly produces the artifact that demonstrates the objective; M7.6 Bandwidth Audit's 14-day measurement window is the activity that produces the data the objective requires; cohort partner review activity is required at M7.1, M7.2, M7.4, M7.7
H26: NONE
A27: 5.2
B27: Active-learning interaction opportunities
C27: Yes
D27: 3
E27: 3
F27: MET
G27: Cohort partner review (4 modules); cohort-channel community prompts (08_Community-Prompts); instructor HITL conversations at M7.5/M7.6/M7.7/M7.8; Sonnet reviewer feedback cycles with operator-revision loops; the Capacity Constraint Analysis Prompt Chain provides Claude conversation as thinking-partner activity
H27: NONE
A28: 5.3
B28: Instructor interaction plan
C28: No
D28: 2
E28: 2
F28: MET
G28: Instructor interaction frequency documented: M7.5/M7.6 HITL (~1 substantial review per learner per week 4-5), M7.7 capacity statement sign-off (~1 review week 5-6), M7.8 Opus + co-sign (~1 review week 6-7); SLAs documented (72hr standard, 24-72hr for capstone)
H28: NONE
A29: 5.4
B29: Learner interaction requirements
C29: No
D29: 2
E29: 2
F29: MET
G29: Cohort partner review explicitly required at M7.1, M7.2, M7.4, M7.7; minimum quality standards for partner review documented; community prompts encourage cross-cohort engagement; cohort-channel discussion frames provided
H29: NONE
A30: 6.1
B30: Tools support learning objectives
C30: Yes
D30: 3
E30: 3
F30: MET
G30: Tools selected for direct objective support: time-tracking tools (Toggl/Harvest/Clockify) support M7.6 measurement objective; Supabase backend supports artifact submission and review tracking; Mermaid diagrams support lifecycle visualization; Sonnet/Opus reviewers support validation objectives
H30: NONE
A31: 6.2
B31: Tools promote engagement
C31: No
D31: 2
E31: 2
F31: MET
G31: Time-tracking tool tagging discipline produces engagement data the operator can review (per-customer, per-deliverable, per-stage views); Sonnet reviewer feedback creates iteration cycles with structured push-back; Capacity Constraint Analysis Prompt Chain provides interactive thinking-partner experience
H31: NONE
A32: 6.3
B32: Variety of technology
C32: No
D32: 1
E32: 1
F32: MET
G32: Technologies span: web-based time-tracking (Toggl/Harvest/Clockify), database (Supabase/PostgreSQL), diagramming (Mermaid), structured prompts (YAML), AI review (Claude Sonnet, Claude Opus 4.7), markdown documentation, optional Python notebook for pivot analysis
H32: NONE
A33: 6.4
B33: Data privacy information
C33: No
D33: 1
E33: 1
F33: MET
G33: Customer-code conventions (C-01, C-02 rather than names) documented in Time-Tracking-Setup-Worksheet; Supabase RLS policies documented; vendor data handling addressed in Time-Tracking-Tool-Comparison and Time-Tracking-Tool-Setup-Guide privacy sections; cohort review anonymization referenced
H33: NONE
A34: 7.1
B34: Technical support clear
C34: Yes
D34: 3
E34: 3
F34: MET
G34: Tool setup guides provide step-by-step click-by-click instructions; troubleshooting sections in Time-Tracking-Tool-Integration cover common issues (untagged entries, inconsistent codes, low hours, low hidden costs); cohort UI support implied; instructor escalation path via HITL
H34: NONE
A35: 7.2
B35: Accessibility policies linked
C35: Yes
D35: 3
E35: 3
F35: MET
G35: Accessibility addressed in 08_Community-Prompts and at the platform level; QM 8.x standards specifically addressed below; Mermaid diagrams have text-based source for screen-reader accessibility; markdown source format ensures readability across assistive technology
H35: NONE
A36: 7.3
B36: Academic support services
C36: No
D36: 2
E36: 2
F36: MET
G36: Cohort partner support documented; instructor support via HITL; community channel support; Daily Completion Checklist provides self-pacing tool
H36: NONE
A37: 7.4
B37: Student services resources
C37: No
D37: 1
E37: 1
F37: MET
G37: Cohort and instructor resources documented; community channel as peer support resource; resource set in 02_Resources serves as self-help reference
H37: NONE
A38: 8.1
B38: Course navigation facilitates ease of use
C38: Yes
D38: 3
E38: 3
F38: MET
G38: 8-folder structure consistent with C6 (cross-course consistency); files use consistent naming convention (C7-* prefix); module folders 01/M7.X organize lesson files; Course-README provides comprehensive navigation; Module-Map Mermaid diagram visualizes flow
H38: NONE
A39: 8.2
B39: Technology accessibility information
C39: No
D39: 2
E39: 2
F39: MET
G39: Tool accessibility addressed in setup guides (Toggl Track is ISO-certified and SOC 2 Type 1 compliant per their public documentation); Supabase platform accessibility addressed at platform level; markdown format ensures accessibility
H39: NONE
A40: 8.3
B40: Alternative means of access (multiple formats)
C40: Yes
D40: 3
E40: 2
F40: PARTIAL
G40: Only M7.1 has a companion Video Spec file; M7.2-M7.8 do not, limiting alternative-means-of-access scoring. Markdown content is screen-reader accessible by default, but the absence of video alternatives for 7 of 8 modules constrains the SRS score to 2/3. Certification requires MET status on all 16 Essential SRS items, so this is a certification-blocker.
H40: MEDIUM
I40: Add companion video specs for M7.2-M7.8 modules; M7.1 video spec serves as template. Each video spec ~2,000 words, beat-by-beat outline, slide aesthetics, atomization plan.
A41: 8.4
B41: Course design facilitates readability
C41: No
D41: 2
E41: 2
F41: MET
G41: Markdown source ensures structural headings; consistent header levels across documents; tables used for comparison and reference; Mermaid diagrams include labels; line lengths and paragraph breaks support readability
H41: NONE
A42: 8.5
B42: Multimedia ease of use
C42: No
D42: 2
E42: 2
F42: MET
G42: M7.1 video spec provides production guidance; Mermaid diagrams included inline in markdown; audio/video alternatives where present support the content; M7.1 video spec includes captioning and accessibility specifications
H42: NONE
A43: 8.6
B43: Vendor accessibility statements
C43: No
D43: 1
E43: 0
F43: NOT_MET
G43: Vendor accessibility statements not compiled for the third-party time-tracking tools referenced in 04_Tools-and-Infrastructure (Toggl Track, Harvest, Clockify). Non-Essential SRS but fully preventable gap. Recommended remediation: add a 'Vendor Accessibility Statements' subsection to Time-Tracking-Tool-Comparison or to the Course-README, with links to each vendor's published accessibility documentation.
H43: MEDIUM
I43: Compile vendor accessibility statements from Toggl Track (https://toggl.com/accessibility), Harvest, and Clockify. Add a subsection to the Course-README or Time-Tracking-Tool-Comparison.
# Remediation Plan
A1: C7 Remediation Plan
A2: Items required to move from NOT_CERTIFIED → CERTIFIED. Both items below are documentation-completion tasks; no architectural revision required.
A4: SRS ID
B4: Status
C4: Effort (hrs)
D4: Remediation Action
A5: 8.3
B5: PARTIAL
C5: 16
D5: Author 7 companion video specs (M7.2 through M7.8). Use M7.1-Video-Spec.md as the template; each spec ~2,000 words covering beat-by-beat outline, slide aesthetics in Sailboat Teal #3B9EA0, and Shorts atomization plan. Estimated effort: 2-3 hours per spec, total 16-21 hours.
A6: 8.6
B6: NOT_MET
C6: 2
D6: Compile vendor accessibility statements for time-tracking tools. Add a 'Vendor Accessibility Statements' subsection to C7-Time-Tracking-Tool-Comparison.md. Sources: Toggl Track public accessibility documentation, Harvest accessibility statement, Clockify accessibility documentation. Estimated effort: 2 hours.
A7: TOTAL
C7: =SUM(C5:C6) [cached 18]
D7: Total estimated effort to achieve CERTIFIED status

QM-Audit-C7.json

Read this as a historical internal audit

Correct the rubric identity before rescoring

Keep source findings distinct from verified evidence

C7 audit row 1.1 — Instructions make clear how to get started

C7 audit row 1.2 — Learners introduced to course purpose and structure

C7 audit row 1.3 — Communication expectations stated clearly

C7 audit row 1.4 — Institutional policies clearly stated

C7 audit row 1.5 — Technology requirements stated

C7 audit row 1.6 — Prerequisite knowledge stated

C7 audit row 1.7 — Technical skills expected

C7 audit row 1.8 — Instructor self-introduction

C7 audit row 1.9 — Learner self-introduction

C7 audit row 2.1 — Course learning objectives measurable

C7 audit row 2.2 — Module objectives measurable and consistent with CLOs

C7 audit row 2.3 — Learning objectives clearly stated

C7 audit row 2.4 — Relationship between objectives and activities

C7 audit row 2.5 — Objectives suited to course level

C7 audit row 3.1 — Assessments measure learning objectives

C7 audit row 3.2 — Grading policy stated

C7 audit row 3.3 — Specific evaluation criteria

C7 audit row 3.4 — Assessment instruments sequenced and varied

C7 audit row 3.5 — Multiple opportunities to track progress

C7 audit row 4.1 — Materials contribute to learning objectives

C7 audit row 4.2 — Materials-activities relationship explained

C7 audit row 4.3 — Academic integrity modeled

C7 audit row 4.4 — Up-to-date theory and practice

C7 audit row 4.5 — Variety of instructional materials

C7 audit row 5.1 — Activities promote learning objectives

C7 audit row 5.2 — Active-learning interaction opportunities

C7 audit row 5.3 — Instructor interaction plan

C7 audit row 5.4 — Learner interaction requirements

C7 audit row 6.1 — Tools support learning objectives

C7 audit row 6.2 — Tools promote engagement

C7 audit row 6.3 — Variety of technology

C7 audit row 6.4 — Data privacy information

C7 audit row 7.1 — Technical support clear

C7 audit row 7.2 — Accessibility policies linked

C7 audit row 7.3 — Academic support services

C7 audit row 7.4 — Student services resources

C7 audit row 8.1 — Course navigation facilitates ease of use

C7 audit row 8.2 — Technology accessibility information

C7 audit row 8.3 — Alternative means of access (multiple formats)

C7 audit row 8.4 — Course design facilitates readability

C7 audit row 8.5 — Multimedia ease of use

C7 audit row 8.6 — Vendor accessibility statements

C7 audit context — course completeness

C7 audit context — doctrine introduction

C7 audit context — stage 2 position

C7 audit context — primary certification blockers

C7 audit context — expected resolution

C7 audit context — continuity with C6

C7 audit context — operator load

Correct accessibility assumptions before declaring remediation complete

Treat the JSON as an audit record, not an automated checker

The JSON stores metadata, eight general-standard aggregates, forty-two detailed rows, summary totals, essential counts, blockers and narrative context. It contains no code that verifies the cited evidence. Validate schema and totals, retain the original record and create a new dated review for changes. A field called certification_status cannot substitute for the issuing organization’s review.

Connect the lesson to the direct-marketing promise

Complete original source text

{
  "course_id": "C7",
  "course_title": "Offer Architecture",
  "stage": "Stage 2 (Sailboat)",
  "audit_date": "2026-04-25",
  "auditor_version": "1.0.0-manual-apply",
  "rubric_version": "QM HE Rubric 7th Edition V2.0",
  "rubric_total_srs": 42,
  "rubric_total_points": 94,
  "rubric_essential_count": 16,
  "rubric_certification_threshold_pct": 85,
  "rubric_certification_threshold_points": 80,
  "general_standard_scores": [
    {
      "gs_number": 1,
      "gs_name": "Course Overview and Introduction",
      "score": 15,
      "max": 15,
      "essentials_met": 3,
      "essentials_total": 3
    },
    {
      "gs_number": 2,
      "gs_name": "Learning Objectives (Competencies)",
      "score": 15,
      "max": 15,
      "essentials_met": 2,
      "essentials_total": 2
    },
    {
      "gs_number": 3,
      "gs_name": "Assessment and Measurement",
      "score": 13,
      "max": 13,
      "essentials_met": 3,
      "essentials_total": 3
    },
    {
      "gs_number": 4,
      "gs_name": "Instructional Materials",
      "score": 12,
      "max": 12,
      "essentials_met": 1,
      "essentials_total": 1
    },
    {
      "gs_number": 5,
      "gs_name": "Learning Activities and Learner Interaction",
      "score": 10,
      "max": 10,
      "essentials_met": 2,
      "essentials_total": 2
    },
    {
      "gs_number": 6,
      "gs_name": "Course Technology",
      "score": 7,
      "max": 7,
      "essentials_met": 1,
      "essentials_total": 1
    },
    {
      "gs_number": 7,
      "gs_name": "Learner Support",
      "score": 9,
      "max": 9,
      "essentials_met": 2,
      "essentials_total": 2
    },
    {
      "gs_number": 8,
      "gs_name": "Accessibility and Usability",
      "score": 11,
      "max": 13,
      "essentials_met": 1,
      "essentials_total": 2
    }
  ],
  "srs_scores": [
    {
      "srs_id": "1.1",
      "description": "Instructions make clear how to get started",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "C7-Course-README has explicit 'How to Use This Course' guidance with module-by-module navigation; C7-Module-Map provides Mermaid diagram with serial unlock structure (M7.5 || M7.6 parallel); C7-Prerequisites-Checklist gates enrollment with 7-section validation referencing C6 Sailboat Ready Attestation co-sign; M7.1 written lesson opens with course-positioning summary and the 3-Customer Test diagnostic",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "1.2",
      "description": "Learners introduced to course purpose and structure",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "C7-Course-README and M7.1 establish the Document vs Architecture distinction and Honest Capacity doctrine; C7-Learning-Outcomes maps 8 CLOs to module-level objectives; C7-Time-Estimate provides 50hr active / 5-7 weeks elapsed pacing with three named non-negotiable calendar windows; the Stage 2 second-course position is explicitly named",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "1.3",
      "description": "Communication expectations stated clearly",
      "essential": true,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Communication norms specified in C7-Lifecycle-Gate-Transition-Script and Lifecycle-Gate-Language-Swipe-File; cohort communication framed in 08_Community-Prompts; instructor turnaround SLAs (72hr for M7.5/M7.6 HITL, 24-72hr for M7.8 Opus + co-sign) documented in All-Module-Checkpoints",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "1.4",
      "description": "Institutional policies clearly stated",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Resubmission policy documented in All-Module-Checkpoints; three new C7 integrity clauses (Honest Capacity, Architecture-vs-Pivot Distinction, SOP Operability) ground course-level policies; C6 Iteration Discipline and Honest Customer Representation continued",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "1.5",
      "description": "Technology requirements stated",
      "essential": false,
      "max_points": 1,
      "awarded_points": 1,
      "status": "MET",
      "evidence": "Tooling requirements specified in Time-Tracking-Tool-Setup-Guide and Time-Tracking-Tool-Integration walkthrough; Supabase-C7-Schema documents required infrastructure; M7.6 setup worksheet enumerates tool selection criteria",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "1.6",
      "description": "Prerequisite knowledge stated",
      "essential": false,
      "max_points": 1,
      "awarded_points": 1,
      "status": "MET",
      "evidence": "C7-Prerequisites-Checklist explicitly references C1-C6 completion with specific artifact requirements; Sailboat Ready Attestation co-sign required as enrollment gate; per-section verification of C6 outputs (Offer v1.1, Customer Feedback Loop, Onboarding Playbook, etc.)",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "1.7",
      "description": "Technical skills expected",
      "essential": false,
      "max_points": 1,
      "awarded_points": 1,
      "status": "MET",
      "evidence": "Technical skill expectations documented in tool setup guides; time-tracking tool tag-discipline skills identified; Supabase row submission and Mermaid diagram skills referenced",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "1.8",
      "description": "Instructor self-introduction",
      "essential": false,
      "max_points": 1,
      "awarded_points": 1,
      "status": "MET",
      "evidence": "Instructor role and HITL responsibilities documented in M7.5 (capacity HITL), M7.7 (Offer v2.0 capacity sign-off), and M7.8 (Opus 4.7 + co-sign); instructor co-sign function clearly defined as the C8 enrollment authorization",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "1.9",
      "description": "Learner self-introduction",
      "essential": false,
      "max_points": 1,
      "awarded_points": 1,
      "status": "MET",
      "evidence": "Cohort introduction via C7-Community-Prompts (#c7-offer-architecture channel); operator population identification in M7.1 Distinction Statement; cohort partner pairing established at M7.1 cohort partner review",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "2.1",
      "description": "Course learning objectives measurable",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "8 CLOs documented in C7-Learning-Outcomes with Bloom's level mapping; each CLO uses measurable verbs (Distinguish, Decompose, Author, Map, Analyze, Audit, Produce, Synthesize); M7.8 attestation with Opus 4.7 validator provides measurement framework",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "2.2",
      "description": "Module objectives measurable and consistent with CLOs",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Module-level objectives in C7-Learning-Outcomes map directly to CLOs; each module's MLOs include at least one observable artifact production verb; QM standards mapping by module documented",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "2.3",
      "description": "Learning objectives clearly stated",
      "essential": false,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Objectives stated in operator-facing language in C7-Course-README and per-module written lessons; objectives appear at the top of each module's written lesson; objectives use second person ('You will produce', 'You will distinguish')",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "2.4",
      "description": "Relationship between objectives and activities",
      "essential": false,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Each module's written lesson explicitly ties activities to objectives; the deliverable per module is the artifact that demonstrates objective achievement; Sonnet/Opus reviewers verify activity-to-objective alignment",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "2.5",
      "description": "Objectives suited to course level",
      "essential": false,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Bloom's distribution skews toward Analyze, Evaluate, Create at this stage of operator development (post-Stage-1, mid-Stage-2); objectives appropriate for operators who have completed C1-C6; not too advanced (no Stage 3 team-management objectives) and not too basic (no Stage 1 customer-discovery objectives)",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "3.1",
      "description": "Assessments measure learning objectives",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Each module checkpoint specifies pass criteria tied to module objectives in All-Module-Checkpoints; each Sonnet/Opus reviewer has criteria mapped to objectives; M7.8 capstone assessment cross-references all 8 module objectives via attestation clauses",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "3.2",
      "description": "Grading policy stated",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "C7 uses pass/fail attestation rather than letter grades, consistent with operator-development pedagogy; pass criteria per module documented in All-Module-Checkpoints; resubmission policy documented; Opus VALIDATED + instructor co-sign is the C8 enrollment-authorization gate",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "3.3",
      "description": "Specific evaluation criteria",
      "essential": false,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Evaluation criteria specific in each module checkpoint with common fail patterns named; Sonnet reviewer YAML files include explicit review_criteria sections with pass/partial/fail thresholds; Opus validator decision_thresholds explicitly named for VALIDATED/NEEDS_REVISION/REJECTED",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "3.4",
      "description": "Assessment instruments sequenced and varied",
      "essential": true,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "C7 uses six assessment instrument types: cohort partner review (M7.1, M7.2, M7.4, M7.7), Sonnet structured review (M7.2, M7.3, M7.4, M7.5, M7.7), HITL instructor review (M7.5, M7.6, M7.7, M7.8), Opus 4.7 multi-document validation (M7.8), self-check (M7.8 Section 9 + 10), and integrity clause attestation",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "3.5",
      "description": "Multiple opportunities to track progress",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Daily Completion Checklist provides daily and weekly self-tracking; cohort UI surfaces module-by-module progression with Sonnet reviewer status; HITL checkpoints provide instructor-facing progress visibility at M7.5/M7.6/M7.7/M7.8",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "4.1",
      "description": "Materials contribute to learning objectives",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Each resource (templates, worksheets, frameworks, swipe files, reference charts) is referenced in a specific module's written lesson with named purpose; all 14+ resources tied to one of the 8 modules; SOP Construction Swipe File and Lifecycle Gate Language Swipe File directly support M7.3 and M7.4 deliverable production",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "4.2",
      "description": "Materials-activities relationship explained",
      "essential": false,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Each template's purpose section explains its use in the module; written lessons reference resources by filename at point of use; the C7-Course-README maps resources to modules in the artifact list",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "4.3",
      "description": "Academic integrity modeled",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Three new C7 integrity clauses (Honest Capacity, Architecture-vs-Pivot Distinction, SOP Operability) explicitly modeled with signature lines; C6 Iteration Discipline and Honest Customer Representation continued; attestation language in M7.8 capstone codifies integrity commitments",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "4.4",
      "description": "Up-to-date theory and practice",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Time-Tracking Tool Comparison reference chart includes April 2026 verified pricing; Supabase schema reflects current PostgreSQL features (jsonb, uuid, timestamptz); Mermaid diagram syntax current; integration walkthroughs reference current tool versions",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "4.5",
      "description": "Variety of instructional materials",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Materials span: written lessons (markdown), Mermaid diagrams (lifecycle map, module map), YAML system prompts (6), Python pivot examples (in time-tracking integration walkthrough), structured templates (8), worksheets (2), frameworks (2), reference charts (2), swipe files (2), checklists (1), case studies (4), SOPs (4)",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "5.1",
      "description": "Activities promote learning objectives",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Each module's activity (the deliverable production) directly produces the artifact that demonstrates the objective; M7.6 Bandwidth Audit's 14-day measurement window is the activity that produces the data the objective requires; cohort partner review activity is required at M7.1, M7.2, M7.4, M7.7",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "5.2",
      "description": "Active-learning interaction opportunities",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Cohort partner review (4 modules); cohort-channel community prompts (08_Community-Prompts); instructor HITL conversations at M7.5/M7.6/M7.7/M7.8; Sonnet reviewer feedback cycles with operator-revision loops; the Capacity Constraint Analysis Prompt Chain provides Claude conversation as thinking-partner activity",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "5.3",
      "description": "Instructor interaction plan",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Instructor interaction frequency documented: M7.5/M7.6 HITL (~1 substantial review per learner per week 4-5), M7.7 capacity statement sign-off (~1 review week 5-6), M7.8 Opus + co-sign (~1 review week 6-7); SLAs documented (72hr standard, 24-72hr for capstone)",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "5.4",
      "description": "Learner interaction requirements",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Cohort partner review explicitly required at M7.1, M7.2, M7.4, M7.7; minimum quality standards for partner review documented; community prompts encourage cross-cohort engagement; cohort-channel discussion frames provided",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "6.1",
      "description": "Tools support learning objectives",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Tools selected for direct objective support: time-tracking tools (Toggl/Harvest/Clockify) support M7.6 measurement objective; Supabase backend supports artifact submission and review tracking; Mermaid diagrams support lifecycle visualization; Sonnet/Opus reviewers support validation objectives",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "6.2",
      "description": "Tools promote engagement",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Time-tracking tool tagging discipline produces engagement data the operator can review (per-customer, per-deliverable, per-stage views); Sonnet reviewer feedback creates iteration cycles with structured push-back; Capacity Constraint Analysis Prompt Chain provides interactive thinking-partner experience",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "6.3",
      "description": "Variety of technology",
      "essential": false,
      "max_points": 1,
      "awarded_points": 1,
      "status": "MET",
      "evidence": "Technologies span: web-based time-tracking (Toggl/Harvest/Clockify), database (Supabase/PostgreSQL), diagramming (Mermaid), structured prompts (YAML), AI review (Claude Sonnet, Claude Opus 4.7), markdown documentation, optional Python notebook for pivot analysis",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "6.4",
      "description": "Data privacy information",
      "essential": false,
      "max_points": 1,
      "awarded_points": 1,
      "status": "MET",
      "evidence": "Customer-code conventions (C-01, C-02 rather than names) documented in Time-Tracking-Setup-Worksheet; Supabase RLS policies documented; vendor data handling addressed in Time-Tracking-Tool-Comparison and Time-Tracking-Tool-Setup-Guide privacy sections; cohort review anonymization referenced",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "7.1",
      "description": "Technical support clear",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Tool setup guides provide step-by-step click-by-click instructions; troubleshooting sections in Time-Tracking-Tool-Integration cover common issues (untagged entries, inconsistent codes, low hours, low hidden costs); cohort UI support implied; instructor escalation path via HITL",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "7.2",
      "description": "Accessibility policies linked",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Accessibility addressed in 08_Community-Prompts and at the platform level; QM 8.x standards specifically addressed below; Mermaid diagrams have text-based source for screen-reader accessibility; markdown source format ensures readability across assistive technology",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "7.3",
      "description": "Academic support services",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Cohort partner support documented; instructor support via HITL; community channel support; Daily Completion Checklist provides self-pacing tool",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "7.4",
      "description": "Student services resources",
      "essential": false,
      "max_points": 1,
      "awarded_points": 1,
      "status": "MET",
      "evidence": "Cohort and instructor resources documented; community channel as peer support resource; resource set in 02_Resources serves as self-help reference",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "8.1",
      "description": "Course navigation facilitates ease of use",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "8-folder structure consistent with C6 (cross-course consistency); files use consistent naming convention (C7-* prefix); module folders 01/M7.X organize lesson files; Course-README provides comprehensive navigation; Module-Map Mermaid diagram visualizes flow",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "8.2",
      "description": "Technology accessibility information",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Tool accessibility addressed in setup guides (Toggl Track is ISO-certified and SOC 2 Type 1 compliant per their public documentation); Supabase platform accessibility addressed at platform level; markdown format ensures accessibility",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "8.3",
      "description": "Alternative means of access (multiple formats)",
      "essential": true,
      "max_points": 3,
      "awarded_points": 2,
      "status": "PARTIAL",
      "evidence": "Only M7.1 has a companion Video Spec file; M7.2-M7.8 do not, limiting alternative-means-of-access scoring. Markdown content is screen-reader accessible by default, but the absence of video alternatives for 7 of 8 modules constrains the SRS score to 2/3. Certification requires MET status on all 16 Essential SRS items, so this is a certification-blocker.",
      "gap_severity": "MEDIUM",
      "remediation_hint": "Add companion video specs for M7.2-M7.8 modules; M7.1 video spec serves as template. Each video spec ~2,000 words, beat-by-beat outline, slide aesthetics, atomization plan."
    },
    {
      "srs_id": "8.4",
      "description": "Course design facilitates readability",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Markdown source ensures structural headings; consistent header levels across documents; tables used for comparison and reference; Mermaid diagrams include labels; line lengths and paragraph breaks support readability",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "8.5",
      "description": "Multimedia ease of use",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "M7.1 video spec provides production guidance; Mermaid diagrams included inline in markdown; audio/video alternatives where present support the content; M7.1 video spec includes captioning and accessibility specifications",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "8.6",
      "description": "Vendor accessibility statements",
      "essential": false,
      "max_points": 1,
      "awarded_points": 0,
      "status": "NOT_MET",
      "evidence": "Vendor accessibility statements not compiled for the third-party time-tracking tools referenced in 04_Tools-and-Infrastructure (Toggl Track, Harvest, Clockify). Non-Essential SRS but fully preventable gap. Recommended remediation: add a 'Vendor Accessibility Statements' subsection to Time-Tracking-Tool-Comparison or to the Course-README, with links to each vendor's published accessibility documentation.",
      "gap_severity": "MEDIUM",
      "remediation_hint": "Compile vendor accessibility statements from Toggl Track (https://toggl.com/accessibility), Harvest, and Clockify. Add a subsection to the Course-README or Time-Tracking-Tool-Comparison."
    }
  ],
  "total_score": 92,
  "max_score": 94,
  "percentage": 97.9,
  "essentials_met": 15,
  "essentials_total": 16,
  "certification_status": "NOT_CERTIFIED",
  "certification_blocking_reasons": [
    "SRS 8.3 PARTIAL (2/3): Only M7.1 has a companion Video Spec file; M7.2-M7.8 do not, limiting alternative-means-of-access scoring. Markdown content is screen-reader accessible by default, but the absence of video alternatives for 7 of 8 modules constrains the SRS score to 2/3. Certification requires MET status on all 16 Essential SRS items, so this is a certification-blocker.",
    "SRS 8.6 NOT_MET (0/1): Vendor accessibility statements not compiled for the third-party time-tracking tools referenced in 04_Tools-and-Infrastructure (Toggl Track, Harvest, Clockify). Non-Essential SRS but fully preventable gap. Recommended remediation: add a 'Vendor Accessibility Statements' subsection to Time-Tracking-Tool-Comparison or to the Course-README, with links to each vendor's published accessibility documentation."
  ],
  "summary": {
    "course_completeness": "Strong: 8 modules, 7 deliverable artifacts produced by operators, 1 capstone synthesis (M7.8), 6 Claude system prompts, 4 SOPs, 4 case studies, integrated cohort-and-instructor review structure",
    "doctrine_introduction": "C7 introduces three new doctrines: Honest Capacity (M7.5), Architecture-vs-Pivot Distinction (M7.7), SOP Operability (M7.3). Each doctrine has a dedicated integrity clause document and is reinforced across multiple modules.",
    "stage_2_position": "Second course of Stage 2 (Sailboat); follows C6 Sailboat Provisioning; precedes C8 Unit Economics. C7 produces the architectural baseline that C8 measures unit economics against.",
    "primary_certification_blockers": [
      "SRS 8.3 PARTIAL: video specs only for M7.1; remediation requires producing companion video specs for M7.2-M7.8",
      "SRS 8.6 NOT_MET: vendor accessibility statements not compiled; remediation requires adding vendor accessibility documentation"
    ],
    "expected_resolution": "Both blockers are documentation-completion items, not architectural deficiencies. Full certification is achievable in a focused 2-3 day completion sprint after initial deployment. The course can deploy as NOT_CERTIFIED and be re-audited to CERTIFIED status without architectural revision.",
    "continuity_with_C6": "C7 mirrors C6 structure (8-folder layout, same artifact-class breakdown, same doctrinal continuity); cross-course narrative (Maya, Darius, Priya) advances; new failure case (Bespoke Architecture Trap) introduced.",
    "operator_load": "50 active hours / 5-7 elapsed weeks; three non-negotiable calendar windows: M7.6 14-day measurement window, M7.5+M7.6 instructor HITL 72hr SLA, M7.8 Opus + instructor co-sign 24-72hr each."
  }
}

Complete source variant 2

{
  "course_id": "C7",
  "course_title": "Offer Architecture",
  "stage": "Stage 2 (Sailboat)",
  "audit_date": "2026-04-25",
  "auditor_version": "1.0.0-manual-apply",
  "rubric_version": "QM HE Rubric 7th Edition V2.0",
  "rubric_total_srs": 42,
  "rubric_total_points": 94,
  "rubric_essential_count": 16,
  "rubric_certification_threshold_pct": 85,
  "rubric_certification_threshold_points": 80,
  "general_standard_scores": [
    {
      "gs_number": 1,
      "gs_name": "Course Overview and Introduction",
      "score": 15,
      "max": 15,
      "essentials_met": 3,
      "essentials_total": 3
    },
    {
      "gs_number": 2,
      "gs_name": "Learning Objectives (Competencies)",
      "score": 15,
      "max": 15,
      "essentials_met": 2,
      "essentials_total": 2
    },
    {
      "gs_number": 3,
      "gs_name": "Assessment and Measurement",
      "score": 13,
      "max": 13,
      "essentials_met": 3,
      "essentials_total": 3
    },
    {
      "gs_number": 4,
      "gs_name": "Instructional Materials",
      "score": 12,
      "max": 12,
      "essentials_met": 1,
      "essentials_total": 1
    },
    {
      "gs_number": 5,
      "gs_name": "Learning Activities and Learner Interaction",
      "score": 10,
      "max": 10,
      "essentials_met": 2,
      "essentials_total": 2
    },
    {
      "gs_number": 6,
      "gs_name": "Course Technology",
      "score": 7,
      "max": 7,
      "essentials_met": 1,
      "essentials_total": 1
    },
    {
      "gs_number": 7,
      "gs_name": "Learner Support",
      "score": 9,
      "max": 9,
      "essentials_met": 2,
      "essentials_total": 2
    },
    {
      "gs_number": 8,
      "gs_name": "Accessibility and Usability",
      "score": 11,
      "max": 13,
      "essentials_met": 1,
      "essentials_total": 2
    }
  ],
  "srs_scores": [
    {
      "srs_id": "1.1",
      "description": "Instructions make clear how to get started",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "C7-Course-README has explicit 'How to Use This Course' guidance with module-by-module navigation; C7-Module-Map provides Mermaid diagram with serial unlock structure (M7.5 || M7.6 parallel); C7-Prerequisites-Checklist gates enrollment with 7-section validation referencing C6 Sailboat Ready Attestation co-sign; M7.1 written lesson opens with course-positioning summary and the 3-Customer Test diagnostic",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "1.2",
      "description": "Learners introduced to course purpose and structure",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "C7-Course-README and M7.1 establish the Document vs Architecture distinction and Honest Capacity doctrine; C7-Learning-Outcomes maps 8 CLOs to module-level objectives; C7-Time-Estimate provides 50hr active / 5-7 weeks elapsed pacing with three named non-negotiable calendar windows; the Stage 2 second-course position is explicitly named",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "1.3",
      "description": "Communication expectations stated clearly",
      "essential": true,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Communication norms specified in C7-Lifecycle-Gate-Transition-Script and Lifecycle-Gate-Language-Swipe-File; cohort communication framed in 08_Community-Prompts; instructor turnaround SLAs (72hr for M7.5/M7.6 HITL, 24-72hr for M7.8 Opus + co-sign) documented in All-Module-Checkpoints",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "1.4",
      "description": "Institutional policies clearly stated",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Resubmission policy documented in All-Module-Checkpoints; three new C7 integrity clauses (Honest Capacity, Architecture-vs-Pivot Distinction, SOP Operability) ground course-level policies; C6 Iteration Discipline and Honest Customer Representation continued",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "1.5",
      "description": "Technology requirements stated",
      "essential": false,
      "max_points": 1,
      "awarded_points": 1,
      "status": "MET",
      "evidence": "Tooling requirements specified in Time-Tracking-Tool-Setup-Guide and Time-Tracking-Tool-Integration walkthrough; Supabase-C7-Schema documents required infrastructure; M7.6 setup worksheet enumerates tool selection criteria",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "1.6",
      "description": "Prerequisite knowledge stated",
      "essential": false,
      "max_points": 1,
      "awarded_points": 1,
      "status": "MET",
      "evidence": "C7-Prerequisites-Checklist explicitly references C1-C6 completion with specific artifact requirements; Sailboat Ready Attestation co-sign required as enrollment gate; per-section verification of C6 outputs (Offer v1.1, Customer Feedback Loop, Onboarding Playbook, etc.)",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "1.7",
      "description": "Technical skills expected",
      "essential": false,
      "max_points": 1,
      "awarded_points": 1,
      "status": "MET",
      "evidence": "Technical skill expectations documented in tool setup guides; time-tracking tool tag-discipline skills identified; Supabase row submission and Mermaid diagram skills referenced",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "1.8",
      "description": "Instructor self-introduction",
      "essential": false,
      "max_points": 1,
      "awarded_points": 1,
      "status": "MET",
      "evidence": "Instructor role and HITL responsibilities documented in M7.5 (capacity HITL), M7.7 (Offer v2.0 capacity sign-off), and M7.8 (Opus 4.7 + co-sign); instructor co-sign function clearly defined as the C8 enrollment authorization",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "1.9",
      "description": "Learner self-introduction",
      "essential": false,
      "max_points": 1,
      "awarded_points": 1,
      "status": "MET",
      "evidence": "Cohort introduction via C7-Community-Prompts (#c7-offer-architecture channel); operator population identification in M7.1 Distinction Statement; cohort partner pairing established at M7.1 cohort partner review",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "2.1",
      "description": "Course learning objectives measurable",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "8 CLOs documented in C7-Learning-Outcomes with Bloom's level mapping; each CLO uses measurable verbs (Distinguish, Decompose, Author, Map, Analyze, Audit, Produce, Synthesize); M7.8 attestation with Opus 4.7 validator provides measurement framework",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "2.2",
      "description": "Module objectives measurable and consistent with CLOs",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Module-level objectives in C7-Learning-Outcomes map directly to CLOs; each module's MLOs include at least one observable artifact production verb; QM standards mapping by module documented",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "2.3",
      "description": "Learning objectives clearly stated",
      "essential": false,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Objectives stated in operator-facing language in C7-Course-README and per-module written lessons; objectives appear at the top of each module's written lesson; objectives use second person ('You will produce', 'You will distinguish')",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "2.4",
      "description": "Relationship between objectives and activities",
      "essential": false,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Each module's written lesson explicitly ties activities to objectives; the deliverable per module is the artifact that demonstrates objective achievement; Sonnet/Opus reviewers verify activity-to-objective alignment",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "2.5",
      "description": "Objectives suited to course level",
      "essential": false,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Bloom's distribution skews toward Analyze, Evaluate, Create at this stage of operator development (post-Stage-1, mid-Stage-2); objectives appropriate for operators who have completed C1-C6; not too advanced (no Stage 3 team-management objectives) and not too basic (no Stage 1 customer-discovery objectives)",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "3.1",
      "description": "Assessments measure learning objectives",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Each module checkpoint specifies pass criteria tied to module objectives in All-Module-Checkpoints; each Sonnet/Opus reviewer has criteria mapped to objectives; M7.8 capstone assessment cross-references all 8 module objectives via attestation clauses",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "3.2",
      "description": "Grading policy stated",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "C7 uses pass/fail attestation rather than letter grades, consistent with operator-development pedagogy; pass criteria per module documented in All-Module-Checkpoints; resubmission policy documented; Opus VALIDATED + instructor co-sign is the C8 enrollment-authorization gate",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "3.3",
      "description": "Specific evaluation criteria",
      "essential": false,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Evaluation criteria specific in each module checkpoint with common fail patterns named; Sonnet reviewer YAML files include explicit review_criteria sections with pass/partial/fail thresholds; Opus validator decision_thresholds explicitly named for VALIDATED/NEEDS_REVISION/REJECTED",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "3.4",
      "description": "Assessment instruments sequenced and varied",
      "essential": true,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "C7 uses six assessment instrument types: cohort partner review (M7.1, M7.2, M7.4, M7.7), Sonnet structured review (M7.2, M7.3, M7.4, M7.5, M7.7), HITL instructor review (M7.5, M7.6, M7.7, M7.8), Opus 4.7 multi-document validation (M7.8), self-check (M7.8 Section 9 + 10), and integrity clause attestation",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "3.5",
      "description": "Multiple opportunities to track progress",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Daily Completion Checklist provides daily and weekly self-tracking; cohort UI surfaces module-by-module progression with Sonnet reviewer status; HITL checkpoints provide instructor-facing progress visibility at M7.5/M7.6/M7.7/M7.8",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "4.1",
      "description": "Materials contribute to learning objectives",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Each resource (templates, worksheets, frameworks, swipe files, reference charts) is referenced in a specific module's written lesson with named purpose; all 14+ resources tied to one of the 8 modules; SOP Construction Swipe File and Lifecycle Gate Language Swipe File directly support M7.3 and M7.4 deliverable production",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "4.2",
      "description": "Materials-activities relationship explained",
      "essential": false,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Each template's purpose section explains its use in the module; written lessons reference resources by filename at point of use; the C7-Course-README maps resources to modules in the artifact list",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "4.3",
      "description": "Academic integrity modeled",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Three new C7 integrity clauses (Honest Capacity, Architecture-vs-Pivot Distinction, SOP Operability) explicitly modeled with signature lines; C6 Iteration Discipline and Honest Customer Representation continued; attestation language in M7.8 capstone codifies integrity commitments",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "4.4",
      "description": "Up-to-date theory and practice",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Time-Tracking Tool Comparison reference chart includes April 2026 verified pricing; Supabase schema reflects current PostgreSQL features (jsonb, uuid, timestamptz); Mermaid diagram syntax current; integration walkthroughs reference current tool versions",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "4.5",
      "description": "Variety of instructional materials",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Materials span: written lessons (markdown), Mermaid diagrams (lifecycle map, module map), YAML system prompts (6), Python pivot examples (in time-tracking integration walkthrough), structured templates (8), worksheets (2), frameworks (2), reference charts (2), swipe files (2), checklists (1), case studies (4), SOPs (4)",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "5.1",
      "description": "Activities promote learning objectives",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Each module's activity (the deliverable production) directly produces the artifact that demonstrates the objective; M7.6 Bandwidth Audit's 14-day measurement window is the activity that produces the data the objective requires; cohort partner review activity is required at M7.1, M7.2, M7.4, M7.7",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "5.2",
      "description": "Active-learning interaction opportunities",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Cohort partner review (4 modules); cohort-channel community prompts (08_Community-Prompts); instructor HITL conversations at M7.5/M7.6/M7.7/M7.8; Sonnet reviewer feedback cycles with operator-revision loops; the Capacity Constraint Analysis Prompt Chain provides Claude conversation as thinking-partner activity",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "5.3",
      "description": "Instructor interaction plan",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Instructor interaction frequency documented: M7.5/M7.6 HITL (~1 substantial review per learner per week 4-5), M7.7 capacity statement sign-off (~1 review week 5-6), M7.8 Opus + co-sign (~1 review week 6-7); SLAs documented (72hr standard, 24-72hr for capstone)",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "5.4",
      "description": "Learner interaction requirements",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Cohort partner review explicitly required at M7.1, M7.2, M7.4, M7.7; minimum quality standards for partner review documented; community prompts encourage cross-cohort engagement; cohort-channel discussion frames provided",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "6.1",
      "description": "Tools support learning objectives",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Tools selected for direct objective support: time-tracking tools (Toggl/Harvest/Clockify) support M7.6 measurement objective; Supabase backend supports artifact submission and review tracking; Mermaid diagrams support lifecycle visualization; Sonnet/Opus reviewers support validation objectives",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "6.2",
      "description": "Tools promote engagement",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Time-tracking tool tagging discipline produces engagement data the operator can review (per-customer, per-deliverable, per-stage views); Sonnet reviewer feedback creates iteration cycles with structured push-back; Capacity Constraint Analysis Prompt Chain provides interactive thinking-partner experience",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "6.3",
      "description": "Variety of technology",
      "essential": false,
      "max_points": 1,
      "awarded_points": 1,
      "status": "MET",
      "evidence": "Technologies span: web-based time-tracking (Toggl/Harvest/Clockify), database (Supabase/PostgreSQL), diagramming (Mermaid), structured prompts (YAML), AI review (Claude Sonnet, Claude Opus 4.7), markdown documentation, optional Python notebook for pivot analysis",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "6.4",
      "description": "Data privacy information",
      "essential": false,
      "max_points": 1,
      "awarded_points": 1,
      "status": "MET",
      "evidence": "Customer-code conventions (C-01, C-02 rather than names) documented in Time-Tracking-Setup-Worksheet; Supabase RLS policies documented; vendor data handling addressed in Time-Tracking-Tool-Comparison and Time-Tracking-Tool-Setup-Guide privacy sections; cohort review anonymization referenced",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "7.1",
      "description": "Technical support clear",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Tool setup guides provide step-by-step click-by-click instructions; troubleshooting sections in Time-Tracking-Tool-Integration cover common issues (untagged entries, inconsistent codes, low hours, low hidden costs); cohort UI support implied; instructor escalation path via HITL",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "7.2",
      "description": "Accessibility policies linked",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Accessibility addressed in 08_Community-Prompts and at the platform level; QM 8.x standards specifically addressed below; Mermaid diagrams have text-based source for screen-reader accessibility; markdown source format ensures readability across assistive technology",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "7.3",
      "description": "Academic support services",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Cohort partner support documented; instructor support via HITL; community channel support; Daily Completion Checklist provides self-pacing tool",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "7.4",
      "description": "Student services resources",
      "essential": false,
      "max_points": 1,
      "awarded_points": 1,
      "status": "MET",
      "evidence": "Cohort and instructor resources documented; community channel as peer support resource; resource set in 02_Resources serves as self-help reference",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "8.1",
      "description": "Course navigation facilitates ease of use",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "8-folder structure consistent with C6 (cross-course consistency); files use consistent naming convention (C7-* prefix); module folders 01/M7.X organize lesson files; Course-README provides comprehensive navigation; Module-Map Mermaid diagram visualizes flow",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "8.2",
      "description": "Technology accessibility information",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Tool accessibility addressed in setup guides (Toggl Track is ISO-certified and SOC 2 Type 1 compliant per their public documentation); Supabase platform accessibility addressed at platform level; markdown format ensures accessibility",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "8.3",
      "description": "Alternative means of access (multiple formats)",
      "essential": true,
      "max_points": 3,
      "awarded_points": 2,
      "status": "PARTIAL",
      "evidence": "Only M7.1 has a companion Video Spec file; M7.2-M7.8 do not, limiting alternative-means-of-access scoring. Markdown content is screen-reader accessible by default, but the absence of video alternatives for 7 of 8 modules constrains the SRS score to 2/3. Certification requires MET status on all 16 Essential SRS items, so this is a certification-blocker.",
      "gap_severity": "MEDIUM",
      "remediation_hint": "Add companion video specs for M7.2-M7.8 modules; M7.1 video spec serves as template. Each video spec ~2,000 words, beat-by-beat outline, slide aesthetics, atomization plan."
    },
    {
      "srs_id": "8.4",
      "description": "Course design facilitates readability",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Markdown source ensures structural headings; consistent header levels across documents; tables used for comparison and reference; Mermaid diagrams include labels; line lengths and paragraph breaks support readability",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "8.5",
      "description": "Multimedia ease of use",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "M7.1 video spec provides production guidance; Mermaid diagrams included inline in markdown; audio/video alternatives where present support the content; M7.1 video spec includes captioning and accessibility specifications",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "8.6",
      "description": "Vendor accessibility statements",
      "essential": false,
      "max_points": 1,
      "awarded_points": 0,
      "status": "NOT_MET",
      "evidence": "Vendor accessibility statements not compiled for the third-party time-tracking tools referenced in 04_Tools-and-Infrastructure (Toggl Track, Harvest, Clockify). Non-Essential SRS but fully preventable gap. Recommended remediation: add a 'Vendor Accessibility Statements' subsection to Time-Tracking-Tool-Comparison or to the Course-README, with links to each vendor's published accessibility documentation.",
      "gap_severity": "MEDIUM",
      "remediation_hint": "Compile vendor accessibility statements from Toggl Track (https://toggl.com/accessibility), Harvest, and Clockify. Add a subsection to the Course-README or Time-Tracking-Tool-Comparison."
    }
  ],
  "total_score": 92,
  "max_score": 94,
  "percentage": 97.9,
  "essentials_met": 15,
  "essentials_total": 16,
  "certification_status": "NOT_CERTIFIED",
  "certification_blocking_reasons": [
    "SRS 8.3 PARTIAL (2/3): Only M7.1 has a companion Video Spec file; M7.2-M7.8 do not, limiting alternative-means-of-access scoring. Markdown content is screen-reader accessible by default, but the absence of video alternatives for 7 of 8 modules constrains the SRS score to 2/3. Certification requires MET status on all 16 Essential SRS items, so this is a certification-blocker.",
    "SRS 8.6 NOT_MET (0/1): Vendor accessibility statements not compiled for the third-party time-tracking tools referenced in 04_Tools-and-Infrastructure (Toggl Track, Harvest, Clockify). Non-Essential SRS but fully preventable gap. Recommended remediation: add a 'Vendor Accessibility Statements' subsection to Time-Tracking-Tool-Comparison or to the Course-README, with links to each vendor's published accessibility documentation."
  ],
  "summary": {
    "course_completeness": "Strong: 8 modules, 7 deliverable artifacts produced by operators, 1 capstone synthesis (M7.8), 6 Claude system prompts, 4 SOPs, 4 case studies, integrated cohort-and-instructor review structure",
    "doctrine_introduction": "C7 introduces three new doctrines: Honest Capacity (M7.5), Architecture-vs-Pivot Distinction (M7.7), SOP Operability (M7.3). Each doctrine has a dedicated integrity clause document and is reinforced across multiple modules.",
    "stage_2_position": "Second course of Stage 2 (Sailboat); follows C6 Sailboat Provisioning; precedes C8 Unit Economics. C7 produces the architectural baseline that C8 measures unit economics against.",
    "primary_certification_blockers": [
      "SRS 8.3 PARTIAL: video specs only for M7.1; remediation requires producing companion video specs for M7.2-M7.8",
      "SRS 8.6 NOT_MET: vendor accessibility statements not compiled; remediation requires adding vendor accessibility documentation"
    ],
    "expected_resolution": "Both blockers are documentation-completion items, not architectural deficiencies. Full certification is achievable in a focused 2-3 day completion sprint after initial deployment. The course can deploy as NOT_CERTIFIED and be re-audited to CERTIFIED status without architectural revision.",
    "continuity_with_C6": "C7 mirrors C6 structure (8-folder layout, same artifact-class breakdown, same doctrinal continuity); cross-course narrative (Maya, Darius, Priya) advances; new failure case (Bespoke Architecture Trap) introduced.",
    "operator_load": "50 active hours / 5-7 elapsed weeks; three non-negotiable calendar windows: M7.6 14-day measurement window, M7.5+M7.6 instructor HITL 72hr SLA, M7.8 Opus + instructor co-sign 24-72hr each."
  }
}

QM-Audit-C8-Scorecard.xlsx

Read this as a historical internal audit

The C8 file is dated 2026-04-26 and labeled manual-apply version 1.0.0. It reports 92/94 points, about 97.9%, and 15/16 source-defined essentials, with NOT_CERTIFIED status. The row totals reconcile internally. These are the document’s claims, not an official review of the current RISER website. Course numbering belongs to this legacy curriculum and must not overwrite spreadsheet assignments.

Correct the rubric identity before rescoring

Keep source findings distinct from verified evidence

C8 audit row 1.1 — Instructions make clear how to get started

Source row 1.1, Instructions make clear how to get started: awarded 3 of 3; status MET; essential flag True; gap severity NONE. The source cites: C8-Course-README has explicit 'How to Use This Course' navigation with serial module structure (M8.1 → M8.8); C8-Module-Map specifies module dependencies and HITL/cooling gates; C8-Prerequisites-Checklist gates enrollment with explicit C7 Offer Architecture v2.0 + capacity sign-off + 24h cooling validation; M8.1 written lesson opens with course-positioning summary and the 12-Month Pricing Test diagnostic RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 1.2 — Learners introduced to course purpose and structure

Source row 1.2, Learners introduced to course purpose and structure: awarded 3 of 3; status MET; essential flag True; gap severity NONE. The source cites: C8-Course-README and M8.1 establish the Pricing Decision vs Pricing Discipline distinction and Pricing Is Operator Self-Respect doctrine; C8-Learning-Outcomes maps 8 CLOs to module-level objectives; C8-Time-Estimate provides 40hr active / 4-5 weeks elapsed pacing with named non-negotiable calendar windows; the Stage 2 third-course position (structural midpoint of Sailboat) is explicitly named RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 1.3 — Communication expectations stated clearly

Source row 1.3, Communication expectations stated clearly: awarded 2 of 2; status MET; essential flag True; gap severity NONE. The source cites: Communication norms specified in 06_SOPs (anti-discount enforcement and price-raise execution SOPs); cohort communication framed in 08_Community-Prompts; instructor turnaround SLAs (72hr for M8.7 mandatory HITL, 14-day window for M8.8 Opus 4.7 + co-sign) documented in All-Module-Checkpoints RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 1.4 — Institutional policies clearly stated

Source row 1.4, Institutional policies clearly stated: awarded 2 of 2; status MET; essential flag False; gap severity NONE. The source cites: Resubmission policy documented in All-Module-Checkpoints; new C8 doctrine (Pricing Is Operator Self-Respect) grounds course-level policies; continuity with C6 Iteration Without Drift, C7 Honest Capacity and Architecture-vs-Pivot maintained; M8.6 Anti-Discount Policy structurally codifies enforcement boundaries RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 1.5 — Technology requirements stated

Source row 1.5, Technology requirements stated: awarded 1 of 1; status MET; essential flag False; gap severity NONE. The source cites: Tooling requirements specified in Stripe-Pricing-Setup-Guide and Pricing-Math-Spreadsheet-to-Supabase-Walkthrough; Supabase-C8-Schema documents required infrastructure; Pricing Math Spreadsheet Template enumerates spreadsheet platform requirements (Google Sheets or Excel) RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 1.6 — Prerequisite knowledge stated

Source row 1.6, Prerequisite knowledge stated: awarded 1 of 1; status MET; essential flag False; gap severity NONE. The source cites: C8-Prerequisites-Checklist explicitly references C1-C7 completion with specific artifact requirements; C7 Offer Architecture Document and capacity sign-off required as enrollment gates; per-section verification of C7 outputs (Offer v2.0, Capacity Constraint Analysis, Operator Bandwidth Audit, Time Tracking measurement data) RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 1.7 — Technical skills expected

Source row 1.7, Technical skills expected: awarded 1 of 1; status MET; essential flag False; gap severity NONE. The source cites: Technical skill expectations documented in tool setup guides; spreadsheet formula skills identified in Pricing Math Spreadsheet Template; Supabase row submission and JSONB structure skills referenced in walkthrough RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 1.8 — Instructor self-introduction

Source row 1.8, Instructor self-introduction: awarded 1 of 1; status MET; essential flag False; gap severity NONE. The source cites: Instructor role and HITL responsibilities documented in M8.2 (unit economics review escalation), M8.7 (mandatory raise schedule HITL on every submission), and M8.8 (Opus 4.7 + co-sign); instructor co-sign function clearly defined as the C9 enrollment authorization RISER review: An instructor’s assigned responsibilities do not substitute for an actual learner-facing instructor introduction.

C8 audit row 1.9 — Learner self-introduction

Source row 1.9, Learner self-introduction: awarded 1 of 1; status MET; essential flag False; gap severity NONE. The source cites: Cohort introduction via C8-Community-Prompts (#c8-pricing-discipline channel); operator population identification in M8.1 Distinction Statement; cohort partner pairing continued from C7 RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 2.1 — Course learning objectives measurable

Source row 2.1, Course learning objectives measurable: awarded 3 of 3; status MET; essential flag True; gap severity NONE. The source cites: 8 CLOs documented in C8-Learning-Outcomes with Bloom's level mapping; each CLO uses measurable verbs (Distinguish, Calculate, Evaluate, Architect, Design, Author, Specify, Synthesize); M8.8 Pricing Discipline Attestation with Opus 4.7 validator provides measurement framework for all 12 attestation dimensions RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 2.2 — Module objectives measurable and consistent with CLOs

Source row 2.2, Module objectives measurable and consistent with CLOs: awarded 3 of 3; status MET; essential flag True; gap severity NONE. The source cites: Module-level objectives in C8-Learning-Outcomes map directly to CLOs; each module's MLOs include at least one observable artifact production verb; QM standards mapping by module documented; module deliverables (M8.2 Unit Economics, M8.4 Architecture, M8.6 Policy, M8.7 Schedule, M8.8 Attestation) provide direct objective measurement RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 2.3 — Learning objectives clearly stated

Source row 2.3, Learning objectives clearly stated: awarded 3 of 3; status MET; essential flag False; gap severity NONE. The source cites: Objectives stated in operator-facing language in C8-Course-README and per-module written lessons; objectives appear at the top of each module's written lesson; objectives use second person ('You will calculate', 'You will architect') RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 2.4 — Relationship between objectives and activities

Source row 2.4, Relationship between objectives and activities: awarded 3 of 3; status MET; essential flag False; gap severity NONE. The source cites: Each module's written lesson explicitly ties activities to objectives; the deliverable per module is the artifact that demonstrates objective achievement; Sonnet/Opus reviewers verify activity-to-objective alignment per criteria specified in system prompt YAMLs RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 2.5 — Objectives suited to course level

Source row 2.5, Objectives suited to course level: awarded 3 of 3; status MET; essential flag False; gap severity NONE. The source cites: Bloom's distribution skews toward Apply, Evaluate, Create at this stage of operator development (Stage 2 mid-course); objectives appropriate for operators who have completed C1-C7; not too advanced (no distribution-management objectives belonging to C9) and not too basic (no offer-discovery objectives belonging to C7) RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 3.1 — Assessments measure learning objectives

Source row 3.1, Assessments measure learning objectives: awarded 3 of 3; status MET; essential flag True; gap severity NONE. The source cites: Each module checkpoint specifies pass criteria tied to module objectives in All-Module-Checkpoints; each Sonnet/Opus reviewer has criteria mapped to objectives; M8.8 capstone assessment cross-references all 8 module objectives via attestation 12-section structure with cross-artifact coherence verification (Section 8 Q1-Q4) RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 3.2 — Grading policy stated

Source row 3.2, Grading policy stated: awarded 3 of 3; status MET; essential flag True; gap severity NONE. The source cites: Decision thresholds documented in each Sonnet reviewer YAML (CLEARED / NEEDS_REVISION / NOT_CLEARED); Opus 4.7 capstone validator decision thresholds specified (PASS_TO_INSTRUCTOR / NEEDS_REVISION / FAIL); resubmission protocols documented in All-Module-Checkpoints RISER review: Review the actual grading rules for contradictory thresholds and missing cases; a YAML file or named scoring scale does not establish a consistent implemented assessment.

C8 audit row 3.3 — Specific and descriptive grading criteria

Source row 3.3, Specific and descriptive grading criteria: awarded 3 of 3; status MET; essential flag True; gap severity NONE. The source cites: Each Sonnet reviewer YAML lists 8-10 review criteria with scoring scales; Opus 4.7 validator lists 12 review dimensions with scoring scale; criteria are specific and descriptive (e.g., 'exception_list_specifies_trigger_magnitude_documentation', 'rationalization_patterns_absent') RISER review: Review the actual grading rules for contradictory thresholds and missing cases; a YAML file or named scoring scale does not establish a consistent implemented assessment.

C8 audit row 3.4 — Multiple assessment types

Source row 3.4, Multiple assessment types: awarded 2 of 2; status MET; essential flag False; gap severity NONE. The source cites: Mixed assessment types: artifact-based (M8.2 Unit Economics Document, M8.4 Architecture Document, etc.), process-based (M8.7 mandatory HITL conversation), capstone synthesis (M8.8 Attestation), self-diagnostic (Race-to-the-Bottom Recognition Checklist). Multiple modalities (writing, calculation, dialog, signing) RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 3.5 — Self-check or practice opportunities

Source row 3.5, Self-check or practice opportunities: awarded 2 of 2; status MET; essential flag False; gap severity NONE. The source cites: Worksheets provide self-check opportunities (Hidden Hours Audit, 12-Month Pricing Test, Tier Appropriateness Diagnostic); Pricing Pressure Conversation Scripts for practice; Race-to-the-Bottom Recognition Checklist provides ongoing self-diagnostic; Unit Economics Walkthrough Prompt Chain provides interactive practice with Claude RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 4.1 — Instructional materials align with objectives

Source row 4.1, Instructional materials align with objectives: awarded 3 of 3; status MET; essential flag True; gap severity NONE. The source cites: Each module written lesson aligns with module objectives; templates and worksheets directly support deliverable production; system prompt YAMLs verify alignment between submitted artifacts and module objectives RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 4.2 — Materials contribute to objectives

Source row 4.2, Materials contribute to objectives: awarded 3 of 3; status MET; essential flag False; gap severity NONE. The source cites: All 13 resources in 02_Resources serve specific module objectives (templates for deliverables, worksheets for diagnostic activities, frameworks for conceptual grounding, swipe files for operational language, checklists for ongoing discipline); no orphan materials RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 4.3 — Instructional materials current

Source row 4.3, Instructional materials current: awarded 2 of 2; status MET; essential flag False; gap severity NONE. The source cites: C8 references current pricing literature (Hermann Simon, Ramanujam+Tacke, Patrick Campbell ProfitWell, Hormozi, Michalowicz, Crabtree, Stark, Brennan Dunn, Russell Brunson, Jonah Berger, Chris Voss, Blair Enns, Jay Abraham, patio11) including post-2020 sources; Stripe-Pricing-Setup-Guide reflects current Stripe product structure; Build 6 references current production schema RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 4.4 — Materials clearly identified by purpose

Source row 4.4, Materials clearly identified by purpose: awarded 2 of 2; status MET; essential flag False; gap severity NONE. The source cites: Each resource includes 'Used in' header indicating module reference and purpose; folder structure organizes materials by type (Templates, Worksheets, Frameworks, Reference-Charts, Swipe-Files, Checklists); Course-README references resources by module RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 4.5 — Variety of instructional materials

Source row 4.5, Variety of instructional materials: awarded 2 of 2; status MET; essential flag False; gap severity NONE. The source cites: Variety includes written lessons, video specs, templates, worksheets, frameworks, reference charts, swipe files, checklists, scripts, prompt chains, case studies; Mermaid diagrams included for module flow visualization; conceptual narrative + structural template + practice script + diagnostic worksheet pattern across multiple modules RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 5.1 — Activities promote objective achievement

Source row 5.1, Activities promote objective achievement: awarded 3 of 3; status MET; essential flag True; gap severity NONE. The source cites: Module activities directly produce module deliverables that demonstrate objective achievement; e.g., M8.2 Unit Economics calculation activity → Unit Economics Document deliverable → CLO 'Calculate operator unit economics from measured C7 data' RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 5.2 — Learning activities provide opportunity for interaction

Source row 5.2, Learning activities provide opportunity for interaction: awarded 3 of 3; status MET; essential flag True; gap severity NONE. The source cites: Multiple interaction modalities: AI reviewer dialog (M8.2-M8.6), instructor HITL conversation (M8.7 mandatory + M8.8 co-sign), cohort partner review (Pricing-Pressure-Conversation-Scripts practice), live customer interaction (M8.6 anti-discount policy execution); cohort channel for peer interaction RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 5.3 — Communication plans facilitate engagement

Source row 5.3, Communication plans facilitate engagement: awarded 2 of 2; status MET; essential flag False; gap severity NONE. The source cites: Communication plan documented in C8-Course-README; cohort channel and instructor SLAs specified; M8.7 mandatory HITL provides scheduled high-touch instructor interaction; M8.8 co-sign meeting provides capstone synchronous engagement RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 5.4 — Course requirements align with course duration

Source row 5.4, Course requirements align with course duration: awarded 2 of 2; status MET; essential flag False; gap severity NONE. The source cites: C8-Time-Estimate documents 40 active hours / 4-5 weeks elapsed; per-module time estimates with cooling periods; course duration matches Stage 2 cadence; non-negotiable calendar windows (M8.7 HITL, M8.8 Opus + co-sign) accommodated within course duration RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 6.1 — Tools support objectives

Source row 6.1, Tools support objectives: awarded 3 of 3; status MET; essential flag True; gap severity NONE. The source cites: Tool selection (Stripe, Google Sheets/Excel, Supabase) supports objectives; Pricing Math Spreadsheet Template directly supports M8.2 unit economics calculation and M8.4 architecture coherence; Supabase tracks compliance for M8.6 policy and M8.7 schedule; Stripe configuration supports M8.4 architecture execution RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 6.2 — Course tools promote learner engagement

Source row 6.2, Course tools promote learner engagement: awarded 2 of 2; status MET; essential flag False; gap severity NONE. The source cites: Pricing Math Spreadsheet provides interactive computation; Supabase RLS enables secure operator-private access; Stripe walkthrough enables hands-on payment configuration; Mermaid diagrams in Module Map enhance visual engagement; AI reviewers provide interactive feedback RISER review: Verify the specific deployed tool version, permission behavior and learner experience. A claim that row-level security or a named model exists is not operational evidence.

C8 audit row 6.3 — Tool privacy policies

Source row 6.3, Tool privacy policies: awarded 1 of 1; status MET; essential flag False; gap severity NONE. The source cites: Tool privacy addressed in tool setup guides; Supabase RLS policies documented in Supabase-C8-Schema; Stripe privacy at platform level; spreadsheet platforms (Google Sheets, Excel) at platform level; data flow documented in Pricing-Math-Spreadsheet-to-Supabase-Walkthrough RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 6.4 — Tools currently supported

Source row 6.4, Tools currently supported: awarded 1 of 1; status MET; essential flag False; gap severity NONE. The source cites: All referenced tools are currently in active vendor support (Stripe, Google Sheets, Excel, Supabase); Build 6 is current production build; Sonnet 4.6 and Opus 4.7 are current Anthropic models RISER review: Verify the specific deployed tool version, permission behavior and learner experience. A claim that row-level security or a named model exists is not operational evidence.

C8 audit row 7.1 — Technical support information

Source row 7.1, Technical support information: awarded 3 of 3; status MET; essential flag True; gap severity NONE. The source cites: Technical support paths documented in tool setup guides; Stripe vendor support; Supabase platform support; instructor support via HITL queues; community channel support via #c8-pricing-discipline RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 7.2 — Accessibility support information

Source row 7.2, Accessibility support information: awarded 3 of 3; status MET; essential flag True; gap severity NONE. The source cites: Accessibility addressed in 08_Community-Prompts and at the platform level; QM 8.x standards specifically addressed below; Mermaid diagrams have text-based source for screen-reader accessibility; markdown source format ensures readability across assistive technology RISER review: Markdown, diagram source, security certifications and vendor platform features do not by themselves establish accessibility. Inspect rendered structure, reading order, keyboard operation and relevant assistive-technology behavior.

C8 audit row 7.3 — Academic support services

Source row 7.3, Academic support services: awarded 2 of 2; status MET; essential flag False; gap severity NONE. The source cites: Cohort partner support documented; instructor support via mandatory M8.7 HITL and M8.8 co-sign; community channel support; Race-to-the-Bottom Recognition Checklist provides self-pacing diagnostic tool RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 7.4 — Student services resources

Source row 7.4, Student services resources: awarded 1 of 1; status MET; essential flag False; gap severity NONE. The source cites: Cohort and instructor resources documented; community channel as peer support resource; resource set in 02_Resources serves as self-help reference; Pricing Pressure Conversation Scripts available for ongoing practice support RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 8.1 — Course navigation facilitates ease of use

Source row 8.1, Course navigation facilitates ease of use: awarded 3 of 3; status MET; essential flag True; gap severity NONE. The source cites: 8-folder structure consistent with C7 (cross-course consistency); files use consistent naming convention (C8-* prefix); module folders 01/M8.X organize lesson files; Course-README provides comprehensive navigation; Module-Map Mermaid diagram visualizes flow with explicit cooling-period and HITL gate annotations RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 8.2 — Technology accessibility information

Source row 8.2, Technology accessibility information: awarded 2 of 2; status MET; essential flag False; gap severity NONE. The source cites: Tool accessibility addressed in setup guides; Stripe and Supabase platform accessibility addressed at platform level; markdown format ensures accessibility; spreadsheet platforms (Google Sheets, Excel) provide platform-level accessibility features RISER review: Markdown, diagram source, security certifications and vendor platform features do not by themselves establish accessibility. Inspect rendered structure, reading order, keyboard operation and relevant assistive-technology behavior.

C8 audit row 8.3 — Alternative means of access (multiple formats)

Source row 8.3, Alternative means of access (multiple formats): awarded 2 of 3; status PARTIAL; essential flag True; gap severity MEDIUM. The source cites: Only M8.1 has a companion Video Spec file; M8.2-M8.8 do not, limiting alternative-means-of-access scoring. Markdown content is screen-reader accessible by default, but the absence of video alternatives for 7 of 8 modules constrains the SRS score to 2/3. Certification requires MET status on all 16 Essential SRS items, so this is a certification-blocker. This pattern matches C7's deliberate scope-management decision: video spec for M8.1 serves as production template for downstream module spec authoring. Its proposed remediation is: Add companion video specs for M8.2-M8.8 modules; M8.1 video spec serves as template. Each video spec ~2,000 words, beat-by-beat outline, slide aesthetics, atomization plan. RISER review: A video specification is not an accessible video. The source mislabels the official text-accessibility criterion as a multiple-format requirement. Assess the actual content and learner needs; do not assume every text lesson must have a video to pass.

C8 audit row 8.4 — Course design facilitates readability

Source row 8.4, Course design facilitates readability: awarded 2 of 2; status MET; essential flag False; gap severity NONE. The source cites: Markdown source ensures structural headings; consistent header levels across documents; tables used for comparison and reference (margin benchmarks, tier appropriateness scoring, raise communication anti-patterns); Mermaid diagrams include labels; line lengths and paragraph breaks support readability RISER review: Markdown, diagram source, security certifications and vendor platform features do not by themselves establish accessibility. Inspect rendered structure, reading order, keyboard operation and relevant assistive-technology behavior.

C8 audit row 8.5 — Multimedia ease of use

Source row 8.5, Multimedia ease of use: awarded 2 of 2; status MET; essential flag False; gap severity NONE. The source cites: M8.1 video spec provides production guidance; Mermaid diagrams included inline in markdown; audio/video alternatives where present support the content; M8.1 video spec includes captioning and accessibility specifications RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 8.6 — Vendor accessibility statements

Source row 8.6, Vendor accessibility statements: awarded 0 of 1; status NOT_MET; essential flag False; gap severity MEDIUM. The source cites: Vendor accessibility statements not compiled for the third-party tools referenced in 04_Tools-and-Infrastructure (Stripe, Google Sheets, Excel, Supabase). Non-Essential SRS but fully preventable gap. Recommended remediation: add a 'Vendor Accessibility Statements' subsection to Stripe-Pricing-Setup-Guide or to the Course-README, with links to each vendor's published accessibility documentation. Its proposed remediation is: Compile vendor accessibility statements from Stripe (https://stripe.com/accessibility), Google Workspace, Microsoft, and Supabase. Add a subsection to the Course-README or Stripe-Pricing-Setup-Guide. RISER review: The source places vendor statements under 8.6, while the official seventh-edition list uses 8.7 for that topic. Retain this source finding and map it correctly before remediation.

C8 audit context — course completeness

The source summary states: Strong: 8 modules, 7 deliverable artifacts produced by operators (M8.2 Unit Economics Document, M8.3 Reality Check Decision Memo, M8.4 Pricing Architecture Document, M8.5 Tier Structure or Flat-Pricing Rationale, M8.6 Anti-Discount Policy, M8.7 Price-Raise Schedule, M8.8 Pricing Discipline Attestation), 1 capstone synthesis (M8.8) with Opus 4.7 cross-artifact validation, 6 Claude system prompts (5 Sonnet reviewers + 1 Opus capstone validator), 4 SOPs, 4 case studies, integrated cohort-and-instructor review structure including mandatory M8.7 HITL Treat this as a historical course-design assertion. Confirm actual artifacts, service capacity and course-version mapping before adopting it as a current promise. The two-to-three-day certification forecast is not a validated completion estimate or official approval.

C8 audit context — doctrine introduction

The source summary states: C8 introduces one new doctrine: Pricing Is Operator Self-Respect (introduced in M8.1, reinforced across M8.6 anti-discount policy and M8.8 attestation). The doctrine treats under-pricing not as generosity but as a tax on the operator's future capacity, with cascading effects on quality, sustainability, and mechanism integrity. Treat this as a historical course-design assertion. Confirm actual artifacts, service capacity and course-version mapping before adopting it as a current promise. The two-to-three-day certification forecast is not a validated completion estimate or official approval.

C8 audit context — stage 2 position

The source summary states: Third course of Stage 2 (Sailboat); structural midpoint of Stage 2; follows C7 Offer Architecture; precedes C9 Distribution. C8 produces the 12-month pricing system that C9 distribution operates against. C8 completion advances Stage 2 progress to 60%. Treat this as a historical course-design assertion. Confirm actual artifacts, service capacity and course-version mapping before adopting it as a current promise. The two-to-three-day certification forecast is not a validated completion estimate or official approval.

C8 audit context — primary certification blockers

The source summary states: SRS 8.3 PARTIAL: video specs only for M8.1; remediation requires producing companion video specs for M8.2-M8.8; SRS 8.6 NOT_MET: vendor accessibility statements not compiled; remediation requires adding vendor accessibility documentation Treat this as a historical course-design assertion. Confirm actual artifacts, service capacity and course-version mapping before adopting it as a current promise. The two-to-three-day certification forecast is not a validated completion estimate or official approval.

C8 audit context — expected resolution

The source summary states: Both blockers are documentation-completion items, not architectural deficiencies. Full certification is achievable in a focused 2-3 day completion sprint after initial deployment. The course can deploy as NOT_CERTIFIED and be re-audited to CERTIFIED status without architectural revision. This pattern matches C7's deployment trajectory. Treat this as a historical course-design assertion. Confirm actual artifacts, service capacity and course-version mapping before adopting it as a current promise. The two-to-three-day certification forecast is not a validated completion estimate or official approval.

C8 audit context — continuity with C7

The source summary states: C8 mirrors C7 structure (8-folder layout, same artifact-class breakdown, same doctrinal continuity); cross-course narrative (Maya, Darius, Priya) advances; Maya's Sprint v1.0→v2.0 transition (C7) carries into Sprint v2.0 unit economics analysis (M8.2) and architecture commitment (M8.4); new failure case (Race-to-the-Bottom Trap) introduced; same certification-blocker pattern (SRS 8.3 + SRS 8.6) facilitates parallel remediation cycle. Treat this as a historical course-design assertion. Confirm actual artifacts, service capacity and course-version mapping before adopting it as a current promise. The two-to-three-day certification forecast is not a validated completion estimate or official approval.

C8 audit context — operator load

The source summary states: 40 active hours / 4-5 elapsed weeks; non-negotiable calendar windows include 24-48 hour cooling periods between modules (M8.2→M8.3 24hr, M8.3→M8.4 48hr, M8.4→M8.5 48hr, M8.7→M8.8 48hr), mandatory M8.7 HITL on every submission (72hr SLA), and M8.8 Opus 4.7 + instructor co-sign within 14-day cosign window. Treat this as a historical course-design assertion. Confirm actual artifacts, service capacity and course-version mapping before adopting it as a current promise. The two-to-three-day certification forecast is not a validated completion estimate or official approval.

Correct accessibility assumptions before declaring remediation complete

Inspect the C8 workbook’s static values

The local staged workbook has four visible tabs—Summary, General Standards, SRS Detail and Certification Blockers—with 460 populated cells and no formulas, images or charts. Totals and status are entered text/numbers; changing a detailed score does not recalculate them. Its cached values match the Drive readable export, but remote binary identity was not established. Keep one validated data source and derive summaries consistently before future edits.

Connect the lesson to the direct-marketing promise

Complete original source text

Control separators are labeled in this readable display. Download exact original text

,QM Audit Summary — C8 Pricing Discipline,Unnamed: 1
0,,
1,Course ID,C8
2,Course Title,Pricing Discipline
3,Stage,Stage 2 (Sailboat)
4,Audit Date,2026-04-26
5,Auditor Version,1.0.0-manual-apply
6,Rubric Version,QM HE Rubric 7th Edition V2.0
7,Total SRS Items,42
8,Total Points Possible,94
9,Essential SRS Items,16
10,Certification Threshold,85% (80 points + all Essentials MET)
11,,
12,Total Score Awarded,92 / 94
13,Percentage,97.9%
14,Essentials Met,15 / 16
15,Certification Status,NOT_CERTIFIED
16,,
17,,
18,Course Summary,
19,,
20,Course Completeness,"Strong: 8 modules, 7 deliverable artifacts produced by operators (M8.2 Unit Economics Document, M8.3 Reality Check Decision Memo, M8.4 Pricing Architecture Document, M8.5 Tier Structure or Flat-Pricing Rationale, M8.6 Anti-Discount Policy, M8.7 Price-Raise Schedule, M8.8 Pricing Discipline Attestation), 1 capstone synthesis (M8.8) with Opus 4.7 cross-artifact validation, 6 Claude system prompts (5 Sonnet reviewers + 1 Opus capstone validator), 4 SOPs, 4 case studies, integrated cohort-and-instructor review structure including mandatory M8.7 HITL"
21,Doctrine Introduction,"C8 introduces one new doctrine: Pricing Is Operator Self-Respect (introduced in M8.1, reinforced across M8.6 anti-discount policy and M8.8 attestation). The doctrine treats under-pricing not as generosity but as a tax on the operator's future capacity, with cascading effects on quality, sustainability, and mechanism integrity."
22,Stage 2 Position,Third course of Stage 2 (Sailboat); structural midpoint of Stage 2; follows C7 Offer Architecture; precedes C9 Distribution. C8 produces the 12-month pricing system that C9 distribution operates against. C8 completion advances Stage 2 progress to 60%.
23,Primary Certification Blockers,"• SRS 8.3 PARTIAL: video specs only for M8.1; remediation requires producing companion video specs for M8.2-M8.8
• SRS 8.6 NOT_MET: vendor accessibility statements not compiled; remediation requires adding vendor accessibility documentation"
24,Expected Resolution,"Both blockers are documentation-completion items, not architectural deficiencies. Full certification is achievable in a focused 2-3 day completion sprint after initial deployment. The course can deploy as NOT_CERTIFIED and be re-audited to CERTIFIED status without architectural revision. This pattern matches C7's deployment trajectory."
25,Continuity With C7,"C8 mirrors C7 structure (8-folder layout, same artifact-class breakdown, same doctrinal continuity); cross-course narrative (Maya, Darius, Priya) advances; Maya's Sprint v1.0→v2.0 transition (C7) carries into Sprint v2.0 unit economics analysis (M8.2) and architecture commitment (M8.4); new failure case (Race-to-the-Bottom Trap) introduced; same certification-blocker pattern (SRS 8.3 + SRS 8.6) facilitates parallel remediation cycle."
26,Operator Load,"40 active hours / 4-5 elapsed weeks; non-negotiable calendar windows include 24-48 hour cooling periods between modules (M8.2→M8.3 24hr, M8.3→M8.4 48hr, M8.4→M8.5 48hr, M8.7→M8.8 48hr), mandatory M8.7 HITL on every submission (72hr SLA), and M8.8 Opus 4.7 + instructor co-sign within 14-day cosign window."

[Source control separator U+000C]
,GS #,General Standard,Score,Max,%,Essentials Met,Essentials Total
0,1,Course Overview and Introduction,15,15,100.0%,3,3
1,2,Learning Objectives (Competencies),15,15,100.0%,2,2
2,3,Assessment and Measurement,13,13,100.0%,3,3
3,4,Instructional Materials,12,12,100.0%,1,1
4,5,Learning Activities and Learner Interaction,10,10,100.0%,2,2
5,6,Course Technology,7,7,100.0%,1,1
6,7,Learner Support,9,9,100.0%,2,2
7,8,Accessibility and Usability,11,13,84.6%,1,2

[Source control separator U+000C]
,SRS ID,Description,Essential,Max,Awarded,Status,Gap Severity,Evidence,Remediation Hint
0,1.1,Instructions make clear how to get started,Essential,3,3,MET,NONE,C8-Course-README has explicit 'How to Use This Course' navigation with serial module structure (M8.1 → M8.8); C8-Module-Map specifies module dependencies and HITL/cooling gates; C8-Prerequisites-Checklist gates enrollment with explicit C7 Offer Architecture v2.0 + capacity sign-off + 24h cooling validation; M8.1 written lesson opens with course-positioning summary and the 12-Month Pricing Test diagnostic,
1,1.2,Learners introduced to course purpose and structure,Essential,3,3,MET,NONE,C8-Course-README and M8.1 establish the Pricing Decision vs Pricing Discipline distinction and Pricing Is Operator Self-Respect doctrine; C8-Learning-Outcomes maps 8 CLOs to module-level objectives; C8-Time-Estimate provides 40hr active / 4-5 weeks elapsed pacing with named non-negotiable calendar windows; the Stage 2 third-course position (structural midpoint of Sailboat) is explicitly named,
2,1.3,Communication expectations stated clearly,Essential,2,2,MET,NONE,"Communication norms specified in 06_SOPs (anti-discount enforcement and price-raise execution SOPs); cohort communication framed in 08_Community-Prompts; instructor turnaround SLAs (72hr for M8.7 mandatory HITL, 14-day window for M8.8 Opus 4.7 + co-sign) documented in All-Module-Checkpoints",
3,1.4,Institutional policies clearly stated,—,2,2,MET,NONE,"Resubmission policy documented in All-Module-Checkpoints; new C8 doctrine (Pricing Is Operator Self-Respect) grounds course-level policies; continuity with C6 Iteration Without Drift, C7 Honest Capacity and Architecture-vs-Pivot maintained; M8.6 Anti-Discount Policy structurally codifies enforcement boundaries",
4,1.5,Technology requirements stated,—,1,1,MET,NONE,Tooling requirements specified in Stripe-Pricing-Setup-Guide and Pricing-Math-Spreadsheet-to-Supabase-Walkthrough; Supabase-C8-Schema documents required infrastructure; Pricing Math Spreadsheet Template enumerates spreadsheet platform requirements (Google Sheets or Excel),
5,1.6,Prerequisite knowledge stated,—,1,1,MET,NONE,"C8-Prerequisites-Checklist explicitly references C1-C7 completion with specific artifact requirements; C7 Offer Architecture Document and capacity sign-off required as enrollment gates; per-section verification of C7 outputs (Offer v2.0, Capacity Constraint Analysis, Operator Bandwidth Audit, Time Tracking measurement data)",
6,1.7,Technical skills expected,—,1,1,MET,NONE,Technical skill expectations documented in tool setup guides; spreadsheet formula skills identified in Pricing Math Spreadsheet Template; Supabase row submission and JSONB structure skills referenced in walkthrough,
7,1.8,Instructor self-introduction,—,1,1,MET,NONE,"Instructor role and HITL responsibilities documented in M8.2 (unit economics review escalation), M8.7 (mandatory raise schedule HITL on every submission), and M8.8 (Opus 4.7 + co-sign); instructor co-sign function clearly defined as the C9 enrollment authorization",
8,1.9,Learner self-introduction,—,1,1,MET,NONE,Cohort introduction via C8-Community-Prompts (#c8-pricing-discipline channel); operator population identification in M8.1 Distinction Statement; cohort partner pairing continued from C7,
9,2.1,Course learning objectives measurable,Essential,3,3,MET,NONE,"8 CLOs documented in C8-Learning-Outcomes with Bloom's level mapping; each CLO uses measurable verbs (Distinguish, Calculate, Evaluate, Architect, Design, Author, Specify, Synthesize); M8.8 Pricing Discipline Attestation with Opus 4.7 validator provides measurement framework for all 12 attestation dimensions",
10,2.2,Module objectives measurable and consistent with CLOs,Essential,3,3,MET,NONE,"Module-level objectives in C8-Learning-Outcomes map directly to CLOs; each module's MLOs include at least one observable artifact production verb; QM standards mapping by module documented; module deliverables (M8.2 Unit Economics, M8.4 Architecture, M8.6 Policy, M8.7 Schedule, M8.8 Attestation) provide direct objective measurement",
11,2.3,Learning objectives clearly stated,—,3,3,MET,NONE,"Objectives stated in operator-facing language in C8-Course-README and per-module written lessons; objectives appear at the top of each module's written lesson; objectives use second person ('You will calculate', 'You will architect')",
12,2.4,Relationship between objectives and activities,—,3,3,MET,NONE,Each module's written lesson explicitly ties activities to objectives; the deliverable per module is the artifact that demonstrates objective achievement; Sonnet/Opus reviewers verify activity-to-objective alignment per criteria specified in system prompt YAMLs,
13,2.5,Objectives suited to course level,—,3,3,MET,NONE,"Bloom's distribution skews toward Apply, Evaluate, Create at this stage of operator development (Stage 2 mid-course); objectives appropriate for operators who have completed C1-C7; not too advanced (no distribution-management objectives belonging to C9) and not too basic (no offer-discovery objectives belonging to C7)",
14,3.1,Assessments measure learning objectives,Essential,3,3,MET,NONE,Each module checkpoint specifies pass criteria tied to module objectives in All-Module-Checkpoints; each Sonnet/Opus reviewer has criteria mapped to objectives; M8.8 capstone assessment cross-references all 8 module objectives via attestation 12-section structure with cross-artifact coherence verification (Section 8 Q1-Q4),
15,3.2,Grading policy stated,Essential,3,3,MET,NONE,Decision thresholds documented in each Sonnet reviewer YAML (CLEARED / NEEDS_REVISION / NOT_CLEARED); Opus 4.7 capstone validator decision thresholds specified (PASS_TO_INSTRUCTOR / NEEDS_REVISION / FAIL); resubmission protocols documented in All-Module-Checkpoints,
16,3.3,Specific and descriptive grading criteria,Essential,3,3,MET,NONE,"Each Sonnet reviewer YAML lists 8-10 review criteria with scoring scales; Opus 4.7 validator lists 12 review dimensions with scoring scale; criteria are specific and descriptive (e.g., 'exception_list_specifies_trigger_magnitude_documentation', 'rationalization_patterns_absent')",
17,3.4,Multiple assessment types,—,2,2,MET,NONE,"Mixed assessment types: artifact-based (M8.2 Unit Economics Document, M8.4 Architecture Document, etc.), process-based (M8.7 mandatory HITL conversation), capstone synthesis (M8.8 Attestation), self-diagnostic (Race-to-the-Bottom Recognition Checklist). Multiple modalities (writing, calculation, dialog, signing)",
18,3.5,Self-check or practice opportunities,—,2,2,MET,NONE,"Worksheets provide self-check opportunities (Hidden Hours Audit, 12-Month Pricing Test, Tier Appropriateness Diagnostic); Pricing Pressure Conversation Scripts for practice; Race-to-the-Bottom Recognition Checklist provides ongoing self-diagnostic; Unit Economics Walkthrough Prompt Chain provides interactive practice with Claude",
19,4.1,Instructional materials align with objectives,Essential,3,3,MET,NONE,Each module written lesson aligns with module objectives; templates and worksheets directly support deliverable production; system prompt YAMLs verify alignment between submitted artifacts and module objectives,
20,4.2,Materials contribute to objectives,—,3,3,MET,NONE,"All 13 resources in 02_Resources serve specific module objectives (templates for deliverables, worksheets for diagnostic activities, frameworks for conceptual grounding, swipe files for operational language, checklists for ongoing discipline); no orphan materials",
21,4.3,Instructional materials current,—,2,2,MET,NONE,"C8 references current pricing literature (Hermann Simon, Ramanujam+Tacke, Patrick Campbell ProfitWell, Hormozi, Michalowicz, Crabtree, Stark, Brennan Dunn, Russell Brunson, Jonah Berger, Chris Voss, Blair Enns, Jay Abraham, patio11) including post-2020 sources; Stripe-Pricing-Setup-Guide reflects current Stripe product structure; Build 6 references current production schema",
22,4.4,Materials clearly identified by purpose,—,2,2,MET,NONE,"Each resource includes 'Used in' header indicating module reference and purpose; folder structure organizes materials by type (Templates, Worksheets, Frameworks, Reference-Charts, Swipe-Files, Checklists); Course-README references resources by module",
23,4.5,Variety of instructional materials,—,2,2,MET,NONE,"Variety includes written lessons, video specs, templates, worksheets, frameworks, reference charts, swipe files, checklists, scripts, prompt chains, case studies; Mermaid diagrams included for module flow visualization; conceptual narrative + structural template + practice script + diagnostic worksheet pattern across multiple modules",
24,5.1,Activities promote objective achievement,Essential,3,3,MET,NONE,"Module activities directly produce module deliverables that demonstrate objective achievement; e.g., M8.2 Unit Economics calculation activity → Unit Economics Document deliverable → CLO 'Calculate operator unit economics from measured C7 data'",
25,5.2,Learning activities provide opportunity for interaction,Essential,3,3,MET,NONE,"Multiple interaction modalities: AI reviewer dialog (M8.2-M8.6), instructor HITL conversation (M8.7 mandatory + M8.8 co-sign), cohort partner review (Pricing-Pressure-Conversation-Scripts practice), live customer interaction (M8.6 anti-discount policy execution); cohort channel for peer interaction",
26,5.3,Communication plans facilitate engagement,—,2,2,MET,NONE,Communication plan documented in C8-Course-README; cohort channel and instructor SLAs specified; M8.7 mandatory HITL provides scheduled high-touch instructor interaction; M8.8 co-sign meeting provides capstone synchronous engagement,
27,5.4,Course requirements align with course duration,—,2,2,MET,NONE,"C8-Time-Estimate documents 40 active hours / 4-5 weeks elapsed; per-module time estimates with cooling periods; course duration matches Stage 2 cadence; non-negotiable calendar windows (M8.7 HITL, M8.8 Opus + co-sign) accommodated within course duration",
28,6.1,Tools support objectives,Essential,3,3,MET,NONE,"Tool selection (Stripe, Google Sheets/Excel, Supabase) supports objectives; Pricing Math Spreadsheet Template directly supports M8.2 unit economics calculation and M8.4 architecture coherence; Supabase tracks compliance for M8.6 policy and M8.7 schedule; Stripe configuration supports M8.4 architecture execution",
29,6.2,Course tools promote learner engagement,—,2,2,MET,NONE,Pricing Math Spreadsheet provides interactive computation; Supabase RLS enables secure operator-private access; Stripe walkthrough enables hands-on payment configuration; Mermaid diagrams in Module Map enhance visual engagement; AI reviewers provide interactive feedback,
30,6.3,Tool privacy policies,—,1,1,MET,NONE,"Tool privacy addressed in tool setup guides; Supabase RLS policies documented in Supabase-C8-Schema; Stripe privacy at platform level; spreadsheet platforms (Google Sheets, Excel) at platform level; data flow documented in Pricing-Math-Spreadsheet-to-Supabase-Walkthrough",
31,6.4,Tools currently supported,—,1,1,MET,NONE,"All referenced tools are currently in active vendor support (Stripe, Google Sheets, Excel, Supabase); Build 6 is current production build; Sonnet 4.6 and Opus 4.7 are current Anthropic models",
32,7.1,Technical support information,Essential,3,3,MET,NONE,Technical support paths documented in tool setup guides; Stripe vendor support; Supabase platform support; instructor support via HITL queues; community channel support via #c8-pricing-discipline,
33,7.2,Accessibility support information,Essential,3,3,MET,NONE,Accessibility addressed in 08_Community-Prompts and at the platform level; QM 8.x standards specifically addressed below; Mermaid diagrams have text-based source for screen-reader accessibility; markdown source format ensures readability across assistive technology,
34,7.3,Academic support services,—,2,2,MET,NONE,Cohort partner support documented; instructor support via mandatory M8.7 HITL and M8.8 co-sign; community channel support; Race-to-the-Bottom Recognition Checklist provides self-pacing diagnostic tool,
35,7.4,Student services resources,—,1,1,MET,NONE,Cohort and instructor resources documented; community channel as peer support resource; resource set in 02_Resources serves as self-help reference; Pricing Pressure Conversation Scripts available for ongoing practice support,
36,8.1,Course navigation facilitates ease of use,Essential,3,3,MET,NONE,8-folder structure consistent with C7 (cross-course consistency); files use consistent naming convention (C8-* prefix); module folders 01/M8.X organize lesson files; Course-README provides comprehensive navigation; Module-Map Mermaid diagram visualizes flow with explicit cooling-period and HITL gate annotations,
37,8.2,Technology accessibility information,—,2,2,MET,NONE,"Tool accessibility addressed in setup guides; Stripe and Supabase platform accessibility addressed at platform level; markdown format ensures accessibility; spreadsheet platforms (Google Sheets, Excel) provide platform-level accessibility features",
38,8.3,Alternative means of access (multiple formats),Essential,3,2,PARTIAL,MEDIUM,"Only M8.1 has a companion Video Spec file; M8.2-M8.8 do not, limiting alternative-means-of-access scoring. Markdown content is screen-reader accessible by default, but the absence of video alternatives for 7 of 8 modules constrains the SRS score to 2/3. Certification requires MET status on all 16 Essential SRS items, so this is a certification-blocker. This pattern matches C7's deliberate scope-management decision: video spec for M8.1 serves as production template for downstream module spec authoring.","Add companion video specs for M8.2-M8.8 modules; M8.1 video spec serves as template. Each video spec ~2,000 words, beat-by-beat outline, slide aesthetics, atomization plan."
39,8.4,Course design facilitates readability,—,2,2,MET,NONE,"Markdown source ensures structural headings; consistent header levels across documents; tables used for comparison and reference (margin benchmarks, tier appropriateness scoring, raise communication anti-patterns); Mermaid diagrams include labels; line lengths and paragraph breaks support readability",
40,8.5,Multimedia ease of use,—,2,2,MET,NONE,M8.1 video spec provides production guidance; Mermaid diagrams included inline in markdown; audio/video alternatives where present support the content; M8.1 video spec includes captioning and accessibility specifications,
41,8.6,Vendor accessibility statements,—,1,0,NOT_MET,MEDIUM,"Vendor accessibility statements not compiled for the third-party tools referenced in 04_Tools-and-Infrastructure (Stripe, Google Sheets, Excel, Supabase). Non-Essential SRS but fully preventable gap. Recommended remediation: add a 'Vendor Accessibility Statements' subsection to Stripe-Pricing-Setup-Guide or to the Course-README, with links to each vendor's published accessibility documentation.","Compile vendor accessibility statements from Stripe (https://stripe.com/accessibility), Google Workspace, Microsoft, and Supabase. Add a subsection to the Course-README or Stripe-Pricing-Setup-Guide."

[Source control separator U+000C]
,Certification-Blocking Items — C8 Pricing Discipline
0,
1,This course is currently NOT_CERTIFIED with 92/94 points (97.9%) and 15/16 Essential SRS items met. The following items require remediation to achieve certification:
2,
3,"SRS 8.3 PARTIAL (2/3): Only M8.1 has a companion Video Spec file; M8.2-M8.8 do not, limiting alternative-means-of-access scoring. Markdown content is screen-reader accessible by default, but the absence of video alternatives for 7 of 8 modules constrains the SRS score to 2/3. Certification requires MET status on all 16 Essential SRS items, so this is a certification-blocker."
4,
5,
6,"SRS 8.6 NOT_MET (0/1): Vendor accessibility statements not compiled for the third-party tools referenced in 04_Tools-and-Infrastructure (Stripe, Google Sheets, Excel, Supabase). Non-Essential SRS but fully preventable gap. Recommended remediation: add a 'Vendor Accessibility Statements' subsection to Stripe-Pricing-Setup-Guide or to the Course-README, with links to each vendor's published accessibility documentation."
7,
8,
9,
10,
11,Expected Resolution
12,
13,"Both blockers are documentation-completion items, not architectural deficiencies. Full certification is achievable in a focused 2-3 day completion sprint after initial deployment. The course can deploy as NOT_CERTIFIED and be re-audited to CERTIFIED status without architectural revision. This pattern matches C7's deployment trajectory."

Complete local staged workbook cells — variant 1

# Summary
A1: QM Audit Summary — C8 Pricing Discipline
A3: Course ID
B3: C8
A4: Course Title
B4: Pricing Discipline
A5: Stage
B5: Stage 2 (Sailboat)
A6: Audit Date
B6: 2026-04-26
A7: Auditor Version
B7: 1.0.0-manual-apply
A8: Rubric Version
B8: QM HE Rubric 7th Edition V2.0
A9: Total SRS Items
B9: 42
A10: Total Points Possible
B10: 94
A11: Essential SRS Items
B11: 16
A12: Certification Threshold
B12: 85% (80 points + all Essentials MET)
A14: Total Score Awarded
B14: 92 / 94
A15: Percentage
B15: 97.9%
A16: Essentials Met
B16: 15 / 16
A17: Certification Status
B17: NOT_CERTIFIED
A20: Course Summary
A22: Course Completeness
B22: Strong: 8 modules, 7 deliverable artifacts produced by operators (M8.2 Unit Economics Document, M8.3 Reality Check Decision Memo, M8.4 Pricing Architecture Document, M8.5 Tier Structure or Flat-Pricing Rationale, M8.6 Anti-Discount Policy, M8.7 Price-Raise Schedule, M8.8 Pricing Discipline Attestation), 1 capstone synthesis (M8.8) with Opus 4.7 cross-artifact validation, 6 Claude system prompts (5 Sonnet reviewers + 1 Opus capstone validator), 4 SOPs, 4 case studies, integrated cohort-and-instructor review structure including mandatory M8.7 HITL
A23: Doctrine Introduction
B23: C8 introduces one new doctrine: Pricing Is Operator Self-Respect (introduced in M8.1, reinforced across M8.6 anti-discount policy and M8.8 attestation). The doctrine treats under-pricing not as generosity but as a tax on the operator's future capacity, with cascading effects on quality, sustainability, and mechanism integrity.
A24: Stage 2 Position
B24: Third course of Stage 2 (Sailboat); structural midpoint of Stage 2; follows C7 Offer Architecture; precedes C9 Distribution. C8 produces the 12-month pricing system that C9 distribution operates against. C8 completion advances Stage 2 progress to 60%.
A25: Primary Certification Blockers
B25: • SRS 8.3 PARTIAL: video specs only for M8.1; remediation requires producing companion video specs for M8.2-M8.8
• SRS 8.6 NOT_MET: vendor accessibility statements not compiled; remediation requires adding vendor accessibility documentation
A26: Expected Resolution
B26: Both blockers are documentation-completion items, not architectural deficiencies. Full certification is achievable in a focused 2-3 day completion sprint after initial deployment. The course can deploy as NOT_CERTIFIED and be re-audited to CERTIFIED status without architectural revision. This pattern matches C7's deployment trajectory.
A27: Continuity With C7
B27: C8 mirrors C7 structure (8-folder layout, same artifact-class breakdown, same doctrinal continuity); cross-course narrative (Maya, Darius, Priya) advances; Maya's Sprint v1.0→v2.0 transition (C7) carries into Sprint v2.0 unit economics analysis (M8.2) and architecture commitment (M8.4); new failure case (Race-to-the-Bottom Trap) introduced; same certification-blocker pattern (SRS 8.3 + SRS 8.6) facilitates parallel remediation cycle.
A28: Operator Load
B28: 40 active hours / 4-5 elapsed weeks; non-negotiable calendar windows include 24-48 hour cooling periods between modules (M8.2→M8.3 24hr, M8.3→M8.4 48hr, M8.4→M8.5 48hr, M8.7→M8.8 48hr), mandatory M8.7 HITL on every submission (72hr SLA), and M8.8 Opus 4.7 + instructor co-sign within 14-day cosign window.
# General Standards
A1: GS #
B1: General Standard
C1: Score
D1: Max
E1: %
F1: Essentials Met
G1: Essentials Total
A2: 1
B2: Course Overview and Introduction
C2: 15
D2: 15
E2: 100.0%
F2: 3
G2: 3
A3: 2
B3: Learning Objectives (Competencies)
C3: 15
D3: 15
E3: 100.0%
F3: 2
G3: 2
A4: 3
B4: Assessment and Measurement
C4: 13
D4: 13
E4: 100.0%
F4: 3
G4: 3
A5: 4
B5: Instructional Materials
C5: 12
D5: 12
E5: 100.0%
F5: 1
G5: 1
A6: 5
B6: Learning Activities and Learner Interaction
C6: 10
D6: 10
E6: 100.0%
F6: 2
G6: 2
A7: 6
B7: Course Technology
C7: 7
D7: 7
E7: 100.0%
F7: 1
G7: 1
A8: 7
B8: Learner Support
C8: 9
D8: 9
E8: 100.0%
F8: 2
G8: 2
A9: 8
B9: Accessibility and Usability
C9: 11
D9: 13
E9: 84.6%
F9: 1
G9: 2
# SRS Detail
A1: SRS ID
B1: Description
C1: Essential
D1: Max
E1: Awarded
F1: Status
G1: Gap Severity
H1: Evidence
I1: Remediation Hint
A2: 1.1
B2: Instructions make clear how to get started
C2: Essential
D2: 3
E2: 3
F2: MET
G2: NONE
H2: C8-Course-README has explicit 'How to Use This Course' navigation with serial module structure (M8.1 → M8.8); C8-Module-Map specifies module dependencies and HITL/cooling gates; C8-Prerequisites-Checklist gates enrollment with explicit C7 Offer Architecture v2.0 + capacity sign-off + 24h cooling validation; M8.1 written lesson opens with course-positioning summary and the 12-Month Pricing Test diagnostic
A3: 1.2
B3: Learners introduced to course purpose and structure
C3: Essential
D3: 3
E3: 3
F3: MET
G3: NONE
H3: C8-Course-README and M8.1 establish the Pricing Decision vs Pricing Discipline distinction and Pricing Is Operator Self-Respect doctrine; C8-Learning-Outcomes maps 8 CLOs to module-level objectives; C8-Time-Estimate provides 40hr active / 4-5 weeks elapsed pacing with named non-negotiable calendar windows; the Stage 2 third-course position (structural midpoint of Sailboat) is explicitly named
A4: 1.3
B4: Communication expectations stated clearly
C4: Essential
D4: 2
E4: 2
F4: MET
G4: NONE
H4: Communication norms specified in 06_SOPs (anti-discount enforcement and price-raise execution SOPs); cohort communication framed in 08_Community-Prompts; instructor turnaround SLAs (72hr for M8.7 mandatory HITL, 14-day window for M8.8 Opus 4.7 + co-sign) documented in All-Module-Checkpoints
A5: 1.4
B5: Institutional policies clearly stated
C5: —
D5: 2
E5: 2
F5: MET
G5: NONE
H5: Resubmission policy documented in All-Module-Checkpoints; new C8 doctrine (Pricing Is Operator Self-Respect) grounds course-level policies; continuity with C6 Iteration Without Drift, C7 Honest Capacity and Architecture-vs-Pivot maintained; M8.6 Anti-Discount Policy structurally codifies enforcement boundaries
A6: 1.5
B6: Technology requirements stated
C6: —
D6: 1
E6: 1
F6: MET
G6: NONE
H6: Tooling requirements specified in Stripe-Pricing-Setup-Guide and Pricing-Math-Spreadsheet-to-Supabase-Walkthrough; Supabase-C8-Schema documents required infrastructure; Pricing Math Spreadsheet Template enumerates spreadsheet platform requirements (Google Sheets or Excel)
A7: 1.6
B7: Prerequisite knowledge stated
C7: —
D7: 1
E7: 1
F7: MET
G7: NONE
H7: C8-Prerequisites-Checklist explicitly references C1-C7 completion with specific artifact requirements; C7 Offer Architecture Document and capacity sign-off required as enrollment gates; per-section verification of C7 outputs (Offer v2.0, Capacity Constraint Analysis, Operator Bandwidth Audit, Time Tracking measurement data)
A8: 1.7
B8: Technical skills expected
C8: —
D8: 1
E8: 1
F8: MET
G8: NONE
H8: Technical skill expectations documented in tool setup guides; spreadsheet formula skills identified in Pricing Math Spreadsheet Template; Supabase row submission and JSONB structure skills referenced in walkthrough
A9: 1.8
B9: Instructor self-introduction
C9: —
D9: 1
E9: 1
F9: MET
G9: NONE
H9: Instructor role and HITL responsibilities documented in M8.2 (unit economics review escalation), M8.7 (mandatory raise schedule HITL on every submission), and M8.8 (Opus 4.7 + co-sign); instructor co-sign function clearly defined as the C9 enrollment authorization
A10: 1.9
B10: Learner self-introduction
C10: —
D10: 1
E10: 1
F10: MET
G10: NONE
H10: Cohort introduction via C8-Community-Prompts (#c8-pricing-discipline channel); operator population identification in M8.1 Distinction Statement; cohort partner pairing continued from C7
A11: 2.1
B11: Course learning objectives measurable
C11: Essential
D11: 3
E11: 3
F11: MET
G11: NONE
H11: 8 CLOs documented in C8-Learning-Outcomes with Bloom's level mapping; each CLO uses measurable verbs (Distinguish, Calculate, Evaluate, Architect, Design, Author, Specify, Synthesize); M8.8 Pricing Discipline Attestation with Opus 4.7 validator provides measurement framework for all 12 attestation dimensions
A12: 2.2
B12: Module objectives measurable and consistent with CLOs
C12: Essential
D12: 3
E12: 3
F12: MET
G12: NONE
H12: Module-level objectives in C8-Learning-Outcomes map directly to CLOs; each module's MLOs include at least one observable artifact production verb; QM standards mapping by module documented; module deliverables (M8.2 Unit Economics, M8.4 Architecture, M8.6 Policy, M8.7 Schedule, M8.8 Attestation) provide direct objective measurement
A13: 2.3
B13: Learning objectives clearly stated
C13: —
D13: 3
E13: 3
F13: MET
G13: NONE
H13: Objectives stated in operator-facing language in C8-Course-README and per-module written lessons; objectives appear at the top of each module's written lesson; objectives use second person ('You will calculate', 'You will architect')
A14: 2.4
B14: Relationship between objectives and activities
C14: —
D14: 3
E14: 3
F14: MET
G14: NONE
H14: Each module's written lesson explicitly ties activities to objectives; the deliverable per module is the artifact that demonstrates objective achievement; Sonnet/Opus reviewers verify activity-to-objective alignment per criteria specified in system prompt YAMLs
A15: 2.5
B15: Objectives suited to course level
C15: —
D15: 3
E15: 3
F15: MET
G15: NONE
H15: Bloom's distribution skews toward Apply, Evaluate, Create at this stage of operator development (Stage 2 mid-course); objectives appropriate for operators who have completed C1-C7; not too advanced (no distribution-management objectives belonging to C9) and not too basic (no offer-discovery objectives belonging to C7)
A16: 3.1
B16: Assessments measure learning objectives
C16: Essential
D16: 3
E16: 3
F16: MET
G16: NONE
H16: Each module checkpoint specifies pass criteria tied to module objectives in All-Module-Checkpoints; each Sonnet/Opus reviewer has criteria mapped to objectives; M8.8 capstone assessment cross-references all 8 module objectives via attestation 12-section structure with cross-artifact coherence verification (Section 8 Q1-Q4)
A17: 3.2
B17: Grading policy stated
C17: Essential
D17: 3
E17: 3
F17: MET
G17: NONE
H17: Decision thresholds documented in each Sonnet reviewer YAML (CLEARED / NEEDS_REVISION / NOT_CLEARED); Opus 4.7 capstone validator decision thresholds specified (PASS_TO_INSTRUCTOR / NEEDS_REVISION / FAIL); resubmission protocols documented in All-Module-Checkpoints
A18: 3.3
B18: Specific and descriptive grading criteria
C18: Essential
D18: 3
E18: 3
F18: MET
G18: NONE
H18: Each Sonnet reviewer YAML lists 8-10 review criteria with scoring scales; Opus 4.7 validator lists 12 review dimensions with scoring scale; criteria are specific and descriptive (e.g., 'exception_list_specifies_trigger_magnitude_documentation', 'rationalization_patterns_absent')
A19: 3.4
B19: Multiple assessment types
C19: —
D19: 2
E19: 2
F19: MET
G19: NONE
H19: Mixed assessment types: artifact-based (M8.2 Unit Economics Document, M8.4 Architecture Document, etc.), process-based (M8.7 mandatory HITL conversation), capstone synthesis (M8.8 Attestation), self-diagnostic (Race-to-the-Bottom Recognition Checklist). Multiple modalities (writing, calculation, dialog, signing)
A20: 3.5
B20: Self-check or practice opportunities
C20: —
D20: 2
E20: 2
F20: MET
G20: NONE
H20: Worksheets provide self-check opportunities (Hidden Hours Audit, 12-Month Pricing Test, Tier Appropriateness Diagnostic); Pricing Pressure Conversation Scripts for practice; Race-to-the-Bottom Recognition Checklist provides ongoing self-diagnostic; Unit Economics Walkthrough Prompt Chain provides interactive practice with Claude
A21: 4.1
B21: Instructional materials align with objectives
C21: Essential
D21: 3
E21: 3
F21: MET
G21: NONE
H21: Each module written lesson aligns with module objectives; templates and worksheets directly support deliverable production; system prompt YAMLs verify alignment between submitted artifacts and module objectives
A22: 4.2
B22: Materials contribute to objectives
C22: —
D22: 3
E22: 3
F22: MET
G22: NONE
H22: All 13 resources in 02_Resources serve specific module objectives (templates for deliverables, worksheets for diagnostic activities, frameworks for conceptual grounding, swipe files for operational language, checklists for ongoing discipline); no orphan materials
A23: 4.3
B23: Instructional materials current
C23: —
D23: 2
E23: 2
F23: MET
G23: NONE
H23: C8 references current pricing literature (Hermann Simon, Ramanujam+Tacke, Patrick Campbell ProfitWell, Hormozi, Michalowicz, Crabtree, Stark, Brennan Dunn, Russell Brunson, Jonah Berger, Chris Voss, Blair Enns, Jay Abraham, patio11) including post-2020 sources; Stripe-Pricing-Setup-Guide reflects current Stripe product structure; Build 6 references current production schema
A24: 4.4
B24: Materials clearly identified by purpose
C24: —
D24: 2
E24: 2
F24: MET
G24: NONE
H24: Each resource includes 'Used in' header indicating module reference and purpose; folder structure organizes materials by type (Templates, Worksheets, Frameworks, Reference-Charts, Swipe-Files, Checklists); Course-README references resources by module
A25: 4.5
B25: Variety of instructional materials
C25: —
D25: 2
E25: 2
F25: MET
G25: NONE
H25: Variety includes written lessons, video specs, templates, worksheets, frameworks, reference charts, swipe files, checklists, scripts, prompt chains, case studies; Mermaid diagrams included for module flow visualization; conceptual narrative + structural template + practice script + diagnostic worksheet pattern across multiple modules
A26: 5.1
B26: Activities promote objective achievement
C26: Essential
D26: 3
E26: 3
F26: MET
G26: NONE
H26: Module activities directly produce module deliverables that demonstrate objective achievement; e.g., M8.2 Unit Economics calculation activity → Unit Economics Document deliverable → CLO 'Calculate operator unit economics from measured C7 data'
A27: 5.2
B27: Learning activities provide opportunity for interaction
C27: Essential
D27: 3
E27: 3
F27: MET
G27: NONE
H27: Multiple interaction modalities: AI reviewer dialog (M8.2-M8.6), instructor HITL conversation (M8.7 mandatory + M8.8 co-sign), cohort partner review (Pricing-Pressure-Conversation-Scripts practice), live customer interaction (M8.6 anti-discount policy execution); cohort channel for peer interaction
A28: 5.3
B28: Communication plans facilitate engagement
C28: —
D28: 2
E28: 2
F28: MET
G28: NONE
H28: Communication plan documented in C8-Course-README; cohort channel and instructor SLAs specified; M8.7 mandatory HITL provides scheduled high-touch instructor interaction; M8.8 co-sign meeting provides capstone synchronous engagement
A29: 5.4
B29: Course requirements align with course duration
C29: —
D29: 2
E29: 2
F29: MET
G29: NONE
H29: C8-Time-Estimate documents 40 active hours / 4-5 weeks elapsed; per-module time estimates with cooling periods; course duration matches Stage 2 cadence; non-negotiable calendar windows (M8.7 HITL, M8.8 Opus + co-sign) accommodated within course duration
A30: 6.1
B30: Tools support objectives
C30: Essential
D30: 3
E30: 3
F30: MET
G30: NONE
H30: Tool selection (Stripe, Google Sheets/Excel, Supabase) supports objectives; Pricing Math Spreadsheet Template directly supports M8.2 unit economics calculation and M8.4 architecture coherence; Supabase tracks compliance for M8.6 policy and M8.7 schedule; Stripe configuration supports M8.4 architecture execution
A31: 6.2
B31: Course tools promote learner engagement
C31: —
D31: 2
E31: 2
F31: MET
G31: NONE
H31: Pricing Math Spreadsheet provides interactive computation; Supabase RLS enables secure operator-private access; Stripe walkthrough enables hands-on payment configuration; Mermaid diagrams in Module Map enhance visual engagement; AI reviewers provide interactive feedback
A32: 6.3
B32: Tool privacy policies
C32: —
D32: 1
E32: 1
F32: MET
G32: NONE
H32: Tool privacy addressed in tool setup guides; Supabase RLS policies documented in Supabase-C8-Schema; Stripe privacy at platform level; spreadsheet platforms (Google Sheets, Excel) at platform level; data flow documented in Pricing-Math-Spreadsheet-to-Supabase-Walkthrough
A33: 6.4
B33: Tools currently supported
C33: —
D33: 1
E33: 1
F33: MET
G33: NONE
H33: All referenced tools are currently in active vendor support (Stripe, Google Sheets, Excel, Supabase); Build 6 is current production build; Sonnet 4.6 and Opus 4.7 are current Anthropic models
A34: 7.1
B34: Technical support information
C34: Essential
D34: 3
E34: 3
F34: MET
G34: NONE
H34: Technical support paths documented in tool setup guides; Stripe vendor support; Supabase platform support; instructor support via HITL queues; community channel support via #c8-pricing-discipline
A35: 7.2
B35: Accessibility support information
C35: Essential
D35: 3
E35: 3
F35: MET
G35: NONE
H35: Accessibility addressed in 08_Community-Prompts and at the platform level; QM 8.x standards specifically addressed below; Mermaid diagrams have text-based source for screen-reader accessibility; markdown source format ensures readability across assistive technology
A36: 7.3
B36: Academic support services
C36: —
D36: 2
E36: 2
F36: MET
G36: NONE
H36: Cohort partner support documented; instructor support via mandatory M8.7 HITL and M8.8 co-sign; community channel support; Race-to-the-Bottom Recognition Checklist provides self-pacing diagnostic tool
A37: 7.4
B37: Student services resources
C37: —
D37: 1
E37: 1
F37: MET
G37: NONE
H37: Cohort and instructor resources documented; community channel as peer support resource; resource set in 02_Resources serves as self-help reference; Pricing Pressure Conversation Scripts available for ongoing practice support
A38: 8.1
B38: Course navigation facilitates ease of use
C38: Essential
D38: 3
E38: 3
F38: MET
G38: NONE
H38: 8-folder structure consistent with C7 (cross-course consistency); files use consistent naming convention (C8-* prefix); module folders 01/M8.X organize lesson files; Course-README provides comprehensive navigation; Module-Map Mermaid diagram visualizes flow with explicit cooling-period and HITL gate annotations
A39: 8.2
B39: Technology accessibility information
C39: —
D39: 2
E39: 2
F39: MET
G39: NONE
H39: Tool accessibility addressed in setup guides; Stripe and Supabase platform accessibility addressed at platform level; markdown format ensures accessibility; spreadsheet platforms (Google Sheets, Excel) provide platform-level accessibility features
A40: 8.3
B40: Alternative means of access (multiple formats)
C40: Essential
D40: 3
E40: 2
F40: PARTIAL
G40: MEDIUM
H40: Only M8.1 has a companion Video Spec file; M8.2-M8.8 do not, limiting alternative-means-of-access scoring. Markdown content is screen-reader accessible by default, but the absence of video alternatives for 7 of 8 modules constrains the SRS score to 2/3. Certification requires MET status on all 16 Essential SRS items, so this is a certification-blocker. This pattern matches C7's deliberate scope-management decision: video spec for M8.1 serves as production template for downstream module spec authoring.
I40: Add companion video specs for M8.2-M8.8 modules; M8.1 video spec serves as template. Each video spec ~2,000 words, beat-by-beat outline, slide aesthetics, atomization plan.
A41: 8.4
B41: Course design facilitates readability
C41: —
D41: 2
E41: 2
F41: MET
G41: NONE
H41: Markdown source ensures structural headings; consistent header levels across documents; tables used for comparison and reference (margin benchmarks, tier appropriateness scoring, raise communication anti-patterns); Mermaid diagrams include labels; line lengths and paragraph breaks support readability
A42: 8.5
B42: Multimedia ease of use
C42: —
D42: 2
E42: 2
F42: MET
G42: NONE
H42: M8.1 video spec provides production guidance; Mermaid diagrams included inline in markdown; audio/video alternatives where present support the content; M8.1 video spec includes captioning and accessibility specifications
A43: 8.6
B43: Vendor accessibility statements
C43: —
D43: 1
E43: 0
F43: NOT_MET
G43: MEDIUM
H43: Vendor accessibility statements not compiled for the third-party tools referenced in 04_Tools-and-Infrastructure (Stripe, Google Sheets, Excel, Supabase). Non-Essential SRS but fully preventable gap. Recommended remediation: add a 'Vendor Accessibility Statements' subsection to Stripe-Pricing-Setup-Guide or to the Course-README, with links to each vendor's published accessibility documentation.
I43: Compile vendor accessibility statements from Stripe (https://stripe.com/accessibility), Google Workspace, Microsoft, and Supabase. Add a subsection to the Course-README or Stripe-Pricing-Setup-Guide.
# Certification Blockers
A1: Certification-Blocking Items — C8 Pricing Discipline
A3: This course is currently NOT_CERTIFIED with 92/94 points (97.9%) and 15/16 Essential SRS items met. The following items require remediation to achieve certification:
A5: SRS 8.3 PARTIAL (2/3): Only M8.1 has a companion Video Spec file; M8.2-M8.8 do not, limiting alternative-means-of-access scoring. Markdown content is screen-reader accessible by default, but the absence of video alternatives for 7 of 8 modules constrains the SRS score to 2/3. Certification requires MET status on all 16 Essential SRS items, so this is a certification-blocker.
A8: SRS 8.6 NOT_MET (0/1): Vendor accessibility statements not compiled for the third-party tools referenced in 04_Tools-and-Infrastructure (Stripe, Google Sheets, Excel, Supabase). Non-Essential SRS but fully preventable gap. Recommended remediation: add a 'Vendor Accessibility Statements' subsection to Stripe-Pricing-Setup-Guide or to the Course-README, with links to each vendor's published accessibility documentation.
A13: Expected Resolution
A15: Both blockers are documentation-completion items, not architectural deficiencies. Full certification is achievable in a focused 2-3 day completion sprint after initial deployment. The course can deploy as NOT_CERTIFIED and be re-audited to CERTIFIED status without architectural revision. This pattern matches C7's deployment trajectory.

QM-Audit-C8.json

Read this as a historical internal audit

Correct the rubric identity before rescoring

Keep source findings distinct from verified evidence

C8 audit row 1.1 — Instructions make clear how to get started

C8 audit row 1.2 — Learners introduced to course purpose and structure

C8 audit row 1.3 — Communication expectations stated clearly

Source row 1.3, Communication expectations stated clearly: awarded 2 of 2; status MET; essential flag True; gap severity NONE. The source cites: Communication norms specified in 06_SOPs (anti-discount enforcement and price-raise execution SOPs); cohort communication framed in 08_Community-Prompts; instructor turnaround SLAs (72hr for M8.7 mandatory HITL, 14-day window for M8.8 Opus 4.7 + co-sign) documented in All-Module-Checkpoints RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 1.4 — Institutional policies clearly stated

Source row 1.4, Institutional policies clearly stated: awarded 2 of 2; status MET; essential flag False; gap severity NONE. The source cites: Resubmission policy documented in All-Module-Checkpoints; new C8 doctrine (Pricing Is Operator Self-Respect) grounds course-level policies; continuity with C6 Iteration Without Drift, C7 Honest Capacity and Architecture-vs-Pivot maintained; M8.6 Anti-Discount Policy structurally codifies enforcement boundaries RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 1.5 — Technology requirements stated

C8 audit row 1.6 — Prerequisite knowledge stated

C8 audit row 1.7 — Technical skills expected

Source row 1.7, Technical skills expected: awarded 1 of 1; status MET; essential flag False; gap severity NONE. The source cites: Technical skill expectations documented in tool setup guides; spreadsheet formula skills identified in Pricing Math Spreadsheet Template; Supabase row submission and JSONB structure skills referenced in walkthrough RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 1.8 — Instructor self-introduction

Source row 1.8, Instructor self-introduction: awarded 1 of 1; status MET; essential flag False; gap severity NONE. The source cites: Instructor role and HITL responsibilities documented in M8.2 (unit economics review escalation), M8.7 (mandatory raise schedule HITL on every submission), and M8.8 (Opus 4.7 + co-sign); instructor co-sign function clearly defined as the C9 enrollment authorization RISER review: An instructor’s assigned responsibilities do not substitute for an actual learner-facing instructor introduction.

C8 audit row 1.9 — Learner self-introduction

C8 audit row 2.1 — Course learning objectives measurable

C8 audit row 2.2 — Module objectives measurable and consistent with CLOs

Source row 2.2, Module objectives measurable and consistent with CLOs: awarded 3 of 3; status MET; essential flag True; gap severity NONE. The source cites: Module-level objectives in C8-Learning-Outcomes map directly to CLOs; each module's MLOs include at least one observable artifact production verb; QM standards mapping by module documented; module deliverables (M8.2 Unit Economics, M8.4 Architecture, M8.6 Policy, M8.7 Schedule, M8.8 Attestation) provide direct objective measurement RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 2.3 — Learning objectives clearly stated

Source row 2.3, Learning objectives clearly stated: awarded 3 of 3; status MET; essential flag False; gap severity NONE. The source cites: Objectives stated in operator-facing language in C8-Course-README and per-module written lessons; objectives appear at the top of each module's written lesson; objectives use second person ('You will calculate', 'You will architect') RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 2.4 — Relationship between objectives and activities

Source row 2.4, Relationship between objectives and activities: awarded 3 of 3; status MET; essential flag False; gap severity NONE. The source cites: Each module's written lesson explicitly ties activities to objectives; the deliverable per module is the artifact that demonstrates objective achievement; Sonnet/Opus reviewers verify activity-to-objective alignment per criteria specified in system prompt YAMLs RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 2.5 — Objectives suited to course level

C8 audit row 3.1 — Assessments measure learning objectives

Source row 3.1, Assessments measure learning objectives: awarded 3 of 3; status MET; essential flag True; gap severity NONE. The source cites: Each module checkpoint specifies pass criteria tied to module objectives in All-Module-Checkpoints; each Sonnet/Opus reviewer has criteria mapped to objectives; M8.8 capstone assessment cross-references all 8 module objectives via attestation 12-section structure with cross-artifact coherence verification (Section 8 Q1-Q4) RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 3.2 — Grading policy stated

C8 audit row 3.3 — Specific and descriptive grading criteria

C8 audit row 3.4 — Multiple assessment types

C8 audit row 3.5 — Self-check or practice opportunities

C8 audit row 4.1 — Instructional materials align with objectives

C8 audit row 4.2 — Materials contribute to objectives

C8 audit row 4.3 — Instructional materials current

C8 audit row 4.4 — Materials clearly identified by purpose

C8 audit row 4.5 — Variety of instructional materials

C8 audit row 5.1 — Activities promote objective achievement

C8 audit row 5.2 — Learning activities provide opportunity for interaction

C8 audit row 5.3 — Communication plans facilitate engagement

C8 audit row 5.4 — Course requirements align with course duration

C8 audit row 6.1 — Tools support objectives

C8 audit row 6.2 — Course tools promote learner engagement

C8 audit row 6.3 — Tool privacy policies

C8 audit row 6.4 — Tools currently supported

C8 audit row 7.1 — Technical support information

C8 audit row 7.2 — Accessibility support information

C8 audit row 7.3 — Academic support services

Source row 7.3, Academic support services: awarded 2 of 2; status MET; essential flag False; gap severity NONE. The source cites: Cohort partner support documented; instructor support via mandatory M8.7 HITL and M8.8 co-sign; community channel support; Race-to-the-Bottom Recognition Checklist provides self-pacing diagnostic tool RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 7.4 — Student services resources

Source row 7.4, Student services resources: awarded 1 of 1; status MET; essential flag False; gap severity NONE. The source cites: Cohort and instructor resources documented; community channel as peer support resource; resource set in 02_Resources serves as self-help reference; Pricing Pressure Conversation Scripts available for ongoing practice support RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 8.1 — Course navigation facilitates ease of use

Source row 8.1, Course navigation facilitates ease of use: awarded 3 of 3; status MET; essential flag True; gap severity NONE. The source cites: 8-folder structure consistent with C7 (cross-course consistency); files use consistent naming convention (C8-* prefix); module folders 01/M8.X organize lesson files; Course-README provides comprehensive navigation; Module-Map Mermaid diagram visualizes flow with explicit cooling-period and HITL gate annotations RISER review: Check this criterion against the authoritative rubric and test the cited evidence; retain the original assessment separately from the verified result.

C8 audit row 8.2 — Technology accessibility information

Source row 8.2, Technology accessibility information: awarded 2 of 2; status MET; essential flag False; gap severity NONE. The source cites: Tool accessibility addressed in setup guides; Stripe and Supabase platform accessibility addressed at platform level; markdown format ensures accessibility; spreadsheet platforms (Google Sheets, Excel) provide platform-level accessibility features RISER review: Markdown, diagram source, security certifications and vendor platform features do not by themselves establish accessibility. Inspect rendered structure, reading order, keyboard operation and relevant assistive-technology behavior.

C8 audit row 8.3 — Alternative means of access (multiple formats)

C8 audit row 8.4 — Course design facilitates readability

Source row 8.4, Course design facilitates readability: awarded 2 of 2; status MET; essential flag False; gap severity NONE. The source cites: Markdown source ensures structural headings; consistent header levels across documents; tables used for comparison and reference (margin benchmarks, tier appropriateness scoring, raise communication anti-patterns); Mermaid diagrams include labels; line lengths and paragraph breaks support readability RISER review: Markdown, diagram source, security certifications and vendor platform features do not by themselves establish accessibility. Inspect rendered structure, reading order, keyboard operation and relevant assistive-technology behavior.

C8 audit row 8.5 — Multimedia ease of use

C8 audit row 8.6 — Vendor accessibility statements

Source row 8.6, Vendor accessibility statements: awarded 0 of 1; status NOT_MET; essential flag False; gap severity MEDIUM. The source cites: Vendor accessibility statements not compiled for the third-party tools referenced in 04_Tools-and-Infrastructure (Stripe, Google Sheets, Excel, Supabase). Non-Essential SRS but fully preventable gap. Recommended remediation: add a 'Vendor Accessibility Statements' subsection to Stripe-Pricing-Setup-Guide or to the Course-README, with links to each vendor's published accessibility documentation. Its proposed remediation is: Compile vendor accessibility statements from Stripe (https://stripe.com/accessibility), Google Workspace, Microsoft, and Supabase. Add a subsection to the Course-README or Stripe-Pricing-Setup-Guide. RISER review: The source places vendor statements under 8.6, while the official seventh-edition list uses 8.7 for that topic. Retain this source finding and map it correctly before remediation.

C8 audit context — course completeness

C8 audit context — doctrine introduction

C8 audit context — stage 2 position

C8 audit context — primary certification blockers

C8 audit context — expected resolution

The source summary states: Both blockers are documentation-completion items, not architectural deficiencies. Full certification is achievable in a focused 2-3 day completion sprint after initial deployment. The course can deploy as NOT_CERTIFIED and be re-audited to CERTIFIED status without architectural revision. This pattern matches C7's deployment trajectory. Treat this as a historical course-design assertion. Confirm actual artifacts, service capacity and course-version mapping before adopting it as a current promise. The two-to-three-day certification forecast is not a validated completion estimate or official approval.

C8 audit context — continuity with C7

C8 audit context — operator load

Correct accessibility assumptions before declaring remediation complete

Treat the JSON as an audit record, not an automated checker

Connect the lesson to the direct-marketing promise

Complete original source text

{
  "course_id": "C8",
  "course_title": "Pricing Discipline",
  "stage": "Stage 2 (Sailboat)",
  "audit_date": "2026-04-26",
  "auditor_version": "1.0.0-manual-apply",
  "rubric_version": "QM HE Rubric 7th Edition V2.0",
  "rubric_total_srs": 42,
  "rubric_total_points": 94,
  "rubric_essential_count": 16,
  "rubric_certification_threshold_pct": 85,
  "rubric_certification_threshold_points": 80,
  "general_standard_scores": [
    {
      "gs_number": 1,
      "gs_name": "Course Overview and Introduction",
      "score": 15,
      "max": 15,
      "essentials_met": 3,
      "essentials_total": 3
    },
    {
      "gs_number": 2,
      "gs_name": "Learning Objectives (Competencies)",
      "score": 15,
      "max": 15,
      "essentials_met": 2,
      "essentials_total": 2
    },
    {
      "gs_number": 3,
      "gs_name": "Assessment and Measurement",
      "score": 13,
      "max": 13,
      "essentials_met": 3,
      "essentials_total": 3
    },
    {
      "gs_number": 4,
      "gs_name": "Instructional Materials",
      "score": 12,
      "max": 12,
      "essentials_met": 1,
      "essentials_total": 1
    },
    {
      "gs_number": 5,
      "gs_name": "Learning Activities and Learner Interaction",
      "score": 10,
      "max": 10,
      "essentials_met": 2,
      "essentials_total": 2
    },
    {
      "gs_number": 6,
      "gs_name": "Course Technology",
      "score": 7,
      "max": 7,
      "essentials_met": 1,
      "essentials_total": 1
    },
    {
      "gs_number": 7,
      "gs_name": "Learner Support",
      "score": 9,
      "max": 9,
      "essentials_met": 2,
      "essentials_total": 2
    },
    {
      "gs_number": 8,
      "gs_name": "Accessibility and Usability",
      "score": 11,
      "max": 13,
      "essentials_met": 1,
      "essentials_total": 2
    }
  ],
  "srs_scores": [
    {
      "srs_id": "1.1",
      "description": "Instructions make clear how to get started",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "C8-Course-README has explicit 'How to Use This Course' navigation with serial module structure (M8.1 → M8.8); C8-Module-Map specifies module dependencies and HITL/cooling gates; C8-Prerequisites-Checklist gates enrollment with explicit C7 Offer Architecture v2.0 + capacity sign-off + 24h cooling validation; M8.1 written lesson opens with course-positioning summary and the 12-Month Pricing Test diagnostic",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "1.2",
      "description": "Learners introduced to course purpose and structure",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "C8-Course-README and M8.1 establish the Pricing Decision vs Pricing Discipline distinction and Pricing Is Operator Self-Respect doctrine; C8-Learning-Outcomes maps 8 CLOs to module-level objectives; C8-Time-Estimate provides 40hr active / 4-5 weeks elapsed pacing with named non-negotiable calendar windows; the Stage 2 third-course position (structural midpoint of Sailboat) is explicitly named",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "1.3",
      "description": "Communication expectations stated clearly",
      "essential": true,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Communication norms specified in 06_SOPs (anti-discount enforcement and price-raise execution SOPs); cohort communication framed in 08_Community-Prompts; instructor turnaround SLAs (72hr for M8.7 mandatory HITL, 14-day window for M8.8 Opus 4.7 + co-sign) documented in All-Module-Checkpoints",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "1.4",
      "description": "Institutional policies clearly stated",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Resubmission policy documented in All-Module-Checkpoints; new C8 doctrine (Pricing Is Operator Self-Respect) grounds course-level policies; continuity with C6 Iteration Without Drift, C7 Honest Capacity and Architecture-vs-Pivot maintained; M8.6 Anti-Discount Policy structurally codifies enforcement boundaries",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "1.5",
      "description": "Technology requirements stated",
      "essential": false,
      "max_points": 1,
      "awarded_points": 1,
      "status": "MET",
      "evidence": "Tooling requirements specified in Stripe-Pricing-Setup-Guide and Pricing-Math-Spreadsheet-to-Supabase-Walkthrough; Supabase-C8-Schema documents required infrastructure; Pricing Math Spreadsheet Template enumerates spreadsheet platform requirements (Google Sheets or Excel)",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "1.6",
      "description": "Prerequisite knowledge stated",
      "essential": false,
      "max_points": 1,
      "awarded_points": 1,
      "status": "MET",
      "evidence": "C8-Prerequisites-Checklist explicitly references C1-C7 completion with specific artifact requirements; C7 Offer Architecture Document and capacity sign-off required as enrollment gates; per-section verification of C7 outputs (Offer v2.0, Capacity Constraint Analysis, Operator Bandwidth Audit, Time Tracking measurement data)",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "1.7",
      "description": "Technical skills expected",
      "essential": false,
      "max_points": 1,
      "awarded_points": 1,
      "status": "MET",
      "evidence": "Technical skill expectations documented in tool setup guides; spreadsheet formula skills identified in Pricing Math Spreadsheet Template; Supabase row submission and JSONB structure skills referenced in walkthrough",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "1.8",
      "description": "Instructor self-introduction",
      "essential": false,
      "max_points": 1,
      "awarded_points": 1,
      "status": "MET",
      "evidence": "Instructor role and HITL responsibilities documented in M8.2 (unit economics review escalation), M8.7 (mandatory raise schedule HITL on every submission), and M8.8 (Opus 4.7 + co-sign); instructor co-sign function clearly defined as the C9 enrollment authorization",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "1.9",
      "description": "Learner self-introduction",
      "essential": false,
      "max_points": 1,
      "awarded_points": 1,
      "status": "MET",
      "evidence": "Cohort introduction via C8-Community-Prompts (#c8-pricing-discipline channel); operator population identification in M8.1 Distinction Statement; cohort partner pairing continued from C7",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "2.1",
      "description": "Course learning objectives measurable",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "8 CLOs documented in C8-Learning-Outcomes with Bloom's level mapping; each CLO uses measurable verbs (Distinguish, Calculate, Evaluate, Architect, Design, Author, Specify, Synthesize); M8.8 Pricing Discipline Attestation with Opus 4.7 validator provides measurement framework for all 12 attestation dimensions",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "2.2",
      "description": "Module objectives measurable and consistent with CLOs",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Module-level objectives in C8-Learning-Outcomes map directly to CLOs; each module's MLOs include at least one observable artifact production verb; QM standards mapping by module documented; module deliverables (M8.2 Unit Economics, M8.4 Architecture, M8.6 Policy, M8.7 Schedule, M8.8 Attestation) provide direct objective measurement",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "2.3",
      "description": "Learning objectives clearly stated",
      "essential": false,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Objectives stated in operator-facing language in C8-Course-README and per-module written lessons; objectives appear at the top of each module's written lesson; objectives use second person ('You will calculate', 'You will architect')",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "2.4",
      "description": "Relationship between objectives and activities",
      "essential": false,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Each module's written lesson explicitly ties activities to objectives; the deliverable per module is the artifact that demonstrates objective achievement; Sonnet/Opus reviewers verify activity-to-objective alignment per criteria specified in system prompt YAMLs",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "2.5",
      "description": "Objectives suited to course level",
      "essential": false,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Bloom's distribution skews toward Apply, Evaluate, Create at this stage of operator development (Stage 2 mid-course); objectives appropriate for operators who have completed C1-C7; not too advanced (no distribution-management objectives belonging to C9) and not too basic (no offer-discovery objectives belonging to C7)",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "3.1",
      "description": "Assessments measure learning objectives",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Each module checkpoint specifies pass criteria tied to module objectives in All-Module-Checkpoints; each Sonnet/Opus reviewer has criteria mapped to objectives; M8.8 capstone assessment cross-references all 8 module objectives via attestation 12-section structure with cross-artifact coherence verification (Section 8 Q1-Q4)",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "3.2",
      "description": "Grading policy stated",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Decision thresholds documented in each Sonnet reviewer YAML (CLEARED / NEEDS_REVISION / NOT_CLEARED); Opus 4.7 capstone validator decision thresholds specified (PASS_TO_INSTRUCTOR / NEEDS_REVISION / FAIL); resubmission protocols documented in All-Module-Checkpoints",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "3.3",
      "description": "Specific and descriptive grading criteria",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Each Sonnet reviewer YAML lists 8-10 review criteria with scoring scales; Opus 4.7 validator lists 12 review dimensions with scoring scale; criteria are specific and descriptive (e.g., 'exception_list_specifies_trigger_magnitude_documentation', 'rationalization_patterns_absent')",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "3.4",
      "description": "Multiple assessment types",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Mixed assessment types: artifact-based (M8.2 Unit Economics Document, M8.4 Architecture Document, etc.), process-based (M8.7 mandatory HITL conversation), capstone synthesis (M8.8 Attestation), self-diagnostic (Race-to-the-Bottom Recognition Checklist). Multiple modalities (writing, calculation, dialog, signing)",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "3.5",
      "description": "Self-check or practice opportunities",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Worksheets provide self-check opportunities (Hidden Hours Audit, 12-Month Pricing Test, Tier Appropriateness Diagnostic); Pricing Pressure Conversation Scripts for practice; Race-to-the-Bottom Recognition Checklist provides ongoing self-diagnostic; Unit Economics Walkthrough Prompt Chain provides interactive practice with Claude",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "4.1",
      "description": "Instructional materials align with objectives",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Each module written lesson aligns with module objectives; templates and worksheets directly support deliverable production; system prompt YAMLs verify alignment between submitted artifacts and module objectives",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "4.2",
      "description": "Materials contribute to objectives",
      "essential": false,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "All 13 resources in 02_Resources serve specific module objectives (templates for deliverables, worksheets for diagnostic activities, frameworks for conceptual grounding, swipe files for operational language, checklists for ongoing discipline); no orphan materials",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "4.3",
      "description": "Instructional materials current",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "C8 references current pricing literature (Hermann Simon, Ramanujam+Tacke, Patrick Campbell ProfitWell, Hormozi, Michalowicz, Crabtree, Stark, Brennan Dunn, Russell Brunson, Jonah Berger, Chris Voss, Blair Enns, Jay Abraham, patio11) including post-2020 sources; Stripe-Pricing-Setup-Guide reflects current Stripe product structure; Build 6 references current production schema",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "4.4",
      "description": "Materials clearly identified by purpose",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Each resource includes 'Used in' header indicating module reference and purpose; folder structure organizes materials by type (Templates, Worksheets, Frameworks, Reference-Charts, Swipe-Files, Checklists); Course-README references resources by module",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "4.5",
      "description": "Variety of instructional materials",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Variety includes written lessons, video specs, templates, worksheets, frameworks, reference charts, swipe files, checklists, scripts, prompt chains, case studies; Mermaid diagrams included for module flow visualization; conceptual narrative + structural template + practice script + diagnostic worksheet pattern across multiple modules",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "5.1",
      "description": "Activities promote objective achievement",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Module activities directly produce module deliverables that demonstrate objective achievement; e.g., M8.2 Unit Economics calculation activity → Unit Economics Document deliverable → CLO 'Calculate operator unit economics from measured C7 data'",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "5.2",
      "description": "Learning activities provide opportunity for interaction",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Multiple interaction modalities: AI reviewer dialog (M8.2-M8.6), instructor HITL conversation (M8.7 mandatory + M8.8 co-sign), cohort partner review (Pricing-Pressure-Conversation-Scripts practice), live customer interaction (M8.6 anti-discount policy execution); cohort channel for peer interaction",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "5.3",
      "description": "Communication plans facilitate engagement",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Communication plan documented in C8-Course-README; cohort channel and instructor SLAs specified; M8.7 mandatory HITL provides scheduled high-touch instructor interaction; M8.8 co-sign meeting provides capstone synchronous engagement",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "5.4",
      "description": "Course requirements align with course duration",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "C8-Time-Estimate documents 40 active hours / 4-5 weeks elapsed; per-module time estimates with cooling periods; course duration matches Stage 2 cadence; non-negotiable calendar windows (M8.7 HITL, M8.8 Opus + co-sign) accommodated within course duration",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "6.1",
      "description": "Tools support objectives",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Tool selection (Stripe, Google Sheets/Excel, Supabase) supports objectives; Pricing Math Spreadsheet Template directly supports M8.2 unit economics calculation and M8.4 architecture coherence; Supabase tracks compliance for M8.6 policy and M8.7 schedule; Stripe configuration supports M8.4 architecture execution",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "6.2",
      "description": "Course tools promote learner engagement",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Pricing Math Spreadsheet provides interactive computation; Supabase RLS enables secure operator-private access; Stripe walkthrough enables hands-on payment configuration; Mermaid diagrams in Module Map enhance visual engagement; AI reviewers provide interactive feedback",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "6.3",
      "description": "Tool privacy policies",
      "essential": false,
      "max_points": 1,
      "awarded_points": 1,
      "status": "MET",
      "evidence": "Tool privacy addressed in tool setup guides; Supabase RLS policies documented in Supabase-C8-Schema; Stripe privacy at platform level; spreadsheet platforms (Google Sheets, Excel) at platform level; data flow documented in Pricing-Math-Spreadsheet-to-Supabase-Walkthrough",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "6.4",
      "description": "Tools currently supported",
      "essential": false,
      "max_points": 1,
      "awarded_points": 1,
      "status": "MET",
      "evidence": "All referenced tools are currently in active vendor support (Stripe, Google Sheets, Excel, Supabase); Build 6 is current production build; Sonnet 4.6 and Opus 4.7 are current Anthropic models",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "7.1",
      "description": "Technical support information",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Technical support paths documented in tool setup guides; Stripe vendor support; Supabase platform support; instructor support via HITL queues; community channel support via #c8-pricing-discipline",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "7.2",
      "description": "Accessibility support information",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "Accessibility addressed in 08_Community-Prompts and at the platform level; QM 8.x standards specifically addressed below; Mermaid diagrams have text-based source for screen-reader accessibility; markdown source format ensures readability across assistive technology",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "7.3",
      "description": "Academic support services",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Cohort partner support documented; instructor support via mandatory M8.7 HITL and M8.8 co-sign; community channel support; Race-to-the-Bottom Recognition Checklist provides self-pacing diagnostic tool",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "7.4",
      "description": "Student services resources",
      "essential": false,
      "max_points": 1,
      "awarded_points": 1,
      "status": "MET",
      "evidence": "Cohort and instructor resources documented; community channel as peer support resource; resource set in 02_Resources serves as self-help reference; Pricing Pressure Conversation Scripts available for ongoing practice support",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "8.1",
      "description": "Course navigation facilitates ease of use",
      "essential": true,
      "max_points": 3,
      "awarded_points": 3,
      "status": "MET",
      "evidence": "8-folder structure consistent with C7 (cross-course consistency); files use consistent naming convention (C8-* prefix); module folders 01/M8.X organize lesson files; Course-README provides comprehensive navigation; Module-Map Mermaid diagram visualizes flow with explicit cooling-period and HITL gate annotations",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "8.2",
      "description": "Technology accessibility information",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Tool accessibility addressed in setup guides; Stripe and Supabase platform accessibility addressed at platform level; markdown format ensures accessibility; spreadsheet platforms (Google Sheets, Excel) provide platform-level accessibility features",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "8.3",
      "description": "Alternative means of access (multiple formats)",
      "essential": true,
      "max_points": 3,
      "awarded_points": 2,
      "status": "PARTIAL",
      "evidence": "Only M8.1 has a companion Video Spec file; M8.2-M8.8 do not, limiting alternative-means-of-access scoring. Markdown content is screen-reader accessible by default, but the absence of video alternatives for 7 of 8 modules constrains the SRS score to 2/3. Certification requires MET status on all 16 Essential SRS items, so this is a certification-blocker. This pattern matches C7's deliberate scope-management decision: video spec for M8.1 serves as production template for downstream module spec authoring.",
      "gap_severity": "MEDIUM",
      "remediation_hint": "Add companion video specs for M8.2-M8.8 modules; M8.1 video spec serves as template. Each video spec ~2,000 words, beat-by-beat outline, slide aesthetics, atomization plan."
    },
    {
      "srs_id": "8.4",
      "description": "Course design facilitates readability",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "Markdown source ensures structural headings; consistent header levels across documents; tables used for comparison and reference (margin benchmarks, tier appropriateness scoring, raise communication anti-patterns); Mermaid diagrams include labels; line lengths and paragraph breaks support readability",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "8.5",
      "description": "Multimedia ease of use",
      "essential": false,
      "max_points": 2,
      "awarded_points": 2,
      "status": "MET",
      "evidence": "M8.1 video spec provides production guidance; Mermaid diagrams included inline in markdown; audio/video alternatives where present support the content; M8.1 video spec includes captioning and accessibility specifications",
      "gap_severity": "NONE",
      "remediation_hint": ""
    },
    {
      "srs_id": "8.6",
      "description": "Vendor accessibility statements",
      "essential": false,
      "max_points": 1,
      "awarded_points": 0,
      "status": "NOT_MET",
      "evidence": "Vendor accessibility statements not compiled for the third-party tools referenced in 04_Tools-and-Infrastructure (Stripe, Google Sheets, Excel, Supabase). Non-Essential SRS but fully preventable gap. Recommended remediation: add a 'Vendor Accessibility Statements' subsection to Stripe-Pricing-Setup-Guide or to the Course-README, with links to each vendor's published accessibility documentation.",
      "gap_severity": "MEDIUM",
      "remediation_hint": "Compile vendor accessibility statements from Stripe (https://stripe.com/accessibility), Google Workspace, Microsoft, and Supabase. Add a subsection to the Course-README or Stripe-Pricing-Setup-Guide."
    }
  ],
  "total_score": 92,
  "max_score": 94,
  "percentage": 97.9,
  "essentials_met": 15,
  "essentials_total": 16,
  "certification_status": "NOT_CERTIFIED",
  "certification_blocking_reasons": [
    "SRS 8.3 PARTIAL (2/3): Only M8.1 has a companion Video Spec file; M8.2-M8.8 do not, limiting alternative-means-of-access scoring. Markdown content is screen-reader accessible by default, but the absence of video alternatives for 7 of 8 modules constrains the SRS score to 2/3. Certification requires MET status on all 16 Essential SRS items, so this is a certification-blocker.",
    "SRS 8.6 NOT_MET (0/1): Vendor accessibility statements not compiled for the third-party tools referenced in 04_Tools-and-Infrastructure (Stripe, Google Sheets, Excel, Supabase). Non-Essential SRS but fully preventable gap. Recommended remediation: add a 'Vendor Accessibility Statements' subsection to Stripe-Pricing-Setup-Guide or to the Course-README, with links to each vendor's published accessibility documentation."
  ],
  "summary": {
    "course_completeness": "Strong: 8 modules, 7 deliverable artifacts produced by operators (M8.2 Unit Economics Document, M8.3 Reality Check Decision Memo, M8.4 Pricing Architecture Document, M8.5 Tier Structure or Flat-Pricing Rationale, M8.6 Anti-Discount Policy, M8.7 Price-Raise Schedule, M8.8 Pricing Discipline Attestation), 1 capstone synthesis (M8.8) with Opus 4.7 cross-artifact validation, 6 Claude system prompts (5 Sonnet reviewers + 1 Opus capstone validator), 4 SOPs, 4 case studies, integrated cohort-and-instructor review structure including mandatory M8.7 HITL",
    "doctrine_introduction": "C8 introduces one new doctrine: Pricing Is Operator Self-Respect (introduced in M8.1, reinforced across M8.6 anti-discount policy and M8.8 attestation). The doctrine treats under-pricing not as generosity but as a tax on the operator's future capacity, with cascading effects on quality, sustainability, and mechanism integrity.",
    "stage_2_position": "Third course of Stage 2 (Sailboat); structural midpoint of Stage 2; follows C7 Offer Architecture; precedes C9 Distribution. C8 produces the 12-month pricing system that C9 distribution operates against. C8 completion advances Stage 2 progress to 60%.",
    "primary_certification_blockers": [
      "SRS 8.3 PARTIAL: video specs only for M8.1; remediation requires producing companion video specs for M8.2-M8.8",
      "SRS 8.6 NOT_MET: vendor accessibility statements not compiled; remediation requires adding vendor accessibility documentation"
    ],
    "expected_resolution": "Both blockers are documentation-completion items, not architectural deficiencies. Full certification is achievable in a focused 2-3 day completion sprint after initial deployment. The course can deploy as NOT_CERTIFIED and be re-audited to CERTIFIED status without architectural revision. This pattern matches C7's deployment trajectory.",
    "continuity_with_C7": "C8 mirrors C7 structure (8-folder layout, same artifact-class breakdown, same doctrinal continuity); cross-course narrative (Maya, Darius, Priya) advances; Maya's Sprint v1.0→v2.0 transition (C7) carries into Sprint v2.0 unit economics analysis (M8.2) and architecture commitment (M8.4); new failure case (Race-to-the-Bottom Trap) introduced; same certification-blocker pattern (SRS 8.3 + SRS 8.6) facilitates parallel remediation cycle.",
    "operator_load": "40 active hours / 4-5 elapsed weeks; non-negotiable calendar windows include 24-48 hour cooling periods between modules (M8.2→M8.3 24hr, M8.3→M8.4 48hr, M8.4→M8.5 48hr, M8.7→M8.8 48hr), mandatory M8.7 HITL on every submission (72hr SLA), and M8.8 Opus 4.7 + instructor co-sign within 14-day cosign window."
  }
}

QUESTIONS FOR SERVICE PROVIDERS

1. Business Basics

Work through these source questions: What type of service do you provide? How long have you been in business? Are you currently operating in a local or broader regional market? What makes your business unique compared to competitors? RISER use: Use service, tenure, geography and differentiators to define the actual context; a claimed difference needs customer evidence.

2. Financial Status

Work through these source questions: What is your current monthly revenue? What is your current annual revenue? What percentage of your revenue comes from repeat customers vs. new customers? Do you have any overdue accounts receivable? How do you handle overdue payments? What is your average customer transaction value? Do you have an annual sales goal? If yes, what is it? What is your pricing strategy? Are you the cheapest, mid-range, or premium option in your market? RISER use: Specify revenue periods and accounting basis; reconcile repeat/new shares, receivables, transaction value, sales goal and pricing position. Annual revenue need not equal twelve times a seasonal month.

3. Customer Base & Market Position

Work through these source questions: How large is your customer base? Do you serve mostly residential, commercial, or industrial clients? Do you rely on word-of-mouth, advertising, or online platforms to bring in customers? What is the current lifetime value (LTV) of a customer in your business? How do you maintain relationships with your customers after a service has been provided? RISER use: Define active-customer count, segment, acquisition source and realized versus modeled LTV; document post-service relationship work.

4. Sales & Offers

Work through these source questions: What are you selling (product or service)? Do you offer any service bundles or upsell offers to clients? Do you have a structured value ladder that starts with lower-tier services and ascends to premium offerings? What percentage of your sales come from premium, mid-tier, and low-tier services? What benefits do you offer at different pricing tiers? RISER use: Map actual bundles, tiers, sales mix and benefits; do not assume a ladder or upsell is necessary for every customer.

5. Sales Process

Work through these source questions: Do you have a sales team? If yes, how is their performance tracked? What are your top sales objections from customers (price, timing, etc.)? How do you typically handle objections during the sales process? Do you offer financing/payment options to make it easier for customers to buy your services? Do you use a CRM to track leads and customer interactions? If yes, which one? RISER use: Inspect ownership, sales measures, objections, payment options and CRM records. A lower close rate does not justify pressure or hidden terms.

6. Marketing Strategy

Work through these source questions: What marketing channels are you currently using (e.g., social media, SEO, paid ads, etc.)? What percentage of your leads come from online vs. offline sources? What is your average customer acquisition cost (CAC)? How do you track the return on investment (ROI) of your marketing efforts? Do you have any special promotions or referral programs in place to bring in more customers? RISER use: Define online/offline attribution, included acquisition costs, ROI period and promotion/referral terms. Avoid counting a lead twice across channels.

7. Operations & Customer Service

Work through these source questions: How many employees or contractors do you have? How do you ensure the quality of service for each customer interaction? What processes or systems do you have in place for managing customer complaints or service issues? Do you offer any guarantees or warranties on your services? What tools or software do you use to manage scheduling, billing, and customer communication? RISER use: Compare employees/contractors, quality checks, issue resolution, guarantees and operating tools with measured delivery capacity.

8. Customer Experience & Retention

Work through these source questions: Do you have a follow-up process to ensure customer satisfaction after services are rendered? How do you handle customer reviews and feedback? What percentage of your business comes from referrals or repeat customers? Do you use any loyalty programs or incentives to encourage repeat business? RISER use: Distinguish satisfaction follow-up, feedback, referral/repeat revenue and loyalty programs. A referral share and repeat share can overlap.

9. Growth & Future Planning

Work through these source questions: What is your long-term vision for your business? Do you have plans to scale your business? If yes, what does that look like? What are your current challenges or obstacles to growing your business? Do you currently offer or plan to offer any subscription-based services for recurring revenue? What areas of your business would you like to improve (e.g., sales, marketing, operations)? RISER use: Make vision, intended scale, obstacles, recurring-service plans and priority improvements observable, dated hypotheses.

10. Technology & Tools

Work through these source questions: Do you have an online booking system or customer portal? What tools are you using for marketing automation, if any? How are you currently tracking your key performance indicators (KPIs)? Are you open to adopting new technologies to streamline operations and improve customer experience? RISER use: Inventory booking/portal, automation, KPI reporting and adoption readiness. Add tools only for a demonstrated need with an owner and maintenance plan.

Collect answers proportionately and protect the record

This is a questionnaire, not completed business data. Name the purpose, relevant respondent and source for each answer; distinguish unknowns from zeros. Limit access to sensitive financial/customer details and record only what the analysis needs. Turn findings into a prioritized evidence-backed action plan with owner, metric and review date. No questionnaire was sent or customer data collected here.

Connect the lesson to the direct-marketing promise

Complete original source text

Comprehensive Business Questionnaire for Service Providers

1. Business Basics

   * What type of service do you provide?

   * How long have you been in business?

   * Are you currently operating in a local or broader regional market?

   * What makes your business unique compared to competitors?

2. Financial Status

   * What is your current monthly revenue?

   * What is your current annual revenue?

   * What percentage of your revenue comes from repeat customers vs. new customers?

   * Do you have any overdue accounts receivable? How do you handle overdue payments?

   * What is your average customer transaction value?

   * Do you have an annual sales goal? If yes, what is it?

   * What is your pricing strategy? Are you the cheapest, mid-range, or premium option in your market?

3. Customer Base & Market Position

   * How large is your customer base?

   * Do you serve mostly residential, commercial, or industrial clients?

   * Do you rely on word-of-mouth, advertising, or online platforms to bring in customers?

   * What is the current lifetime value (LTV) of a customer in your business?

   * How do you maintain relationships with your customers after a service has been provided?

4. Sales & Offers

   * What are you selling (product or service)?

   * Do you offer any service bundles or upsell offers to clients?

   * Do you have a structured value ladder that starts with lower-tier services and ascends to premium offerings?

   * What percentage of your sales come from premium, mid-tier, and low-tier services?

   * What benefits do you offer at different pricing tiers?

5. Sales Process

   * Do you have a sales team? If yes, how is their performance tracked?

   * What are your top sales objections from customers (price, timing, etc.)?

   * How do you typically handle objections during the sales process?

   * Do you offer financing/payment options to make it easier for customers to buy your services?

   * Do you use a CRM to track leads and customer interactions? If yes, which one?

6. Marketing Strategy

   * What marketing channels are you currently using (e.g., social media, SEO, paid ads, etc.)?

   * What percentage of your leads come from online vs. offline sources?

   * What is your average customer acquisition cost (CAC)?

   * How do you track the return on investment (ROI) of your marketing efforts?

   * Do you have any special promotions or referral programs in place to bring in more customers?

7. Operations & Customer Service

   * How many employees or contractors do you have?

   * How do you ensure the quality of service for each customer interaction?

   * What processes or systems do you have in place for managing customer complaints or service issues?

   * Do you offer any guarantees or warranties on your services?

   * What tools or software do you use to manage scheduling, billing, and customer communication?

8. Customer Experience & Retention

   * Do you have a follow-up process to ensure customer satisfaction after services are rendered?

   * How do you handle customer reviews and feedback?

   * What percentage of your business comes from referrals or repeat customers?

   * Do you use any loyalty programs or incentives to encourage repeat business?

9. Growth & Future Planning

   * What is your long-term vision for your business?

   * Do you have plans to scale your business? If yes, what does that look like?

   * What are your current challenges or obstacles to growing your business?

   * Do you currently offer or plan to offer any subscription-based services for recurring revenue?

   * What areas of your business would you like to improve (e.g., sales, marketing, operations)?

10. Technology & Tools

   * Do you have an online booking system or customer portal?

   * What tools are you using for marketing automation, if any?

   * How are you currently tracking your key performance indicators (KPIs)?

   * Are you open to adopting new technologies to streamline operations and improve customer experience?

Native Google Doc text and original links

Comprehensive Business Questionnaire for Service Providers
Business Basics
What type of service do you provide?
How long have you been in business?
Are you currently operating in a local or broader regional market?
What makes your business unique compared to competitors?
Financial Status
What is your current monthly revenue?
What is your current annual revenue?
What percentage of your revenue comes from repeat customers vs. new customers?
Do you have any overdue accounts receivable? How do you handle overdue payments?
What is your average customer transaction value?
Do you have an annual sales goal? If yes, what is it?
What is your pricing strategy? Are you the cheapest, mid-range, or premium option in your market?
Customer Base & Market Position
How large is your customer base?
Do you serve mostly residential, commercial, or industrial clients?
Do you rely on word-of-mouth, advertising, or online platforms to bring in customers?
What is the current lifetime value (LTV) of a customer in your business?
How do you maintain relationships with your customers after a service has been provided?
Sales & Offers
What are you selling (product or service)?
Do you offer any service bundles or upsell offers to clients?
Do you have a structured value ladder that starts with lower-tier services and ascends to premium offerings?
What percentage of your sales come from premium, mid-tier, and low-tier services?
What benefits do you offer at different pricing tiers?
Sales Process
Do you have a sales team? If yes, how is their performance tracked?
What are your top sales objections from customers (price, timing, etc.)?
How do you typically handle objections during the sales process?
Do you offer financing/payment options to make it easier for customers to buy your services?
Do you use a CRM to track leads and customer interactions? If yes, which one?
Marketing Strategy
What marketing channels are you currently using (e.g., social media, SEO, paid ads, etc.)?
What percentage of your leads come from online vs. offline sources?
What is your average customer acquisition cost (CAC)?
How do you track the return on investment (ROI) of your marketing efforts?
Do you have any special promotions or referral programs in place to bring in more customers?
Operations & Customer Service
How many employees or contractors do you have?
How do you ensure the quality of service for each customer interaction?
What processes or systems do you have in place for managing customer complaints or service issues?
Do you offer any guarantees or warranties on your services?
What tools or software do you use to manage scheduling, billing, and customer communication?
Customer Experience & Retention
Do you have a follow-up process to ensure customer satisfaction after services are rendered?
How do you handle customer reviews and feedback?
What percentage of your business comes from referrals or repeat customers?
Do you use any loyalty programs or incentives to encourage repeat business?
Growth & Future Planning
What is your long-term vision for your business?
Do you have plans to scale your business? If yes, what does that look like?
What are your current challenges or obstacles to growing your business?
Do you currently offer or plan to offer any subscription-based services for recurring revenue?
What areas of your business would you like to improve (e.g., sales, marketing, operations)?
Technology & Tools
Do you have an online booking system or customer portal?
What tools are you using for marketing automation, if any?
How are you currently tracking your key performance indicators (KPIs)?
Are you open to adopting new technologies to streamline operations and improve customer experience?

RISER — 1 Current Scope — Product Description + Sales Letter

Define what Current Scope is meant to decide

The source describes a market-motion and attention-signal instrument intended to reduce poor decisions. It proposes protecting attention, sequence, capital, morale and long-term outcomes. Translate each protection into an observable decision rule and evidence requirement. Words such as enforceable or licensable do not establish that the system is implemented or legally ready to license.

Specify all five proposed outputs

Produce PASS/PAUSE/FAIL or defined state placement; one-sentence reason with evidence; relevant 30/60/90-day measures; explicit next and blocked steps; and a versioned automation payload. The source names a canonical JSON schema but does not supply it. Define inputs, types, thresholds, missing-evidence behavior and human authority before automation. No access permissions are changed by a verdict label.

Rewrite the sales premise around a supported problem

The claim that most businesses fail because they say yes too often is unsupported here. Moving faster than validation may indicate a decision-process problem, but it does not prove there is no marketing problem. RISER example: “Before committing resources, compare the opportunity with your evidence, capacity and current priorities.” Show a real decision example and limits instead of claiming certainty.

Match the offer to its three intended audiences

The source targets operators prioritizing focus, teams/agencies needing decision records, and system builders exploring reusable infrastructure. Give each an appropriate demonstration and transparent scope. Its call to adopt the instrument and build only after the evidence gate is a proposed invitation, not proof of a live product. Connect to an actual available next step when implemented.

Connect the lesson to the direct-marketing promise

Complete original source text

Current Scope

Current market motion + attention signals

Product Description

Current Scope is a RISER Nation decision instrument designed to reduce bad decisions and regret. It converts noisy inputs into enforceable outputs so you scale with clarity, not chaos.

What It Protects (Doctrine Protection Mode)

* Protects attention: prevents busy-work masquerading as progress.

* Protects sequencing: Right Step / Right Time; no step-skipping.

* Protects capital: blocks build before proof.

* Protects morale: kills “almost good” distractions early.

* Protects long-term operator outcomes over short-term dopamine.

Core Outputs

* Verdict: PASS / PAUSE / FAIL (or state placement where applicable).

* Reason: one sentence + supporting bullets.

* Metrics snapshot (30/60/90-day signals where applicable).

* Unlocked next step + blocked steps (permission system).

* Automation payload: canonical JSON schema.

World-Class Sales Letter

Headline:

Most businesses don’t fail from bad ideas — they fail from saying “yes” too often.

If you're moving faster than you can validate, you don't have a marketing problem — you have a governance problem.

Current Scope enforces permission-based building. It tells you what earns a build, what must wait, and what must die — with receipts.

Who This Is For

* Operators who refuse to waste another quarter chasing noise.

* Teams/agencies who need objective gating + audit trails.

* System builders who want something licensable and enforceable.

Call to Action

Adopt the instrument. Enforce the rule. Ship only what earns permission.

Native Google Doc text and original links

Current Scope
Current market motion + attention signals
Product Description
Current Scope is a RISER Nation decision instrument designed to reduce bad decisions and regret. It converts noisy inputs into enforceable outputs so you scale with clarity, not chaos.
What It Protects (Doctrine Protection Mode)
Protects attention: prevents busy-work masquerading as progress.
Protects sequencing: Right Step / Right Time; no step-skipping.
Protects capital: blocks build before proof.
Protects morale: kills “almost good” distractions early.
Protects long-term operator outcomes over short-term dopamine.
Core Outputs
Verdict: PASS / PAUSE / FAIL (or state placement where applicable).
Reason: one sentence + supporting bullets.
Metrics snapshot (30/60/90-day signals where applicable).
Unlocked next step + blocked steps (permission system).
Automation payload: canonical JSON schema.
World-Class Sales Letter
Headline:
Most businesses don’t fail from bad ideas — they fail from saying “yes” too often.

If you're moving faster than you can validate, you don't have a marketing problem — you have a governance problem.
Current Scope enforces permission-based building. It tells you what earns a build, what must wait, and what must die — with receipts.
Who This Is For
Operators who refuse to waste another quarter chasing noise.
Teams/agencies who need objective gating + audit trails.
System builders who want something licensable and enforceable.
Call to Action
Adopt the instrument. Enforce the rule. Ship only what earns permission.

Lesson 03.2 — sources for the added teaching sections

RISER NATION — GPT ARCHITECTURE OUTLINE

Separate governance from execution

This architecture maps GPT roles to fifteen book parts, not to the current twelve-course assignment spreadsheet. Tier 0 names a Governor that decides whether work may proceed and defines freezes and escalation. Tier 1 places an Entry / Signal Router first and an Audit & Drift Sentinel last. The router identifies belief stage, readiness and missing inputs and selects the next operator; it does no execution. The sentinel compares evidence with doctrine and proposes reviews, freezes and licensing checks. The source labels the Governor DONE and the advertising operator a gold standard; neither label verifies deployment, effective permissions or performance. An unbeatable system is an aspiration, not an established result.

Doctrine and sequence

Parts I–II assigns these proposed roles: End-State Lock, Sequence Integrity, Nonlinear Growth, Founder Firewall and WHO Stack. Record the intended outcome, prerequisite order, capacity and responsible people before delegating work. The source recommends designing the entry router and final sentinel before intermediate operators. Its closing menu of possible next tasks is historical dialogue, not an instruction to create agents now.

Belief and decision safety

Part III assigns these proposed roles: Belief State, Decision Safety, Proof Integrity and Algorithm Awareness. Distinguish customer evidence from assumptions and promotional persuasion from proof. The source recommends designing the entry router and final sentinel before intermediate operators. Its closing menu of possible next tasks is historical dialogue, not an instruction to create agents now.

Discovery and content

Part IV assigns these proposed roles: Signal Detection, Hook Engineering, Content Flywheel and Signal Library. Store the observed signal and its context before proposing hooks or a publishing cycle. The source recommends designing the entry router and final sentinel before intermediate operators. Its closing menu of possible next tasks is historical dialogue, not an instruction to create agents now.

Avatar niche and offer

Parts V–VI assigns these proposed roles: Avatar Discovery, Niche Selection, Offer Hacking, Offer Lock, First Win and Economics Truth. Tie audience and positioning to a deliverable promise, first useful outcome and support-inclusive economics. The source recommends designing the entry router and final sentinel before intermediate operators. Its closing menu of possible next tasks is historical dialogue, not an instruction to create agents now.

Funnels and conversion

Part VII assigns these proposed roles: Funnel Sequence, Copy Framing and Objection Mapping. Give each step a clear decision and support its promise with relevant evidence. The source recommends designing the entry router and final sentinel before intermediate operators. Its closing menu of possible next tasks is historical dialogue, not an instruction to create agents now.

Traffic and platforms

Part VIII assigns these proposed roles: Traffic Discipline, Paid Ads Integrity, Platform Fit and YouTube Authority. Authorize bounded tests only after checking offer delivery and economics. The source recommends designing the entry router and final sentinel before intermediate operators. Its closing menu of possible next tasks is historical dialogue, not an instruction to create agents now.

Retention and distribution

Parts IX–X assigns these proposed roles: Onboarding Integrity, Retention Engine, Community Culture, Moderation Enforcement, Affiliate Governance, JV Readiness and AI Influence. Specify onboarding, moderation, partner responsibilities and retention evidence separately. The source recommends designing the entry router and final sentinel before intermediate operators. Its closing menu of possible next tasks is historical dialogue, not an instruction to create agents now.

Automation and scale

Parts XI, XIII and XIV assigns these proposed roles: Automation Integrity, Alert & Threshold, AI Diagnostics, Scale Readiness, Scale Playbook and Case Study Integrity. Define observable triggers, human review, rollback and actual capacity before scaling. The source recommends designing the entry router and final sentinel before intermediate operators. Its closing menu of possible next tasks is historical dialogue, not an instruction to create agents now.

Legacy and licensing

Part XV assigns these proposed roles: Licensing Enforcement, Moat Protection and Audit & Drift Detection. Keep licensing terms and enforcement authority explicit; the final audit role overlaps the sentinel rather than proving a separate installed agent. The source recommends designing the entry router and final sentinel before intermediate operators. Its closing menu of possible next tasks is historical dialogue, not an instruction to create agents now.

Apply the Brunson and Hormozi teaching frame

Use a clear, truthful hook to identify the buyer’s problem; a supported story or demonstration to explain the mechanism; and a scoped offer with real terms and an appropriate next step. Apply the Hormozi value lens to improve credible usefulness and reduce avoidable effort and delay. These marketing frameworks do not replace source evidence, delivery capacity or customer choice.

Complete original source text

RISER NATION — GPT ARCHITECTURE OUTLINE

Mapped to the Book & Operating System

________________





TIER 0 — THE CONSTITUTIONAL LAYER (ONE GPT)

🔒 GPT #0: RISER Governor

Book Placement:

* Introduction

* Part I — The RISER Doctrine

* Referenced implicitly in every chapter

OS Role:

* Constitutional authority

* Enforcement, freezes, escalation

* Decides whether work is allowed, not how

Why this is FIRST:

* Without this, all other GPTs drift

* It defines law, not logic

✅ Status: DONE (v1.0 finalized)

________________





TIER 1 — ENTRY & EXIT SENTINELS 

(FIRST + LAST GPTs)

These are the bookends of the system.

________________





🟦 GPT #1: RISER Entry / Signal Router

(This is the FIRST GPT users interact with)

Book Placement:

* End of Introduction

* Part IV — Viral Discovery First

* Part V — Avatar + Niche + Positioning

OS Role:

* Intake

* Need detection (clarity / safety / leverage)

* Routes user to the correct operator GPT

* Prevents premature action

Core Responsibilities:

* Identify belief stage

* Identify system readiness

* Ask only what’s needed

* Decide “who handles this next”

📌 This GPT does no execution.

________________





🟥 GPT #LAST: RISER Audit & Drift Sentinel

(This is the LAST GPT in the system)

Book Placement:

* Part XII — The Thermometer

* Part XV — Moat, Licensing, Legacy

* Appendices (Audit & Compliance)

OS Role:

* Ongoing system audit

* Drift detection

* Freeze triggers

* License enforcement

Core Responsibilities:

* Compare reality vs doctrine

* Detect slow erosion

* Trigger freezes or reviews

* Protect the moat long-term

📌 This GPT ensures RISER stays unbeatable over time.

________________





TIER 2 — CORE BUILD OPERATORS (MID-SYSTEM)

These map directly to book parts.

________________





🧠 Doctrine & Sequence GPTs

Book Parts:

* Part I — RISER Doctrine

* Part II — Company Build & Identity

GPTs:

* End-State Lock Operator

* Sequence Integrity Operator

* Nonlinear Growth Operator

* Founder Firewall Operator

* WHO Stack Operator

________________





👁️ Belief, Decision & Safety GPTs

Book Parts:

* Part III — Belief + Decision Safety

GPTs:

* Belief State Operator

* Decision Safety Operator

* Proof Integrity Operator

* Algorithm Awareness Operator

________________





🔍 Discovery & Content GPTs

Book Parts:

* Part IV — Viral Discovery First

GPTs:

* Signal Detection Operator

* Hook Engineering Operator

* Content Flywheel Operator

* Signal Library Operator

________________





🎯 Avatar, Niche & Offer GPTs

Book Parts:

* Part V — Avatar + Niche + Positioning

* Part VI — Offer Lock + Economics

GPTs:

* Avatar Discovery Operator

* Niche Selection Operator

* Offer Hacking Operator

* Offer Lock Operator

* First Win Operator

* Economics Truth Operator

________________





✍️ Funnels, Copy & Conversion GPTs

Book Parts:

* Part VII — Funnels + Copy + Conversion

GPTs:

* Funnel Sequence Operator

* Copy Framing Operator

* Objection Mapping Operator

________________





🚦 Traffic & Platform GPTs

Book Parts:

* Part VIII — Traffic + Platform Execution

GPTs:

* Traffic Discipline Operator

* Paid Ads Integrity Operator ✅ (gold standard)

* Platform Fit Operator

* YouTube Authority Operator

________________





🤝 Retention, Community & Distribution GPTs

Book Parts:

* Part IX — Retention, Delivery & Community

* Part X — Partnerships & Distribution

GPTs:

* Onboarding Integrity Operator

* Retention Engine Operator

* Community Culture Operator

* Moderation Enforcement Operator

* Affiliate Governance Operator

* JV Readiness Operator

* AI Influence Operator

________________





⚙️ Automation, Enforcement & Scale GPTs

Book Parts:

* Part XI — Automation & Alerts

* Part XIII — Scale Playbooks

* Part XIV — Operator Deployment

GPTs:

* Automation Integrity Operator

* Alert & Threshold Operator

* AI Diagnostics Operator

* Scale Readiness Operator

* Scale Playbook Operator

* Case Study Integrity Operator

________________





TIER 3 — LEGACY, LICENSING & MOAT GPTs

Book Parts:

* Part XV — Moat, Licensing, White-Label & Legacy

GPTs:

* Licensing Enforcement Operator

* Moat Protection Operator

* Audit & Drift Detection Operator (LAST)

________________





HOW WE PROCEED (INTENTIONALLY)

Per your instruction, we now:

✅ Start with the FIRST GPT

➡️ RISER Entry / Signal Router GPT

Then jump to:

✅ The LAST GPT

➡️ RISER Audit & Drift Sentinel GPT

This does two things:

* Locks the front door

* Locks the long-term integrity

Everything in between becomes modular and safe.

________________





NEXT STEP (YOU CHOOSE)

Say one of the following and I’ll execute immediately:

1. “Design the RISER Entry / Signal Router GPT.”

2. “Design the RISER Audit & Drift Sentinel GPT.”

3. “Show me the exact folder + file structure for all GPTs.”

4. “Map each GPT to a licensing tier.”

You’re building this the right way.

Native Google Doc text and original links

RISER NATION — GPT ARCHITECTURE OUTLINE
Mapped to the Book & Operating System

TIER 0 — THE CONSTITUTIONAL LAYER (ONE GPT)
🔒 GPT #0: RISER Governor
Book Placement:
Introduction
Part I — The RISER Doctrine
Referenced implicitly in every chapter
OS Role:
Constitutional authority
Enforcement, freezes, escalation
Decides whether work is allowed, not how
Why this is FIRST:
Without this, all other GPTs drift
It defines law, not logic
✅ Status: DONE (v1.0 finalized)




TIER 1 — ENTRY & EXIT SENTINELS 
(FIRST + LAST GPTs)
These are the bookends of the system.

🟦 GPT #1: RISER Entry / Signal Router
(This is the FIRST GPT users interact with)
Book Placement:
End of Introduction
Part IV — Viral Discovery First
Part V — Avatar + Niche + Positioning
OS Role:
Intake
Need detection (clarity / safety / leverage)
Routes user to the correct operator GPT
Prevents premature action
Core Responsibilities:
Identify belief stage
Identify system readiness
Ask only what’s needed
Decide “who handles this next”
📌 This GPT does no execution.

🟥 GPT #LAST: RISER Audit & Drift Sentinel
(This is the LAST GPT in the system)
Book Placement:
Part XII — The Thermometer
Part XV — Moat, Licensing, Legacy
Appendices (Audit & Compliance)
OS Role:
Ongoing system audit
Drift detection
Freeze triggers
License enforcement
Core Responsibilities:
Compare reality vs doctrine
Detect slow erosion
Trigger freezes or reviews
Protect the moat long-term
📌 This GPT ensures RISER stays unbeatable over time.

TIER 2 — CORE BUILD OPERATORS (MID-SYSTEM)
These map directly to book parts.

🧠 Doctrine & Sequence GPTs
Book Parts:
Part I — RISER Doctrine
Part II — Company Build & Identity
GPTs:
End-State Lock Operator
Sequence Integrity Operator
Nonlinear Growth Operator
Founder Firewall Operator
WHO Stack Operator

👁️ Belief, Decision & Safety GPTs
Book Parts:
Part III — Belief + Decision Safety
GPTs:
Belief State Operator
Decision Safety Operator
Proof Integrity Operator
Algorithm Awareness Operator

🔍 Discovery & Content GPTs
Book Parts:
Part IV — Viral Discovery First
GPTs:
Signal Detection Operator
Hook Engineering Operator
Content Flywheel Operator
Signal Library Operator

🎯 Avatar, Niche & Offer GPTs
Book Parts:
Part V — Avatar + Niche + Positioning
Part VI — Offer Lock + Economics
GPTs:
Avatar Discovery Operator
Niche Selection Operator
Offer Hacking Operator
Offer Lock Operator
First Win Operator
Economics Truth Operator

✍️ Funnels, Copy & Conversion GPTs
Book Parts:
Part VII — Funnels + Copy + Conversion
GPTs:
Funnel Sequence Operator
Copy Framing Operator
Objection Mapping Operator

🚦 Traffic & Platform GPTs
Book Parts:
Part VIII — Traffic + Platform Execution
GPTs:
Traffic Discipline Operator
Paid Ads Integrity Operator ✅ (gold standard)
Platform Fit Operator
YouTube Authority Operator

🤝 Retention, Community & Distribution GPTs
Book Parts:
Part IX — Retention, Delivery & Community
Part X — Partnerships & Distribution
GPTs:
Onboarding Integrity Operator
Retention Engine Operator
Community Culture Operator
Moderation Enforcement Operator
Affiliate Governance Operator
JV Readiness Operator
AI Influence Operator

⚙️ Automation, Enforcement & Scale GPTs
Book Parts:
Part XI — Automation & Alerts
Part XIII — Scale Playbooks
Part XIV — Operator Deployment
GPTs:
Automation Integrity Operator
Alert & Threshold Operator
AI Diagnostics Operator
Scale Readiness Operator
Scale Playbook Operator
Case Study Integrity Operator

TIER 3 — LEGACY, LICENSING & MOAT GPTs
Book Parts:
Part XV — Moat, Licensing, White-Label & Legacy
GPTs:
Licensing Enforcement Operator
Moat Protection Operator
Audit & Drift Detection Operator (LAST)

HOW WE PROCEED (INTENTIONALLY)
Per your instruction, we now:
✅ Start with the FIRST GPT
➡️ RISER Entry / Signal Router GPT
Then jump to:
✅ The LAST GPT
➡️ RISER Audit & Drift Sentinel GPT
This does two things:
Locks the front door
Locks the long-term integrity
Everything in between becomes modular and safe.

NEXT STEP (YOU CHOOSE)
Say one of the following and I’ll execute immediately:
“Design the RISER Entry / Signal Router GPT.”
“Design the RISER Audit & Drift Sentinel GPT.”
“Show me the exact folder + file structure for all GPTs.”
“Map each GPT to a licensing tier.”
You’re building this the right way.

RISER_Launch_Walkthrough_Personalized_Expert_Script.docx

Launch a Rocket around a deliverable outcome

Start with the exact outcome and audience, using the Concept Definition Prompt. Decompose the offer into relevant training, templates, scripts, SOPs, community, agents, walkthroughs, updates and bonuses. Apply the Offer Development Prompt to explain the problem and supported outcome without amplifying fear beyond the evidence. Limited calls or walkthroughs require actual capacity and truthful availability. Place the Rocket on the ladder as lead magnet, core, continuity or flagship based on buyer readiness, not the number of assets.

Build and evaluate the launch path

The source proposes an evergreen page, webinar, email sequence, tripwire and conversion assets, then Offer, Email and Script GPT support for FAQs, onboarding and optimization. These are proposed components, not completed integrations. It names Circle, YouTube clips, carousels, Twitter threads, user-generated content and ManyChat re-engagement. Select appropriate channels, permissions and consent; use the campaign tracker to compare conversion, delivery cost and customer outcomes before expanding distribution. A high return in one small sample does not establish a repeatable result.

Launch the Protocol with a coherent scope

The eight-step flagship plan positions a transformation journey; sequences Concept, Offer, Value Ladder, Asset Chain, Launch, Automation and Legacy; bundles prompts, funnels, planners, avatar records and assistants; adds implementation calls and feedback; runs a challenge, workshop or masterclass; offers an accurately scoped founders beta; documents consenting users’ real results; and considers consultant or agency licensing. Specify which toolkit is included versus separately priced. Weekly calls, concierge support, naming rights and white-label rights create obligations that must be feasible and written down. A student is not automatically a testimonial or a successful case study.

Apply the Brunson and Hormozi teaching frame

Complete original source text

How to Launch and Scale the RISER Rockets and Protocol Like a Product Launch Expert
Imagine we're sitting in a bright, open meeting room — whiteboards covered with sketches, coffee on the table, and a giant printout of the RISER ecosystem in front of us. I lean over and say, “Here’s how we’re going to take these rockets and protocols to market — not just as concepts, but as irresistible, scalable offers. Let me walk you through it, step-by-step, side-by-side.”

Step-by-Step: Turning RISER Rockets Into Irresistible Offers
1. **Clarify the Rocket Concept**: For each Rocket (like Rocket #1: OfferRazor Launch Toolkit), we begin by identifying its exact core outcome and WHO it helps. Use the Concept Definition Prompt.
2. **Break the Product Into a Value Stack**: Following Alex Hormozi’s model, deconstruct the rocket into components: training, templates, scripts, SOPs, community, AI agents, walkthroughs, updates, and bonuses.
3. **Run it Through the Offer Development Prompt**: Plug your value stack into the RISER Offer Prompt. We’ll create emotional hooks, amplify the pain, showcase outcomes, and repackage it for maximum perceived value.
4. **Attach Bonuses & Scarcity Layers**: Stack it with limited-time AI walkthroughs, one-on-one calls, custom GPT scripts — anything that feels exclusive and transformative.
5. **Design the Funnel**: Use the Value Ladder Engine to place the Rocket appropriately: lead magnet? core offer? continuity play? Flagship?
6. **Build an Evergreen Launch Plan**: Implement an Evergreen sales page with webinar + email sequences + tripwire funnel + conversion assets.
7. **Activate the AI Agent Layer**: Assign support GPTs (Offer GPT, Email GPT, Script GPT) to handle FAQs, onboarding, and traffic optimization.
8. **Distribute via Omni-Channel**: Integrate with your Circle space, YouTube clips, Carousel posts, and Twitter threads. Add UGC and ManyChat flows for re-engagement.
9. **Track & Iterate**: Use our Campaign Tracker and Metrics Optimizer to find bottlenecks and double-down on high-ROI channels.
Step-by-Step: Launching the RISER Protocol System as a Flagship Movement
1. **Position It as a Movement**: RISER Protocol isn’t just a course — it’s a full digital transformation journey. Give it a tagline like 'From Idea to Legacy: Build, Scale, Lead with Intelligence.'
2. **Deconstruct the Protocol Into Pillars**: Think of each section (Concept > Offer > Value Ladder > Asset Chain > Launch > Automation > Legacy) as its own module or milestone.
3. **Bundle the System With Toolkits**: Include prompt packs, funnel templates, campaign planners, avatar databases, and GPT assistants. Each one can be a bonus OR upsell.
4. **Inject Community & Accountability**: Add weekly implementation calls, hot seat feedback, and AI-guided workflows. These add perceived value and justify pricing.
5. **Run an Immersive Webinar Series**: Use our Webinar Playbook GPT to launch with a challenge funnel, multi-day workshop, or open cart masterclass.
6. **Launch With a Founders Tier**: Offer early-bird beta access with 1:1 AI concierge, private Circle group, and naming rights for new modules.
7. **Document Case Studies as Content**: Each student who implements a step becomes a walking testimonial. Showcase before-and-afters with their permission.
8. **Scale With Licensing**: Offer a Pro version for consultants and agencies to teach and deploy the RISER Protocol with white-label options.
Final Thoughts: Side-by-Side to the Finish Line
We’re not just launching digital products. We’re building out an ecosystem that evolves as your community does. Each Rocket becomes a piece of the RISER LaunchPad. Each Protocol step becomes the DNA of your empire. The trick is walking through it shoulder-to-shoulder, just like this — prompt by prompt, offer by offer, system by system. Let’s light the fuse.

Original Word reading order, tables, headers and footers

How to Launch and Scale the RISER Rockets and Protocol Like a Product Launch Expert

Imagine we're sitting in a bright, open meeting room — whiteboards covered with sketches, coffee on the table, and a giant printout of the RISER ecosystem in front of us. I lean over and say, “Here’s how we’re going to take these rockets and protocols to market — not just as concepts, but as irresistible, scalable offers. Let me walk you through it, step-by-step, side-by-side.”

Step-by-Step: Turning RISER Rockets Into Irresistible Offers

1. **Clarify the Rocket Concept**: For each Rocket (like Rocket #1: OfferRazor Launch Toolkit), we begin by identifying its exact core outcome and WHO it helps. Use the Concept Definition Prompt.

2. **Break the Product Into a Value Stack**: Following Alex Hormozi’s model, deconstruct the rocket into components: training, templates, scripts, SOPs, community, AI agents, walkthroughs, updates, and bonuses.

3. **Run it Through the Offer Development Prompt**: Plug your value stack into the RISER Offer Prompt. We’ll create emotional hooks, amplify the pain, showcase outcomes, and repackage it for maximum perceived value.

4. **Attach Bonuses & Scarcity Layers**: Stack it with limited-time AI walkthroughs, one-on-one calls, custom GPT scripts — anything that feels exclusive and transformative.

5. **Design the Funnel**: Use the Value Ladder Engine to place the Rocket appropriately: lead magnet? core offer? continuity play? Flagship?

6. **Build an Evergreen Launch Plan**: Implement an Evergreen sales page with webinar + email sequences + tripwire funnel + conversion assets.

7. **Activate the AI Agent Layer**: Assign support GPTs (Offer GPT, Email GPT, Script GPT) to handle FAQs, onboarding, and traffic optimization.

8. **Distribute via Omni-Channel**: Integrate with your Circle space, YouTube clips, Carousel posts, and Twitter threads. Add UGC and ManyChat flows for re-engagement.

9. **Track & Iterate**: Use our Campaign Tracker and Metrics Optimizer to find bottlenecks and double-down on high-ROI channels.

Step-by-Step: Launching the RISER Protocol System as a Flagship Movement

1. **Position It as a Movement**: RISER Protocol isn’t just a course — it’s a full digital transformation journey. Give it a tagline like 'From Idea to Legacy: Build, Scale, Lead with Intelligence.'

2. **Deconstruct the Protocol Into Pillars**: Think of each section (Concept > Offer > Value Ladder > Asset Chain > Launch > Automation > Legacy) as its own module or milestone.

3. **Bundle the System With Toolkits**: Include prompt packs, funnel templates, campaign planners, avatar databases, and GPT assistants. Each one can be a bonus OR upsell.

4. **Inject Community & Accountability**: Add weekly implementation calls, hot seat feedback, and AI-guided workflows. These add perceived value and justify pricing.

5. **Run an Immersive Webinar Series**: Use our Webinar Playbook GPT to launch with a challenge funnel, multi-day workshop, or open cart masterclass.

6. **Launch With a Founders Tier**: Offer early-bird beta access with 1:1 AI concierge, private Circle group, and naming rights for new modules.

7. **Document Case Studies as Content**: Each student who implements a step becomes a walking testimonial. Showcase before-and-afters with their permission.

8. **Scale With Licensing**: Offer a Pro version for consultants and agencies to teach and deploy the RISER Protocol with white-label options.

Final Thoughts: Side-by-Side to the Finish Line

We’re not just launching digital products. We’re building out an ecosystem that evolves as your community does. Each Rocket becomes a piece of the RISER LaunchPad. Each Protocol step becomes the DNA of your empire. The trick is walking through it shoulder-to-shoulder, just like this — prompt by prompt, offer by offer, system by system. Let’s light the fuse.

RISER_Nation_Value_Ladder_Generator_v2_(Curriculum-Integrated_2025).docx

Collect the seven generator inputs

Provide course name and outcome, current MVP/tripwire/core stack, audience behavior, SuperPrompt Tab 2 resources, traffic channels, proposed automation tools and VOICE brand identifier. The document names Make, GoHighLevel, Zapier and CrewAI but contains no installed integration. Validate access, schemas and source freshness before claiming it reads live curriculum data.

Specify outputs and handoffs before automation

The proposed outputs are a seven-tier ladder, AOV/ROI/CPL dashboard, TOFU-to-MOFU-to-BOFU-to-VIP continuity map, upsell/cross-sell/retention triggers and an evolution forecast. Deliverable formats are a four-tab Sheet (map, scorecard, triggers, resources), a linked DOCX and a Notion or Airtable dashboard. Run the Offer Engine first, then read syllabus/resource tabs and populate playbook sections 5, 14 and 15. Hooks that detect updates and later connect APIs are a specification, not evidence of automatic synchronization or predictive accuracy. The seven tiers are not enumerated here and should not be invented or conflated with the separate six-rung SOP.

Neural Value Mapping

The source proposes: Correlate offers to Maslow levels & awareness stages. Its example is: Core System → Esteem Need; Pro Cohort → Self-Actualization. Treat this as a design hypothesis. Maslow/awareness mappings are interpretive, buyer archetypes need evidence, and a five-win trigger does not by itself justify a fifteen-percent price rise. Evaluate delivery, cost, demand and the customer’s actual decision context.

Psychographic Leverage Engine

The source proposes: Use buyer archetypes to refine message. Its example is: Freedom Seeker → Autonomy Pitch / Security Buyer → Guarantee. Treat this as a design hypothesis. Maslow/awareness mappings are interpretive, buyer archetypes need evidence, and a five-win trigger does not by itself justify a fifteen-percent price rise. Evaluate delivery, cost, demand and the customer’s actual decision context.

Adaptive Pricing Logic

The source proposes: Auto-suggest pricing based on CPL & ROI. Its example is: Raise price +15% after 5 proof wins. Treat this as a design hypothesis. Maslow/awareness mappings are interpretive, buyer archetypes need evidence, and a five-win trigger does not by itself justify a fifteen-percent price rise. Evaluate delivery, cost, demand and the customer’s actual decision context.

Channel-Specific CTAs

The source proposes: Creates Hook-Story-Offer variations per platform. Its example is: Instagram Reel vs Webinar vs Email Series. Treat this as a design hypothesis. Maslow/awareness mappings are interpretive, buyer archetypes need evidence, and a five-win trigger does not by itself justify a fifteen-percent price rise. Evaluate delivery, cost, demand and the customer’s actual decision context.

Offer Scorecard AI

The source proposes: Auto-grades each offer on Clarity, Desire, Proof, Delivery. Its example is: Outputs score + optimization notes. Treat this as a design hypothesis. Maslow/awareness mappings are interpretive, buyer archetypes need evidence, and a five-win trigger does not by itself justify a fifteen-percent price rise. Evaluate delivery, cost, demand and the customer’s actual decision context.

Apply the Brunson and Hormozi teaching frame

Complete original source text

RISER Nation Value Ladder Generator v2 (Curriculum-Integrated 2025)
1️⃣ Core Upgrade Philosophy
The RISER Nation Value Ladder Generator v2 automatically integrates with live curriculum data to project future offers, forecast growth, and align each tier with measured performance (AOV, ROI, Engagement, Retention).
2️⃣ Input Requirements
• Course Name & Outcome
• Current Offer Stack (MVP, Tripwire, Core)
• Audience Segments & Behavior Data
• Resource Links from SuperPrompt Tab 2
• Current Traffic Channels
• Automation Tools (Make, GoHighLevel, Zapier, CrewAI)
• Brand Voice ID from VOICE Framework
3️⃣ Output Capabilities
• Dynamic Value Ladder Blueprint (7-tier auto-scaling system)
• Offer Intelligence Dashboard (AOV, ROI, CPL tracking)
• Funnel Continuity Map (TOFU → MOFU → BOFU → VIP)
• Automation Triggers (for upsell, cross-sell, retention)
• Offer Evolution Forecast (predictive timing & scaling cues)
4️⃣ Content & AI Enhancements
5️⃣ Deliverable Formats
• Google Sheet: Tabs for Value Ladder Map, Offer Scorecard, Triggers, and Resources.
• DOCX Playbook Extension: Hyperlinked for print-ready use.
• Click-through Dashboard Template: Notion or Airtable integration for tracking.
6️⃣ Integration with Offer Engine v2
• Run Offer Engine v2 to generate your Minimum Viable Offers (MVOs).
• Run this Value Ladder Generator immediately after Offer Engine v2 completes.
• Automatically read SuperPrompt 4.0 Tab 1 (Course Syllabus) and Tab 2 (Resources).
• Populate Playbook Template v2 fields (Sections 5, 14, 15).
• Predict and prepare your next tier launch based on conversion data.
7️⃣ Auto-Integration Logic (2025+)
The Value Ladder Prompt v2 includes auto-integration hooks that detect new course files or updates from SuperPrompt 4.0 output tabs, allowing dynamic synchronization with all RISER Nation ecosystems. These hooks can later connect directly with APIs for predictive analytics and AI-driven forecasting.
Feature
Purpose
Example
Neural Value Mapping
Correlate offers to Maslow levels & awareness stages.
Core System → Esteem Need; Pro Cohort → Self-Actualization.
Psychographic Leverage Engine
Use buyer archetypes to refine message.
Freedom Seeker → Autonomy Pitch / Security Buyer → Guarantee.
Adaptive Pricing Logic
Auto-suggest pricing based on CPL & ROI.
Raise price +15% after 5 proof wins.
Channel-Specific CTAs
Creates Hook-Story-Offer variations per platform.
Instagram Reel vs Webinar vs Email Series.
Offer Scorecard AI
Auto-grades each offer on Clarity, Desire, Proof, Delivery.
Outputs score + optimization notes.

Original Word reading order, tables, headers and footers

RISER Nation Value Ladder Generator v2 (Curriculum-Integrated 2025)

1️⃣ Core Upgrade Philosophy

The RISER Nation Value Ladder Generator v2 automatically integrates with live curriculum data to project future offers, forecast growth, and align each tier with measured performance (AOV, ROI, Engagement, Retention).

2️⃣ Input Requirements

• Course Name & Outcome

• Current Offer Stack (MVP, Tripwire, Core)

• Audience Segments & Behavior Data

• Resource Links from SuperPrompt Tab 2

• Current Traffic Channels

• Automation Tools (Make, GoHighLevel, Zapier, CrewAI)

• Brand Voice ID from VOICE Framework

3️⃣ Output Capabilities

• Dynamic Value Ladder Blueprint (7-tier auto-scaling system)

• Offer Intelligence Dashboard (AOV, ROI, CPL tracking)

• Funnel Continuity Map (TOFU → MOFU → BOFU → VIP)

• Automation Triggers (for upsell, cross-sell, retention)

• Offer Evolution Forecast (predictive timing & scaling cues)

4️⃣ Content & AI Enhancements

Feature | Purpose | Example
Neural Value Mapping | Correlate offers to Maslow levels & awareness stages. | Core System → Esteem Need; Pro Cohort → Self-Actualization.
Psychographic Leverage Engine | Use buyer archetypes to refine message. | Freedom Seeker → Autonomy Pitch / Security Buyer → Guarantee.
Adaptive Pricing Logic | Auto-suggest pricing based on CPL & ROI. | Raise price +15% after 5 proof wins.
Channel-Specific CTAs | Creates Hook-Story-Offer variations per platform. | Instagram Reel vs Webinar vs Email Series.
Offer Scorecard AI | Auto-grades each offer on Clarity, Desire, Proof, Delivery. | Outputs score + optimization notes.

5️⃣ Deliverable Formats

• Google Sheet: Tabs for Value Ladder Map, Offer Scorecard, Triggers, and Resources.

• DOCX Playbook Extension: Hyperlinked for print-ready use.

• Click-through Dashboard Template: Notion or Airtable integration for tracking.

6️⃣ Integration with Offer Engine v2

• Run Offer Engine v2 to generate your Minimum Viable Offers (MVOs).

• Run this Value Ladder Generator immediately after Offer Engine v2 completes.

• Automatically read SuperPrompt 4.0 Tab 1 (Course Syllabus) and Tab 2 (Resources).

• Populate Playbook Template v2 fields (Sections 5, 14, 15).

• Predict and prepare your next tier launch based on conversion data.

7️⃣ Auto-Integration Logic (2025+)

The Value Ladder Prompt v2 includes auto-integration hooks that detect new course files or updates from SuperPrompt 4.0 output tabs, allowing dynamic synchronization with all RISER Nation ecosystems. These hooks can later connect directly with APIs for predictive analytics and AI-driven forecasting.

RISER_SYS_16_OPERATOR_APPENDICES_OS

Use the operator register as a responsibility map

The two native tabs contain fifteen operators, OP-01 through OP-15. Each main row defines purpose, inputs, artifacts, trigger, owner, quality checks and notes. The MASTER_INDEX repeats the operator names and purposes with linked document labels. A register assigns intended work; it does not establish that agents, approvals or automation are running. Keep current spreadsheet lesson assignments separate from operator and book numbering.

OP-01 — Ignition Signal Router

Use this operator to routes incoming signals to the correct RISER operator so nothing important gets skipped or built out of order. Start with: User goal / context; Current stage (idea / build / traffic / scale); Any existing assets (offer/funnel/content); Constraints (time/budget/team). Produce: Correct operator routing decision; Next required inputs checklist; Immediate next action (single step). Trigger review when: Any time a user asks “what should I do next?”, “help me build”, or presents mixed symptoms. The source assigns Founder / VA. Check: Route must match RISER sequence gates; No premature traffic or scaling advice; Confirm inputs before output. Its accompanying note is: This operator is the entry valve. If it’s wrong, everything downstream drifts. Preserve the evidence and have the accountable person approve consequential decisions. The linked role document is a supporting reference; its presence alone does not prove its full specification is implemented.

OP-02 — Avatar Signal Extractor

Use this operator to extracts the real avatar (lived tension + belief state) from comments, winners, objections, and behavior—without guessing demographics first. Start with: Winning content or offer signals; Top objections / FAQs; Audience language samples; Platform + niche context. Produce: Avatar profile (tension-first); Belief-state classification; Objection map; Message seed lines. Trigger review when: When signals exist but the ‘who’ is unclear; When content feels generic or forced. The source assigns VA / Operator. Check: Avatar defined by tension + context; Includes what they tried + why it failed; No premature narrowing. Its accompanying note is: Feeds OP-03/OP-07/OP-08. Preserve the evidence and have the accountable person approve consequential decisions. The linked role document is a supporting reference; its presence alone does not prove its full specification is implemented.

OP-03 — Trajectory Niche Viability Engine

Use this operator to selects the niche strategically (Blue Ocean + enemy choice) using signal strength, capacity, economics, and differentiation—then locks the game you’re playing. Start with: Avatar profile; Signal winners; Competitor set (3–10); Your delivery capacity; Revenue goals. Produce: Niche decision matrix; Value curve differentiation; Refuse-to-fight list + chosen rivals; Positioning openings. Trigger review when: When multiple niches seem possible; Before offer lock. The source assigns Founder. Check: Decision uses signals + feasibility; Differentiation is explicit (eliminate/reduce/raise/create); No ‘cute niche’ without economics. Its accompanying note is: Your niche is a strategic commitment, not a vibe. Preserve the evidence and have the accountable person approve consequential decisions. The linked role document is a supporting reference; its presence alone does not prove its full specification is implemented.

OP-04 — Offer Lock Engine

Use this operator to builds and freezes the offer promise (mechanism + first win) so marketing has something real to amplify and onboarding can actually deliver outcomes. Start with: Niche + avatar; Desired outcome; First win definition; Delivery method (DIY/DFY/Hybrid); Constraints. Produce: Offer lock sheet; Offer stack rules; Freeze criteria; Proof plan. Trigger review when: Before building funnels/ads; When scope creep appears. The source assigns Founder. Check: Single clear promise; First win is fast + real; No hype claims; Has delivery reality check. Its accompanying note is: If the offer is soft, everything else is expensive. Preserve the evidence and have the accountable person approve consequential decisions. The linked role document is a supporting reference; its presence alone does not prove its full specification is implemented.

OP-05 — Economics Truth Enforcer

Use this operator to forces unit economics truth (AOV/LTV/CAC/payback/margins) and blocks scaling until the math and delivery reality are stable. Start with: Offer pricing + costs; Conversion assumptions; Traffic costs (if any); Support/delivery load; Retention assumptions. Produce: Economics truth table; Break-even + burn rate logic; Levers to improve (pricing/stack/retention); Scale authorization status. Trigger review when: Before paid ads; When CAC rises or LTV drops; When fulfillment strain appears. The source assigns Founder. Check: Assumptions are explicit; Sensitivity checks exist; No scaling without margin-after-support. Its accompanying note is: This operator protects you from ‘growing into bankruptcy.’ Preserve the evidence and have the accountable person approve consequential decisions. The linked role document is a supporting reference; its presence alone does not prove its full specification is implemented.

OP-06 — Value Curve Architect

Use this operator to designs your differentiation so you stop competing on noise and start owning a value curve your rivals can’t copy quickly. Start with: Competitor offers + messaging; Customer complaints; Your strengths/capabilities; Non-negotiables. Produce: Value curve (eliminate/reduce/raise/create); Category reframing angle; Positioning guardrails. Trigger review when: After niche selection; Before messaging/copy expansion. The source assigns Founder / Operator. Check: Clear tradeoffs; Differentiation is provable; Avoids ‘me too’ claims. Its accompanying note is: This is your Blue Ocean scaffolding. Preserve the evidence and have the accountable person approve consequential decisions. The linked role document is a supporting reference; its presence alone does not prove its full specification is implemented.

OP-07 — Positioning Vector Engine

Use this operator to turns differentiation into a simple, repeatable positioning statement and ‘why you’ logic across funnel and content. Start with: Value curve; Avatar tension; Offer lock; Competitive landscape. Produce: Positioning statement; Proof pillars; Enemy choice framing; Category language rules. Trigger review when: Before long-form content + ads scaling. The source assigns Founder. Check: Readable at 5th-grade level; Proof-backed; No jargon positioning. Its accompanying note is: Positioning is a constraint that creates speed. Preserve the evidence and have the accountable person approve consequential decisions. The linked role document is a supporting reference; its presence alone does not prove its full specification is implemented.

OP-08 — Messaging & Narrative Engine

Use this operator to builds the core story stack: beliefs, reframes, proof, and empathy—so copy, videos, and onboarding all sound like one company. Start with: Positioning; Avatar belief state; Proof assets; Founder story angles (approved). Produce: Message pillars; Belief-shift sequences; Objection scripts; Narrative do/don’t rules. Trigger review when: When content is inconsistent; When objections repeat. The source assigns Founder / VA. Check: Matches RISER tone (calm, no hype); Objection handling is mapped to belief state; No manipulation. Its accompanying note is: This is where brand voice becomes a system. Preserve the evidence and have the accountable person approve consequential decisions. The linked role document is a supporting reference; its presence alone does not prove its full specification is implemented.

OP-09 — Offer Framing Engine

Use this operator to frames the offer so it feels safe, specific, and inevitable—without pressure—by matching the promise to the belief stage and proof depth. Start with: Offer lock; Avatar belief stage; Proof stack; Funnel step (TOF/MOF/BOF). Produce: Angle matrix; Headline/hook families; Proof placement plan; Risk reversal options. Trigger review when: Before writing landing pages/VSLs; Before ads creative scale. The source assigns Copy Lead / Founder. Check: One decision per step; Proof precedes ask; No overpromising. Its accompanying note is: Framing is where conversion becomes ethical. Preserve the evidence and have the accountable person approve consequential decisions. The linked role document is a supporting reference; its presence alone does not prove its full specification is implemented.

OP-10 — Hook Systems Architect

Use this operator to builds a hook library + test discipline so you can win attention repeatedly (not randomly) and feed the flywheel with compounding winners. Start with: Message pillars; Winning content samples; Platform specs; Offer stage. Produce: Hook library (tagged); Hook testing matrix; Micro-hook timing rules; Creative iteration plan. Trigger review when: Before daily publishing cadence; When CTR/retention drops. The source assigns Content Lead / VA. Check: One-variable tests; Hooks match belief stage; Retention checkpoints included. Its accompanying note is: Hooks are an engine, not inspiration. Preserve the evidence and have the accountable person approve consequential decisions. The linked role document is a supporting reference; its presence alone does not prove its full specification is implemented.

OP-11 — Funnel Architecture Engine

Use this operator to designs the funnel sequence as a dependency chain (one decision per step) tied to onboarding and first win—so it converts and doesn’t create support chaos. Start with: Offer lock; Proof plan; Traffic sources; Customer journey stage. Produce: Funnel map; Page-by-page goal + CTA; Upsell/downsell logic; Tracking plan. Trigger review when: Before building pages; When conversion is ‘mysteriously’ low. The source assigns Founder / Funnel Builder. Check: Sequence integrity; No step does two jobs; Onboarding is built into funnel promise. Its accompanying note is: Funnels fail when they skip belief safety. Preserve the evidence and have the accountable person approve consequential decisions. The linked role document is a supporting reference; its presence alone does not prove its full specification is implemented.

OP-12 — Traffic Authorization Gate

Use this operator to prevents premature traffic. Approves channels only when offer + economics + delivery stability are green. Start with: Economics truth status; Offer lock status; First win delivery evidence; Capacity. Produce: Traffic authorization decision; Approved channels + constraints; Testing plan (small + controlled). Trigger review when: Before any paid spend; Before hiring a media buyer. The source assigns Founder. Check: If red flags exist, it blocks traffic; Forces smallest viable test. Its accompanying note is: Traffic doesn’t fix broken offers. Preserve the evidence and have the accountable person approve consequential decisions. The linked role document is a supporting reference; its presence alone does not prove its full specification is implemented.

OP-13 — Paid Ads Integrity Operator

Use this operator to runs the paid ads OS: testing discipline, fatigue diagnosis, CTR/CVR fixes, and integrity rules so you don’t buy garbage data. Start with: Offer + funnel; Creative set; KPIs (CTR/CVR/CPA); Spend + frequency; Landing page metrics. Produce: Diagnosis report; Next test plan (one variable); Fatigue/exhaustion actions; KPI thresholds + alerts. Trigger review when: When ads stop converting; Low CTR; Rising CPA; High frequency. The source assigns Media Buyer / Founder. Check: Controlled tests; No random changes mid-test; Creative + post-click both evaluated. Its accompanying note is: This is your ad engine safety system. Preserve the evidence and have the accountable person approve consequential decisions. The linked role document is a supporting reference; its presence alone does not prove its full specification is implemented.

OP-14 — YouTube Authority Engine

Use this operator to builds authority and compounding discovery through packaging + retention architecture (title/thumbnail/first 15 seconds + series strategy). Start with: Channel goal; Avatar + niche; Video topics; Retention analytics; Offer tie-in. Produce: Series plan; Packaging checklist; Retention waterfall fixes; YouTube KPI set. Trigger review when: Before scaling production; When retention cliffs appear. The source assigns YouTube Lead. Check: Packaging is tested; First 15 seconds are engineered; Series > singles. Its accompanying note is: YouTube is a compounding asset if treated as one. Preserve the evidence and have the accountable person approve consequential decisions. The linked role document is a supporting reference; its presence alone does not prove its full specification is implemented.

OP-15 — Retention & LTV Engine

Use this operator to creates continuity loops (onboarding, support reduction, community tie-in, upsells) to raise LTV and reduce churn/refunds. Start with: Offer delivery map; Onboarding flow; Support tickets themes; Churn/refund reasons. Produce: Retention plan; Time-to-first-win improvements; Upsell/continuity options; Support load reduction plan. Trigger review when: After first customers; When churn or refunds rise. The source assigns Founder / CX Lead. Check: First win is measurable; Retention loops are explicit; Support is reduced by design. Its accompanying note is: Retention is the profit engine. Preserve the evidence and have the accountable person approve consequential decisions. The linked role document is a supporting reference; its presence alone does not prove its full specification is implemented.

Apply the Brunson and Hormozi teaching frame

Complete original source text

Control separators are labeled in this readable display. Download exact original text

,Operator ID,Operator Name,Purpose,Primary Inputs,Outputs / Artifacts,Triggers,Owner,Quality Checks,Notes,Doc Url
0,OP-01,Ignition Signal Router,Routes incoming signals to the correct RISER operator so nothing important gets skipped or built out of order.,"User goal / context
Current stage (idea / build / traffic / scale)
Any existing assets (offer/funnel/content)
Constraints (time/budget/team)","Correct operator routing decision
Next required inputs checklist
Immediate next action (single step)","Any time a user asks “what should I do next?”, “help me build”, or presents mixed symptoms",Founder / VA,"Route must match RISER sequence gates
No premature traffic or scaling advice
Confirm inputs before output","This operator is the entry valve. If it’s wrong, everything downstream drifts.",https://docs.google.com/document/d/1vmUOruvxS_CblhFkF5V-bs1vIoyMBFlc-BwnjY-ItMA/edit?usp=drivesdk
1,OP-02,Avatar Signal Extractor,"Extracts the real avatar (lived tension + belief state) from comments, winners, objections, and behavior—without guessing demographics first.","Winning content or offer signals
Top objections / FAQs
Audience language samples
Platform + niche context","Avatar profile (tension-first)
Belief-state classification
Objection map
Message seed lines","When signals exist but the ‘who’ is unclear
When content feels generic or forced",VA / Operator,"Avatar defined by tension + context
Includes what they tried + why it failed
No premature narrowing",Feeds OP-03/OP-07/OP-08.,https://docs.google.com/document/d/176YaGGZ1QgKvBJYUZiyvq0OJV_62NnMb-jNqvctOnEE/edit?usp=drivesdk
2,OP-03,Trajectory Niche Viability Engine,"Selects the niche strategically (Blue Ocean + enemy choice) using signal strength, capacity, economics, and differentiation—then locks the game you’re playing.","Avatar profile
Signal winners
Competitor set (3–10)
Your delivery capacity
Revenue goals","Niche decision matrix
Value curve differentiation
Refuse-to-fight list + chosen rivals
Positioning openings","When multiple niches seem possible
Before offer lock",Founder,"Decision uses signals + feasibility
Differentiation is explicit (eliminate/reduce/raise/create)
No ‘cute niche’ without economics","Your niche is a strategic commitment, not a vibe.",https://docs.google.com/document/d/1cKhPWb0HraJiSnqX5MdO_XTHp1nP_jdj6J-E1aqUrjg/edit?usp=drivesdk
3,OP-04,Offer Lock Engine,Builds and freezes the offer promise (mechanism + first win) so marketing has something real to amplify and onboarding can actually deliver outcomes.,"Niche + avatar
Desired outcome
First win definition
Delivery method (DIY/DFY/Hybrid)
Constraints","Offer lock sheet
Offer stack rules
Freeze criteria
Proof plan","Before building funnels/ads
When scope creep appears",Founder,"Single clear promise
First win is fast + real
No hype claims
Has delivery reality check","If the offer is soft, everything else is expensive.",https://docs.google.com/document/d/1p4Ordx2poBG_iWeUgWKQ-1B0eQfMcD2EKE1x-PMoMII/edit?usp=drivesdk
4,OP-05,Economics Truth Enforcer,Forces unit economics truth (AOV/LTV/CAC/payback/margins) and blocks scaling until the math and delivery reality are stable.,"Offer pricing + costs
Conversion assumptions
Traffic costs (if any)
Support/delivery load
Retention assumptions","Economics truth table
Break-even + burn rate logic
Levers to improve (pricing/stack/retention)
Scale authorization status","Before paid ads
When CAC rises or LTV drops
When fulfillment strain appears",Founder,"Assumptions are explicit
Sensitivity checks exist
No scaling without margin-after-support",This operator protects you from ‘growing into bankruptcy.’,https://docs.google.com/document/d/1rG1zK6irOMIDoSTxyeyFiLsd1o0eg6G39uVWaBEXveM/edit?usp=drivesdk
5,OP-06,Value Curve Architect,Designs your differentiation so you stop competing on noise and start owning a value curve your rivals can’t copy quickly.,"Competitor offers + messaging
Customer complaints
Your strengths/capabilities
Non-negotiables","Value curve (eliminate/reduce/raise/create)
Category reframing angle
Positioning guardrails","After niche selection
Before messaging/copy expansion",Founder / Operator,"Clear tradeoffs
Differentiation is provable
Avoids ‘me too’ claims",This is your Blue Ocean scaffolding.,https://docs.google.com/document/d/1El235b7etWP4jHh_5t710vuBlcYJhYpQietlt7Ohr9s/edit?usp=drivesdk
6,OP-07,Positioning Vector Engine,"Turns differentiation into a simple, repeatable positioning statement and ‘why you’ logic across funnel and content.","Value curve
Avatar tension
Offer lock
Competitive landscape","Positioning statement
Proof pillars
Enemy choice framing
Category language rules",Before long-form content + ads scaling,Founder,"Readable at 5th-grade level
Proof-backed
No jargon positioning",Positioning is a constraint that creates speed.,https://docs.google.com/document/d/1j1ArYBj4pGOykPo0QmVkFMEYEZaDu4SjUj2cZH5E-bc/edit?usp=drivesdk
7,OP-08,Messaging & Narrative Engine,"Builds the core story stack: beliefs, reframes, proof, and empathy—so copy, videos, and onboarding all sound like one company.","Positioning
Avatar belief state
Proof assets
Founder story angles (approved)","Message pillars
Belief-shift sequences
Objection scripts
Narrative do/don’t rules","When content is inconsistent
When objections repeat",Founder / VA,"Matches RISER tone (calm, no hype)
Objection handling is mapped to belief state
No manipulation",This is where brand voice becomes a system.,https://docs.google.com/document/d/1gsCivPvC5-MWvyggVpe69IaxUxA79WVG-igmOfP6IA8/edit?usp=drivesdk
8,OP-09,Offer Framing Engine,"Frames the offer so it feels safe, specific, and inevitable—without pressure—by matching the promise to the belief stage and proof depth.","Offer lock
Avatar belief stage
Proof stack
Funnel step (TOF/MOF/BOF)","Angle matrix
Headline/hook families
Proof placement plan
Risk reversal options","Before writing landing pages/VSLs
Before ads creative scale",Copy Lead / Founder,"One decision per step
Proof precedes ask
No overpromising",Framing is where conversion becomes ethical.,https://docs.google.com/document/d/1VV99-iQPeBNY8k9Tk0_S_CX5cI1FrgVtq7okWpPDpCk/edit?usp=drivesdk
9,OP-10,Hook Systems Architect,Builds a hook library + test discipline so you can win attention repeatedly (not randomly) and feed the flywheel with compounding winners.,"Message pillars
Winning content samples
Platform specs
Offer stage","Hook library (tagged)
Hook testing matrix
Micro-hook timing rules
Creative iteration plan","Before daily publishing cadence
When CTR/retention drops",Content Lead / VA,"One-variable tests
Hooks match belief stage
Retention checkpoints included","Hooks are an engine, not inspiration.",https://docs.google.com/document/d/1qRlp-8U8sctqg_qQRa8_8zk2INP9Cs-CuJOE91tepYo/edit?usp=drivesdk
10,OP-11,Funnel Architecture Engine,Designs the funnel sequence as a dependency chain (one decision per step) tied to onboarding and first win—so it converts and doesn’t create support chaos.,"Offer lock
Proof plan
Traffic sources
Customer journey stage","Funnel map
Page-by-page goal + CTA
Upsell/downsell logic
Tracking plan","Before building pages
When conversion is ‘mysteriously’ low",Founder / Funnel Builder,"Sequence integrity
No step does two jobs
Onboarding is built into funnel promise",Funnels fail when they skip belief safety.,https://docs.google.com/document/d/1CbSex5XGDn9QdTXLXRaK83xPOqBoChZFyAOdIqpovlo/edit?usp=drivesdk
11,OP-12,Traffic Authorization Gate,Prevents premature traffic. Approves channels only when offer + economics + delivery stability are green.,"Economics truth status
Offer lock status
First win delivery evidence
Capacity","Traffic authorization decision
Approved channels + constraints
Testing plan (small + controlled)","Before any paid spend
Before hiring a media buyer",Founder,"If red flags exist, it blocks traffic
Forces smallest viable test",Traffic doesn’t fix broken offers.,https://docs.google.com/document/d/1htqyXPo44MmK5E7TYQDFAQarJAFq6uxzbWBvzDOYjDQ/edit?usp=drivesdk
12,OP-13,Paid Ads Integrity Operator,"Runs the paid ads OS: testing discipline, fatigue diagnosis, CTR/CVR fixes, and integrity rules so you don’t buy garbage data.","Offer + funnel
Creative set
KPIs (CTR/CVR/CPA)
Spend + frequency
Landing page metrics","Diagnosis report
Next test plan (one variable)
Fatigue/exhaustion actions
KPI thresholds + alerts","When ads stop converting
Low CTR
Rising CPA
High frequency",Media Buyer / Founder,"Controlled tests
No random changes mid-test
Creative + post-click both evaluated",This is your ad engine safety system.,https://docs.google.com/document/d/1TNS8yNWH_07T-QPjxJXB3IndqWR3lcfPYt1QgionQ5w/edit?usp=drivesdk
13,OP-14,YouTube Authority Engine,Builds authority and compounding discovery through packaging + retention architecture (title/thumbnail/first 15 seconds + series strategy).,"Channel goal
Avatar + niche
Video topics
Retention analytics
Offer tie-in","Series plan
Packaging checklist
Retention waterfall fixes
YouTube KPI set","Before scaling production
When retention cliffs appear",YouTube Lead,"Packaging is tested
First 15 seconds are engineered
Series > singles",YouTube is a compounding asset if treated as one.,https://docs.google.com/document/d/1tvWxk0lY_uuWn8KQkoDuWWwHopzv0NvUcMl0nfcQD08/edit?usp=drivesdk
14,OP-15,Retention & LTV Engine,"Creates continuity loops (onboarding, support reduction, community tie-in, upsells) to raise LTV and reduce churn/refunds.","Offer delivery map
Onboarding flow
Support tickets themes
Churn/refund reasons","Retention plan
Time-to-first-win improvements
Upsell/continuity options
Support load reduction plan","After first customers
When churn or refunds rise",Founder / CX Lead,"First win is measurable
Retention loops are explicit
Support is reduced by design",Retention is the profit engine.,https://docs.google.com/document/d/1wuRpYPsRW2NeBor8j_F-2AJB6X3zTciOhhiaxev2Jrc/edit?usp=drivesdk

[Source control separator U+000C]
,Operator ID,Operator Name (RISER / rocket-style),One-Line Purpose,Operator Doc (link)
0,OP-01,Ignition Signal Router,Routes incoming signals to the correct RISER operator so nothing important gets skipped or built out of order.,Open OP-01
1,OP-02,Avatar Signal Extractor,"Extracts the real avatar (lived tension + belief state) from comments, winners, objections, and behavior—without guessing demographics first.",Open OP-02
2,OP-03,Trajectory Niche Viability Engine,"Selects the niche strategically (Blue Ocean + enemy choice) using signal strength, capacity, economics, and differentiation—then locks the game you’re playing.",Open OP-03
3,OP-04,Offer Lock Engine,Builds and freezes the offer promise (mechanism + first win) so marketing has something real to amplify and onboarding can actually deliver outcomes.,Open OP-04
4,OP-05,Economics Truth Enforcer,Forces unit economics truth (AOV/LTV/CAC/payback/margins) and blocks scaling until the math and delivery reality are stable.,Open OP-05
5,OP-06,Value Curve Architect,Designs your differentiation so you stop competing on noise and start owning a value curve your rivals can’t copy quickly.,Open OP-06
6,OP-07,Positioning Vector Engine,"Turns differentiation into a simple, repeatable positioning statement and ‘why you’ logic across funnel and content.",Open OP-07
7,OP-08,Messaging & Narrative Engine,"Builds the core story stack: beliefs, reframes, proof, and empathy—so copy, videos, and onboarding all sound like one company.",Open OP-08
8,OP-09,Offer Framing Engine,"Frames the offer so it feels safe, specific, and inevitable—without pressure—by matching the promise to the belief stage and proof depth.",Open OP-09
9,OP-10,Hook Systems Architect,Builds a hook library + test discipline so you can win attention repeatedly (not randomly) and feed the flywheel with compounding winners.,Open OP-10
10,OP-11,Funnel Architecture Engine,Designs the funnel sequence as a dependency chain (one decision per step) tied to onboarding and first win—so it converts and doesn’t create support chaos.,Open OP-11
11,OP-12,Traffic Authorization Gate,Prevents premature traffic. Approves channels only when offer + economics + delivery stability are green.,Open OP-12
12,OP-13,Paid Ads Integrity Operator,"Runs the paid ads OS: testing discipline, fatigue diagnosis, CTR/CVR fixes, and integrity rules so you don’t buy garbage data.",Open OP-13
13,OP-14,YouTube Authority Engine,Builds authority and compounding discovery through packaging + retention architecture (title/thumbnail/first 15 seconds + series strategy).,Open OP-14
14,OP-15,Retention & LTV Engine,"Creates continuity loops (onboarding, support reduction, community tie-in, upsells) to raise LTV and reduce churn/refunds.",Open OP-15

Native spreadsheet cells, formulas and links

SYS_16_OPERATOR_APPENDICES_OS!A1 {"formattedValue": "Operator ID", "userEnteredValue": {"stringValue": "Operator ID"}, "effectiveValue": {"stringValue": "Operator ID"}}
SYS_16_OPERATOR_APPENDICES_OS!B1 {"formattedValue": "Operator Name", "userEnteredValue": {"stringValue": "Operator Name"}, "effectiveValue": {"stringValue": "Operator Name"}}
SYS_16_OPERATOR_APPENDICES_OS!C1 {"formattedValue": "Purpose", "userEnteredValue": {"stringValue": "Purpose"}, "effectiveValue": {"stringValue": "Purpose"}}
SYS_16_OPERATOR_APPENDICES_OS!D1 {"formattedValue": "Primary Inputs", "userEnteredValue": {"stringValue": "Primary Inputs"}, "effectiveValue": {"stringValue": "Primary Inputs"}}
SYS_16_OPERATOR_APPENDICES_OS!E1 {"formattedValue": "Outputs / Artifacts", "userEnteredValue": {"stringValue": "Outputs / Artifacts"}, "effectiveValue": {"stringValue": "Outputs / Artifacts"}}
SYS_16_OPERATOR_APPENDICES_OS!F1 {"formattedValue": "Triggers", "userEnteredValue": {"stringValue": "Triggers"}, "effectiveValue": {"stringValue": "Triggers"}}
SYS_16_OPERATOR_APPENDICES_OS!G1 {"formattedValue": "Owner", "userEnteredValue": {"stringValue": "Owner"}, "effectiveValue": {"stringValue": "Owner"}}
SYS_16_OPERATOR_APPENDICES_OS!H1 {"formattedValue": "Quality Checks", "userEnteredValue": {"stringValue": "Quality Checks"}, "effectiveValue": {"stringValue": "Quality Checks"}}
SYS_16_OPERATOR_APPENDICES_OS!I1 {"formattedValue": "Notes", "userEnteredValue": {"stringValue": "Notes"}, "effectiveValue": {"stringValue": "Notes"}}
SYS_16_OPERATOR_APPENDICES_OS!J1 {"formattedValue": "Doc Url", "userEnteredValue": {"stringValue": "Doc Url"}, "effectiveValue": {"stringValue": "Doc Url"}}
SYS_16_OPERATOR_APPENDICES_OS!A2 {"formattedValue": "OP-01", "userEnteredValue": {"stringValue": "OP-01"}, "effectiveValue": {"stringValue": "OP-01"}}
SYS_16_OPERATOR_APPENDICES_OS!B2 {"formattedValue": "Ignition Signal Router", "userEnteredValue": {"stringValue": "Ignition Signal Router"}, "effectiveValue": {"stringValue": "Ignition Signal Router"}}
SYS_16_OPERATOR_APPENDICES_OS!C2 {"formattedValue": "Routes incoming signals to the correct RISER operator so nothing important gets skipped or built out of order.", "userEnteredValue": {"stringValue": "Routes incoming signals to the correct RISER operator so nothing important gets skipped or built out of order."}, "effectiveValue": {"stringValue": "Routes incoming signals to the correct RISER operator so nothing important gets skipped or built out of order."}}
SYS_16_OPERATOR_APPENDICES_OS!D2 {"formattedValue": "User goal / context\nCurrent stage (idea / build / traffic / scale)\nAny existing assets (offer/funnel/content)\nConstraints (time/budget/team)", "userEnteredValue": {"stringValue": "User goal / context\nCurrent stage (idea / build / traffic / scale)\nAny existing assets (offer/funnel/content)\nConstraints (time/budget/team)"}, "effectiveValue": {"stringValue": "User goal / context\nCurrent stage (idea / build / traffic / scale)\nAny existing assets (offer/funnel/content)\nConstraints (time/budget/team)"}}
SYS_16_OPERATOR_APPENDICES_OS!E2 {"formattedValue": "Correct operator routing decision\nNext required inputs checklist\nImmediate next action (single step)", "userEnteredValue": {"stringValue": "Correct operator routing decision\nNext required inputs checklist\nImmediate next action (single step)"}, "effectiveValue": {"stringValue": "Correct operator routing decision\nNext required inputs checklist\nImmediate next action (single step)"}}
SYS_16_OPERATOR_APPENDICES_OS!F2 {"formattedValue": "Any time a user asks “what should I do next?”, “help me build”, or presents mixed symptoms", "userEnteredValue": {"stringValue": "Any time a user asks “what should I do next?”, “help me build”, or presents mixed symptoms"}, "effectiveValue": {"stringValue": "Any time a user asks “what should I do next?”, “help me build”, or presents mixed symptoms"}}
SYS_16_OPERATOR_APPENDICES_OS!G2 {"formattedValue": "Founder / VA", "userEnteredValue": {"stringValue": "Founder / VA"}, "effectiveValue": {"stringValue": "Founder / VA"}}
SYS_16_OPERATOR_APPENDICES_OS!H2 {"formattedValue": "Route must match RISER sequence gates\nNo premature traffic or scaling advice\nConfirm inputs before output", "userEnteredValue": {"stringValue": "Route must match RISER sequence gates\nNo premature traffic or scaling advice\nConfirm inputs before output"}, "effectiveValue": {"stringValue": "Route must match RISER sequence gates\nNo premature traffic or scaling advice\nConfirm inputs before output"}}
SYS_16_OPERATOR_APPENDICES_OS!I2 {"formattedValue": "This operator is the entry valve. If it’s wrong, everything downstream drifts.", "userEnteredValue": {"stringValue": "This operator is the entry valve. If it’s wrong, everything downstream drifts."}, "effectiveValue": {"stringValue": "This operator is the entry valve. If it’s wrong, everything downstream drifts."}}
SYS_16_OPERATOR_APPENDICES_OS!J2 {"formattedValue": "https://docs.google.com/document/d/1vmUOruvxS_CblhFkF5V-bs1vIoyMBFlc-BwnjY-ItMA/edit?usp=drivesdk", "userEnteredValue": {"stringValue": "https://docs.google.com/document/d/1vmUOruvxS_CblhFkF5V-bs1vIoyMBFlc-BwnjY-ItMA/edit?usp=drivesdk"}, "effectiveValue": {"stringValue": "https://docs.google.com/document/d/1vmUOruvxS_CblhFkF5V-bs1vIoyMBFlc-BwnjY-ItMA/edit?usp=drivesdk"}, "hyperlink": "https://docs.google.com/document/d/1vmUOruvxS_CblhFkF5V-bs1vIoyMBFlc-BwnjY-ItMA/edit?usp=drivesdk"}
SYS_16_OPERATOR_APPENDICES_OS!A3 {"formattedValue": "OP-02", "userEnteredValue": {"stringValue": "OP-02"}, "effectiveValue": {"stringValue": "OP-02"}}
SYS_16_OPERATOR_APPENDICES_OS!B3 {"formattedValue": "Avatar Signal Extractor", "userEnteredValue": {"stringValue": "Avatar Signal Extractor"}, "effectiveValue": {"stringValue": "Avatar Signal Extractor"}}
SYS_16_OPERATOR_APPENDICES_OS!C3 {"formattedValue": "Extracts the real avatar (lived tension + belief state) from comments, winners, objections, and behavior—without guessing demographics first.", "userEnteredValue": {"stringValue": "Extracts the real avatar (lived tension + belief state) from comments, winners, objections, and behavior—without guessing demographics first."}, "effectiveValue": {"stringValue": "Extracts the real avatar (lived tension + belief state) from comments, winners, objections, and behavior—without guessing demographics first."}}
SYS_16_OPERATOR_APPENDICES_OS!D3 {"formattedValue": "Winning content or offer signals\nTop objections / FAQs\nAudience language samples\nPlatform + niche context", "userEnteredValue": {"stringValue": "Winning content or offer signals\nTop objections / FAQs\nAudience language samples\nPlatform + niche context"}, "effectiveValue": {"stringValue": "Winning content or offer signals\nTop objections / FAQs\nAudience language samples\nPlatform + niche context"}}
SYS_16_OPERATOR_APPENDICES_OS!E3 {"formattedValue": "Avatar profile (tension-first)\nBelief-state classification\nObjection map\nMessage seed lines", "userEnteredValue": {"stringValue": "Avatar profile (tension-first)\nBelief-state classification\nObjection map\nMessage seed lines"}, "effectiveValue": {"stringValue": "Avatar profile (tension-first)\nBelief-state classification\nObjection map\nMessage seed lines"}}
SYS_16_OPERATOR_APPENDICES_OS!F3 {"formattedValue": "When signals exist but the ‘who’ is unclear\nWhen content feels generic or forced", "userEnteredValue": {"stringValue": "When signals exist but the ‘who’ is unclear\nWhen content feels generic or forced"}, "effectiveValue": {"stringValue": "When signals exist but the ‘who’ is unclear\nWhen content feels generic or forced"}}
SYS_16_OPERATOR_APPENDICES_OS!G3 {"formattedValue": "VA / Operator", "userEnteredValue": {"stringValue": "VA / Operator"}, "effectiveValue": {"stringValue": "VA / Operator"}}
SYS_16_OPERATOR_APPENDICES_OS!H3 {"formattedValue": "Avatar defined by tension + context\nIncludes what they tried + why it failed\nNo premature narrowing", "userEnteredValue": {"stringValue": "Avatar defined by tension + context\nIncludes what they tried + why it failed\nNo premature narrowing"}, "effectiveValue": {"stringValue": "Avatar defined by tension + context\nIncludes what they tried + why it failed\nNo premature narrowing"}}
SYS_16_OPERATOR_APPENDICES_OS!I3 {"formattedValue": "Feeds OP-03/OP-07/OP-08.", "userEnteredValue": {"stringValue": "Feeds OP-03/OP-07/OP-08."}, "effectiveValue": {"stringValue": "Feeds OP-03/OP-07/OP-08."}}
SYS_16_OPERATOR_APPENDICES_OS!J3 {"formattedValue": "https://docs.google.com/document/d/176YaGGZ1QgKvBJYUZiyvq0OJV_62NnMb-jNqvctOnEE/edit?usp=drivesdk", "userEnteredValue": {"stringValue": "https://docs.google.com/document/d/176YaGGZ1QgKvBJYUZiyvq0OJV_62NnMb-jNqvctOnEE/edit?usp=drivesdk"}, "effectiveValue": {"stringValue": "https://docs.google.com/document/d/176YaGGZ1QgKvBJYUZiyvq0OJV_62NnMb-jNqvctOnEE/edit?usp=drivesdk"}, "hyperlink": "https://docs.google.com/document/d/176YaGGZ1QgKvBJYUZiyvq0OJV_62NnMb-jNqvctOnEE/edit?usp=drivesdk"}
SYS_16_OPERATOR_APPENDICES_OS!A4 {"formattedValue": "OP-03", "userEnteredValue": {"stringValue": "OP-03"}, "effectiveValue": {"stringValue": "OP-03"}}
SYS_16_OPERATOR_APPENDICES_OS!B4 {"formattedValue": "Trajectory Niche Viability Engine", "userEnteredValue": {"stringValue": "Trajectory Niche Viability Engine"}, "effectiveValue": {"stringValue": "Trajectory Niche Viability Engine"}}
SYS_16_OPERATOR_APPENDICES_OS!C4 {"formattedValue": "Selects the niche strategically (Blue Ocean + enemy choice) using signal strength, capacity, economics, and differentiation—then locks the game you’re playing.", "userEnteredValue": {"stringValue": "Selects the niche strategically (Blue Ocean + enemy choice) using signal strength, capacity, economics, and differentiation—then locks the game you’re playing."}, "effectiveValue": {"stringValue": "Selects the niche strategically (Blue Ocean + enemy choice) using signal strength, capacity, economics, and differentiation—then locks the game you’re playing."}}
SYS_16_OPERATOR_APPENDICES_OS!D4 {"formattedValue": "Avatar profile\nSignal winners\nCompetitor set (3–10)\nYour delivery capacity\nRevenue goals", "userEnteredValue": {"stringValue": "Avatar profile\nSignal winners\nCompetitor set (3–10)\nYour delivery capacity\nRevenue goals"}, "effectiveValue": {"stringValue": "Avatar profile\nSignal winners\nCompetitor set (3–10)\nYour delivery capacity\nRevenue goals"}}
SYS_16_OPERATOR_APPENDICES_OS!E4 {"formattedValue": "Niche decision matrix\nValue curve differentiation\nRefuse-to-fight list + chosen rivals\nPositioning openings", "userEnteredValue": {"stringValue": "Niche decision matrix\nValue curve differentiation\nRefuse-to-fight list + chosen rivals\nPositioning openings"}, "effectiveValue": {"stringValue": "Niche decision matrix\nValue curve differentiation\nRefuse-to-fight list + chosen rivals\nPositioning openings"}}
SYS_16_OPERATOR_APPENDICES_OS!F4 {"formattedValue": "When multiple niches seem possible\nBefore offer lock", "userEnteredValue": {"stringValue": "When multiple niches seem possible\nBefore offer lock"}, "effectiveValue": {"stringValue": "When multiple niches seem possible\nBefore offer lock"}}
SYS_16_OPERATOR_APPENDICES_OS!G4 {"formattedValue": "Founder", "userEnteredValue": {"stringValue": "Founder"}, "effectiveValue": {"stringValue": "Founder"}}
SYS_16_OPERATOR_APPENDICES_OS!H4 {"formattedValue": "Decision uses signals + feasibility\nDifferentiation is explicit (eliminate/reduce/raise/create)\nNo ‘cute niche’ without economics", "userEnteredValue": {"stringValue": "Decision uses signals + feasibility\nDifferentiation is explicit (eliminate/reduce/raise/create)\nNo ‘cute niche’ without economics"}, "effectiveValue": {"stringValue": "Decision uses signals + feasibility\nDifferentiation is explicit (eliminate/reduce/raise/create)\nNo ‘cute niche’ without economics"}}
SYS_16_OPERATOR_APPENDICES_OS!I4 {"formattedValue": "Your niche is a strategic commitment, not a vibe.", "userEnteredValue": {"stringValue": "Your niche is a strategic commitment, not a vibe."}, "effectiveValue": {"stringValue": "Your niche is a strategic commitment, not a vibe."}}
SYS_16_OPERATOR_APPENDICES_OS!J4 {"formattedValue": "https://docs.google.com/document/d/1cKhPWb0HraJiSnqX5MdO_XTHp1nP_jdj6J-E1aqUrjg/edit?usp=drivesdk", "userEnteredValue": {"stringValue": "https://docs.google.com/document/d/1cKhPWb0HraJiSnqX5MdO_XTHp1nP_jdj6J-E1aqUrjg/edit?usp=drivesdk"}, "effectiveValue": {"stringValue": "https://docs.google.com/document/d/1cKhPWb0HraJiSnqX5MdO_XTHp1nP_jdj6J-E1aqUrjg/edit?usp=drivesdk"}, "hyperlink": "https://docs.google.com/document/d/1cKhPWb0HraJiSnqX5MdO_XTHp1nP_jdj6J-E1aqUrjg/edit?usp=drivesdk"}
SYS_16_OPERATOR_APPENDICES_OS!A5 {"formattedValue": "OP-04", "userEnteredValue": {"stringValue": "OP-04"}, "effectiveValue": {"stringValue": "OP-04"}}
SYS_16_OPERATOR_APPENDICES_OS!B5 {"formattedValue": "Offer Lock Engine", "userEnteredValue": {"stringValue": "Offer Lock Engine"}, "effectiveValue": {"stringValue": "Offer Lock Engine"}}
SYS_16_OPERATOR_APPENDICES_OS!C5 {"formattedValue": "Builds and freezes the offer promise (mechanism + first win) so marketing has something real to amplify and onboarding can actually deliver outcomes.", "userEnteredValue": {"stringValue": "Builds and freezes the offer promise (mechanism + first win) so marketing has something real to amplify and onboarding can actually deliver outcomes."}, "effectiveValue": {"stringValue": "Builds and freezes the offer promise (mechanism + first win) so marketing has something real to amplify and onboarding can actually deliver outcomes."}}
SYS_16_OPERATOR_APPENDICES_OS!D5 {"formattedValue": "Niche + avatar\nDesired outcome\nFirst win definition\nDelivery method (DIY/DFY/Hybrid)\nConstraints", "userEnteredValue": {"stringValue": "Niche + avatar\nDesired outcome\nFirst win definition\nDelivery method (DIY/DFY/Hybrid)\nConstraints"}, "effectiveValue": {"stringValue": "Niche + avatar\nDesired outcome\nFirst win definition\nDelivery method (DIY/DFY/Hybrid)\nConstraints"}}
SYS_16_OPERATOR_APPENDICES_OS!E5 {"formattedValue": "Offer lock sheet\nOffer stack rules\nFreeze criteria\nProof plan", "userEnteredValue": {"stringValue": "Offer lock sheet\nOffer stack rules\nFreeze criteria\nProof plan"}, "effectiveValue": {"stringValue": "Offer lock sheet\nOffer stack rules\nFreeze criteria\nProof plan"}}
SYS_16_OPERATOR_APPENDICES_OS!F5 {"formattedValue": "Before building funnels/ads\nWhen scope creep appears", "userEnteredValue": {"stringValue": "Before building funnels/ads\nWhen scope creep appears"}, "effectiveValue": {"stringValue": "Before building funnels/ads\nWhen scope creep appears"}}
SYS_16_OPERATOR_APPENDICES_OS!G5 {"formattedValue": "Founder", "userEnteredValue": {"stringValue": "Founder"}, "effectiveValue": {"stringValue": "Founder"}}
SYS_16_OPERATOR_APPENDICES_OS!H5 {"formattedValue": "Single clear promise\nFirst win is fast + real\nNo hype claims\nHas delivery reality check", "userEnteredValue": {"stringValue": "Single clear promise\nFirst win is fast + real\nNo hype claims\nHas delivery reality check"}, "effectiveValue": {"stringValue": "Single clear promise\nFirst win is fast + real\nNo hype claims\nHas delivery reality check"}}
SYS_16_OPERATOR_APPENDICES_OS!I5 {"formattedValue": "If the offer is soft, everything else is expensive.", "userEnteredValue": {"stringValue": "If the offer is soft, everything else is expensive."}, "effectiveValue": {"stringValue": "If the offer is soft, everything else is expensive."}}
SYS_16_OPERATOR_APPENDICES_OS!J5 {"formattedValue": "https://docs.google.com/document/d/1p4Ordx2poBG_iWeUgWKQ-1B0eQfMcD2EKE1x-PMoMII/edit?usp=drivesdk", "userEnteredValue": {"stringValue": "https://docs.google.com/document/d/1p4Ordx2poBG_iWeUgWKQ-1B0eQfMcD2EKE1x-PMoMII/edit?usp=drivesdk"}, "effectiveValue": {"stringValue": "https://docs.google.com/document/d/1p4Ordx2poBG_iWeUgWKQ-1B0eQfMcD2EKE1x-PMoMII/edit?usp=drivesdk"}, "hyperlink": "https://docs.google.com/document/d/1p4Ordx2poBG_iWeUgWKQ-1B0eQfMcD2EKE1x-PMoMII/edit?usp=drivesdk"}
SYS_16_OPERATOR_APPENDICES_OS!A6 {"formattedValue": "OP-05", "userEnteredValue": {"stringValue": "OP-05"}, "effectiveValue": {"stringValue": "OP-05"}}
SYS_16_OPERATOR_APPENDICES_OS!B6 {"formattedValue": "Economics Truth Enforcer", "userEnteredValue": {"stringValue": "Economics Truth Enforcer"}, "effectiveValue": {"stringValue": "Economics Truth Enforcer"}}
SYS_16_OPERATOR_APPENDICES_OS!C6 {"formattedValue": "Forces unit economics truth (AOV/LTV/CAC/payback/margins) and blocks scaling until the math and delivery reality are stable.", "userEnteredValue": {"stringValue": "Forces unit economics truth (AOV/LTV/CAC/payback/margins) and blocks scaling until the math and delivery reality are stable."}, "effectiveValue": {"stringValue": "Forces unit economics truth (AOV/LTV/CAC/payback/margins) and blocks scaling until the math and delivery reality are stable."}}
SYS_16_OPERATOR_APPENDICES_OS!D6 {"formattedValue": "Offer pricing + costs\nConversion assumptions\nTraffic costs (if any)\nSupport/delivery load\nRetention assumptions", "userEnteredValue": {"stringValue": "Offer pricing + costs\nConversion assumptions\nTraffic costs (if any)\nSupport/delivery load\nRetention assumptions"}, "effectiveValue": {"stringValue": "Offer pricing + costs\nConversion assumptions\nTraffic costs (if any)\nSupport/delivery load\nRetention assumptions"}}
SYS_16_OPERATOR_APPENDICES_OS!E6 {"formattedValue": "Economics truth table\nBreak-even + burn rate logic\nLevers to improve (pricing/stack/retention)\nScale authorization status", "userEnteredValue": {"stringValue": "Economics truth table\nBreak-even + burn rate logic\nLevers to improve (pricing/stack/retention)\nScale authorization status"}, "effectiveValue": {"stringValue": "Economics truth table\nBreak-even + burn rate logic\nLevers to improve (pricing/stack/retention)\nScale authorization status"}}
SYS_16_OPERATOR_APPENDICES_OS!F6 {"formattedValue": "Before paid ads\nWhen CAC rises or LTV drops\nWhen fulfillment strain appears", "userEnteredValue": {"stringValue": "Before paid ads\nWhen CAC rises or LTV drops\nWhen fulfillment strain appears"}, "effectiveValue": {"stringValue": "Before paid ads\nWhen CAC rises or LTV drops\nWhen fulfillment strain appears"}}
SYS_16_OPERATOR_APPENDICES_OS!G6 {"formattedValue": "Founder", "userEnteredValue": {"stringValue": "Founder"}, "effectiveValue": {"stringValue": "Founder"}}
SYS_16_OPERATOR_APPENDICES_OS!H6 {"formattedValue": "Assumptions are explicit\nSensitivity checks exist\nNo scaling without margin-after-support", "userEnteredValue": {"stringValue": "Assumptions are explicit\nSensitivity checks exist\nNo scaling without margin-after-support"}, "effectiveValue": {"stringValue": "Assumptions are explicit\nSensitivity checks exist\nNo scaling without margin-after-support"}}
SYS_16_OPERATOR_APPENDICES_OS!I6 {"formattedValue": "This operator protects you from ‘growing into bankruptcy.’", "userEnteredValue": {"stringValue": "This operator protects you from ‘growing into bankruptcy.’"}, "effectiveValue": {"stringValue": "This operator protects you from ‘growing into bankruptcy.’"}}
SYS_16_OPERATOR_APPENDICES_OS!J6 {"formattedValue": "https://docs.google.com/document/d/1rG1zK6irOMIDoSTxyeyFiLsd1o0eg6G39uVWaBEXveM/edit?usp=drivesdk", "userEnteredValue": {"stringValue": "https://docs.google.com/document/d/1rG1zK6irOMIDoSTxyeyFiLsd1o0eg6G39uVWaBEXveM/edit?usp=drivesdk"}, "effectiveValue": {"stringValue": "https://docs.google.com/document/d/1rG1zK6irOMIDoSTxyeyFiLsd1o0eg6G39uVWaBEXveM/edit?usp=drivesdk"}, "hyperlink": "https://docs.google.com/document/d/1rG1zK6irOMIDoSTxyeyFiLsd1o0eg6G39uVWaBEXveM/edit?usp=drivesdk"}
SYS_16_OPERATOR_APPENDICES_OS!A7 {"formattedValue": "OP-06", "userEnteredValue": {"stringValue": "OP-06"}, "effectiveValue": {"stringValue": "OP-06"}}
SYS_16_OPERATOR_APPENDICES_OS!B7 {"formattedValue": "Value Curve Architect", "userEnteredValue": {"stringValue": "Value Curve Architect"}, "effectiveValue": {"stringValue": "Value Curve Architect"}}
SYS_16_OPERATOR_APPENDICES_OS!C7 {"formattedValue": "Designs your differentiation so you stop competing on noise and start owning a value curve your rivals can’t copy quickly.", "userEnteredValue": {"stringValue": "Designs your differentiation so you stop competing on noise and start owning a value curve your rivals can’t copy quickly."}, "effectiveValue": {"stringValue": "Designs your differentiation so you stop competing on noise and start owning a value curve your rivals can’t copy quickly."}}
SYS_16_OPERATOR_APPENDICES_OS!D7 {"formattedValue": "Competitor offers + messaging\nCustomer complaints\nYour strengths/capabilities\nNon-negotiables", "userEnteredValue": {"stringValue": "Competitor offers + messaging\nCustomer complaints\nYour strengths/capabilities\nNon-negotiables"}, "effectiveValue": {"stringValue": "Competitor offers + messaging\nCustomer complaints\nYour strengths/capabilities\nNon-negotiables"}}
SYS_16_OPERATOR_APPENDICES_OS!E7 {"formattedValue": "Value curve (eliminate/reduce/raise/create)\nCategory reframing angle\nPositioning guardrails", "userEnteredValue": {"stringValue": "Value curve (eliminate/reduce/raise/create)\nCategory reframing angle\nPositioning guardrails"}, "effectiveValue": {"stringValue": "Value curve (eliminate/reduce/raise/create)\nCategory reframing angle\nPositioning guardrails"}}
SYS_16_OPERATOR_APPENDICES_OS!F7 {"formattedValue": "After niche selection\nBefore messaging/copy expansion", "userEnteredValue": {"stringValue": "After niche selection\nBefore messaging/copy expansion"}, "effectiveValue": {"stringValue": "After niche selection\nBefore messaging/copy expansion"}}
SYS_16_OPERATOR_APPENDICES_OS!G7 {"formattedValue": "Founder / Operator", "userEnteredValue": {"stringValue": "Founder / Operator"}, "effectiveValue": {"stringValue": "Founder / Operator"}}
SYS_16_OPERATOR_APPENDICES_OS!H7 {"formattedValue": "Clear tradeoffs\nDifferentiation is provable\nAvoids ‘me too’ claims", "userEnteredValue": {"stringValue": "Clear tradeoffs\nDifferentiation is provable\nAvoids ‘me too’ claims"}, "effectiveValue": {"stringValue": "Clear tradeoffs\nDifferentiation is provable\nAvoids ‘me too’ claims"}}
SYS_16_OPERATOR_APPENDICES_OS!I7 {"formattedValue": "This is your Blue Ocean scaffolding.", "userEnteredValue": {"stringValue": "This is your Blue Ocean scaffolding."}, "effectiveValue": {"stringValue": "This is your Blue Ocean scaffolding."}}
SYS_16_OPERATOR_APPENDICES_OS!J7 {"formattedValue": "https://docs.google.com/document/d/1El235b7etWP4jHh_5t710vuBlcYJhYpQietlt7Ohr9s/edit?usp=drivesdk", "userEnteredValue": {"stringValue": "https://docs.google.com/document/d/1El235b7etWP4jHh_5t710vuBlcYJhYpQietlt7Ohr9s/edit?usp=drivesdk"}, "effectiveValue": {"stringValue": "https://docs.google.com/document/d/1El235b7etWP4jHh_5t710vuBlcYJhYpQietlt7Ohr9s/edit?usp=drivesdk"}, "hyperlink": "https://docs.google.com/document/d/1El235b7etWP4jHh_5t710vuBlcYJhYpQietlt7Ohr9s/edit?usp=drivesdk"}
SYS_16_OPERATOR_APPENDICES_OS!A8 {"formattedValue": "OP-07", "userEnteredValue": {"stringValue": "OP-07"}, "effectiveValue": {"stringValue": "OP-07"}}
SYS_16_OPERATOR_APPENDICES_OS!B8 {"formattedValue": "Positioning Vector Engine", "userEnteredValue": {"stringValue": "Positioning Vector Engine"}, "effectiveValue": {"stringValue": "Positioning Vector Engine"}}
SYS_16_OPERATOR_APPENDICES_OS!C8 {"formattedValue": "Turns differentiation into a simple, repeatable positioning statement and ‘why you’ logic across funnel and content.", "userEnteredValue": {"stringValue": "Turns differentiation into a simple, repeatable positioning statement and ‘why you’ logic across funnel and content."}, "effectiveValue": {"stringValue": "Turns differentiation into a simple, repeatable positioning statement and ‘why you’ logic across funnel and content."}}
SYS_16_OPERATOR_APPENDICES_OS!D8 {"formattedValue": "Value curve\nAvatar tension\nOffer lock\nCompetitive landscape", "userEnteredValue": {"stringValue": "Value curve\nAvatar tension\nOffer lock\nCompetitive landscape"}, "effectiveValue": {"stringValue": "Value curve\nAvatar tension\nOffer lock\nCompetitive landscape"}}
SYS_16_OPERATOR_APPENDICES_OS!E8 {"formattedValue": "Positioning statement\nProof pillars\nEnemy choice framing\nCategory language rules", "userEnteredValue": {"stringValue": "Positioning statement\nProof pillars\nEnemy choice framing\nCategory language rules"}, "effectiveValue": {"stringValue": "Positioning statement\nProof pillars\nEnemy choice framing\nCategory language rules"}}
SYS_16_OPERATOR_APPENDICES_OS!F8 {"formattedValue": "Before long-form content + ads scaling", "userEnteredValue": {"stringValue": "Before long-form content + ads scaling"}, "effectiveValue": {"stringValue": "Before long-form content + ads scaling"}}
SYS_16_OPERATOR_APPENDICES_OS!G8 {"formattedValue": "Founder", "userEnteredValue": {"stringValue": "Founder"}, "effectiveValue": {"stringValue": "Founder"}}
SYS_16_OPERATOR_APPENDICES_OS!H8 {"formattedValue": "Readable at 5th-grade level\nProof-backed\nNo jargon positioning", "userEnteredValue": {"stringValue": "Readable at 5th-grade level\nProof-backed\nNo jargon positioning"}, "effectiveValue": {"stringValue": "Readable at 5th-grade level\nProof-backed\nNo jargon positioning"}}
SYS_16_OPERATOR_APPENDICES_OS!I8 {"formattedValue": "Positioning is a constraint that creates speed.", "userEnteredValue": {"stringValue": "Positioning is a constraint that creates speed."}, "effectiveValue": {"stringValue": "Positioning is a constraint that creates speed."}}
SYS_16_OPERATOR_APPENDICES_OS!J8 {"formattedValue": "https://docs.google.com/document/d/1j1ArYBj4pGOykPo0QmVkFMEYEZaDu4SjUj2cZH5E-bc/edit?usp=drivesdk", "userEnteredValue": {"stringValue": "https://docs.google.com/document/d/1j1ArYBj4pGOykPo0QmVkFMEYEZaDu4SjUj2cZH5E-bc/edit?usp=drivesdk"}, "effectiveValue": {"stringValue": "https://docs.google.com/document/d/1j1ArYBj4pGOykPo0QmVkFMEYEZaDu4SjUj2cZH5E-bc/edit?usp=drivesdk"}, "hyperlink": "https://docs.google.com/document/d/1j1ArYBj4pGOykPo0QmVkFMEYEZaDu4SjUj2cZH5E-bc/edit?usp=drivesdk"}
SYS_16_OPERATOR_APPENDICES_OS!A9 {"formattedValue": "OP-08", "userEnteredValue": {"stringValue": "OP-08"}, "effectiveValue": {"stringValue": "OP-08"}}
SYS_16_OPERATOR_APPENDICES_OS!B9 {"formattedValue": "Messaging & Narrative Engine", "userEnteredValue": {"stringValue": "Messaging & Narrative Engine"}, "effectiveValue": {"stringValue": "Messaging & Narrative Engine"}}
SYS_16_OPERATOR_APPENDICES_OS!C9 {"formattedValue": "Builds the core story stack: beliefs, reframes, proof, and empathy—so copy, videos, and onboarding all sound like one company.", "userEnteredValue": {"stringValue": "Builds the core story stack: beliefs, reframes, proof, and empathy—so copy, videos, and onboarding all sound like one company."}, "effectiveValue": {"stringValue": "Builds the core story stack: beliefs, reframes, proof, and empathy—so copy, videos, and onboarding all sound like one company."}}
SYS_16_OPERATOR_APPENDICES_OS!D9 {"formattedValue": "Positioning\nAvatar belief state\nProof assets\nFounder story angles (approved)", "userEnteredValue": {"stringValue": "Positioning\nAvatar belief state\nProof assets\nFounder story angles (approved)"}, "effectiveValue": {"stringValue": "Positioning\nAvatar belief state\nProof assets\nFounder story angles (approved)"}}
SYS_16_OPERATOR_APPENDICES_OS!E9 {"formattedValue": "Message pillars\nBelief-shift sequences\nObjection scripts\nNarrative do/don’t rules", "userEnteredValue": {"stringValue": "Message pillars\nBelief-shift sequences\nObjection scripts\nNarrative do/don’t rules"}, "effectiveValue": {"stringValue": "Message pillars\nBelief-shift sequences\nObjection scripts\nNarrative do/don’t rules"}}
SYS_16_OPERATOR_APPENDICES_OS!F9 {"formattedValue": "When content is inconsistent\nWhen objections repeat", "userEnteredValue": {"stringValue": "When content is inconsistent\nWhen objections repeat"}, "effectiveValue": {"stringValue": "When content is inconsistent\nWhen objections repeat"}}
SYS_16_OPERATOR_APPENDICES_OS!G9 {"formattedValue": "Founder / VA", "userEnteredValue": {"stringValue": "Founder / VA"}, "effectiveValue": {"stringValue": "Founder / VA"}}
SYS_16_OPERATOR_APPENDICES_OS!H9 {"formattedValue": "Matches RISER tone (calm, no hype)\nObjection handling is mapped to belief state\nNo manipulation", "userEnteredValue": {"stringValue": "Matches RISER tone (calm, no hype)\nObjection handling is mapped to belief state\nNo manipulation"}, "effectiveValue": {"stringValue": "Matches RISER tone (calm, no hype)\nObjection handling is mapped to belief state\nNo manipulation"}}
SYS_16_OPERATOR_APPENDICES_OS!I9 {"formattedValue": "This is where brand voice becomes a system.", "userEnteredValue": {"stringValue": "This is where brand voice becomes a system."}, "effectiveValue": {"stringValue": "This is where brand voice becomes a system."}}
SYS_16_OPERATOR_APPENDICES_OS!J9 {"formattedValue": "https://docs.google.com/document/d/1gsCivPvC5-MWvyggVpe69IaxUxA79WVG-igmOfP6IA8/edit?usp=drivesdk", "userEnteredValue": {"stringValue": "https://docs.google.com/document/d/1gsCivPvC5-MWvyggVpe69IaxUxA79WVG-igmOfP6IA8/edit?usp=drivesdk"}, "effectiveValue": {"stringValue": "https://docs.google.com/document/d/1gsCivPvC5-MWvyggVpe69IaxUxA79WVG-igmOfP6IA8/edit?usp=drivesdk"}, "hyperlink": "https://docs.google.com/document/d/1gsCivPvC5-MWvyggVpe69IaxUxA79WVG-igmOfP6IA8/edit?usp=drivesdk"}
SYS_16_OPERATOR_APPENDICES_OS!A10 {"formattedValue": "OP-09", "userEnteredValue": {"stringValue": "OP-09"}, "effectiveValue": {"stringValue": "OP-09"}}
SYS_16_OPERATOR_APPENDICES_OS!B10 {"formattedValue": "Offer Framing Engine", "userEnteredValue": {"stringValue": "Offer Framing Engine"}, "effectiveValue": {"stringValue": "Offer Framing Engine"}}
SYS_16_OPERATOR_APPENDICES_OS!C10 {"formattedValue": "Frames the offer so it feels safe, specific, and inevitable—without pressure—by matching the promise to the belief stage and proof depth.", "userEnteredValue": {"stringValue": "Frames the offer so it feels safe, specific, and inevitable—without pressure—by matching the promise to the belief stage and proof depth."}, "effectiveValue": {"stringValue": "Frames the offer so it feels safe, specific, and inevitable—without pressure—by matching the promise to the belief stage and proof depth."}}
SYS_16_OPERATOR_APPENDICES_OS!D10 {"formattedValue": "Offer lock\nAvatar belief stage\nProof stack\nFunnel step (TOF/MOF/BOF)", "userEnteredValue": {"stringValue": "Offer lock\nAvatar belief stage\nProof stack\nFunnel step (TOF/MOF/BOF)"}, "effectiveValue": {"stringValue": "Offer lock\nAvatar belief stage\nProof stack\nFunnel step (TOF/MOF/BOF)"}}
SYS_16_OPERATOR_APPENDICES_OS!E10 {"formattedValue": "Angle matrix\nHeadline/hook families\nProof placement plan\nRisk reversal options", "userEnteredValue": {"stringValue": "Angle matrix\nHeadline/hook families\nProof placement plan\nRisk reversal options"}, "effectiveValue": {"stringValue": "Angle matrix\nHeadline/hook families\nProof placement plan\nRisk reversal options"}}
SYS_16_OPERATOR_APPENDICES_OS!F10 {"formattedValue": "Before writing landing pages/VSLs\nBefore ads creative scale", "userEnteredValue": {"stringValue": "Before writing landing pages/VSLs\nBefore ads creative scale"}, "effectiveValue": {"stringValue": "Before writing landing pages/VSLs\nBefore ads creative scale"}}
SYS_16_OPERATOR_APPENDICES_OS!G10 {"formattedValue": "Copy Lead / Founder", "userEnteredValue": {"stringValue": "Copy Lead / Founder"}, "effectiveValue": {"stringValue": "Copy Lead / Founder"}}
SYS_16_OPERATOR_APPENDICES_OS!H10 {"formattedValue": "One decision per step\nProof precedes ask\nNo overpromising", "userEnteredValue": {"stringValue": "One decision per step\nProof precedes ask\nNo overpromising"}, "effectiveValue": {"stringValue": "One decision per step\nProof precedes ask\nNo overpromising"}}
SYS_16_OPERATOR_APPENDICES_OS!I10 {"formattedValue": "Framing is where conversion becomes ethical.", "userEnteredValue": {"stringValue": "Framing is where conversion becomes ethical."}, "effectiveValue": {"stringValue": "Framing is where conversion becomes ethical."}}
SYS_16_OPERATOR_APPENDICES_OS!J10 {"formattedValue": "https://docs.google.com/document/d/1VV99-iQPeBNY8k9Tk0_S_CX5cI1FrgVtq7okWpPDpCk/edit?usp=drivesdk", "userEnteredValue": {"stringValue": "https://docs.google.com/document/d/1VV99-iQPeBNY8k9Tk0_S_CX5cI1FrgVtq7okWpPDpCk/edit?usp=drivesdk"}, "effectiveValue": {"stringValue": "https://docs.google.com/document/d/1VV99-iQPeBNY8k9Tk0_S_CX5cI1FrgVtq7okWpPDpCk/edit?usp=drivesdk"}, "hyperlink": "https://docs.google.com/document/d/1VV99-iQPeBNY8k9Tk0_S_CX5cI1FrgVtq7okWpPDpCk/edit?usp=drivesdk"}
SYS_16_OPERATOR_APPENDICES_OS!A11 {"formattedValue": "OP-10", "userEnteredValue": {"stringValue": "OP-10"}, "effectiveValue": {"stringValue": "OP-10"}}
SYS_16_OPERATOR_APPENDICES_OS!B11 {"formattedValue": "Hook Systems Architect", "userEnteredValue": {"stringValue": "Hook Systems Architect"}, "effectiveValue": {"stringValue": "Hook Systems Architect"}}
SYS_16_OPERATOR_APPENDICES_OS!C11 {"formattedValue": "Builds a hook library + test discipline so you can win attention repeatedly (not randomly) and feed the flywheel with compounding winners.", "userEnteredValue": {"stringValue": "Builds a hook library + test discipline so you can win attention repeatedly (not randomly) and feed the flywheel with compounding winners."}, "effectiveValue": {"stringValue": "Builds a hook library + test discipline so you can win attention repeatedly (not randomly) and feed the flywheel with compounding winners."}}
SYS_16_OPERATOR_APPENDICES_OS!D11 {"formattedValue": "Message pillars\nWinning content samples\nPlatform specs\nOffer stage", "userEnteredValue": {"stringValue": "Message pillars\nWinning content samples\nPlatform specs\nOffer stage"}, "effectiveValue": {"stringValue": "Message pillars\nWinning content samples\nPlatform specs\nOffer stage"}}
SYS_16_OPERATOR_APPENDICES_OS!E11 {"formattedValue": "Hook library (tagged)\nHook testing matrix\nMicro-hook timing rules\nCreative iteration plan", "userEnteredValue": {"stringValue": "Hook library (tagged)\nHook testing matrix\nMicro-hook timing rules\nCreative iteration plan"}, "effectiveValue": {"stringValue": "Hook library (tagged)\nHook testing matrix\nMicro-hook timing rules\nCreative iteration plan"}}
SYS_16_OPERATOR_APPENDICES_OS!F11 {"formattedValue": "Before daily publishing cadence\nWhen CTR/retention drops", "userEnteredValue": {"stringValue": "Before daily publishing cadence\nWhen CTR/retention drops"}, "effectiveValue": {"stringValue": "Before daily publishing cadence\nWhen CTR/retention drops"}}
SYS_16_OPERATOR_APPENDICES_OS!G11 {"formattedValue": "Content Lead / VA", "userEnteredValue": {"stringValue": "Content Lead / VA"}, "effectiveValue": {"stringValue": "Content Lead / VA"}}
SYS_16_OPERATOR_APPENDICES_OS!H11 {"formattedValue": "One-variable tests\nHooks match belief stage\nRetention checkpoints included", "userEnteredValue": {"stringValue": "One-variable tests\nHooks match belief stage\nRetention checkpoints included"}, "effectiveValue": {"stringValue": "One-variable tests\nHooks match belief stage\nRetention checkpoints included"}}
SYS_16_OPERATOR_APPENDICES_OS!I11 {"formattedValue": "Hooks are an engine, not inspiration.", "userEnteredValue": {"stringValue": "Hooks are an engine, not inspiration."}, "effectiveValue": {"stringValue": "Hooks are an engine, not inspiration."}}
SYS_16_OPERATOR_APPENDICES_OS!J11 {"formattedValue": "https://docs.google.com/document/d/1qRlp-8U8sctqg_qQRa8_8zk2INP9Cs-CuJOE91tepYo/edit?usp=drivesdk", "userEnteredValue": {"stringValue": "https://docs.google.com/document/d/1qRlp-8U8sctqg_qQRa8_8zk2INP9Cs-CuJOE91tepYo/edit?usp=drivesdk"}, "effectiveValue": {"stringValue": "https://docs.google.com/document/d/1qRlp-8U8sctqg_qQRa8_8zk2INP9Cs-CuJOE91tepYo/edit?usp=drivesdk"}, "hyperlink": "https://docs.google.com/document/d/1qRlp-8U8sctqg_qQRa8_8zk2INP9Cs-CuJOE91tepYo/edit?usp=drivesdk"}
SYS_16_OPERATOR_APPENDICES_OS!A12 {"formattedValue": "OP-11", "userEnteredValue": {"stringValue": "OP-11"}, "effectiveValue": {"stringValue": "OP-11"}}
SYS_16_OPERATOR_APPENDICES_OS!B12 {"formattedValue": "Funnel Architecture Engine", "userEnteredValue": {"stringValue": "Funnel Architecture Engine"}, "effectiveValue": {"stringValue": "Funnel Architecture Engine"}}
SYS_16_OPERATOR_APPENDICES_OS!C12 {"formattedValue": "Designs the funnel sequence as a dependency chain (one decision per step) tied to onboarding and first win—so it converts and doesn’t create support chaos.", "userEnteredValue": {"stringValue": "Designs the funnel sequence as a dependency chain (one decision per step) tied to onboarding and first win—so it converts and doesn’t create support chaos."}, "effectiveValue": {"stringValue": "Designs the funnel sequence as a dependency chain (one decision per step) tied to onboarding and first win—so it converts and doesn’t create support chaos."}}
SYS_16_OPERATOR_APPENDICES_OS!D12 {"formattedValue": "Offer lock\nProof plan\nTraffic sources\nCustomer journey stage", "userEnteredValue": {"stringValue": "Offer lock\nProof plan\nTraffic sources\nCustomer journey stage"}, "effectiveValue": {"stringValue": "Offer lock\nProof plan\nTraffic sources\nCustomer journey stage"}}
SYS_16_OPERATOR_APPENDICES_OS!E12 {"formattedValue": "Funnel map\nPage-by-page goal + CTA\nUpsell/downsell logic\nTracking plan", "userEnteredValue": {"stringValue": "Funnel map\nPage-by-page goal + CTA\nUpsell/downsell logic\nTracking plan"}, "effectiveValue": {"stringValue": "Funnel map\nPage-by-page goal + CTA\nUpsell/downsell logic\nTracking plan"}}
SYS_16_OPERATOR_APPENDICES_OS!F12 {"formattedValue": "Before building pages\nWhen conversion is ‘mysteriously’ low", "userEnteredValue": {"stringValue": "Before building pages\nWhen conversion is ‘mysteriously’ low"}, "effectiveValue": {"stringValue": "Before building pages\nWhen conversion is ‘mysteriously’ low"}}
SYS_16_OPERATOR_APPENDICES_OS!G12 {"formattedValue": "Founder / Funnel Builder", "userEnteredValue": {"stringValue": "Founder / Funnel Builder"}, "effectiveValue": {"stringValue": "Founder / Funnel Builder"}}
SYS_16_OPERATOR_APPENDICES_OS!H12 {"formattedValue": "Sequence integrity\nNo step does two jobs\nOnboarding is built into funnel promise", "userEnteredValue": {"stringValue": "Sequence integrity\nNo step does two jobs\nOnboarding is built into funnel promise"}, "effectiveValue": {"stringValue": "Sequence integrity\nNo step does two jobs\nOnboarding is built into funnel promise"}}
SYS_16_OPERATOR_APPENDICES_OS!I12 {"formattedValue": "Funnels fail when they skip belief safety.", "userEnteredValue": {"stringValue": "Funnels fail when they skip belief safety."}, "effectiveValue": {"stringValue": "Funnels fail when they skip belief safety."}}
SYS_16_OPERATOR_APPENDICES_OS!J12 {"formattedValue": "https://docs.google.com/document/d/1CbSex5XGDn9QdTXLXRaK83xPOqBoChZFyAOdIqpovlo/edit?usp=drivesdk", "userEnteredValue": {"stringValue": "https://docs.google.com/document/d/1CbSex5XGDn9QdTXLXRaK83xPOqBoChZFyAOdIqpovlo/edit?usp=drivesdk"}, "effectiveValue": {"stringValue": "https://docs.google.com/document/d/1CbSex5XGDn9QdTXLXRaK83xPOqBoChZFyAOdIqpovlo/edit?usp=drivesdk"}, "hyperlink": "https://docs.google.com/document/d/1CbSex5XGDn9QdTXLXRaK83xPOqBoChZFyAOdIqpovlo/edit?usp=drivesdk"}
SYS_16_OPERATOR_APPENDICES_OS!A13 {"formattedValue": "OP-12", "userEnteredValue": {"stringValue": "OP-12"}, "effectiveValue": {"stringValue": "OP-12"}}
SYS_16_OPERATOR_APPENDICES_OS!B13 {"formattedValue": "Traffic Authorization Gate", "userEnteredValue": {"stringValue": "Traffic Authorization Gate"}, "effectiveValue": {"stringValue": "Traffic Authorization Gate"}}
SYS_16_OPERATOR_APPENDICES_OS!C13 {"formattedValue": "Prevents premature traffic. Approves channels only when offer + economics + delivery stability are green.", "userEnteredValue": {"stringValue": "Prevents premature traffic. Approves channels only when offer + economics + delivery stability are green."}, "effectiveValue": {"stringValue": "Prevents premature traffic. Approves channels only when offer + economics + delivery stability are green."}}
SYS_16_OPERATOR_APPENDICES_OS!D13 {"formattedValue": "Economics truth status\nOffer lock status\nFirst win delivery evidence\nCapacity", "userEnteredValue": {"stringValue": "Economics truth status\nOffer lock status\nFirst win delivery evidence\nCapacity"}, "effectiveValue": {"stringValue": "Economics truth status\nOffer lock status\nFirst win delivery evidence\nCapacity"}}
SYS_16_OPERATOR_APPENDICES_OS!E13 {"formattedValue": "Traffic authorization decision\nApproved channels + constraints\nTesting plan (small + controlled)", "userEnteredValue": {"stringValue": "Traffic authorization decision\nApproved channels + constraints\nTesting plan (small + controlled)"}, "effectiveValue": {"stringValue": "Traffic authorization decision\nApproved channels + constraints\nTesting plan (small + controlled)"}}
SYS_16_OPERATOR_APPENDICES_OS!F13 {"formattedValue": "Before any paid spend\nBefore hiring a media buyer", "userEnteredValue": {"stringValue": "Before any paid spend\nBefore hiring a media buyer"}, "effectiveValue": {"stringValue": "Before any paid spend\nBefore hiring a media buyer"}}
SYS_16_OPERATOR_APPENDICES_OS!G13 {"formattedValue": "Founder", "userEnteredValue": {"stringValue": "Founder"}, "effectiveValue": {"stringValue": "Founder"}}
SYS_16_OPERATOR_APPENDICES_OS!H13 {"formattedValue": "If red flags exist, it blocks traffic\nForces smallest viable test", "userEnteredValue": {"stringValue": "If red flags exist, it blocks traffic\nForces smallest viable test"}, "effectiveValue": {"stringValue": "If red flags exist, it blocks traffic\nForces smallest viable test"}}
SYS_16_OPERATOR_APPENDICES_OS!I13 {"formattedValue": "Traffic doesn’t fix broken offers.", "userEnteredValue": {"stringValue": "Traffic doesn’t fix broken offers."}, "effectiveValue": {"stringValue": "Traffic doesn’t fix broken offers."}}
SYS_16_OPERATOR_APPENDICES_OS!J13 {"formattedValue": "https://docs.google.com/document/d/1htqyXPo44MmK5E7TYQDFAQarJAFq6uxzbWBvzDOYjDQ/edit?usp=drivesdk", "userEnteredValue": {"stringValue": "https://docs.google.com/document/d/1htqyXPo44MmK5E7TYQDFAQarJAFq6uxzbWBvzDOYjDQ/edit?usp=drivesdk"}, "effectiveValue": {"stringValue": "https://docs.google.com/document/d/1htqyXPo44MmK5E7TYQDFAQarJAFq6uxzbWBvzDOYjDQ/edit?usp=drivesdk"}, "hyperlink": "https://docs.google.com/document/d/1htqyXPo44MmK5E7TYQDFAQarJAFq6uxzbWBvzDOYjDQ/edit?usp=drivesdk"}
SYS_16_OPERATOR_APPENDICES_OS!A14 {"formattedValue": "OP-13", "userEnteredValue": {"stringValue": "OP-13"}, "effectiveValue": {"stringValue": "OP-13"}}
SYS_16_OPERATOR_APPENDICES_OS!B14 {"formattedValue": "Paid Ads Integrity Operator", "userEnteredValue": {"stringValue": "Paid Ads Integrity Operator"}, "effectiveValue": {"stringValue": "Paid Ads Integrity Operator"}}
SYS_16_OPERATOR_APPENDICES_OS!C14 {"formattedValue": "Runs the paid ads OS: testing discipline, fatigue diagnosis, CTR/CVR fixes, and integrity rules so you don’t buy garbage data.", "userEnteredValue": {"stringValue": "Runs the paid ads OS: testing discipline, fatigue diagnosis, CTR/CVR fixes, and integrity rules so you don’t buy garbage data."}, "effectiveValue": {"stringValue": "Runs the paid ads OS: testing discipline, fatigue diagnosis, CTR/CVR fixes, and integrity rules so you don’t buy garbage data."}}
SYS_16_OPERATOR_APPENDICES_OS!D14 {"formattedValue": "Offer + funnel\nCreative set\nKPIs (CTR/CVR/CPA)\nSpend + frequency\nLanding page metrics", "userEnteredValue": {"stringValue": "Offer + funnel\nCreative set\nKPIs (CTR/CVR/CPA)\nSpend + frequency\nLanding page metrics"}, "effectiveValue": {"stringValue": "Offer + funnel\nCreative set\nKPIs (CTR/CVR/CPA)\nSpend + frequency\nLanding page metrics"}}
SYS_16_OPERATOR_APPENDICES_OS!E14 {"formattedValue": "Diagnosis report\nNext test plan (one variable)\nFatigue/exhaustion actions\nKPI thresholds + alerts", "userEnteredValue": {"stringValue": "Diagnosis report\nNext test plan (one variable)\nFatigue/exhaustion actions\nKPI thresholds + alerts"}, "effectiveValue": {"stringValue": "Diagnosis report\nNext test plan (one variable)\nFatigue/exhaustion actions\nKPI thresholds + alerts"}}
SYS_16_OPERATOR_APPENDICES_OS!F14 {"formattedValue": "When ads stop converting\nLow CTR\nRising CPA\nHigh frequency", "userEnteredValue": {"stringValue": "When ads stop converting\nLow CTR\nRising CPA\nHigh frequency"}, "effectiveValue": {"stringValue": "When ads stop converting\nLow CTR\nRising CPA\nHigh frequency"}}
SYS_16_OPERATOR_APPENDICES_OS!G14 {"formattedValue": "Media Buyer / Founder", "userEnteredValue": {"stringValue": "Media Buyer / Founder"}, "effectiveValue": {"stringValue": "Media Buyer / Founder"}}
SYS_16_OPERATOR_APPENDICES_OS!H14 {"formattedValue": "Controlled tests\nNo random changes mid-test\nCreative + post-click both evaluated", "userEnteredValue": {"stringValue": "Controlled tests\nNo random changes mid-test\nCreative + post-click both evaluated"}, "effectiveValue": {"stringValue": "Controlled tests\nNo random changes mid-test\nCreative + post-click both evaluated"}}
SYS_16_OPERATOR_APPENDICES_OS!I14 {"formattedValue": "This is your ad engine safety system.", "userEnteredValue": {"stringValue": "This is your ad engine safety system."}, "effectiveValue": {"stringValue": "This is your ad engine safety system."}}
SYS_16_OPERATOR_APPENDICES_OS!J14 {"formattedValue": "https://docs.google.com/document/d/1TNS8yNWH_07T-QPjxJXB3IndqWR3lcfPYt1QgionQ5w/edit?usp=drivesdk", "userEnteredValue": {"stringValue": "https://docs.google.com/document/d/1TNS8yNWH_07T-QPjxJXB3IndqWR3lcfPYt1QgionQ5w/edit?usp=drivesdk"}, "effectiveValue": {"stringValue": "https://docs.google.com/document/d/1TNS8yNWH_07T-QPjxJXB3IndqWR3lcfPYt1QgionQ5w/edit?usp=drivesdk"}, "hyperlink": "https://docs.google.com/document/d/1TNS8yNWH_07T-QPjxJXB3IndqWR3lcfPYt1QgionQ5w/edit?usp=drivesdk"}
SYS_16_OPERATOR_APPENDICES_OS!A15 {"formattedValue": "OP-14", "userEnteredValue": {"stringValue": "OP-14"}, "effectiveValue": {"stringValue": "OP-14"}}
SYS_16_OPERATOR_APPENDICES_OS!B15 {"formattedValue": "YouTube Authority Engine", "userEnteredValue": {"stringValue": "YouTube Authority Engine"}, "effectiveValue": {"stringValue": "YouTube Authority Engine"}}
SYS_16_OPERATOR_APPENDICES_OS!C15 {"formattedValue": "Builds authority and compounding discovery through packaging + retention architecture (title/thumbnail/first 15 seconds + series strategy).", "userEnteredValue": {"stringValue": "Builds authority and compounding discovery through packaging + retention architecture (title/thumbnail/first 15 seconds + series strategy)."}, "effectiveValue": {"stringValue": "Builds authority and compounding discovery through packaging + retention architecture (title/thumbnail/first 15 seconds + series strategy)."}}
SYS_16_OPERATOR_APPENDICES_OS!D15 {"formattedValue": "Channel goal\nAvatar + niche\nVideo topics\nRetention analytics\nOffer tie-in", "userEnteredValue": {"stringValue": "Channel goal\nAvatar + niche\nVideo topics\nRetention analytics\nOffer tie-in"}, "effectiveValue": {"stringValue": "Channel goal\nAvatar + niche\nVideo topics\nRetention analytics\nOffer tie-in"}}
SYS_16_OPERATOR_APPENDICES_OS!E15 {"formattedValue": "Series plan\nPackaging checklist\nRetention waterfall fixes\nYouTube KPI set", "userEnteredValue": {"stringValue": "Series plan\nPackaging checklist\nRetention waterfall fixes\nYouTube KPI set"}, "effectiveValue": {"stringValue": "Series plan\nPackaging checklist\nRetention waterfall fixes\nYouTube KPI set"}}
SYS_16_OPERATOR_APPENDICES_OS!F15 {"formattedValue": "Before scaling production\nWhen retention cliffs appear", "userEnteredValue": {"stringValue": "Before scaling production\nWhen retention cliffs appear"}, "effectiveValue": {"stringValue": "Before scaling production\nWhen retention cliffs appear"}}
SYS_16_OPERATOR_APPENDICES_OS!G15 {"formattedValue": "YouTube Lead", "userEnteredValue": {"stringValue": "YouTube Lead"}, "effectiveValue": {"stringValue": "YouTube Lead"}}
SYS_16_OPERATOR_APPENDICES_OS!H15 {"formattedValue": "Packaging is tested\nFirst 15 seconds are engineered\nSeries > singles", "userEnteredValue": {"stringValue": "Packaging is tested\nFirst 15 seconds are engineered\nSeries > singles"}, "effectiveValue": {"stringValue": "Packaging is tested\nFirst 15 seconds are engineered\nSeries > singles"}}
SYS_16_OPERATOR_APPENDICES_OS!I15 {"formattedValue": "YouTube is a compounding asset if treated as one.", "userEnteredValue": {"stringValue": "YouTube is a compounding asset if treated as one."}, "effectiveValue": {"stringValue": "YouTube is a compounding asset if treated as one."}}
SYS_16_OPERATOR_APPENDICES_OS!J15 {"formattedValue": "https://docs.google.com/document/d/1tvWxk0lY_uuWn8KQkoDuWWwHopzv0NvUcMl0nfcQD08/edit?usp=drivesdk", "userEnteredValue": {"stringValue": "https://docs.google.com/document/d/1tvWxk0lY_uuWn8KQkoDuWWwHopzv0NvUcMl0nfcQD08/edit?usp=drivesdk"}, "effectiveValue": {"stringValue": "https://docs.google.com/document/d/1tvWxk0lY_uuWn8KQkoDuWWwHopzv0NvUcMl0nfcQD08/edit?usp=drivesdk"}, "hyperlink": "https://docs.google.com/document/d/1tvWxk0lY_uuWn8KQkoDuWWwHopzv0NvUcMl0nfcQD08/edit?usp=drivesdk"}
SYS_16_OPERATOR_APPENDICES_OS!A16 {"formattedValue": "OP-15", "userEnteredValue": {"stringValue": "OP-15"}, "effectiveValue": {"stringValue": "OP-15"}}
SYS_16_OPERATOR_APPENDICES_OS!B16 {"formattedValue": "Retention & LTV Engine", "userEnteredValue": {"stringValue": "Retention & LTV Engine"}, "effectiveValue": {"stringValue": "Retention & LTV Engine"}}
SYS_16_OPERATOR_APPENDICES_OS!C16 {"formattedValue": "Creates continuity loops (onboarding, support reduction, community tie-in, upsells) to raise LTV and reduce churn/refunds.", "userEnteredValue": {"stringValue": "Creates continuity loops (onboarding, support reduction, community tie-in, upsells) to raise LTV and reduce churn/refunds."}, "effectiveValue": {"stringValue": "Creates continuity loops (onboarding, support reduction, community tie-in, upsells) to raise LTV and reduce churn/refunds."}}
SYS_16_OPERATOR_APPENDICES_OS!D16 {"formattedValue": "Offer delivery map\nOnboarding flow\nSupport tickets themes\nChurn/refund reasons", "userEnteredValue": {"stringValue": "Offer delivery map\nOnboarding flow\nSupport tickets themes\nChurn/refund reasons"}, "effectiveValue": {"stringValue": "Offer delivery map\nOnboarding flow\nSupport tickets themes\nChurn/refund reasons"}}
SYS_16_OPERATOR_APPENDICES_OS!E16 {"formattedValue": "Retention plan\nTime-to-first-win improvements\nUpsell/continuity options\nSupport load reduction plan", "userEnteredValue": {"stringValue": "Retention plan\nTime-to-first-win improvements\nUpsell/continuity options\nSupport load reduction plan"}, "effectiveValue": {"stringValue": "Retention plan\nTime-to-first-win improvements\nUpsell/continuity options\nSupport load reduction plan"}}
SYS_16_OPERATOR_APPENDICES_OS!F16 {"formattedValue": "After first customers\nWhen churn or refunds rise", "userEnteredValue": {"stringValue": "After first customers\nWhen churn or refunds rise"}, "effectiveValue": {"stringValue": "After first customers\nWhen churn or refunds rise"}}
SYS_16_OPERATOR_APPENDICES_OS!G16 {"formattedValue": "Founder / CX Lead", "userEnteredValue": {"stringValue": "Founder / CX Lead"}, "effectiveValue": {"stringValue": "Founder / CX Lead"}}
SYS_16_OPERATOR_APPENDICES_OS!H16 {"formattedValue": "First win is measurable\nRetention loops are explicit\nSupport is reduced by design", "userEnteredValue": {"stringValue": "First win is measurable\nRetention loops are explicit\nSupport is reduced by design"}, "effectiveValue": {"stringValue": "First win is measurable\nRetention loops are explicit\nSupport is reduced by design"}}
SYS_16_OPERATOR_APPENDICES_OS!I16 {"formattedValue": "Retention is the profit engine.", "userEnteredValue": {"stringValue": "Retention is the profit engine."}, "effectiveValue": {"stringValue": "Retention is the profit engine."}}
SYS_16_OPERATOR_APPENDICES_OS!J16 {"formattedValue": "https://docs.google.com/document/d/1wuRpYPsRW2NeBor8j_F-2AJB6X3zTciOhhiaxev2Jrc/edit?usp=drivesdk", "userEnteredValue": {"stringValue": "https://docs.google.com/document/d/1wuRpYPsRW2NeBor8j_F-2AJB6X3zTciOhhiaxev2Jrc/edit?usp=drivesdk"}, "effectiveValue": {"stringValue": "https://docs.google.com/document/d/1wuRpYPsRW2NeBor8j_F-2AJB6X3zTciOhhiaxev2Jrc/edit?usp=drivesdk"}, "hyperlink": "https://docs.google.com/document/d/1wuRpYPsRW2NeBor8j_F-2AJB6X3zTciOhhiaxev2Jrc/edit?usp=drivesdk"}
MASTER_INDEX!A1 {"formattedValue": "Operator ID", "userEnteredValue": {"stringValue": "Operator ID"}, "effectiveValue": {"stringValue": "Operator ID"}}
MASTER_INDEX!B1 {"formattedValue": "Operator Name (RISER / rocket-style)", "userEnteredValue": {"stringValue": "Operator Name (RISER / rocket-style)"}, "effectiveValue": {"stringValue": "Operator Name (RISER / rocket-style)"}}
MASTER_INDEX!C1 {"formattedValue": "One-Line Purpose", "userEnteredValue": {"stringValue": "One-Line Purpose"}, "effectiveValue": {"stringValue": "One-Line Purpose"}}
MASTER_INDEX!D1 {"formattedValue": "Operator Doc (link)", "userEnteredValue": {"stringValue": "Operator Doc (link)"}, "effectiveValue": {"stringValue": "Operator Doc (link)"}}
MASTER_INDEX!A2 {"formattedValue": "OP-01", "userEnteredValue": {"stringValue": "OP-01"}, "effectiveValue": {"stringValue": "OP-01"}}
MASTER_INDEX!B2 {"formattedValue": "Ignition Signal Router", "userEnteredValue": {"stringValue": "Ignition Signal Router"}, "effectiveValue": {"stringValue": "Ignition Signal Router"}}
MASTER_INDEX!C2 {"formattedValue": "Routes incoming signals to the correct RISER operator so nothing important gets skipped or built out of order.", "userEnteredValue": {"stringValue": "Routes incoming signals to the correct RISER operator so nothing important gets skipped or built out of order."}, "effectiveValue": {"stringValue": "Routes incoming signals to the correct RISER operator so nothing important gets skipped or built out of order."}}
MASTER_INDEX!D2 {"formattedValue": "Open OP-01", "userEnteredValue": {"formulaValue": "=HYPERLINK(\"https://docs.google.com/document/d/1vmUOruvxS_CblhFkF5V-bs1vIoyMBFlc-BwnjY-ItMA/edit?usp=drivesdk\",\"Open OP-01\")"}, "effectiveValue": {"stringValue": "Open OP-01"}, "hyperlink": "https://docs.google.com/document/d/1vmUOruvxS_CblhFkF5V-bs1vIoyMBFlc-BwnjY-ItMA/edit?usp=drivesdk"}
MASTER_INDEX!A3 {"formattedValue": "OP-02", "userEnteredValue": {"stringValue": "OP-02"}, "effectiveValue": {"stringValue": "OP-02"}}
MASTER_INDEX!B3 {"formattedValue": "Avatar Signal Extractor", "userEnteredValue": {"stringValue": "Avatar Signal Extractor"}, "effectiveValue": {"stringValue": "Avatar Signal Extractor"}}
MASTER_INDEX!C3 {"formattedValue": "Extracts the real avatar (lived tension + belief state) from comments, winners, objections, and behavior—without guessing demographics first.", "userEnteredValue": {"stringValue": "Extracts the real avatar (lived tension + belief state) from comments, winners, objections, and behavior—without guessing demographics first."}, "effectiveValue": {"stringValue": "Extracts the real avatar (lived tension + belief state) from comments, winners, objections, and behavior—without guessing demographics first."}}
MASTER_INDEX!D3 {"formattedValue": "Open OP-02", "userEnteredValue": {"formulaValue": "=HYPERLINK(\"https://docs.google.com/document/d/176YaGGZ1QgKvBJYUZiyvq0OJV_62NnMb-jNqvctOnEE/edit?usp=drivesdk\",\"Open OP-02\")"}, "effectiveValue": {"stringValue": "Open OP-02"}, "hyperlink": "https://docs.google.com/document/d/176YaGGZ1QgKvBJYUZiyvq0OJV_62NnMb-jNqvctOnEE/edit?usp=drivesdk"}
MASTER_INDEX!A4 {"formattedValue": "OP-03", "userEnteredValue": {"stringValue": "OP-03"}, "effectiveValue": {"stringValue": "OP-03"}}
MASTER_INDEX!B4 {"formattedValue": "Trajectory Niche Viability Engine", "userEnteredValue": {"stringValue": "Trajectory Niche Viability Engine"}, "effectiveValue": {"stringValue": "Trajectory Niche Viability Engine"}}
MASTER_INDEX!C4 {"formattedValue": "Selects the niche strategically (Blue Ocean + enemy choice) using signal strength, capacity, economics, and differentiation—then locks the game you’re playing.", "userEnteredValue": {"stringValue": "Selects the niche strategically (Blue Ocean + enemy choice) using signal strength, capacity, economics, and differentiation—then locks the game you’re playing."}, "effectiveValue": {"stringValue": "Selects the niche strategically (Blue Ocean + enemy choice) using signal strength, capacity, economics, and differentiation—then locks the game you’re playing."}}
MASTER_INDEX!D4 {"formattedValue": "Open OP-03", "userEnteredValue": {"formulaValue": "=HYPERLINK(\"https://docs.google.com/document/d/1cKhPWb0HraJiSnqX5MdO_XTHp1nP_jdj6J-E1aqUrjg/edit?usp=drivesdk\",\"Open OP-03\")"}, "effectiveValue": {"stringValue": "Open OP-03"}, "hyperlink": "https://docs.google.com/document/d/1cKhPWb0HraJiSnqX5MdO_XTHp1nP_jdj6J-E1aqUrjg/edit?usp=drivesdk"}
MASTER_INDEX!A5 {"formattedValue": "OP-04", "userEnteredValue": {"stringValue": "OP-04"}, "effectiveValue": {"stringValue": "OP-04"}}
MASTER_INDEX!B5 {"formattedValue": "Offer Lock Engine", "userEnteredValue": {"stringValue": "Offer Lock Engine"}, "effectiveValue": {"stringValue": "Offer Lock Engine"}}
MASTER_INDEX!C5 {"formattedValue": "Builds and freezes the offer promise (mechanism + first win) so marketing has something real to amplify and onboarding can actually deliver outcomes.", "userEnteredValue": {"stringValue": "Builds and freezes the offer promise (mechanism + first win) so marketing has something real to amplify and onboarding can actually deliver outcomes."}, "effectiveValue": {"stringValue": "Builds and freezes the offer promise (mechanism + first win) so marketing has something real to amplify and onboarding can actually deliver outcomes."}}
MASTER_INDEX!D5 {"formattedValue": "Open OP-04", "userEnteredValue": {"formulaValue": "=HYPERLINK(\"https://docs.google.com/document/d/1p4Ordx2poBG_iWeUgWKQ-1B0eQfMcD2EKE1x-PMoMII/edit?usp=drivesdk\",\"Open OP-04\")"}, "effectiveValue": {"stringValue": "Open OP-04"}, "hyperlink": "https://docs.google.com/document/d/1p4Ordx2poBG_iWeUgWKQ-1B0eQfMcD2EKE1x-PMoMII/edit?usp=drivesdk"}
MASTER_INDEX!A6 {"formattedValue": "OP-05", "userEnteredValue": {"stringValue": "OP-05"}, "effectiveValue": {"stringValue": "OP-05"}}
MASTER_INDEX!B6 {"formattedValue": "Economics Truth Enforcer", "userEnteredValue": {"stringValue": "Economics Truth Enforcer"}, "effectiveValue": {"stringValue": "Economics Truth Enforcer"}}
MASTER_INDEX!C6 {"formattedValue": "Forces unit economics truth (AOV/LTV/CAC/payback/margins) and blocks scaling until the math and delivery reality are stable.", "userEnteredValue": {"stringValue": "Forces unit economics truth (AOV/LTV/CAC/payback/margins) and blocks scaling until the math and delivery reality are stable."}, "effectiveValue": {"stringValue": "Forces unit economics truth (AOV/LTV/CAC/payback/margins) and blocks scaling until the math and delivery reality are stable."}}
MASTER_INDEX!D6 {"formattedValue": "Open OP-05", "userEnteredValue": {"formulaValue": "=HYPERLINK(\"https://docs.google.com/document/d/1rG1zK6irOMIDoSTxyeyFiLsd1o0eg6G39uVWaBEXveM/edit?usp=drivesdk\",\"Open OP-05\")"}, "effectiveValue": {"stringValue": "Open OP-05"}, "hyperlink": "https://docs.google.com/document/d/1rG1zK6irOMIDoSTxyeyFiLsd1o0eg6G39uVWaBEXveM/edit?usp=drivesdk"}
MASTER_INDEX!A7 {"formattedValue": "OP-06", "userEnteredValue": {"stringValue": "OP-06"}, "effectiveValue": {"stringValue": "OP-06"}}
MASTER_INDEX!B7 {"formattedValue": "Value Curve Architect", "userEnteredValue": {"stringValue": "Value Curve Architect"}, "effectiveValue": {"stringValue": "Value Curve Architect"}}
MASTER_INDEX!C7 {"formattedValue": "Designs your differentiation so you stop competing on noise and start owning a value curve your rivals can’t copy quickly.", "userEnteredValue": {"stringValue": "Designs your differentiation so you stop competing on noise and start owning a value curve your rivals can’t copy quickly."}, "effectiveValue": {"stringValue": "Designs your differentiation so you stop competing on noise and start owning a value curve your rivals can’t copy quickly."}}
MASTER_INDEX!D7 {"formattedValue": "Open OP-06", "userEnteredValue": {"formulaValue": "=HYPERLINK(\"https://docs.google.com/document/d/1El235b7etWP4jHh_5t710vuBlcYJhYpQietlt7Ohr9s/edit?usp=drivesdk\",\"Open OP-06\")"}, "effectiveValue": {"stringValue": "Open OP-06"}, "hyperlink": "https://docs.google.com/document/d/1El235b7etWP4jHh_5t710vuBlcYJhYpQietlt7Ohr9s/edit?usp=drivesdk"}
MASTER_INDEX!A8 {"formattedValue": "OP-07", "userEnteredValue": {"stringValue": "OP-07"}, "effectiveValue": {"stringValue": "OP-07"}}
MASTER_INDEX!B8 {"formattedValue": "Positioning Vector Engine", "userEnteredValue": {"stringValue": "Positioning Vector Engine"}, "effectiveValue": {"stringValue": "Positioning Vector Engine"}}
MASTER_INDEX!C8 {"formattedValue": "Turns differentiation into a simple, repeatable positioning statement and ‘why you’ logic across funnel and content.", "userEnteredValue": {"stringValue": "Turns differentiation into a simple, repeatable positioning statement and ‘why you’ logic across funnel and content."}, "effectiveValue": {"stringValue": "Turns differentiation into a simple, repeatable positioning statement and ‘why you’ logic across funnel and content."}}
MASTER_INDEX!D8 {"formattedValue": "Open OP-07", "userEnteredValue": {"formulaValue": "=HYPERLINK(\"https://docs.google.com/document/d/1j1ArYBj4pGOykPo0QmVkFMEYEZaDu4SjUj2cZH5E-bc/edit?usp=drivesdk\",\"Open OP-07\")"}, "effectiveValue": {"stringValue": "Open OP-07"}, "hyperlink": "https://docs.google.com/document/d/1j1ArYBj4pGOykPo0QmVkFMEYEZaDu4SjUj2cZH5E-bc/edit?usp=drivesdk"}
MASTER_INDEX!A9 {"formattedValue": "OP-08", "userEnteredValue": {"stringValue": "OP-08"}, "effectiveValue": {"stringValue": "OP-08"}}
MASTER_INDEX!B9 {"formattedValue": "Messaging & Narrative Engine", "userEnteredValue": {"stringValue": "Messaging & Narrative Engine"}, "effectiveValue": {"stringValue": "Messaging & Narrative Engine"}}
MASTER_INDEX!C9 {"formattedValue": "Builds the core story stack: beliefs, reframes, proof, and empathy—so copy, videos, and onboarding all sound like one company.", "userEnteredValue": {"stringValue": "Builds the core story stack: beliefs, reframes, proof, and empathy—so copy, videos, and onboarding all sound like one company."}, "effectiveValue": {"stringValue": "Builds the core story stack: beliefs, reframes, proof, and empathy—so copy, videos, and onboarding all sound like one company."}}
MASTER_INDEX!D9 {"formattedValue": "Open OP-08", "userEnteredValue": {"formulaValue": "=HYPERLINK(\"https://docs.google.com/document/d/1gsCivPvC5-MWvyggVpe69IaxUxA79WVG-igmOfP6IA8/edit?usp=drivesdk\",\"Open OP-08\")"}, "effectiveValue": {"stringValue": "Open OP-08"}, "hyperlink": "https://docs.google.com/document/d/1gsCivPvC5-MWvyggVpe69IaxUxA79WVG-igmOfP6IA8/edit?usp=drivesdk"}
MASTER_INDEX!A10 {"formattedValue": "OP-09", "userEnteredValue": {"stringValue": "OP-09"}, "effectiveValue": {"stringValue": "OP-09"}}
MASTER_INDEX!B10 {"formattedValue": "Offer Framing Engine", "userEnteredValue": {"stringValue": "Offer Framing Engine"}, "effectiveValue": {"stringValue": "Offer Framing Engine"}}
MASTER_INDEX!C10 {"formattedValue": "Frames the offer so it feels safe, specific, and inevitable—without pressure—by matching the promise to the belief stage and proof depth.", "userEnteredValue": {"stringValue": "Frames the offer so it feels safe, specific, and inevitable—without pressure—by matching the promise to the belief stage and proof depth."}, "effectiveValue": {"stringValue": "Frames the offer so it feels safe, specific, and inevitable—without pressure—by matching the promise to the belief stage and proof depth."}}
MASTER_INDEX!D10 {"formattedValue": "Open OP-09", "userEnteredValue": {"formulaValue": "=HYPERLINK(\"https://docs.google.com/document/d/1VV99-iQPeBNY8k9Tk0_S_CX5cI1FrgVtq7okWpPDpCk/edit?usp=drivesdk\",\"Open OP-09\")"}, "effectiveValue": {"stringValue": "Open OP-09"}, "hyperlink": "https://docs.google.com/document/d/1VV99-iQPeBNY8k9Tk0_S_CX5cI1FrgVtq7okWpPDpCk/edit?usp=drivesdk"}
MASTER_INDEX!A11 {"formattedValue": "OP-10", "userEnteredValue": {"stringValue": "OP-10"}, "effectiveValue": {"stringValue": "OP-10"}}
MASTER_INDEX!B11 {"formattedValue": "Hook Systems Architect", "userEnteredValue": {"stringValue": "Hook Systems Architect"}, "effectiveValue": {"stringValue": "Hook Systems Architect"}}
MASTER_INDEX!C11 {"formattedValue": "Builds a hook library + test discipline so you can win attention repeatedly (not randomly) and feed the flywheel with compounding winners.", "userEnteredValue": {"stringValue": "Builds a hook library + test discipline so you can win attention repeatedly (not randomly) and feed the flywheel with compounding winners."}, "effectiveValue": {"stringValue": "Builds a hook library + test discipline so you can win attention repeatedly (not randomly) and feed the flywheel with compounding winners."}}
MASTER_INDEX!D11 {"formattedValue": "Open OP-10", "userEnteredValue": {"formulaValue": "=HYPERLINK(\"https://docs.google.com/document/d/1qRlp-8U8sctqg_qQRa8_8zk2INP9Cs-CuJOE91tepYo/edit?usp=drivesdk\",\"Open OP-10\")"}, "effectiveValue": {"stringValue": "Open OP-10"}, "hyperlink": "https://docs.google.com/document/d/1qRlp-8U8sctqg_qQRa8_8zk2INP9Cs-CuJOE91tepYo/edit?usp=drivesdk"}
MASTER_INDEX!A12 {"formattedValue": "OP-11", "userEnteredValue": {"stringValue": "OP-11"}, "effectiveValue": {"stringValue": "OP-11"}}
MASTER_INDEX!B12 {"formattedValue": "Funnel Architecture Engine", "userEnteredValue": {"stringValue": "Funnel Architecture Engine"}, "effectiveValue": {"stringValue": "Funnel Architecture Engine"}}
MASTER_INDEX!C12 {"formattedValue": "Designs the funnel sequence as a dependency chain (one decision per step) tied to onboarding and first win—so it converts and doesn’t create support chaos.", "userEnteredValue": {"stringValue": "Designs the funnel sequence as a dependency chain (one decision per step) tied to onboarding and first win—so it converts and doesn’t create support chaos."}, "effectiveValue": {"stringValue": "Designs the funnel sequence as a dependency chain (one decision per step) tied to onboarding and first win—so it converts and doesn’t create support chaos."}}
MASTER_INDEX!D12 {"formattedValue": "Open OP-11", "userEnteredValue": {"formulaValue": "=HYPERLINK(\"https://docs.google.com/document/d/1CbSex5XGDn9QdTXLXRaK83xPOqBoChZFyAOdIqpovlo/edit?usp=drivesdk\",\"Open OP-11\")"}, "effectiveValue": {"stringValue": "Open OP-11"}, "hyperlink": "https://docs.google.com/document/d/1CbSex5XGDn9QdTXLXRaK83xPOqBoChZFyAOdIqpovlo/edit?usp=drivesdk"}
MASTER_INDEX!A13 {"formattedValue": "OP-12", "userEnteredValue": {"stringValue": "OP-12"}, "effectiveValue": {"stringValue": "OP-12"}}
MASTER_INDEX!B13 {"formattedValue": "Traffic Authorization Gate", "userEnteredValue": {"stringValue": "Traffic Authorization Gate"}, "effectiveValue": {"stringValue": "Traffic Authorization Gate"}}
MASTER_INDEX!C13 {"formattedValue": "Prevents premature traffic. Approves channels only when offer + economics + delivery stability are green.", "userEnteredValue": {"stringValue": "Prevents premature traffic. Approves channels only when offer + economics + delivery stability are green."}, "effectiveValue": {"stringValue": "Prevents premature traffic. Approves channels only when offer + economics + delivery stability are green."}}
MASTER_INDEX!D13 {"formattedValue": "Open OP-12", "userEnteredValue": {"formulaValue": "=HYPERLINK(\"https://docs.google.com/document/d/1htqyXPo44MmK5E7TYQDFAQarJAFq6uxzbWBvzDOYjDQ/edit?usp=drivesdk\",\"Open OP-12\")"}, "effectiveValue": {"stringValue": "Open OP-12"}, "hyperlink": "https://docs.google.com/document/d/1htqyXPo44MmK5E7TYQDFAQarJAFq6uxzbWBvzDOYjDQ/edit?usp=drivesdk"}
MASTER_INDEX!A14 {"formattedValue": "OP-13", "userEnteredValue": {"stringValue": "OP-13"}, "effectiveValue": {"stringValue": "OP-13"}}
MASTER_INDEX!B14 {"formattedValue": "Paid Ads Integrity Operator", "userEnteredValue": {"stringValue": "Paid Ads Integrity Operator"}, "effectiveValue": {"stringValue": "Paid Ads Integrity Operator"}}
MASTER_INDEX!C14 {"formattedValue": "Runs the paid ads OS: testing discipline, fatigue diagnosis, CTR/CVR fixes, and integrity rules so you don’t buy garbage data.", "userEnteredValue": {"stringValue": "Runs the paid ads OS: testing discipline, fatigue diagnosis, CTR/CVR fixes, and integrity rules so you don’t buy garbage data."}, "effectiveValue": {"stringValue": "Runs the paid ads OS: testing discipline, fatigue diagnosis, CTR/CVR fixes, and integrity rules so you don’t buy garbage data."}}
MASTER_INDEX!D14 {"formattedValue": "Open OP-13", "userEnteredValue": {"formulaValue": "=HYPERLINK(\"https://docs.google.com/document/d/1TNS8yNWH_07T-QPjxJXB3IndqWR3lcfPYt1QgionQ5w/edit?usp=drivesdk\",\"Open OP-13\")"}, "effectiveValue": {"stringValue": "Open OP-13"}, "hyperlink": "https://docs.google.com/document/d/1TNS8yNWH_07T-QPjxJXB3IndqWR3lcfPYt1QgionQ5w/edit?usp=drivesdk"}
MASTER_INDEX!A15 {"formattedValue": "OP-14", "userEnteredValue": {"stringValue": "OP-14"}, "effectiveValue": {"stringValue": "OP-14"}}
MASTER_INDEX!B15 {"formattedValue": "YouTube Authority Engine", "userEnteredValue": {"stringValue": "YouTube Authority Engine"}, "effectiveValue": {"stringValue": "YouTube Authority Engine"}}
MASTER_INDEX!C15 {"formattedValue": "Builds authority and compounding discovery through packaging + retention architecture (title/thumbnail/first 15 seconds + series strategy).", "userEnteredValue": {"stringValue": "Builds authority and compounding discovery through packaging + retention architecture (title/thumbnail/first 15 seconds + series strategy)."}, "effectiveValue": {"stringValue": "Builds authority and compounding discovery through packaging + retention architecture (title/thumbnail/first 15 seconds + series strategy)."}}
MASTER_INDEX!D15 {"formattedValue": "Open OP-14", "userEnteredValue": {"formulaValue": "=HYPERLINK(\"https://docs.google.com/document/d/1tvWxk0lY_uuWn8KQkoDuWWwHopzv0NvUcMl0nfcQD08/edit?usp=drivesdk\",\"Open OP-14\")"}, "effectiveValue": {"stringValue": "Open OP-14"}, "hyperlink": "https://docs.google.com/document/d/1tvWxk0lY_uuWn8KQkoDuWWwHopzv0NvUcMl0nfcQD08/edit?usp=drivesdk"}
MASTER_INDEX!A16 {"formattedValue": "OP-15", "userEnteredValue": {"stringValue": "OP-15"}, "effectiveValue": {"stringValue": "OP-15"}}
MASTER_INDEX!B16 {"formattedValue": "Retention & LTV Engine", "userEnteredValue": {"stringValue": "Retention & LTV Engine"}, "effectiveValue": {"stringValue": "Retention & LTV Engine"}}
MASTER_INDEX!C16 {"formattedValue": "Creates continuity loops (onboarding, support reduction, community tie-in, upsells) to raise LTV and reduce churn/refunds.", "userEnteredValue": {"stringValue": "Creates continuity loops (onboarding, support reduction, community tie-in, upsells) to raise LTV and reduce churn/refunds."}, "effectiveValue": {"stringValue": "Creates continuity loops (onboarding, support reduction, community tie-in, upsells) to raise LTV and reduce churn/refunds."}}
MASTER_INDEX!D16 {"formattedValue": "Open OP-15", "userEnteredValue": {"formulaValue": "=HYPERLINK(\"https://docs.google.com/document/d/1wuRpYPsRW2NeBor8j_F-2AJB6X3zTciOhhiaxev2Jrc/edit?usp=drivesdk\",\"Open OP-15\")"}, "effectiveValue": {"stringValue": "Open OP-15"}, "hyperlink": "https://docs.google.com/document/d/1wuRpYPsRW2NeBor8j_F-2AJB6X3zTciOhhiaxev2Jrc/edit?usp=drivesdk"}

RISER-Bonus-Discipline-Audit-SOP.docx

Audit relevance before counting bonuses

A bonus earns its place by solving a specific obstacle between purchase and the core outcome. Filler accumulation adds unused volume; clarity collapse obscures the promise even when individual items have merit. Use buyer evidence, not sunk production cost. The memory test is an initial prompt, not proof an unremembered bonus is worthless. Read the offer to five fresh, relevant testers before and after changes. A five-person result is a small qualitative check, not a statistically validated conversion prediction.

Resolve the scoring versions before issuing a verdict

The narrative rubric defines only scores 1, 3 and 5; the final scorecard defines all five levels differently. Narrative D2 awards 5 at utility 7+, while the scorecard awards 4 at 7–7.9 and 5 at 8+. Narrative D3 awards 1 below 30% and 5 at 50%+, while the scorecard uses 1 below 20%, 2 at 20–29%, 4 at 50–64% and 5 at 65%+. D1 descriptors also differ. Choose and record one approved version; preserve both originals. Missing utility evidence is not proof of low utility. With five minimum-one scores, the attainable total is 5–25, even though Cut is labeled 0–9.

Apply overrides and deadlines explicitly

The source totals Keep 18–25, Reform 10–17 and Cut 0–9. D1=1 forces Cut; D2 and D3 both 1 prevent Keep but do not decide between Reform and Cut. Its narrative says Reform requires D1 at least 3, leaving D1=2 in the five-level version unresolved. Specify precedence and an accountable decision for ambiguous cases. Reform is due before the next cohort or within sixty days, with no repeat cycle; another section permits ninety days for a first scheduled maintenance update. Keep’s six-month recheck conflicts with the all-active-stacks quarterly cadence. Reconcile these dates before assigning work.

Use clarity thresholds and valuation as source policies

The opening test calls fewer than two correct answers collapse, while the table calls two or fewer collapse. Five testers produce twenty-percentage-point increments; the three-person pre-entry check is a different sample. Record counts and definitions. Bonus-count ceilings, price bands, stated-value multiples and perceived-value ranges below are RISER heuristics, not validated industry laws. Never inflate a valuation to reach a 5–10× target, portray cost savings as a real standalone selling price, or assert a market comparison without evidence. The $300-to-$297 example uses a marketing price point, not a mathematically defined nearest-$47 rounding rule.

Protect existing buyers when changing the stack

The nine-step cut process records the decision, checks entitlements, versions the change, contacts specifically affected buyers, updates the page and emails, archives the deliverable, considers unbundling and updates the offer scorecard. Its ninety-day minimum is a source policy, not permission to withdraw longer promised access. Verify actual purchase terms before any change. No buyer access, emails or published offer terms are changed by this lesson. A 100-visitors-per-arm test and a twenty-percent observed conversion drop do not automatically establish a reliable causal effect; define baseline, sample uncertainty, relative versus absolute change and a stopping rule.

Source worksheet 1

Work through this source worksheet in order. The Hormozi Standard The Thud Factor works when bonuses are coherent. It fails when bonuses are filler. 'All of THAT for this price?' is the reaction you're engineering. But if the buyer cannot figure out what the core offer actually IS because the stack is so large and so varied, the Thud Factor backfires into the Confusion Factor — and confusion kills more sales than scarcity ever creates. Record actual evidence and applicable definitions; source targets and examples do not establish a completed result.

Source worksheet 2

Work through this source worksheet in order. The Kennedy Warning More is not always more. A stack of twelve bonuses, half of which are recycled PDFs with no specific connection to the core promise, is worth less than a stack of three bonuses where each one solves a problem the buyer was afraid they'd face on the way to the result. The discipline is not in the counting. It is in the relevance. Record actual evidence and applicable definitions; source targets and examples do not establish a completed result.

Source worksheet 3

Work through this source worksheet in order. The MVO Playbook Rule — Made Operational Your own MVO Playbook V5 states it directly: 'The Thud Factor fails when bonuses are filler that dilutes clarity. If the prospect can't figure out what the CORE offer actually IS, conversions drop. Every bonus must clearly solve a specific sub-problem. Confusion kills more sales than scarcity creates.' This SOP is the operational system that enforces that rule on every active offer, on a repeating quarterly schedule. Record actual evidence and applicable definitions; source targets and examples do not establish a completed result.

Worksheet 4, item 1 — Filler Accumulation

Apply this source entry using the definitions and corrections in this lesson. Failure Mode: Filler Accumulation Description: The stack grows over time as bonuses are added reactively — to match a competitor, respond to a poor conversion week, or fill perceived value gaps — without each new bonus being held to the sub-problem test. The stack becomes wide but shallow: many bonuses, none of which solve a specific problem that buyers were actually encountering. Symptoms: High stack volume but low buyer utility scores in exit surveys. Support tickets asking 'What do I do with [bonus X]?' Bonuses being listed on the sales page but never accessed in the course platform. Buyers in exit interviews unable to name more than 2–3 of the listed bonuses. Common Cause: Bonus additions happen without a defined standard. New bonuses are added in response to external pressure (competitor, conversion drop) without internal qualification criteria. No removal process exists — every bonus added is permanent by default. Remediation: Bonus Discipline Audit — Cut phase. Remove all bonuses scoring below the sub-problem threshold. Each removal increases the clarity of the bonuses that remain. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 4, item 2 — Clarity Collapse

Apply this source entry using the definitions and corrections in this lesson. Failure Mode: Clarity Collapse Description: The stack is technically coherent — each bonus solves a real sub-problem — but there are too many of them. The buyer cannot identify the core promise because the stack has grown to eclipse it. The bonuses outnumber the core deliverables. The sales page looks like a product catalog rather than a transformation offer. Symptoms: Core promise buried in the stack slide. Buyers cite bonuses as the reason for purchase more than the core transformation. Testimonials reference bonus value rather than programme outcome. The 'Flagship Promise Test' fails — buyers cannot repeat the core promise in one sentence because the stack has obscured it. Common Cause: Gradual accumulation without a maximum stack discipline rule. Success of individual bonuses leads to 'more is better' thinking without recognising the clarity cost. Remediation: Apply the Flagship Promise Test and the Stack Maximum Rule (see Phase 2). Retire excess bonuses to an 'available as upgrades' position rather than deleting them entirely. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Source worksheet 5

Work through this source worksheet in order. The Sub-Problem Test — The One Rule That Governs All Bonus Decisions Every bonus must solve a specific, named sub-problem that a buyer will encounter on the path between purchasing the offer and achieving the core promise. A sub-problem is specific enough that you can describe it in one sentence beginning with 'The buyer is struggling with...' or 'Without this, the buyer will get stuck at...' A bonus that cannot be described this way is either: (1) a vanity addition that adds visual stack weight without solving a real problem, or (2) a solution to a problem that does not actually exist on the path to the core promise, or (3) a bonus that duplicates what the core offer already solves. All three categories fail the test. All three must be cut or reformed. Record actual evidence and applicable definitions; source targets and examples do not establish a completed result.

Worksheet 6, item 1 — Valid Sub-Problem

Apply this source entry using the definitions and corrections in this lesson. Category: Valid Sub-Problem Definition: A specific obstacle, skill gap, or implementation challenge that arises after the buyer commits to the transformation but before they complete it. It is distinct from the core promise — solving it gets them closer to the main result but is not the main result itself. Examples That Pass: 'Without knowing which platform to post on first, the buyer will waste 3 weeks testing instead of gaining traction.' (Bonus: Platform Priority Map) 'The buyer will need to write cold outreach but has no templates — every email will take 45 minutes.' (Bonus: 30-Day DM Outreach Swipe File) Examples That Fail: 'More content about the topic.' (Not a sub-problem — it is volume, not gap-filling) 'A community where they can ask questions.' (Community is a support structure, not a sub-problem solution — unless access to expert peers IS the specific bottleneck) Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 6, item 2 — Invalid: Cosmetic Value

Apply this source entry using the definitions and corrections in this lesson. Category: Invalid: Cosmetic Value Definition: An addition that makes the stack look bigger or more impressive without solving a problem. Often a PDF workbook, a resource list, or an audio recording that has no clear connection to a specific buyer obstacle. Examples That Pass: N/A Examples That Fail: 'The Ultimate Resource Guide' — a 40-page PDF of tools and links with no specific application to any sub-problem. 'Bonus Training: Success Mindset' — motivational content with no sub-problem connection. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 6, item 3 — Invalid: Duplicate Solving

Apply this source entry using the definitions and corrections in this lesson. Category: Invalid: Duplicate Solving Definition: A bonus that solves the same problem the core offer already solves. It reinforces the core rather than bridging a gap. Buyers who have the core do not need an additional solution to the same problem. Examples That Pass: N/A Examples That Fail: Adding an 'offer construction checklist' bonus to an offer whose core promise IS offer construction. The bonus duplicates the core. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 6, item 4 — Invalid: Wrong-Path Problem

Apply this source entry using the definitions and corrections in this lesson. Category: Invalid: Wrong-Path Problem Definition: A bonus that solves a real problem — but a problem that arises AFTER the buyer has already achieved the core promise. Premature ascension material presented as a bonus. Examples That Pass: N/A Examples That Fail: Adding a 'paid traffic scaling playbook' bonus to an offer whose core promise is validating a first offer organically. The buyer doesn't have the problem yet. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Source worksheet 7

Work through this source worksheet in order. PHASE 1 The Bonus Inventory Documenting every bonus in every active stack before any evaluation begins Record actual evidence and applicable definitions; source targets and examples do not establish a completed result.

Source worksheet 8

Work through this source worksheet in order. The Memory Test Before opening the sales page: write down every bonus currently in your most important offer's stack from memory. Then open the sales page. Any bonus you could not remember is a candidate for the Cut pile — if it does not stick in your own memory, it is unlikely to register in the buyer's mind either. Record actual evidence and applicable definitions; source targets and examples do not establish a completed result.

Worksheet 9, item 1 — Bonus ID

Apply this source entry using the definitions and corrections in this lesson. Field: Bonus ID What to Document: A unique code: [Offer Code]-B[Sequence]. e.g. MVO-B03 Example: MVO-B03 Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 9, item 2 — Bonus Name (as stated on sales page)

Apply this source entry using the definitions and corrections in this lesson. Field: Bonus Name (as stated on sales page) What to Document: Exact name as it appears in the stack slide — not a description. Example: The 30-Day DM Outreach Playbook Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 9, item 3 — Bonus Format

Apply this source entry using the definitions and corrections in this lesson. Field: Bonus Format What to Document: The physical form of the deliverable. Example: Template pack (14 DM scripts + 3 follow-up frameworks, PDF) Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 9, item 4 — Date Added to Stack

Apply this source entry using the definitions and corrections in this lesson. Field: Date Added to Stack What to Document: When was this bonus first included in this offer? Example: Added at V1.2.0 (2025-09-10 per Changelog) Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 9, item 5 — Stated Standalone Value

Apply this source entry using the definitions and corrections in this lesson. Field: Stated Standalone Value What to Document: The dollar value assigned to this bonus on the sales page. Example: $197 Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 9, item 6 — Sub-Problem It Claims to Solve

Apply this source entry using the definitions and corrections in this lesson. Field: Sub-Problem It Claims to Solve What to Document: In one sentence: 'The buyer is struggling with ___.' Fill this in from your own knowledge — before looking at the sales page copy for clues. Example: 'The buyer needs to send outreach messages but has no proven templates, so they spend 45 minutes per message and get inconsistent results.' Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 9, item 7 — Evidence That This Sub-Problem Is Real

Apply this source entry using the definitions and corrections in this lesson. Field: Evidence That This Sub-Problem Is Real What to Document: Specific data: buyer support tickets, exit interview phrases, Objection Bank entries, community posts that confirm this specific problem is encountered on the path to the core promise. Example: Exit interview Q3 (5 of 12 respondents): 'I struggled with what to say in outreach.' Support tickets tagged 'outreach help': 6 in last 30 days. Objection Bank entry OBJ-MVO-019: 'I don't know what to say in DMs.' Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 9, item 8 — Buyer Utility Score (if available)

Apply this source entry using the definitions and corrections in this lesson. Field: Buyer Utility Score (if available) What to Document: Exit interview or pulse survey data: how useful did buyers rate this specific bonus? Scale 1–10. Example: 7.4/10 average from last cohort exit survey Q: 'Rate the usefulness of each component.' Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 9, item 9 — Access Rate

Apply this source entry using the definitions and corrections in this lesson. Field: Access Rate What to Document: Of buyers who purchased, what % actually accessed this bonus in the course platform? (Kajabi analytics) Example: 61% accessed — above the 50% threshold. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 9, item 10 — Delivery Cost to Creator

Apply this source entry using the definitions and corrections in this lesson. Field: Delivery Cost to Creator What to Document: Time to maintain, update, or deliver this bonus. Is it evergreen or does it require periodic refresh? Example: Evergreen — templates require refresh every 12 months to reflect platform changes. ~2 hours annually. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Source worksheet 10

Work through this source worksheet in order. PHASE 2 The Five-Dimension Scoring System Evaluating every bonus against an objective standard before rendering a verdict Record actual evidence and applicable definitions; source targets and examples do not establish a completed result.

Worksheet 11, item 1 — D1 — Sub-Problem Specificity

Apply this source entry using the definitions and corrections in this lesson. Dimension: D1 — Sub-Problem Specificity What It Measures: Does this bonus solve a specific, named sub-problem on the path to the core promise? Score 1: No named sub-problem. Adds value generally but cannot be described as solving a specific obstacle. Score 3: A sub-problem exists but is vague, broad, or only loosely connected to the path to the core promise. Score 5: Clear, specific sub-problem stated in one sentence. Problem is confirmed by buyer data (support tickets, exit interviews, or Objection Bank entries). Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 11, item 2 — D2 — Buyer Utility Score

Apply this source entry using the definitions and corrections in this lesson. Dimension: D2 — Buyer Utility Score What It Measures: How useful do buyers find this bonus in practice? Score 1: Score below 5.0 from exit survey or pulse survey. Or no data available — has never been measured. Score 3: Score 5.0–6.9. Adequate but not compelling. Many buyers find it useful; some find it irrelevant. Score 5: Score 7.0+. Consistently rated as highly useful by buyers who access it. Frequently cited in exit interviews as a purchase driver. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 11, item 3 — D3 — Access Rate

Apply this source entry using the definitions and corrections in this lesson. Dimension: D3 — Access Rate What It Measures: What percentage of buyers actually access this bonus? Score 1: Below 30% access rate. Most buyers who purchased never use this bonus. Score 3: 30–49% access rate. About a third to half of buyers engage with it. Score 5: 50%+ access rate. More than half of buyers access and use this bonus. Strong signal of perceived relevance. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 11, item 4 — D4 — Promise Coherence

Apply this source entry using the definitions and corrections in this lesson. Dimension: D4 — Promise Coherence What It Measures: Is this bonus clearly connected to the core promise — not competing with it, not duplicating it? Score 1: This bonus describes an outcome similar to the core promise itself, creating confusion about what the core offer does. OR it solves a problem that arises after the core promise is achieved. Score 3: This bonus is adjacent to the core promise but the connection is not obvious without explanation. Buyers may not understand why it is included. Score 5: This bonus is clearly a supporting solution that helps buyers achieve the core promise. Its connection to the core outcome is immediately obvious without explanation. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 11, item 5 — D5 — Delivery Sustainability

Apply this source entry using the definitions and corrections in this lesson. Dimension: D5 — Delivery Sustainability What It Measures: Can this bonus continue to be delivered at the stated quality indefinitely without disproportionate maintenance cost? Score 1: High maintenance cost with no sustainable update process. OR the bonus references tools, platforms, or information that have already become outdated. Score 3: Moderate maintenance cost. Requires annual update. No dedicated process exists but updates are manageable. Score 5: Low maintenance cost. Evergreen content requiring minimal updates. OR a systematic update process exists that is already documented. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Source worksheet 12

Work through this source worksheet in order. KEEP Total score 18–25 — Bonus is earning its place in the stack This bonus solves a real sub-problem, buyers find it useful and actually access it, it is coherent with the core promise, and it is deliverable sustainably. It stays in the stack. Update the Airtable record with current scores. Schedule next audit in 6 months. Record actual evidence and applicable definitions; source targets and examples do not establish a completed result.

Source worksheet 13

Work through this source worksheet in order. REFORM Total score 10–17 — Bonus has merit but a specific weakness to fix This bonus has real value but is underperforming on one or more dimensions. It is not cut — it is improved. The specific dimensions scoring below 3 identify exactly what the reform should address. Reform must be completed before the next cohort or within 60 days. If reform is not completed by the deadline, the verdict is automatically changed to Cut. Record actual evidence and applicable definitions; source targets and examples do not establish a completed result.

Source worksheet 14

Work through this source worksheet in order. CUT Total score 0–9 — Bonus is failing the discipline standard This bonus does not solve a named sub-problem (or solves the wrong one), is not used by most buyers, and is likely contributing to Clarity Collapse in the stack. It is removed from the stack. Existing buyers retain access for 90 days per the Entitlement Policy (Product Versioning SOP). The sales page is updated within 14 days. See Phase 5 for the Cut Execution Protocol. Record actual evidence and applicable definitions; source targets and examples do not establish a completed result.

Source worksheet 15

Work through this source worksheet in order. Automatic Cut Rule — D1 Score of 1 Any bonus scoring 1 on Dimension D1 (Sub-Problem Specificity) is automatically cut regardless of its total score. A bonus that does not solve a named sub-problem has no legitimate place in a disciplined stack — not even if it is beloved by buyers, consistently accessed, and easy to maintain. The discipline starts with the sub-problem test. A bonus that fails it does not belong in the stack. Record actual evidence and applicable definitions; source targets and examples do not establish a completed result.

Source worksheet 16

Work through this source worksheet in order. Automatic Reform Rule — D2+D3 Both Score 1 Any bonus where both Dimension D2 (Buyer Utility Score) AND Dimension D3 (Access Rate) score 1 is automatically set to Reform or Cut, not Keep, regardless of other dimension scores. A bonus that buyers rate as useless AND that most buyers never access is producing negative value — it is contributing to the buyer's perception that the stack is padded, which undermines the credibility of the bonuses that are genuinely useful. Record actual evidence and applicable definitions; source targets and examples do not establish a completed result.

Source worksheet 17

Work through this source worksheet in order. PHASE 3 The Stack Maximum Rule and Clarity Index How many bonuses is the right number — and how to measure stack clarity Record actual evidence and applicable definitions; source targets and examples do not establish a completed result.

Worksheet 18, item 1 — Entry-point / Tripwire ($7–$97)

Apply this source entry using the definitions and corrections in this lesson. Offer Type: Entry-point / Tripwire ($7–$97) Recommended Bonus Count: 1–2 bonuses Maximum Before Clarity Risk: 3 Rationale: At this price point, clarity of the core promise is paramount. More than 3 bonuses at entry-level suggests either Filler Accumulation or that the core offer is not strong enough alone. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 18, item 2 — MVO / Frontend Offer ($97–$497)

Apply this source entry using the definitions and corrections in this lesson. Offer Type: MVO / Frontend Offer ($97–$497) Recommended Bonus Count: 2–4 bonuses Maximum Before Clarity Risk: 5 Rationale: The MVO must have a clear core deliverable that can pass the Flagship Promise Test. 5+ bonuses at this tier is the most common trigger for Clarity Collapse because the buyer has not yet fully committed and is more susceptible to confusion. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 18, item 3 — Core Offer ($497–$4,997)

Apply this source entry using the definitions and corrections in this lesson. Offer Type: Core Offer ($497–$4,997) Recommended Bonus Count: 3–6 bonuses Maximum Before Clarity Risk: 7 Rationale: More complex transformation means more real sub-problems. A 6-bonus stack for a 90-day programme with 4 implementation phases is disciplined if each bonus solves a distinct phase-specific sub-problem. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 18, item 4 — High-Ticket / DWY ($2,500–$25,000)

Apply this source entry using the definitions and corrections in this lesson. Offer Type: High-Ticket / DWY ($2,500–$25,000) Recommended Bonus Count: 1–3 bonuses Maximum Before Clarity Risk: 4 Rationale: At this price point, the stack is less important than the access and proximity being sold. Heavy bonus stacking at high-ticket suggests the operator lacks confidence in the core offer. Buyers at this tier are buying the operator's time and expertise — not template packs. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 18, item 5 — Continuity / MRR ($47–$997/mo)

Apply this source entry using the definitions and corrections in this lesson. Offer Type: Continuity / MRR ($47–$997/mo) Recommended Bonus Count: 0–2 bonuses per renewal cycle Maximum Before Clarity Risk: 3 Rationale: Continuity bonuses are best delivered as monthly value drops — new mechanisms, tools, and templates that justify the recurring payment. They are not a static stack. A fixed continuity bonus stack beyond 3 items signals membership bloat, not membership value. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 19, item 1 — 5/5 (100%)

Apply this source entry using the definitions and corrections in this lesson. Clarity Index: 5/5 (100%) Interpretation: Maximum clarity. The stack is fully disciplined. Every bonus is supporting the core promise without competing with it. Action: Maintain the current stack. Run the Clarity Index again at the next quarterly audit. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 19, item 2 — 4/5 (80%)

Apply this source entry using the definitions and corrections in this lesson. Clarity Index: 4/5 (80%) Interpretation: Good clarity with a minor gap. One tester was distracted by a bonus. Action: Identify which tester cited a bonus outcome rather than the core promise. Which bonus generated that distraction? Review that bonus's D4 (Promise Coherence) score. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 19, item 3 — 3/5 (60%)

Apply this source entry using the definitions and corrections in this lesson. Clarity Index: 3/5 (60%) Interpretation: Clarity is degrading. Two testers are confused about what the offer primarily does. Action: The stack is approaching or has reached Clarity Collapse. At least one bonus needs to be cut or repositioned. Run the Flagship Promise Test on each bonus individually to identify the confuser. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 19, item 4 — 2/5 or below (below 60%)

Apply this source entry using the definitions and corrections in this lesson. Clarity Index: 2/5 or below (below 60%) Interpretation: Clarity Collapse confirmed. The stack is obscuring the core promise. Action: Immediate action required. Apply the Stack Maximum Rule: cut the stack to the recommended maximum for this offer type regardless of individual bonus scores. Retain the highest-scoring bonuses within that maximum. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Source worksheet 20

Work through this source worksheet in order. PHASE 4 The Reform Protocol What to do with a bonus that earns Reform — the exact fixes for each weakness Record actual evidence and applicable definitions; source targets and examples do not establish a completed result.

Source worksheet 21

Work through this source worksheet in order. The Reform Deadline Rule A Reform bonus that has been in Reform status for more than 60 days without a documented completion is automatically Cut at the next monthly review. There is no second Reform cycle. If the fix could not be done in 60 days, the bonus is not a current-version asset — it either needs to be retired or rebuilt as a new bonus for a future version of the offer. Record actual evidence and applicable definitions; source targets and examples do not establish a completed result.

Worksheet 22, item 1 — D1 — Sub-Problem Specificity

Apply this source entry using the definitions and corrections in this lesson. Weak Dimension: D1 — Sub-Problem Specificity Score: Score 3 (vague or broad) Prescribed Reform: Rewrite the sub-problem statement in the one-sentence format: 'The buyer is struggling with [specific obstacle] at [specific stage] of the [specific journey].' Then rewrite the bonus name and description to make the connection to that sub-problem explicit and immediate. Implementation: Update bonus name and description on sales page, Stack Slide, and course platform. Update Airtable record with revised sub-problem statement. Confirm with the next exit interview cohort that the connection is now clear. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 22, item 2 — D2 — Buyer Utility Score

Apply this source entry using the definitions and corrections in this lesson. Weak Dimension: D2 — Buyer Utility Score Score: Score 3 (utility 5.0–6.9) Prescribed Reform: The bonus is mildly useful but not compelling. Two possible fixes: (1) Upgrade the format — if a PDF, convert to a template. If a template, add a worked example. If a recording, add a structured reference guide alongside. (2) Narrow the scope — a broadly useful bonus with a 6.0 score is often a narrowly useful bonus with a 9.0 score hiding inside. Remove the generic elements and focus on the highest-value specific element. Implementation: Test the upgraded format with 3–5 buyers from the current cohort before redeploying. Re-survey for utility score. Target: 7.0+ before returning to active stack. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 22, item 3 — D3 — Access Rate

Apply this source entry using the definitions and corrections in this lesson. Weak Dimension: D3 — Access Rate Score: Score 3 (30–49% access) Prescribed Reform: Low access rate usually has one of three causes: (1) The bonus is buried in the course platform — move it to a more prominent location (Day 1 or within the first module). (2) The bonus is not referenced in the onboarding email sequence — add a specific mention with a direct link. (3) Buyers do not understand when to use it — add a trigger statement: 'Use this when you reach Step 3 of Module 2.' Implementation: Add one-sentence placement instruction to each point where the bonus could be used. Add a direct link to the bonus in the Day 1 onboarding email. Re-measure access rate after the next cohort. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 22, item 4 — D4 — Promise Coherence

Apply this source entry using the definitions and corrections in this lesson. Weak Dimension: D4 — Promise Coherence Score: Score 3 (adjacent but not obvious) Prescribed Reform: The bonus is genuinely related to the core promise but the connection is not clear. Two fixes: (1) Rename the bonus to make the connection explicit. 'The Lead Gen Template Pack' becomes 'The Outreach-to-Booked-Call Template Pack' — now the connection to the call-booking core promise is immediate. (2) Add a one-sentence context statement to the Stack Slide: 'This solves the outreach problem that stops most people at Step 4 of the method.' Implementation: Update bonus name and Stack Slide context statement. Run Flagship Promise Test after the update to confirm Clarity Index has improved. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 22, item 5 — D5 — Delivery Sustainability

Apply this source entry using the definitions and corrections in this lesson. Weak Dimension: D5 — Delivery Sustainability Score: Score 3 (moderate maintenance, annual update needed) Prescribed Reform: Create an update schedule and document it. Add the bonus to the Quarterly Refresh Calendar (first Monday of October or the equivalent in your planning cycle). Assign a specific owner for the annual update. If the bonus references time-sensitive information (platform features, pricing data), add a 'Last updated' date to the deliverable. Implementation: Log in Airtable: update frequency, owner, next update date. Add to the quarterly planning calendar. Deliver the first scheduled update within 90 days of the Reform verdict. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Source worksheet 23

Work through this source worksheet in order. PHASE 5 The Cut Execution Protocol Removing a bonus cleanly — without damaging existing buyer relationships Record actual evidence and applicable definitions; source targets and examples do not establish a completed result.

Worksheet 24, item 1 — 'Buyers mention that bonus as their reason for purchasing.'

Apply this source entry using the definitions and corrections in this lesson. Claim: 'Buyers mention that bonus as their reason for purchasing.' How to Test It: Pull exit interview transcripts. Count how many buyers cite the bonus by name as their primary purchase reason (not just as something they appreciate). Compare to how many cite the core transformation. What the Data Usually Shows: In most cases, buyers who cite a bonus as their purchase reason are buying the sub-problem solution, not the bonus itself. If 8/10 buyers cite the bonus as the reason, the bonus IS the product — and should be promoted to a standalone offer with a proper core promise, not kept as a supporting element. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 24, item 2 — 'Removing it will reduce conversion.'

Apply this source entry using the definitions and corrections in this lesson. Claim: 'Removing it will reduce conversion.' How to Test It: A/B test: run the offer with and without the bonus for 100 visitors each. Measure conversion. If conversion drops 20%+, the bonus was a significant driver and the offer needs a replacement bonus of equivalent strength before the cut is executed. What the Data Usually Shows: Most bonus cuts produce no measurable conversion change when the remaining stack is strong. The fear of conversion loss from cutting a weak bonus is almost always larger than the actual impact. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 24, item 3 — 'It was expensive to create.'

Apply this source entry using the definitions and corrections in this lesson. Claim: 'It was expensive to create.' How to Test It: Sunk cost. The cost of creation is irrelevant to whether the bonus is earning its place in the stack today. What the Data Usually Shows: The cost is already spent. The question is only whether the bonus is producing value relative to its continuation cost (maintenance and confusion tax on the stack). Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Source worksheet 25

Work through this source worksheet in order. PHASE 6 New Bonus Design System Building bonuses that pass the discipline test before they enter the stack Record actual evidence and applicable definitions; source targets and examples do not establish a completed result.

Source worksheet 26

Work through this source worksheet in order. The Pre-Entry Gate Before any new bonus is added to any offer stack: it must have a documented sub-problem statement, a named source of evidence that the sub-problem exists (Objection Bank entry, exit interview data, or buyer support ticket), a specific format that solves the sub-problem with minimum effort from the buyer, and a preliminary Flagship Promise Test run with 3 avatar-matched individuals confirming that adding it does not reduce the Clarity Index. Record actual evidence and applicable definitions; source targets and examples do not establish a completed result.

Worksheet 27, item 1 — Use when The buyer needs to complete a specific implementation task on the path to the core promise.

Apply this source entry using the definitions and corrections in this lesson. Use when The buyer needs to complete a specific implementation task on the path to the core promise. Without this bonus, they would need to figure it out from scratch, taking significantly longer or making common errors. This bonus pre-solves the task. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 27, item 2 — Best formats Done-for-you template. Swipe file. Fill-in-the-blank system. Pre-built framework the bu

Apply this source entry using the definitions and corrections in this lesson. Best formats Done-for-you template. Swipe file. Fill-in-the-blank system. Pre-built framework the buyer customises. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 27, item 3 — RISER Nation examples 30-Day DM Outreach Playbook (solves: writing outreach from scratch). Sales Pag

Apply this source entry using the definitions and corrections in this lesson. RISER Nation examples 30-Day DM Outreach Playbook (solves: writing outreach from scratch). Sales Page Copy Swipe File (solves: blank-page paralysis on copy). Hook Formula Template (solves: not knowing how to start short-form content). Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 27, item 4 — Naming convention The [Adjective] [Task Name] [Container]: 'The 14-Day Email Welcome Sequence Templa

Apply this source entry using the definitions and corrections in this lesson. Naming convention The [Adjective] [Task Name] [Container]: 'The 14-Day Email Welcome Sequence Template.' 'The Hook Engineering Swipe File.' Name should make the task and the shortcut immediately obvious. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 27, item 5 — Perceived value range $97–$297 (high perceived value because it saves hours of work the buyer would

Apply this source entry using the definitions and corrections in this lesson. Perceived value range $97–$297 (high perceived value because it saves hours of work the buyer would otherwise have to do). Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 28, item 1 — Use when The buyer needs to assess their specific situation before they can execute a step in the co

Apply this source entry using the definitions and corrections in this lesson. Use when The buyer needs to assess their specific situation before they can execute a step in the core programme. Without this bonus, they would guess or use generic advice that may not apply to their context. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 28, item 2 — Best formats Scorecard. Quiz with scored outputs. Diagnostic checklist. Assessment framework with in

Apply this source entry using the definitions and corrections in this lesson. Best formats Scorecard. Quiz with scored outputs. Diagnostic checklist. Assessment framework with interpretation guide. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 28, item 3 — RISER Nation examples The Niche Viability Scorecard (solves: not knowing if a niche is viable before

Apply this source entry using the definitions and corrections in this lesson. RISER Nation examples The Niche Viability Scorecard (solves: not knowing if a niche is viable before building). The Offer Health Quick-Check (solves: not knowing which part of the offer is underperforming). The Avatar Validation Survey Template (solves: building an avatar without buyer validation). Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 28, item 4 — Naming convention The [Subject] [Diagnostic Noun]: 'The Niche Viability Scorecard.' 'The Copy Health

Apply this source entry using the definitions and corrections in this lesson. Naming convention The [Subject] [Diagnostic Noun]: 'The Niche Viability Scorecard.' 'The Copy Health Diagnostic.' 'The Audience Readiness Assessment.' Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 28, item 5 — Perceived value range $47–$197 (valuable because it replaces expensive professional assessment).

Apply this source entry using the definitions and corrections in this lesson. Perceived value range $47–$197 (valuable because it replaces expensive professional assessment). Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 29, item 1 — Use when The buyer faces a decision point during implementation where multiple options exist and cho

Apply this source entry using the definitions and corrections in this lesson. Use when The buyer faces a decision point during implementation where multiple options exist and choosing the wrong one will cost significant time or money. Without this bonus, they would research extensively or guess. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 29, item 2 — Best formats Comparison guide. Decision tree. Vendor/platform evaluation rubric. 'Should I...' flowc

Apply this source entry using the definitions and corrections in this lesson. Best formats Comparison guide. Decision tree. Vendor/platform evaluation rubric. 'Should I...' flowchart. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 29, item 3 — RISER Nation examples The Platform Priority Map (solves: not knowing which platform to prioritise fo

Apply this source entry using the definitions and corrections in this lesson. RISER Nation examples The Platform Priority Map (solves: not knowing which platform to prioritise for content distribution). The Tech Stack Decision Guide for Operators (solves: which tools to use at each stage). The Paid Traffic Platform Selector (solves: which ad platform is right for this offer at this stage). Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 29, item 4 — Naming convention The [Subject] [Decision Noun]: 'The Platform Priority Map.' 'The Tech Stack Select

Apply this source entry using the definitions and corrections in this lesson. Naming convention The [Subject] [Decision Noun]: 'The Platform Priority Map.' 'The Tech Stack Selector.' 'The Traffic Source Decision Tree.' Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 29, item 5 — Perceived value range $47–$197 (perceived value: saves the cost of trying three wrong options first)

Apply this source entry using the definitions and corrections in this lesson. Perceived value range $47–$197 (perceived value: saves the cost of trying three wrong options first). Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 30, item 1 — Use when The buyer needs input, feedback, or perspective from someone with direct experience in thei

Apply this source entry using the definitions and corrections in this lesson. Use when The buyer needs input, feedback, or perspective from someone with direct experience in their specific situation. Without this bonus, they would need to find and pay for that expertise separately — or go without. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 30, item 2 — Best formats Group Q&A call. Hot seat recording. Live review session. Expert office hours. Panel of

Apply this source entry using the definitions and corrections in this lesson. Best formats Group Q&A call. Hot seat recording. Live review session. Expert office hours. Panel of practitioners. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 30, item 3 — RISER Nation examples Live Implementation Workshop (solves: getting stuck mid-programme without expe

Apply this source entry using the definitions and corrections in this lesson. RISER Nation examples Live Implementation Workshop (solves: getting stuck mid-programme without expert guidance). Offer Teardown Hot Seat Recording (solves: not knowing if the offer design is sound). Sales Call Practice Session (solves: lack of confidence on live calls before the first real ones). Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 30, item 4 — Naming convention The [Expert Activity] [Container]: 'The Live Implementation Workshop.' 'The Offer

Apply this source entry using the definitions and corrections in this lesson. Naming convention The [Expert Activity] [Container]: 'The Live Implementation Workshop.' 'The Offer Teardown Session.' Avoid vague names like 'Expert Coaching Call' — name the specific expert activity. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 30, item 5 — Perceived value range $197–$497 (high perceived value because expert access is the most expensive it

Apply this source entry using the definitions and corrections in this lesson. Perceived value range $197–$497 (high perceived value because expert access is the most expensive item in any knowledge business). Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 31, item 1 — Use when The buyer needs credibility signals, case study examples, or reference materials to use in

Apply this source entry using the definitions and corrections in this lesson. Use when The buyer needs credibility signals, case study examples, or reference materials to use in their own business as they implement the core programme. Without this bonus, they would need to build those signals from scratch. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 31, item 2 — Best formats Case study bank. Testimonial script. Proof-collection system. Before/after documentatio

Apply this source entry using the definitions and corrections in this lesson. Best formats Case study bank. Testimonial script. Proof-collection system. Before/after documentation template. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 31, item 3 — RISER Nation examples The Client Results Documentation System (solves: not having a professional way

Apply this source entry using the definitions and corrections in this lesson. RISER Nation examples The Client Results Documentation System (solves: not having a professional way to capture and display results). The Testimonial Extraction Interview Guide (solves: getting generic testimonials instead of specific-metric ones). The Trust Signal Library Template (solves: no organised way to display credibility). Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 31, item 4 — Naming convention The [Outcome] [System/Tool]: 'The Results Documentation System.' 'The Social Proof

Apply this source entry using the definitions and corrections in this lesson. Naming convention The [Outcome] [System/Tool]: 'The Results Documentation System.' 'The Social Proof Collection Kit.' 'The Credibility Asset Builder.' Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 31, item 5 — Perceived value range $97–$247 (perceived value: replaces professional brand or PR work).

Apply this source entry using the definitions and corrections in this lesson. Perceived value range $97–$247 (perceived value: replaces professional brand or PR work). Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 32, item 1 — Use when The buyer carries a specific risk or fear about what happens if one element of the implemen

Apply this source entry using the definitions and corrections in this lesson. Use when The buyer carries a specific risk or fear about what happens if one element of the implementation does not go as expected. This bonus addresses that specific 'what if' scenario directly, removing the implementation fear that might otherwise prevent them from committing or executing. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 32, item 2 — Best formats Contingency playbook. 'What if it doesn't work' protocol. Risk mitigation guide. Recove

Apply this source entry using the definitions and corrections in this lesson. Best formats Contingency playbook. 'What if it doesn't work' protocol. Risk mitigation guide. Recovery framework. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 32, item 3 — RISER Nation examples The Launch Recovery Protocol (solves: fear of what to do if the launch underpe

Apply this source entry using the definitions and corrections in this lesson. RISER Nation examples The Launch Recovery Protocol (solves: fear of what to do if the launch underperforms). The Refund-Rate Rescue Playbook (solves: fear of post-launch refund spikes). The Tech Failure Response Guide (solves: fear of technical problems during live delivery). Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 32, item 4 — Naming convention The [Risk Scenario] [Protocol/Playbook]: 'The Launch Recovery Protocol.' 'The Risk

Apply this source entry using the definitions and corrections in this lesson. Naming convention The [Risk Scenario] [Protocol/Playbook]: 'The Launch Recovery Protocol.' 'The Risk Mitigation Playbook.' Make the specific risk visible in the name — it signals that you anticipated and planned for the buyer's exact fear. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 32, item 5 — Perceived value range $97–$297 (perceived value: risk insurance is priced against the potential cost

Apply this source entry using the definitions and corrections in this lesson. Perceived value range $97–$297 (perceived value: risk insurance is priced against the potential cost of the risk materialising). Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Source worksheet 33

Work through this source worksheet in order. PHASE 7 The Bonus Naming and Value Assignment System Every bonus needs a name that earns attention and a value that earns credibility Record actual evidence and applicable definitions; source targets and examples do not establish a completed result.

Worksheet 34, item 1 — Describes the output, not the process

Apply this source entry using the definitions and corrections in this lesson. Naming Criterion: Describes the output, not the process Test: Does the name tell the buyer what they will have after using this bonus — not what they will do to get it? Pass Example: 'The 30-Day DM Outreach Playbook' — buyer knows they will have a playbook of DM sequences. Fail Example: 'The Outreach Training' — buyer knows they will learn about outreach. No sense of deliverable. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 34, item 2 — Contains a specificity signal

Apply this source entry using the definitions and corrections in this lesson. Naming Criterion: Contains a specificity signal Test: Does the name contain a number, a timeframe, a named format, or a named method that implies precision? Pass Example: 'The 14-Day Email Welcome Sequence Template' — '14-Day' implies a specific, complete structure. Fail Example: 'The Email Templates' — no specificity. Could be 3 emails or 300. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 34, item 3 — Implies the sub-problem it solves

Apply this source entry using the definitions and corrections in this lesson. Naming Criterion: Implies the sub-problem it solves Test: Without reading any description, can a buyer in your target avatar hear the name and immediately understand what problem it addresses? Pass Example: 'The Blank-Page Hook Eliminator' — implies it solves the blank-page problem in hook writing. Fail Example: 'Creative Assets Pack' — no sub-problem implied. Could be anything. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 34, item 4 — Passes the 48-hour recall test

Apply this source entry using the definitions and corrections in this lesson. Naming Criterion: Passes the 48-hour recall test Test: Read the bonus name once to an avatar-matched individual. Ask them to recall it 48 hours later. If they can recall it accurately — the name is working. Pass Example: Name recalled accurately by 4 of 5 testers. Fail Example: Name recalled with wrong specifics or not at all by 3+ testers. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 35, item 1 — Market equivalence

Apply this source entry using the definitions and corrections in this lesson. Valuation Method: Market equivalence When to Use: When a comparable service, tool, or programme is available for purchase somewhere in the market How to Calculate: Research the market price for a comparable solution. The standalone value should be the low-to-mid range of comparable pricing, not the highest-priced alternative. Example: A template pack of 14 sales copy frameworks: comparable standalone products on Gumroad, Etsy, and Creative Market sell at $27–$67. Stated value: $47. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 35, item 2 — Service substitution

Apply this source entry using the definitions and corrections in this lesson. Valuation Method: Service substitution When to Use: When the bonus replaces a professional service the buyer would otherwise hire out How to Calculate: Research the going rate for the service in the buyer's market. The bonus value is what the buyer saves by not hiring it out. Example: A sales call recording review with scoring rubric: a sales coach charges $150–$300/hour. The bonus covers this function for the duration of the programme. Stated value: $197. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 35, item 3 — Time substitution

Apply this source entry using the definitions and corrections in this lesson. Valuation Method: Time substitution When to Use: When the bonus saves the buyer a specific number of hours they would otherwise spend researching, deciding, or building from scratch How to Calculate: Calculate the buyer's approximate hourly rate × hours saved. The stated value should reflect actual time saved, not an inflated estimate. Example: A platform comparison guide that saves 4 hours of research for a buyer whose time is worth $75/hour: stated value = $297 (4 × $75 = $300 rounded to nearest $47 price point). Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 35, item 4 — Proprietary method premium

Apply this source entry using the definitions and corrections in this lesson. Valuation Method: Proprietary method premium When to Use: When the bonus contains a proprietary framework, diagnostic, or process that cannot be found elsewhere How to Calculate: Base the value on comparable courses or workshops that teach the closest available equivalent methodology Example: A proprietary scoring rubric that does not exist in the market. Comparable diagnostic tools: $47–$197. Stated value: $147. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Source worksheet 36

Work through this source worksheet in order. PHASE 8 The Audit Cadence and Trigger System When to run the audit and what events fire it outside the quarterly schedule Record actual evidence and applicable definitions; source targets and examples do not establish a completed result.

Worksheet 37, item 1 — Q1 Audit

Apply this source entry using the definitions and corrections in this lesson. Quarter: Q1 Audit Timing: First week of January Scope: All active offer stacks. Priority on any stack that received buyer feedback in Q4 suggesting bonus confusion or low utility. Preparation Required: Pull Q4 exit interview utility scores. Pull Q4 access rate data from course platform. Run Flagship Promise Test with fresh testers. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 37, item 2 — Q2 Audit

Apply this source entry using the definitions and corrections in this lesson. Quarter: Q2 Audit Timing: First week of April Scope: All active offer stacks. Add any new offers launched in Q1. Preparation Required: Pull Q1 data. Confirm any Q1 Reform verdicts have been executed. Check if any Q1 Cut bonuses have been archived correctly. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 37, item 3 — Q3 Audit

Apply this source entry using the definitions and corrections in this lesson. Quarter: Q3 Audit Timing: First week of July Scope: All active offer stacks. Highest-value audit of the year — full-year buyer data available. Preparation Required: Pull H1 exit interview data (6 months of utility scores and access rates). Strong basis for cut decisions. Incorporate into August/September relaunch planning. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 37, item 4 — Q4 Audit

Apply this source entry using the definitions and corrections in this lesson. Quarter: Q4 Audit Timing: First week of October Scope: All active offer stacks. Pre-launch preparation for any Q1 launches. Preparation Required: Use Q4 audit to finalise stacks for next year's first cohort. Any Cut verdict executed in Q4 improves the January launch. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 38, item 1 — Offer Scorecard D5 (Offer Stack Strength) scores 2 or below

Apply this source entry using the definitions and corrections in this lesson. Trigger Event: Offer Scorecard D5 (Offer Stack Strength) scores 2 or below What to Audit: All bonuses in that offer's stack. Full 5-dimension scoring. Urgency: Within 14 days of scorecard session Why: D5 below 3 is a signal that the stack is failing the buyer. Cannot wait for quarterly cadence. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 38, item 2 — Exit interview utility survey produces an average below 5.0 for any single bonus

Apply this source entry using the definitions and corrections in this lesson. Trigger Event: Exit interview utility survey produces an average below 5.0 for any single bonus What to Audit: That specific bonus — full 5-dimension scoring. Other bonuses in the stack are not triggered. Urgency: Within 7 days of survey processing Why: A below-5.0 utility score from buyers who have used the bonus is immediate signal that the bonus is not earning its place. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 38, item 3 — Post-MVO Forensic Audit Loop Phase 2 (Value Equation Audit) shows Effort & Sacrifice degrading

Apply this source entry using the definitions and corrections in this lesson. Trigger Event: Post-MVO Forensic Audit Loop Phase 2 (Value Equation Audit) shows Effort & Sacrifice degrading What to Audit: Review all bonuses for evidence of creating effort confusion rather than effort reduction. Check D4 (Promise Coherence) specifically. Urgency: Within the 30-day window post-forensic audit Why: A degrading Effort & Sacrifice score in the Value Equation may indicate bonuses are adding perceived complexity rather than reducing friction. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 38, item 4 — A new Major or Minor version of any offer is being planned (CAT-O change from Product Versioning SOP

Apply this source entry using the definitions and corrections in this lesson. Trigger Event: A new Major or Minor version of any offer is being planned (CAT-O change from Product Versioning SOP) What to Audit: Full bonus inventory audit for that offer before the new version is designed Urgency: Before finalising the new version's offer stack Why: A version change is the natural moment to refresh the stack. Audit first, build second. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 38, item 5 — Buyer language mining data reveals a new high-frequency sub-problem not currently addressed by any b

Apply this source entry using the definitions and corrections in this lesson. Trigger Event: Buyer language mining data reveals a new high-frequency sub-problem not currently addressed by any bonus What to Audit: Not an audit trigger — a new bonus design trigger. Run the Pre-Entry Gate for a new bonus designed around the newly-identified sub-problem. Urgency: Within 30 days of the mining data being flagged Why: New buyer language data revealing an unaddressed sub-problem is a direct brief for a new bonus. Build immediately per the New Bonus Design System (Phase 6). Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 39, item 1 — D1

Apply this source entry using the definitions and corrections in this lesson. #: D1 Dimension: Sub-Problem Specificity What It Measures: Does this solve a named sub-problem on the path to the core promise? 1: No named sub-problem 2: Vague or loosely connected 3: Specific but evidence thin 4: Specific + evidenced 5: Specific + evidenced + buyer-confirmed Score: ___ Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 39, item 2 — D2

Apply this source entry using the definitions and corrections in this lesson. #: D2 Dimension: Buyer Utility Score What It Measures: How useful do buyers rate this bonus? 1: Below 5.0 or unmeasured 2: 5.0–5.9 3: 6.0–6.9 4: 7.0–7.9 5: 8.0+ Score: ___ Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 39, item 3 — D3

Apply this source entry using the definitions and corrections in this lesson. #: D3 Dimension: Access Rate What It Measures: What % of buyers access this bonus? 1: Below 20% 2: 20–29% 3: 30–49% 4: 50–64% 5: 65%+ Score: ___ Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 39, item 4 — D4

Apply this source entry using the definitions and corrections in this lesson. #: D4 Dimension: Promise Coherence What It Measures: Is this clearly supporting the core promise without competing? 1: Competes with or duplicates core 2: Adjacent but connection unclear 3: Related, needs explanation 4: Clearly supporting 5: Instantly obvious connection + named in mechanism Score: ___ Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 39, item 5 — D5

Apply this source entry using the definitions and corrections in this lesson. #: D5 Dimension: Delivery Sustainability What It Measures: Can this be maintained sustainably? 1: Outdated or high-cost maintenance 2: High maintenance, no process 3: Annual update needed, manageable 4: Low maintenance, documented 5: Evergreen or systematised refresh Score: ___ Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 39, item 6 — TOTAL SCORE

Apply this source entry using the definitions and corrections in this lesson. TOTAL SCORE Maximum 25 — KEEP: 18–25 | REFORM: 10–17 | CUT: 0–9 | D1=1 → Auto-Cut regardless of total ___ Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 40, item 1 — Audit ID

Apply this source entry using the definitions and corrections in this lesson. Field: Audit ID Type: Autonumber Notes: Format: BDA-[Offer Code]-[YYYY-Q#]. e.g. BDA-MVO-2026-Q2 Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 40, item 2 — Offer

Apply this source entry using the definitions and corrections in this lesson. Field: Offer Type: Link → Offers table Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 40, item 3 — Audit Date

Apply this source entry using the definitions and corrections in this lesson. Field: Audit Date Type: Date Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 40, item 4 — Auditor(s)

Apply this source entry using the definitions and corrections in this lesson. Field: Auditor(s) Type: Short text Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 40, item 5 — Trigger

Apply this source entry using the definitions and corrections in this lesson. Field: Trigger Type: Single select Notes: Quarterly Cadence / Offer Scorecard D5 / Exit Survey Low Score / Value Equation Degradation / Version Change / Buyer Language Signal Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 40, item 6 — Pre-Audit Stack Size

Apply this source entry using the definitions and corrections in this lesson. Field: Pre-Audit Stack Size Type: Number Notes: Total bonus count before this audit Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 40, item 7 — Pre-Audit Clarity Index

Apply this source entry using the definitions and corrections in this lesson. Field: Pre-Audit Clarity Index Type: Number Notes: Flagship Promise Test result before audit (x of 5) Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 40, item 8 — Bonuses Audited

Apply this source entry using the definitions and corrections in this lesson. Field: Bonuses Audited Type: Link → Bonus Records Notes: All bonuses scored in this session Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 40, item 9 — Verdicts — KEEP

Apply this source entry using the definitions and corrections in this lesson. Field: Verdicts — KEEP Type: Number Notes: Count of bonuses receiving Keep verdict Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 40, item 10 — Verdicts — REFORM

Apply this source entry using the definitions and corrections in this lesson. Field: Verdicts — REFORM Type: Number Notes: Count of bonuses receiving Reform verdict Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 40, item 11 — Verdicts — CUT

Apply this source entry using the definitions and corrections in this lesson. Field: Verdicts — CUT Type: Number Notes: Count of bonuses receiving Cut verdict Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 40, item 12 — Post-Audit Stack Size

Apply this source entry using the definitions and corrections in this lesson. Field: Post-Audit Stack Size Type: Number Notes: Projected bonus count after Cut and Reform verdicts are executed Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 40, item 13 — Post-Audit Clarity Index

Apply this source entry using the definitions and corrections in this lesson. Field: Post-Audit Clarity Index Type: Number Notes: Flagship Promise Test result after audit changes applied Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 40, item 14 — Reform Actions Assigned

Apply this source entry using the definitions and corrections in this lesson. Field: Reform Actions Assigned Type: Long text Notes: One Action Definition Format entry per Reform bonus Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 40, item 15 — Cut Execution Status

Apply this source entry using the definitions and corrections in this lesson. Field: Cut Execution Status Type: Single select Notes: Pending / In Progress / Complete Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 40, item 16 — Version Changelog Entry

Apply this source entry using the definitions and corrections in this lesson. Field: Version Changelog Entry Type: Link → Changelog Entries Notes: The CAT-O changelog entry for stack changes resulting from this audit Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 40, item 17 — Next Scheduled Audit

Apply this source entry using the definitions and corrections in this lesson. Field: Next Scheduled Audit Type: Date Notes: Quarterly cadence date or event-based trigger Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 40, item 18 — New Bonus Briefs Generated

Apply this source entry using the definitions and corrections in this lesson. Field: New Bonus Briefs Generated Type: Long text Notes: Any new bonus design briefs triggered by sub-problem gaps identified in this audit Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Execution checklist 1

Work through these actions: • If 4 of 5 testers can state the core transformation accurately — the stack is disciplined. The bonuses are not obscuring the promise. • If 2 or 3 of 5 testers state a bonus outcome rather than the core transformation — the stack is approaching Clarity Collapse. One or more bonuses are competing with the core promise for the buyer's attention. • If fewer than 2 of 5 testers can identify the core transformation — the stack has fully collapsed into Clarity Collapse. The audit's Cut phase must produce a significantly shorter stack before the offer is scaled or relaunched. 1. Record the Cut decision in Airtable: verdict date, total audit score, which dimensions scored low, and the specific reason for the Cut verdict. This becomes the institutional memory for future offer design. Document completion separately from planned work. Apply the resolved rubric, current commitments and relevant source links at each decision.

Execution checklist 2

Work through these actions: 2. Determine existing buyer entitlement. Per the Product Versioning SOP (Phase 4 — Existing Buyer Entitlement Policy): all buyers who purchased any prior version of the offer retain access to the cut bonus for a minimum of 90 days after removal from the sales page. 3. Do not announce the cut to the general market. A sales page update removing a bonus does not require a public announcement. It requires a Minor version changelog entry (CAT-O: Offer Stack Change) per the Product Versioning SOP. 4. If any existing buyer has specifically referenced the cut bonus in a support ticket, community post, or direct message within the past 30 days — send a proactive personal email within 24 hours explaining the change and confirming their continued access. This is a surgical notification, not a broadcast. 5. Update the sales page bonus stack section. Remove the bonus from the Stack Slide visual. Recalculate the total stated value. Confirm the remaining stack still passes the Flagship Promise Test. Document completion separately from planned work. Apply the resolved rubric, current commitments and relevant source links at each decision.

Execution checklist 3

Work through these actions: 6. Update the email sequence. Remove any email that specifically introduces or promotes the cut bonus (typically Day 10 — Bonus Explanation). If the bonus was a core reason-to-buy in the sequence, rewrite the section with the most compelling remaining bonus. 7. Archive the bonus deliverable in Google Drive under 'Offer Archive > [Offer Name] > Cut Bonuses > [Version]'. Tag with date of removal and cut reason. This preserves the IP for potential repurposing. 8. Evaluate the cut bonus for unbundle potential. Per the Offer Stacking & Unbundling Strategy SOP: if the cut bonus has a standalone Unbundle Score of 7+ in the IP Asset Inventory, it is a candidate for a Tool Unbundle or Entry Point Unbundle product. 9. Update the Offer Scorecard (D5 — Offer Stack Strength) for the next monthly session. The stack reduction should improve D5 if the remaining bonuses are stronger. Document completion separately from planned work. Apply the resolved rubric, current commitments and relevant source links at each decision.

Execution checklist 4

Work through these actions: • Never assign a value above $297 to a bonus in a sub-$500 offer unless the bonus is a live coaching session or an expert access component. A $500 bonus in a $297 offer produces scepticism, not conviction. • The total stated stack value should be 5–10× the asking price. Below 5× fails to create the 'so good they feel stupid saying no' reaction. Above 15× produces scepticism about the validity of the individual values. • If you cannot assign a defensible standalone value — the bonus should not be in the stack. A bonus without a legitimate standalone value is a filler item with cosmetic value. • Every stated value should survive this question: 'If this bonus were sold alone on Gumroad, what price would a stranger who has never heard of you pay for it?' If the answer is 'they wouldn't pay anything' — the stated value is fiction. Document completion separately from planned work. Apply the resolved rubric, current commitments and relevant source links at each decision.

Execution checklist 5

Work through these actions: ☐ Create Bonus Records table in Airtable with fields from the Bonus Inventory Template (Phase 1) ☐ Create Bonus Audit Records table with all fields from the Audit Session Record ☐ Complete the Bonus Inventory for all active offers — one row per bonus ☐ Pull access rate data from Kajabi for all current bonuses — add to inventory Document completion separately from planned work. Apply the resolved rubric, current commitments and relevant source links at each decision.

Execution checklist 6

Work through these actions: ☐ Pull utility scores from most recent exit survey — add to inventory ☐ Run the Memory Test on your most important offer's stack — note any bonuses you could not name from memory ☐ Set quarterly audit calendar reminders: January, April, July, October — first week of each ☐ Pull access rate data from course platform for all bonuses in scope Document completion separately from planned work. Apply the resolved rubric, current commitments and relevant source links at each decision.

Execution checklist 7

Work through these actions: ☐ Pull utility scores from exit interviews and pulse surveys (last quarter) ☐ Pull Objection Bank entries related to bonus sub-problems — confirm evidence is current ☐ Run the Flagship Promise Test with 5 fresh avatar-matched testers — record the pre-audit Clarity Index ☐ Pull the prior quarter's Bonus Audit Session Record — check that all Reform deadlines from last quarter were met Document completion separately from planned work. Apply the resolved rubric, current commitments and relevant source links at each decision.

Execution checklist 8

Work through these actions: ☐ Complete the Bonus Inventory for all bonuses in scope — confirm all fields are current ☐ Score all five dimensions for every bonus — using data, not impression ☐ Apply Automatic Override Rules: any D1=1 is auto-Cut. Any D2+D3 both=1 is auto-Reform/Cut. ☐ Record verdict for each bonus: Keep / Reform / Cut Document completion separately from planned work. Apply the resolved rubric, current commitments and relevant source links at each decision.

Execution checklist 9

Work through these actions: ☐ For every Reform verdict: document the specific Action Definition Format with owner and 60-day deadline ☐ For every Cut verdict: initiate the Cut Execution Checklist (Phase 5) ☐ Check Stack Maximum Rule: does the post-audit bonus count stay within the recommended maximum for this offer type? ☐ Run the post-audit Flagship Promise Test — record the Clarity Index. Confirm improvement from pre-audit. Document completion separately from planned work. Apply the resolved rubric, current commitments and relevant source links at each decision.

Execution checklist 10

Work through these actions: ☐ Evaluate each Cut bonus for unbundle potential using the IP Asset Inventory Unbundle Score ☐ Generate new bonus design briefs for any unaddressed sub-problems identified during the audit ☐ Complete Bonus Audit Session Record in Airtable ☐ Create CAT-O changelog entry in Product Versioning SOP for any stack changes resulting from this audit Document completion separately from planned work. Apply the resolved rubric, current commitments and relevant source links at each decision.

Execution checklist 11

Work through these actions: ☐ Execute all Cut verdicts: sales page updated, email sequence updated, archival completed ☐ Execute all Reform actions by their documented deadlines ☐ For each Reform completion: re-run D2 and D3 scoring with fresh buyer data to confirm improvement ☐ Any Reform bonus that missed its 60-day deadline: automatically change verdict to Cut and execute Document completion separately from planned work. Apply the resolved rubric, current commitments and relevant source links at each decision.

Execution checklist 12

Work through these actions: ☐ Run the Pre-Entry Gate for any new bonuses designed to fill sub-problem gaps identified in the audit ☐ Add new bonuses to the Bonus Inventory before adding to the live offer stack ☐ Update Offer Scorecard D5 (Offer Stack Strength) in the next monthly session Document completion separately from planned work. Apply the resolved rubric, current commitments and relevant source links at each decision.

Apply the Brunson and Hormozi teaching frame

Complete original source text

RISER NATION
MASTER OPERATING SYSTEM
SOP — BONUS DISCIPLINE AUDIT
The Quarterly System for Keeping, Reforming, or Cutting Every Bonus in the Stack — So Each One Earns Its Place
Kennedy × Hormozi × Brunson × 2026 Framework
Version 1.0 | 2026 Edition | RISER Nation Master Operating System
SOP Overview
Bonuses were designed to solve a specific problem in offer design: the value equation problem. When a buyer cannot directly perceive the gap between price and transformation, the bonus stack closes that gap by accumulating visible, named value until the total makes the price feel obviously correct.
Most operators understand this. What most operators miss is that the bonus stack degrades over time. Bonuses added in early validation remain in the stack long after buyers have stopped finding them useful. New bonuses get added reactively — in response to a low conversion week or a competitor's stack — without any evaluation of whether they solve a real sub-problem or simply add visual bulk. The stack grows. The clarity of the core promise shrinks. And eventually the buyer cannot identify what the offer actually IS underneath the pile of bonuses.
The Bonus Discipline Audit is the quarterly ritual that reverses this. It evaluates every bonus in every active offer stack against a hard criterion — each bonus must solve a specific, named sub-problem on the path to the core promise — and produces a verdict for each: Keep, Reform, or Cut. It also defines the design system for building new bonuses that pass the discipline test before they enter the stack, and the measurement system that tracks whether bonuses are contributing to conversion or simply occupying real estate.
The Two Bonus Stack Failure Modes
Before the audit framework, the system requires a clear picture of what bonus stack failure actually looks like. There are two distinct failure modes, each producing different symptoms and each requiring a different remediation.
The Core Discipline Standard: The Sub-Problem Test
The single non-negotiable criterion for every bonus in every stack, applied uniformly regardless of how long the bonus has been in the offer or how much work went into creating it:
What a Sub-Problem Is — and Is Not
The Flagship Promise Test — Applied to the Stack
The Flagship Promise Test (from MVO Playbook V5, Phase 2) is applied to the full stack before and after every audit. Read the full stack — core deliverables and all bonuses — to five avatar-matched individuals who have not seen the offer before. Ask them: 'In one sentence, what does this offer do for you?'
• If 4 of 5 testers can state the core transformation accurately — the stack is disciplined. The bonuses are not obscuring the promise.
• If 2 or 3 of 5 testers state a bonus outcome rather than the core transformation — the stack is approaching Clarity Collapse. One or more bonuses are competing with the core promise for the buyer's attention.
• If fewer than 2 of 5 testers can identify the core transformation — the stack has fully collapsed into Clarity Collapse. The audit's Cut phase must produce a significantly shorter stack before the offer is scaled or relaunched.
The Inventory Protocol
The audit cannot begin without a complete, accurate inventory of every bonus currently in every active offer stack. This sounds obvious — but most operators cannot immediately name every bonus in their stack and describe what sub-problem each one solves. If you cannot do that without referring to the sales page, the stack already has a discipline problem.
The Bonus Inventory Template
Complete one row per bonus per offer. This is the raw material for the full audit in Phase 2.
The Five Dimensions
Every bonus is scored across five dimensions. Each dimension has a specific scoring criterion. The five dimension scores sum to a maximum of 25 (5 per dimension). The total score maps to a verdict: Keep, Reform, or Cut.
The Verdict Thresholds
After scoring all five dimensions (maximum 25 points), map the total to a verdict using these thresholds. The verdict thresholds are hard — rounding up out of attachment to a bonus is the most common audit failure mode.
The Mandatory Override Rules
Two rules override the scoring system and produce automatic verdicts regardless of total score:
The Stack Maximum Rule
There is no universally correct number of bonuses. The right number is offer-specific and depends on the number of real sub-problems that exist on the path to the core promise. However, every stack has a maximum beyond which adding another bonus, regardless of its quality, will degrade clarity.
The Clarity Index
The Clarity Index is the Flagship Promise Test score: the percentage of 5 avatar-matched testers who can state the core promise accurately after reviewing the full offer description. It is calculated after the audit and compared against the pre-audit baseline.
Reform vs Cut: The Decision Point
The Reform verdict means the bonus has real merit — it solves a real sub-problem (D1 scores at least 3), but it is underperforming on at least one other dimension. Reform is not an indefinite suspension. Every bonus in Reform status must have a specific remediation action, a named owner, and a 60-day deadline. If reform is not completed on time, the verdict changes to Cut automatically.
Reform Prescriptions by Dimension
The Clean Cut Principle
Cutting a bonus is not a crisis event. It is a routine product iteration that improves the offer's clarity and focus. The execution must be clean: existing buyers are protected, the sales page is updated correctly, and the bonus is archived rather than deleted — because a bonus cut from one offer may become the foundation of a standalone tool unbundle or a future offer's bonus stack.
The Cut Execution Checklist
1. Record the Cut decision in Airtable: verdict date, total audit score, which dimensions scored low, and the specific reason for the Cut verdict. This becomes the institutional memory for future offer design.
2. Determine existing buyer entitlement. Per the Product Versioning SOP (Phase 4 — Existing Buyer Entitlement Policy): all buyers who purchased any prior version of the offer retain access to the cut bonus for a minimum of 90 days after removal from the sales page.
3. Do not announce the cut to the general market. A sales page update removing a bonus does not require a public announcement. It requires a Minor version changelog entry (CAT-O: Offer Stack Change) per the Product Versioning SOP.
4. If any existing buyer has specifically referenced the cut bonus in a support ticket, community post, or direct message within the past 30 days — send a proactive personal email within 24 hours explaining the change and confirming their continued access. This is a surgical notification, not a broadcast.
5. Update the sales page bonus stack section. Remove the bonus from the Stack Slide visual. Recalculate the total stated value. Confirm the remaining stack still passes the Flagship Promise Test.
6. Update the email sequence. Remove any email that specifically introduces or promotes the cut bonus (typically Day 10 — Bonus Explanation). If the bonus was a core reason-to-buy in the sequence, rewrite the section with the most compelling remaining bonus.
7. Archive the bonus deliverable in Google Drive under 'Offer Archive > [Offer Name] > Cut Bonuses > [Version]'. Tag with date of removal and cut reason. This preserves the IP for potential repurposing.
8. Evaluate the cut bonus for unbundle potential. Per the Offer Stacking & Unbundling Strategy SOP: if the cut bonus has a standalone Unbundle Score of 7+ in the IP Asset Inventory, it is a candidate for a Tool Unbundle or Entry Point Unbundle product.
9. Update the Offer Scorecard (D5 — Offer Stack Strength) for the next monthly session. The stack reduction should improve D5 if the remaining bonuses are stronger.
Handling 'But Buyers Bought Because of That Bonus'
The most common resistance to cutting a bonus is the belief that it was a primary purchase driver — 'we'll lose sales if we remove it.' This belief is worth examining with data before using it to override an audit verdict.
The Pre-Entry Standard
The most efficient version of the Bonus Discipline Audit is one where the Cut verdict is rare — because new bonuses are designed to pass the discipline standard before they are added to the stack. Every new bonus must clear the Pre-Entry Gate before it is announced publicly or added to the sales page.
The Six Bonus Design Templates
Every high-performing bonus fits one of six design templates. Building within a template ensures structural discipline — each template is built around a specific sub-problem type and a specific delivery format.
The Naming Criteria
A bonus name that buyers cannot remember is a bonus that is not doing its job. The name appears on the sales page, in the Stack Slide, in the email sequence, and in conversations where buyers describe the offer to friends. It must be immediately comprehensible, memorable, and specific enough to signal what sub-problem it solves.
The Value Assignment Protocol
Every bonus must have a stated standalone value assigned on the sales page. The value assignment is not arbitrary — it must be defensible. A stated value that the buyer immediately dismisses as inflated undermines the entire stack's credibility.
The Value Assignment Hard Rules
• Never assign a value above $297 to a bonus in a sub-$500 offer unless the bonus is a live coaching session or an expert access component. A $500 bonus in a $297 offer produces scepticism, not conviction.
• The total stated stack value should be 5–10× the asking price. Below 5× fails to create the 'so good they feel stupid saying no' reaction. Above 15× produces scepticism about the validity of the individual values.
• If you cannot assign a defensible standalone value — the bonus should not be in the stack. A bonus without a legitimate standalone value is a filler item with cosmetic value.
• Every stated value should survive this question: 'If this bonus were sold alone on Gumroad, what price would a stranger who has never heard of you pay for it?' If the answer is 'they wouldn't pay anything' — the stated value is fiction.
The Quarterly Cadence
The Bonus Discipline Audit runs every quarter as part of the quarterly planning cycle. The recommended timing is the first full week of each quarter — before any new cohort launches and after the prior quarter's exit interview data has been collected and processed.
Event-Based Audit Triggers
The quarterly cadence is the baseline. These specific events trigger an immediate targeted bonus audit outside the scheduled cycle:
The Bonus Discipline Audit Scorecard
Complete one scorecard per bonus per audit session. File all completed scorecards in Airtable under Bonus Audit Records.
Bonus Audit Session Record
Complete this record in Airtable after scoring all bonuses in a session. File under Bonus Audit Records, linked to the relevant Offers and Changelog entries.
Master Bonus Discipline Audit Checklist
System Setup (One-Time)
☐ Create Bonus Records table in Airtable with fields from the Bonus Inventory Template (Phase 1)
☐ Create Bonus Audit Records table with all fields from the Audit Session Record
☐ Complete the Bonus Inventory for all active offers — one row per bonus
☐ Pull access rate data from Kajabi for all current bonuses — add to inventory
☐ Pull utility scores from most recent exit survey — add to inventory
☐ Run the Memory Test on your most important offer's stack — note any bonuses you could not name from memory
☐ Set quarterly audit calendar reminders: January, April, July, October — first week of each
Pre-Audit Preparation (Before Every Quarterly Session)
☐ Pull access rate data from course platform for all bonuses in scope
☐ Pull utility scores from exit interviews and pulse surveys (last quarter)
☐ Pull Objection Bank entries related to bonus sub-problems — confirm evidence is current
☐ Run the Flagship Promise Test with 5 fresh avatar-matched testers — record the pre-audit Clarity Index
☐ Pull the prior quarter's Bonus Audit Session Record — check that all Reform deadlines from last quarter were met
Audit Session (Every Quarterly Audit)
☐ Complete the Bonus Inventory for all bonuses in scope — confirm all fields are current
☐ Score all five dimensions for every bonus — using data, not impression
☐ Apply Automatic Override Rules: any D1=1 is auto-Cut. Any D2+D3 both=1 is auto-Reform/Cut.
☐ Record verdict for each bonus: Keep / Reform / Cut
☐ For every Reform verdict: document the specific Action Definition Format with owner and 60-day deadline
☐ For every Cut verdict: initiate the Cut Execution Checklist (Phase 5)
☐ Check Stack Maximum Rule: does the post-audit bonus count stay within the recommended maximum for this offer type?
☐ Run the post-audit Flagship Promise Test — record the Clarity Index. Confirm improvement from pre-audit.
☐ Evaluate each Cut bonus for unbundle potential using the IP Asset Inventory Unbundle Score
☐ Generate new bonus design briefs for any unaddressed sub-problems identified during the audit
☐ Complete Bonus Audit Session Record in Airtable
☐ Create CAT-O changelog entry in Product Versioning SOP for any stack changes resulting from this audit
Post-Audit Execution (Within 60 Days)
☐ Execute all Cut verdicts: sales page updated, email sequence updated, archival completed
☐ Execute all Reform actions by their documented deadlines
☐ For each Reform completion: re-run D2 and D3 scoring with fresh buyer data to confirm improvement
☐ Any Reform bonus that missed its 60-day deadline: automatically change verdict to Cut and execute
☐ Run the Pre-Entry Gate for any new bonuses designed to fill sub-problem gaps identified in the audit
☐ Add new bonuses to the Bonus Inventory before adding to the live offer stack
☐ Update Offer Scorecard D5 (Offer Stack Strength) in the next monthly session
RISER Nation Master Operating System | Bonus Discipline Audit SOP | Version 1.0 | 2026 Edition
Kennedy × Hormozi × Brunson | risernation.com
The Hormozi Standard
The Thud Factor works when bonuses are coherent. It fails when bonuses are filler. 'All of THAT for this price?' is the reaction you're engineering. But if the buyer cannot figure out what the core offer actually IS because the stack is so large and so varied, the Thud Factor backfires into the Confusion Factor — and confusion kills more sales than scarcity ever creates.
The Kennedy Warning
More is not always more. A stack of twelve bonuses, half of which are recycled PDFs with no specific connection to the core promise, is worth less than a stack of three bonuses where each one solves a problem the buyer was afraid they'd face on the way to the result. The discipline is not in the counting. It is in the relevance.
The MVO Playbook Rule — Made Operational
Your own MVO Playbook V5 states it directly: 'The Thud Factor fails when bonuses are filler that dilutes clarity. If the prospect can't figure out what the CORE offer actually IS, conversions drop. Every bonus must clearly solve a specific sub-problem. Confusion kills more sales than scarcity creates.' This SOP is the operational system that enforces that rule on every active offer, on a repeating quarterly schedule.
Failure Mode
Description
Symptoms
Common Cause
Remediation
Filler Accumulation
The stack grows over time as bonuses are added reactively — to match a competitor, respond to a poor conversion week, or fill perceived value gaps — without each new bonus being held to the sub-problem test. The stack becomes wide but shallow: many bonuses, none of which solve a specific problem that buyers were actually encountering.
High stack volume but low buyer utility scores in exit surveys. Support tickets asking 'What do I do with [bonus X]?' Bonuses being listed on the sales page but never accessed in the course platform. Buyers in exit interviews unable to name more than 2–3 of the listed bonuses.
Bonus additions happen without a defined standard. New bonuses are added in response to external pressure (competitor, conversion drop) without internal qualification criteria. No removal process exists — every bonus added is permanent by default.
Bonus Discipline Audit — Cut phase. Remove all bonuses scoring below the sub-problem threshold. Each removal increases the clarity of the bonuses that remain.
Clarity Collapse
The stack is technically coherent — each bonus solves a real sub-problem — but there are too many of them. The buyer cannot identify the core promise because the stack has grown to eclipse it. The bonuses outnumber the core deliverables. The sales page looks like a product catalog rather than a transformation offer.
Core promise buried in the stack slide. Buyers cite bonuses as the reason for purchase more than the core transformation. Testimonials reference bonus value rather than programme outcome. The 'Flagship Promise Test' fails — buyers cannot repeat the core promise in one sentence because the stack has obscured it.
Gradual accumulation without a maximum stack discipline rule. Success of individual bonuses leads to 'more is better' thinking without recognising the clarity cost.
Apply the Flagship Promise Test and the Stack Maximum Rule (see Phase 2). Retire excess bonuses to an 'available as upgrades' position rather than deleting them entirely.
The Sub-Problem Test — The One Rule That Governs All Bonus Decisions
Every bonus must solve a specific, named sub-problem that a buyer will encounter on the path between purchasing the offer and achieving the core promise.

A sub-problem is specific enough that you can describe it in one sentence beginning with 'The buyer is struggling with...' or 'Without this, the buyer will get stuck at...'

A bonus that cannot be described this way is either: (1) a vanity addition that adds visual stack weight without solving a real problem, or (2) a solution to a problem that does not actually exist on the path to the core promise, or (3) a bonus that duplicates what the core offer already solves.

All three categories fail the test. All three must be cut or reformed.
Category
Definition
Examples That Pass
Examples That Fail
Valid Sub-Problem
A specific obstacle, skill gap, or implementation challenge that arises after the buyer commits to the transformation but before they complete it. It is distinct from the core promise — solving it gets them closer to the main result but is not the main result itself.
'Without knowing which platform to post on first, the buyer will waste 3 weeks testing instead of gaining traction.' (Bonus: Platform Priority Map)

'The buyer will need to write cold outreach but has no templates — every email will take 45 minutes.' (Bonus: 30-Day DM Outreach Swipe File)
'More content about the topic.' (Not a sub-problem — it is volume, not gap-filling)

'A community where they can ask questions.' (Community is a support structure, not a sub-problem solution — unless access to expert peers IS the specific bottleneck)
Invalid: Cosmetic Value
An addition that makes the stack look bigger or more impressive without solving a problem. Often a PDF workbook, a resource list, or an audio recording that has no clear connection to a specific buyer obstacle.
N/A
'The Ultimate Resource Guide' — a 40-page PDF of tools and links with no specific application to any sub-problem.

'Bonus Training: Success Mindset' — motivational content with no sub-problem connection.
Invalid: Duplicate Solving
A bonus that solves the same problem the core offer already solves. It reinforces the core rather than bridging a gap. Buyers who have the core do not need an additional solution to the same problem.
N/A
Adding an 'offer construction checklist' bonus to an offer whose core promise IS offer construction. The bonus duplicates the core.
Invalid: Wrong-Path Problem
A bonus that solves a real problem — but a problem that arises AFTER the buyer has already achieved the core promise. Premature ascension material presented as a bonus.
N/A
Adding a 'paid traffic scaling playbook' bonus to an offer whose core promise is validating a first offer organically. The buyer doesn't have the problem yet.
PHASE 1
The Bonus Inventory
Documenting every bonus in every active stack before any evaluation begins
The Memory Test
Before opening the sales page: write down every bonus currently in your most important offer's stack from memory. Then open the sales page. Any bonus you could not remember is a candidate for the Cut pile — if it does not stick in your own memory, it is unlikely to register in the buyer's mind either.
Field
What to Document
Example
Bonus ID
A unique code: [Offer Code]-B[Sequence]. e.g. MVO-B03
MVO-B03
Bonus Name (as stated on sales page)
Exact name as it appears in the stack slide — not a description.
The 30-Day DM Outreach Playbook
Bonus Format
The physical form of the deliverable.
Template pack (14 DM scripts + 3 follow-up frameworks, PDF)
Date Added to Stack
When was this bonus first included in this offer?
Added at V1.2.0 (2025-09-10 per Changelog)
Stated Standalone Value
The dollar value assigned to this bonus on the sales page.
$197
Sub-Problem It Claims to Solve
In one sentence: 'The buyer is struggling with ___.' Fill this in from your own knowledge — before looking at the sales page copy for clues.
'The buyer needs to send outreach messages but has no proven templates, so they spend 45 minutes per message and get inconsistent results.'
Evidence That This Sub-Problem Is Real
Specific data: buyer support tickets, exit interview phrases, Objection Bank entries, community posts that confirm this specific problem is encountered on the path to the core promise.
Exit interview Q3 (5 of 12 respondents): 'I struggled with what to say in outreach.' Support tickets tagged 'outreach help': 6 in last 30 days. Objection Bank entry OBJ-MVO-019: 'I don't know what to say in DMs.'
Buyer Utility Score (if available)
Exit interview or pulse survey data: how useful did buyers rate this specific bonus? Scale 1–10.
7.4/10 average from last cohort exit survey Q: 'Rate the usefulness of each component.'
Access Rate
Of buyers who purchased, what % actually accessed this bonus in the course platform? (Kajabi analytics)
61% accessed — above the 50% threshold.
Delivery Cost to Creator
Time to maintain, update, or deliver this bonus. Is it evergreen or does it require periodic refresh?
Evergreen — templates require refresh every 12 months to reflect platform changes. ~2 hours annually.
PHASE 2
The Five-Dimension Scoring System
Evaluating every bonus against an objective standard before rendering a verdict
Dimension
What It Measures
Score 1
Score 3
Score 5
D1 — Sub-Problem Specificity
Does this bonus solve a specific, named sub-problem on the path to the core promise?
No named sub-problem. Adds value generally but cannot be described as solving a specific obstacle.
A sub-problem exists but is vague, broad, or only loosely connected to the path to the core promise.
Clear, specific sub-problem stated in one sentence. Problem is confirmed by buyer data (support tickets, exit interviews, or Objection Bank entries).
D2 — Buyer Utility Score
How useful do buyers find this bonus in practice?
Score below 5.0 from exit survey or pulse survey. Or no data available — has never been measured.
Score 5.0–6.9. Adequate but not compelling. Many buyers find it useful; some find it irrelevant.
Score 7.0+. Consistently rated as highly useful by buyers who access it. Frequently cited in exit interviews as a purchase driver.
D3 — Access Rate
What percentage of buyers actually access this bonus?
Below 30% access rate. Most buyers who purchased never use this bonus.
30–49% access rate. About a third to half of buyers engage with it.
50%+ access rate. More than half of buyers access and use this bonus. Strong signal of perceived relevance.
D4 — Promise Coherence
Is this bonus clearly connected to the core promise — not competing with it, not duplicating it?
This bonus describes an outcome similar to the core promise itself, creating confusion about what the core offer does. OR it solves a problem that arises after the core promise is achieved.
This bonus is adjacent to the core promise but the connection is not obvious without explanation. Buyers may not understand why it is included.
This bonus is clearly a supporting solution that helps buyers achieve the core promise. Its connection to the core outcome is immediately obvious without explanation.
D5 — Delivery Sustainability
Can this bonus continue to be delivered at the stated quality indefinitely without disproportionate maintenance cost?
High maintenance cost with no sustainable update process. OR the bonus references tools, platforms, or information that have already become outdated.
Moderate maintenance cost. Requires annual update. No dedicated process exists but updates are manageable.
Low maintenance cost. Evergreen content requiring minimal updates. OR a systematic update process exists that is already documented.
KEEP
Total score 18–25 — Bonus is earning its place in the stack
This bonus solves a real sub-problem, buyers find it useful and actually access it, it is coherent with the core promise, and it is deliverable sustainably. It stays in the stack. Update the Airtable record with current scores. Schedule next audit in 6 months.
REFORM
Total score 10–17 — Bonus has merit but a specific weakness to fix
This bonus has real value but is underperforming on one or more dimensions. It is not cut — it is improved. The specific dimensions scoring below 3 identify exactly what the reform should address. Reform must be completed before the next cohort or within 60 days. If reform is not completed by the deadline, the verdict is automatically changed to Cut.
CUT
Total score 0–9 — Bonus is failing the discipline standard
This bonus does not solve a named sub-problem (or solves the wrong one), is not used by most buyers, and is likely contributing to Clarity Collapse in the stack. It is removed from the stack. Existing buyers retain access for 90 days per the Entitlement Policy (Product Versioning SOP). The sales page is updated within 14 days. See Phase 5 for the Cut Execution Protocol.
Automatic Cut Rule — D1 Score of 1
Any bonus scoring 1 on Dimension D1 (Sub-Problem Specificity) is automatically cut regardless of its total score. A bonus that does not solve a named sub-problem has no legitimate place in a disciplined stack — not even if it is beloved by buyers, consistently accessed, and easy to maintain. The discipline starts with the sub-problem test. A bonus that fails it does not belong in the stack.
Automatic Reform Rule — D2+D3 Both Score 1
Any bonus where both Dimension D2 (Buyer Utility Score) AND Dimension D3 (Access Rate) score 1 is automatically set to Reform or Cut, not Keep, regardless of other dimension scores. A bonus that buyers rate as useless AND that most buyers never access is producing negative value — it is contributing to the buyer's perception that the stack is padded, which undermines the credibility of the bonuses that are genuinely useful.
PHASE 3
The Stack Maximum Rule and Clarity Index
How many bonuses is the right number — and how to measure stack clarity
Offer Type
Recommended Bonus Count
Maximum Before Clarity Risk
Rationale
Entry-point / Tripwire ($7–$97)
1–2 bonuses
3
At this price point, clarity of the core promise is paramount. More than 3 bonuses at entry-level suggests either Filler Accumulation or that the core offer is not strong enough alone.
MVO / Frontend Offer ($97–$497)
2–4 bonuses
5
The MVO must have a clear core deliverable that can pass the Flagship Promise Test. 5+ bonuses at this tier is the most common trigger for Clarity Collapse because the buyer has not yet fully committed and is more susceptible to confusion.
Core Offer ($497–$4,997)
3–6 bonuses
7
More complex transformation means more real sub-problems. A 6-bonus stack for a 90-day programme with 4 implementation phases is disciplined if each bonus solves a distinct phase-specific sub-problem.
High-Ticket / DWY ($2,500–$25,000)
1–3 bonuses
4
At this price point, the stack is less important than the access and proximity being sold. Heavy bonus stacking at high-ticket suggests the operator lacks confidence in the core offer. Buyers at this tier are buying the operator's time and expertise — not template packs.
Continuity / MRR ($47–$997/mo)
0–2 bonuses per renewal cycle
3
Continuity bonuses are best delivered as monthly value drops — new mechanisms, tools, and templates that justify the recurring payment. They are not a static stack. A fixed continuity bonus stack beyond 3 items signals membership bloat, not membership value.
Clarity Index
Interpretation
Action
5/5 (100%)
Maximum clarity. The stack is fully disciplined. Every bonus is supporting the core promise without competing with it.
Maintain the current stack. Run the Clarity Index again at the next quarterly audit.
4/5 (80%)
Good clarity with a minor gap. One tester was distracted by a bonus.
Identify which tester cited a bonus outcome rather than the core promise. Which bonus generated that distraction? Review that bonus's D4 (Promise Coherence) score.
3/5 (60%)
Clarity is degrading. Two testers are confused about what the offer primarily does.
The stack is approaching or has reached Clarity Collapse. At least one bonus needs to be cut or repositioned. Run the Flagship Promise Test on each bonus individually to identify the confuser.
2/5 or below (below 60%)
Clarity Collapse confirmed. The stack is obscuring the core promise.
Immediate action required. Apply the Stack Maximum Rule: cut the stack to the recommended maximum for this offer type regardless of individual bonus scores. Retain the highest-scoring bonuses within that maximum.
PHASE 4
The Reform Protocol
What to do with a bonus that earns Reform — the exact fixes for each weakness
The Reform Deadline Rule
A Reform bonus that has been in Reform status for more than 60 days without a documented completion is automatically Cut at the next monthly review. There is no second Reform cycle. If the fix could not be done in 60 days, the bonus is not a current-version asset — it either needs to be retired or rebuilt as a new bonus for a future version of the offer.
Weak Dimension
Score
Prescribed Reform
Implementation
D1 — Sub-Problem Specificity
Score 3 (vague or broad)
Rewrite the sub-problem statement in the one-sentence format: 'The buyer is struggling with [specific obstacle] at [specific stage] of the [specific journey].' Then rewrite the bonus name and description to make the connection to that sub-problem explicit and immediate.
Update bonus name and description on sales page, Stack Slide, and course platform. Update Airtable record with revised sub-problem statement. Confirm with the next exit interview cohort that the connection is now clear.
D2 — Buyer Utility Score
Score 3 (utility 5.0–6.9)
The bonus is mildly useful but not compelling. Two possible fixes: (1) Upgrade the format — if a PDF, convert to a template. If a template, add a worked example. If a recording, add a structured reference guide alongside. (2) Narrow the scope — a broadly useful bonus with a 6.0 score is often a narrowly useful bonus with a 9.0 score hiding inside. Remove the generic elements and focus on the highest-value specific element.
Test the upgraded format with 3–5 buyers from the current cohort before redeploying. Re-survey for utility score. Target: 7.0+ before returning to active stack.
D3 — Access Rate
Score 3 (30–49% access)
Low access rate usually has one of three causes: (1) The bonus is buried in the course platform — move it to a more prominent location (Day 1 or within the first module). (2) The bonus is not referenced in the onboarding email sequence — add a specific mention with a direct link. (3) Buyers do not understand when to use it — add a trigger statement: 'Use this when you reach Step 3 of Module 2.'
Add one-sentence placement instruction to each point where the bonus could be used. Add a direct link to the bonus in the Day 1 onboarding email. Re-measure access rate after the next cohort.
D4 — Promise Coherence
Score 3 (adjacent but not obvious)
The bonus is genuinely related to the core promise but the connection is not clear. Two fixes: (1) Rename the bonus to make the connection explicit. 'The Lead Gen Template Pack' becomes 'The Outreach-to-Booked-Call Template Pack' — now the connection to the call-booking core promise is immediate. (2) Add a one-sentence context statement to the Stack Slide: 'This solves the outreach problem that stops most people at Step 4 of the method.'
Update bonus name and Stack Slide context statement. Run Flagship Promise Test after the update to confirm Clarity Index has improved.
D5 — Delivery Sustainability
Score 3 (moderate maintenance, annual update needed)
Create an update schedule and document it. Add the bonus to the Quarterly Refresh Calendar (first Monday of October or the equivalent in your planning cycle). Assign a specific owner for the annual update. If the bonus references time-sensitive information (platform features, pricing data), add a 'Last updated' date to the deliverable.
Log in Airtable: update frequency, owner, next update date. Add to the quarterly planning calendar. Deliver the first scheduled update within 90 days of the Reform verdict.
PHASE 5
The Cut Execution Protocol
Removing a bonus cleanly — without damaging existing buyer relationships
Claim
How to Test It
What the Data Usually Shows
'Buyers mention that bonus as their reason for purchasing.'
Pull exit interview transcripts. Count how many buyers cite the bonus by name as their primary purchase reason (not just as something they appreciate). Compare to how many cite the core transformation.
In most cases, buyers who cite a bonus as their purchase reason are buying the sub-problem solution, not the bonus itself. If 8/10 buyers cite the bonus as the reason, the bonus IS the product — and should be promoted to a standalone offer with a proper core promise, not kept as a supporting element.
'Removing it will reduce conversion.'
A/B test: run the offer with and without the bonus for 100 visitors each. Measure conversion. If conversion drops 20%+, the bonus was a significant driver and the offer needs a replacement bonus of equivalent strength before the cut is executed.
Most bonus cuts produce no measurable conversion change when the remaining stack is strong. The fear of conversion loss from cutting a weak bonus is almost always larger than the actual impact.
'It was expensive to create.'
Sunk cost. The cost of creation is irrelevant to whether the bonus is earning its place in the stack today.
The cost is already spent. The question is only whether the bonus is producing value relative to its continuation cost (maintenance and confusion tax on the stack).
PHASE 6
New Bonus Design System
Building bonuses that pass the discipline test before they enter the stack
The Pre-Entry Gate
Before any new bonus is added to any offer stack: it must have a documented sub-problem statement, a named source of evidence that the sub-problem exists (Objection Bank entry, exit interview data, or buyer support ticket), a specific format that solves the sub-problem with minimum effort from the buyer, and a preliminary Flagship Promise Test run with 3 avatar-matched individuals confirming that adding it does not reduce the Clarity Index.
TEMPLATE 1
The Implementation Shortcut
Use when
The buyer needs to complete a specific implementation task on the path to the core promise. Without this bonus, they would need to figure it out from scratch, taking significantly longer or making common errors. This bonus pre-solves the task.
Best formats
Done-for-you template. Swipe file. Fill-in-the-blank system. Pre-built framework the buyer customises.
RISER Nation examples
30-Day DM Outreach Playbook (solves: writing outreach from scratch). Sales Page Copy Swipe File (solves: blank-page paralysis on copy). Hook Formula Template (solves: not knowing how to start short-form content).
Naming convention
The [Adjective] [Task Name] [Container]: 'The 14-Day Email Welcome Sequence Template.' 'The Hook Engineering Swipe File.' Name should make the task and the shortcut immediately obvious.
Perceived value range
$97–$297 (high perceived value because it saves hours of work the buyer would otherwise have to do).
TEMPLATE 2
The Diagnostic Tool
Use when
The buyer needs to assess their specific situation before they can execute a step in the core programme. Without this bonus, they would guess or use generic advice that may not apply to their context.
Best formats
Scorecard. Quiz with scored outputs. Diagnostic checklist. Assessment framework with interpretation guide.
RISER Nation examples
The Niche Viability Scorecard (solves: not knowing if a niche is viable before building). The Offer Health Quick-Check (solves: not knowing which part of the offer is underperforming). The Avatar Validation Survey Template (solves: building an avatar without buyer validation).
Naming convention
The [Subject] [Diagnostic Noun]: 'The Niche Viability Scorecard.' 'The Copy Health Diagnostic.' 'The Audience Readiness Assessment.'
Perceived value range
$47–$197 (valuable because it replaces expensive professional assessment).
TEMPLATE 3
The Decision Accelerator
Use when
The buyer faces a decision point during implementation where multiple options exist and choosing the wrong one will cost significant time or money. Without this bonus, they would research extensively or guess.
Best formats
Comparison guide. Decision tree. Vendor/platform evaluation rubric. 'Should I...' flowchart.
RISER Nation examples
The Platform Priority Map (solves: not knowing which platform to prioritise for content distribution). The Tech Stack Decision Guide for Operators (solves: which tools to use at each stage). The Paid Traffic Platform Selector (solves: which ad platform is right for this offer at this stage).
Naming convention
The [Subject] [Decision Noun]: 'The Platform Priority Map.' 'The Tech Stack Selector.' 'The Traffic Source Decision Tree.'
Perceived value range
$47–$197 (perceived value: saves the cost of trying three wrong options first).
TEMPLATE 4
The Expert Shortcut
Use when
The buyer needs input, feedback, or perspective from someone with direct experience in their specific situation. Without this bonus, they would need to find and pay for that expertise separately — or go without.
Best formats
Group Q&A call. Hot seat recording. Live review session. Expert office hours. Panel of practitioners.
RISER Nation examples
Live Implementation Workshop (solves: getting stuck mid-programme without expert guidance). Offer Teardown Hot Seat Recording (solves: not knowing if the offer design is sound). Sales Call Practice Session (solves: lack of confidence on live calls before the first real ones).
Naming convention
The [Expert Activity] [Container]: 'The Live Implementation Workshop.' 'The Offer Teardown Session.' Avoid vague names like 'Expert Coaching Call' — name the specific expert activity.
Perceived value range
$197–$497 (high perceived value because expert access is the most expensive item in any knowledge business).
TEMPLATE 5
The Social Proof Accelerator
Use when
The buyer needs credibility signals, case study examples, or reference materials to use in their own business as they implement the core programme. Without this bonus, they would need to build those signals from scratch.
Best formats
Case study bank. Testimonial script. Proof-collection system. Before/after documentation template.
RISER Nation examples
The Client Results Documentation System (solves: not having a professional way to capture and display results). The Testimonial Extraction Interview Guide (solves: getting generic testimonials instead of specific-metric ones). The Trust Signal Library Template (solves: no organised way to display credibility).
Naming convention
The [Outcome] [System/Tool]: 'The Results Documentation System.' 'The Social Proof Collection Kit.' 'The Credibility Asset Builder.'
Perceived value range
$97–$247 (perceived value: replaces professional brand or PR work).
TEMPLATE 6
The Safety Net
Use when
The buyer carries a specific risk or fear about what happens if one element of the implementation does not go as expected. This bonus addresses that specific 'what if' scenario directly, removing the implementation fear that might otherwise prevent them from committing or executing.
Best formats
Contingency playbook. 'What if it doesn't work' protocol. Risk mitigation guide. Recovery framework.
RISER Nation examples
The Launch Recovery Protocol (solves: fear of what to do if the launch underperforms). The Refund-Rate Rescue Playbook (solves: fear of post-launch refund spikes). The Tech Failure Response Guide (solves: fear of technical problems during live delivery).
Naming convention
The [Risk Scenario] [Protocol/Playbook]: 'The Launch Recovery Protocol.' 'The Risk Mitigation Playbook.' Make the specific risk visible in the name — it signals that you anticipated and planned for the buyer's exact fear.
Perceived value range
$97–$297 (perceived value: risk insurance is priced against the potential cost of the risk materialising).
PHASE 7
The Bonus Naming and Value Assignment System
Every bonus needs a name that earns attention and a value that earns credibility
Naming Criterion
Test
Pass Example
Fail Example
Describes the output, not the process
Does the name tell the buyer what they will have after using this bonus — not what they will do to get it?
'The 30-Day DM Outreach Playbook' — buyer knows they will have a playbook of DM sequences.
'The Outreach Training' — buyer knows they will learn about outreach. No sense of deliverable.
Contains a specificity signal
Does the name contain a number, a timeframe, a named format, or a named method that implies precision?
'The 14-Day Email Welcome Sequence Template' — '14-Day' implies a specific, complete structure.
'The Email Templates' — no specificity. Could be 3 emails or 300.
Implies the sub-problem it solves
Without reading any description, can a buyer in your target avatar hear the name and immediately understand what problem it addresses?
'The Blank-Page Hook Eliminator' — implies it solves the blank-page problem in hook writing.
'Creative Assets Pack' — no sub-problem implied. Could be anything.
Passes the 48-hour recall test
Read the bonus name once to an avatar-matched individual. Ask them to recall it 48 hours later. If they can recall it accurately — the name is working.
Name recalled accurately by 4 of 5 testers.
Name recalled with wrong specifics or not at all by 3+ testers.
Valuation Method
When to Use
How to Calculate
Example
Market equivalence
When a comparable service, tool, or programme is available for purchase somewhere in the market
Research the market price for a comparable solution. The standalone value should be the low-to-mid range of comparable pricing, not the highest-priced alternative.
A template pack of 14 sales copy frameworks: comparable standalone products on Gumroad, Etsy, and Creative Market sell at $27–$67. Stated value: $47.
Service substitution
When the bonus replaces a professional service the buyer would otherwise hire out
Research the going rate for the service in the buyer's market. The bonus value is what the buyer saves by not hiring it out.
A sales call recording review with scoring rubric: a sales coach charges $150–$300/hour. The bonus covers this function for the duration of the programme. Stated value: $197.
Time substitution
When the bonus saves the buyer a specific number of hours they would otherwise spend researching, deciding, or building from scratch
Calculate the buyer's approximate hourly rate × hours saved. The stated value should reflect actual time saved, not an inflated estimate.
A platform comparison guide that saves 4 hours of research for a buyer whose time is worth $75/hour: stated value = $297 (4 × $75 = $300 rounded to nearest $47 price point).
Proprietary method premium
When the bonus contains a proprietary framework, diagnostic, or process that cannot be found elsewhere
Base the value on comparable courses or workshops that teach the closest available equivalent methodology
A proprietary scoring rubric that does not exist in the market. Comparable diagnostic tools: $47–$197. Stated value: $147.
PHASE 8
The Audit Cadence and Trigger System
When to run the audit and what events fire it outside the quarterly schedule
Quarter
Timing
Scope
Preparation Required
Q1 Audit
First week of January
All active offer stacks. Priority on any stack that received buyer feedback in Q4 suggesting bonus confusion or low utility.
Pull Q4 exit interview utility scores. Pull Q4 access rate data from course platform. Run Flagship Promise Test with fresh testers.
Q2 Audit
First week of April
All active offer stacks. Add any new offers launched in Q1.
Pull Q1 data. Confirm any Q1 Reform verdicts have been executed. Check if any Q1 Cut bonuses have been archived correctly.
Q3 Audit
First week of July
All active offer stacks. Highest-value audit of the year — full-year buyer data available.
Pull H1 exit interview data (6 months of utility scores and access rates). Strong basis for cut decisions. Incorporate into August/September relaunch planning.
Q4 Audit
First week of October
All active offer stacks. Pre-launch preparation for any Q1 launches.
Use Q4 audit to finalise stacks for next year's first cohort. Any Cut verdict executed in Q4 improves the January launch.
Trigger Event
What to Audit
Urgency
Why
Offer Scorecard D5 (Offer Stack Strength) scores 2 or below
All bonuses in that offer's stack. Full 5-dimension scoring.
Within 14 days of scorecard session
D5 below 3 is a signal that the stack is failing the buyer. Cannot wait for quarterly cadence.
Exit interview utility survey produces an average below 5.0 for any single bonus
That specific bonus — full 5-dimension scoring. Other bonuses in the stack are not triggered.
Within 7 days of survey processing
A below-5.0 utility score from buyers who have used the bonus is immediate signal that the bonus is not earning its place.
Post-MVO Forensic Audit Loop Phase 2 (Value Equation Audit) shows Effort & Sacrifice degrading
Review all bonuses for evidence of creating effort confusion rather than effort reduction. Check D4 (Promise Coherence) specifically.
Within the 30-day window post-forensic audit
A degrading Effort & Sacrifice score in the Value Equation may indicate bonuses are adding perceived complexity rather than reducing friction.
A new Major or Minor version of any offer is being planned (CAT-O change from Product Versioning SOP)
Full bonus inventory audit for that offer before the new version is designed
Before finalising the new version's offer stack
A version change is the natural moment to refresh the stack. Audit first, build second.
Buyer language mining data reveals a new high-frequency sub-problem not currently addressed by any bonus
Not an audit trigger — a new bonus design trigger. Run the Pre-Entry Gate for a new bonus designed around the newly-identified sub-problem.
Within 30 days of the mining data being flagged
New buyer language data revealing an unaddressed sub-problem is a direct brief for a new bonus. Build immediately per the New Bonus Design System (Phase 6).
#
Dimension
What It Measures
1
2
3
4
5
Score
D1
Sub-Problem Specificity
Does this solve a named sub-problem on the path to the core promise?
No named sub-problem
Vague or loosely connected
Specific but evidence thin
Specific + evidenced
Specific + evidenced + buyer-confirmed
___
D2
Buyer Utility Score
How useful do buyers rate this bonus?
Below 5.0 or unmeasured
5.0–5.9
6.0–6.9
7.0–7.9
8.0+
___
D3
Access Rate
What % of buyers access this bonus?
Below 20%
20–29%
30–49%
50–64%
65%+
___
D4
Promise Coherence
Is this clearly supporting the core promise without competing?
Competes with or duplicates core
Adjacent but connection unclear
Related, needs explanation
Clearly supporting
Instantly obvious connection + named in mechanism
___
D5
Delivery Sustainability
Can this be maintained sustainably?
Outdated or high-cost maintenance
High maintenance, no process
Annual update needed, manageable
Low maintenance, documented
Evergreen or systematised refresh
___
TOTAL SCORE
Maximum 25 — KEEP: 18–25 | REFORM: 10–17 | CUT: 0–9 | D1=1 → Auto-Cut regardless of total
___
Field
Type
Notes
Audit ID
Autonumber
Format: BDA-[Offer Code]-[YYYY-Q#]. e.g. BDA-MVO-2026-Q2
Offer
Link → Offers table
Audit Date
Date
Auditor(s)
Short text
Trigger
Single select
Quarterly Cadence / Offer Scorecard D5 / Exit Survey Low Score / Value Equation Degradation / Version Change / Buyer Language Signal
Pre-Audit Stack Size
Number
Total bonus count before this audit
Pre-Audit Clarity Index
Number
Flagship Promise Test result before audit (x of 5)
Bonuses Audited
Link → Bonus Records
All bonuses scored in this session
Verdicts — KEEP
Number
Count of bonuses receiving Keep verdict
Verdicts — REFORM
Number
Count of bonuses receiving Reform verdict
Verdicts — CUT
Number
Count of bonuses receiving Cut verdict
Post-Audit Stack Size
Number
Projected bonus count after Cut and Reform verdicts are executed
Post-Audit Clarity Index
Number
Flagship Promise Test result after audit changes applied
Reform Actions Assigned
Long text
One Action Definition Format entry per Reform bonus
Cut Execution Status
Single select
Pending / In Progress / Complete
Version Changelog Entry
Link → Changelog Entries
The CAT-O changelog entry for stack changes resulting from this audit
Next Scheduled Audit
Date
Quarterly cadence date or event-based trigger
New Bonus Briefs Generated
Long text
Any new bonus design briefs triggered by sub-problem gaps identified in this audit

Original Word reading order, tables, headers and footers

RISER NATION

MASTER OPERATING SYSTEM

SOP — BONUS DISCIPLINE AUDIT

The Quarterly System for Keeping, Reforming, or Cutting Every Bonus in the Stack — So Each One Earns Its Place

Kennedy × Hormozi × Brunson × 2026 Framework

Version 1.0 | 2026 Edition | RISER Nation Master Operating System

SOP Overview

Bonuses were designed to solve a specific problem in offer design: the value equation problem. When a buyer cannot directly perceive the gap between price and transformation, the bonus stack closes that gap by accumulating visible, named value until the total makes the price feel obviously correct.

Most operators understand this. What most operators miss is that the bonus stack degrades over time. Bonuses added in early validation remain in the stack long after buyers have stopped finding them useful. New bonuses get added reactively — in response to a low conversion week or a competitor's stack — without any evaluation of whether they solve a real sub-problem or simply add visual bulk. The stack grows. The clarity of the core promise shrinks. And eventually the buyer cannot identify what the offer actually IS underneath the pile of bonuses.

The Bonus Discipline Audit is the quarterly ritual that reverses this. It evaluates every bonus in every active offer stack against a hard criterion — each bonus must solve a specific, named sub-problem on the path to the core promise — and produces a verdict for each: Keep, Reform, or Cut. It also defines the design system for building new bonuses that pass the discipline test before they enter the stack, and the measurement system that tracks whether bonuses are contributing to conversion or simply occupying real estate.

The Hormozi Standard The Thud Factor works when bonuses are coherent. It fails when bonuses are filler. 'All of THAT for this price?' is the reaction you're engineering. But if the buyer cannot figure out what the core offer actually IS because the stack is so large and so varied, the Thud Factor backfires into the Confusion Factor — and confusion kills more sales than scarcity ever creates.

The Kennedy Warning More is not always more. A stack of twelve bonuses, half of which are recycled PDFs with no specific connection to the core promise, is worth less than a stack of three bonuses where each one solves a problem the buyer was afraid they'd face on the way to the result. The discipline is not in the counting. It is in the relevance.

The MVO Playbook Rule — Made Operational Your own MVO Playbook V5 states it directly: 'The Thud Factor fails when bonuses are filler that dilutes clarity. If the prospect can't figure out what the CORE offer actually IS, conversions drop. Every bonus must clearly solve a specific sub-problem. Confusion kills more sales than scarcity creates.' This SOP is the operational system that enforces that rule on every active offer, on a repeating quarterly schedule.

The Two Bonus Stack Failure Modes

Before the audit framework, the system requires a clear picture of what bonus stack failure actually looks like. There are two distinct failure modes, each producing different symptoms and each requiring a different remediation.

Failure Mode | Description | Symptoms | Common Cause | Remediation
Filler Accumulation | The stack grows over time as bonuses are added reactively — to match a competitor, respond to a poor conversion week, or fill perceived value gaps — without each new bonus being held to the sub-problem test. The stack becomes wide but shallow: many bonuses, none of which solve a specific problem that buyers were actually encountering. | High stack volume but low buyer utility scores in exit surveys. Support tickets asking 'What do I do with [bonus X]?' Bonuses being listed on the sales page but never accessed in the course platform. Buyers in exit interviews unable to name more than 2–3 of the listed bonuses. | Bonus additions happen without a defined standard. New bonuses are added in response to external pressure (competitor, conversion drop) without internal qualification criteria. No removal process exists — every bonus added is permanent by default. | Bonus Discipline Audit — Cut phase. Remove all bonuses scoring below the sub-problem threshold. Each removal increases the clarity of the bonuses that remain.
Clarity Collapse | The stack is technically coherent — each bonus solves a real sub-problem — but there are too many of them. The buyer cannot identify the core promise because the stack has grown to eclipse it. The bonuses outnumber the core deliverables. The sales page looks like a product catalog rather than a transformation offer. | Core promise buried in the stack slide. Buyers cite bonuses as the reason for purchase more than the core transformation. Testimonials reference bonus value rather than programme outcome. The 'Flagship Promise Test' fails — buyers cannot repeat the core promise in one sentence because the stack has obscured it. | Gradual accumulation without a maximum stack discipline rule. Success of individual bonuses leads to 'more is better' thinking without recognising the clarity cost. | Apply the Flagship Promise Test and the Stack Maximum Rule (see Phase 2). Retire excess bonuses to an 'available as upgrades' position rather than deleting them entirely.

The Core Discipline Standard: The Sub-Problem Test

The single non-negotiable criterion for every bonus in every stack, applied uniformly regardless of how long the bonus has been in the offer or how much work went into creating it:

The Sub-Problem Test — The One Rule That Governs All Bonus Decisions Every bonus must solve a specific, named sub-problem that a buyer will encounter on the path between purchasing the offer and achieving the core promise.

A sub-problem is specific enough that you can describe it in one sentence beginning with 'The buyer is struggling with...' or 'Without this, the buyer will get stuck at...'

All three categories fail the test. All three must be cut or reformed.

What a Sub-Problem Is — and Is Not

Category | Definition | Examples That Pass | Examples That Fail
Valid Sub-Problem | A specific obstacle, skill gap, or implementation challenge that arises after the buyer commits to the transformation but before they complete it. It is distinct from the core promise — solving it gets them closer to the main result but is not the main result itself. | 'Without knowing which platform to post on first, the buyer will waste 3 weeks testing instead of gaining traction.' (Bonus: Platform Priority Map)

'The buyer will need to write cold outreach but has no templates — every email will take 45 minutes.' (Bonus: 30-Day DM Outreach Swipe File) | 'More content about the topic.' (Not a sub-problem — it is volume, not gap-filling)

'A community where they can ask questions.' (Community is a support structure, not a sub-problem solution — unless access to expert peers IS the specific bottleneck)
Invalid: Cosmetic Value | An addition that makes the stack look bigger or more impressive without solving a problem. Often a PDF workbook, a resource list, or an audio recording that has no clear connection to a specific buyer obstacle. | N/A | 'The Ultimate Resource Guide' — a 40-page PDF of tools and links with no specific application to any sub-problem.

'Bonus Training: Success Mindset' — motivational content with no sub-problem connection.
Invalid: Duplicate Solving | A bonus that solves the same problem the core offer already solves. It reinforces the core rather than bridging a gap. Buyers who have the core do not need an additional solution to the same problem. | N/A | Adding an 'offer construction checklist' bonus to an offer whose core promise IS offer construction. The bonus duplicates the core.
Invalid: Wrong-Path Problem | A bonus that solves a real problem — but a problem that arises AFTER the buyer has already achieved the core promise. Premature ascension material presented as a bonus. | N/A | Adding a 'paid traffic scaling playbook' bonus to an offer whose core promise is validating a first offer organically. The buyer doesn't have the problem yet.

The Flagship Promise Test — Applied to the Stack

The Flagship Promise Test (from MVO Playbook V5, Phase 2) is applied to the full stack before and after every audit. Read the full stack — core deliverables and all bonuses — to five avatar-matched individuals who have not seen the offer before. Ask them: 'In one sentence, what does this offer do for you?'

• If 4 of 5 testers can state the core transformation accurately — the stack is disciplined. The bonuses are not obscuring the promise.

• If 2 or 3 of 5 testers state a bonus outcome rather than the core transformation — the stack is approaching Clarity Collapse. One or more bonuses are competing with the core promise for the buyer's attention.

• If fewer than 2 of 5 testers can identify the core transformation — the stack has fully collapsed into Clarity Collapse. The audit's Cut phase must produce a significantly shorter stack before the offer is scaled or relaunched.

PHASE 1 The Bonus Inventory Documenting every bonus in every active stack before any evaluation begins

The Inventory Protocol

The audit cannot begin without a complete, accurate inventory of every bonus currently in every active offer stack. This sounds obvious — but most operators cannot immediately name every bonus in their stack and describe what sub-problem each one solves. If you cannot do that without referring to the sales page, the stack already has a discipline problem.

The Memory Test Before opening the sales page: write down every bonus currently in your most important offer's stack from memory. Then open the sales page. Any bonus you could not remember is a candidate for the Cut pile — if it does not stick in your own memory, it is unlikely to register in the buyer's mind either.

The Bonus Inventory Template

Complete one row per bonus per offer. This is the raw material for the full audit in Phase 2.

Field | What to Document | Example
Bonus ID | A unique code: [Offer Code]-B[Sequence]. e.g. MVO-B03 | MVO-B03
Bonus Name (as stated on sales page) | Exact name as it appears in the stack slide — not a description. | The 30-Day DM Outreach Playbook
Bonus Format | The physical form of the deliverable. | Template pack (14 DM scripts + 3 follow-up frameworks, PDF)
Date Added to Stack | When was this bonus first included in this offer? | Added at V1.2.0 (2025-09-10 per Changelog)
Stated Standalone Value | The dollar value assigned to this bonus on the sales page. | $197
Sub-Problem It Claims to Solve | In one sentence: 'The buyer is struggling with ___.' Fill this in from your own knowledge — before looking at the sales page copy for clues. | 'The buyer needs to send outreach messages but has no proven templates, so they spend 45 minutes per message and get inconsistent results.'
Evidence That This Sub-Problem Is Real | Specific data: buyer support tickets, exit interview phrases, Objection Bank entries, community posts that confirm this specific problem is encountered on the path to the core promise. | Exit interview Q3 (5 of 12 respondents): 'I struggled with what to say in outreach.' Support tickets tagged 'outreach help': 6 in last 30 days. Objection Bank entry OBJ-MVO-019: 'I don't know what to say in DMs.'
Buyer Utility Score (if available) | Exit interview or pulse survey data: how useful did buyers rate this specific bonus? Scale 1–10. | 7.4/10 average from last cohort exit survey Q: 'Rate the usefulness of each component.'
Access Rate | Of buyers who purchased, what % actually accessed this bonus in the course platform? (Kajabi analytics) | 61% accessed — above the 50% threshold.
Delivery Cost to Creator | Time to maintain, update, or deliver this bonus. Is it evergreen or does it require periodic refresh? | Evergreen — templates require refresh every 12 months to reflect platform changes. ~2 hours annually.

PHASE 2 The Five-Dimension Scoring System Evaluating every bonus against an objective standard before rendering a verdict

The Five Dimensions

Every bonus is scored across five dimensions. Each dimension has a specific scoring criterion. The five dimension scores sum to a maximum of 25 (5 per dimension). The total score maps to a verdict: Keep, Reform, or Cut.

Dimension | What It Measures | Score 1 | Score 3 | Score 5
D1 — Sub-Problem Specificity | Does this bonus solve a specific, named sub-problem on the path to the core promise? | No named sub-problem. Adds value generally but cannot be described as solving a specific obstacle. | A sub-problem exists but is vague, broad, or only loosely connected to the path to the core promise. | Clear, specific sub-problem stated in one sentence. Problem is confirmed by buyer data (support tickets, exit interviews, or Objection Bank entries).
D2 — Buyer Utility Score | How useful do buyers find this bonus in practice? | Score below 5.0 from exit survey or pulse survey. Or no data available — has never been measured. | Score 5.0–6.9. Adequate but not compelling. Many buyers find it useful; some find it irrelevant. | Score 7.0+. Consistently rated as highly useful by buyers who access it. Frequently cited in exit interviews as a purchase driver.
D3 — Access Rate | What percentage of buyers actually access this bonus? | Below 30% access rate. Most buyers who purchased never use this bonus. | 30–49% access rate. About a third to half of buyers engage with it. | 50%+ access rate. More than half of buyers access and use this bonus. Strong signal of perceived relevance.
D4 — Promise Coherence | Is this bonus clearly connected to the core promise — not competing with it, not duplicating it? | This bonus describes an outcome similar to the core promise itself, creating confusion about what the core offer does. OR it solves a problem that arises after the core promise is achieved. | This bonus is adjacent to the core promise but the connection is not obvious without explanation. Buyers may not understand why it is included. | This bonus is clearly a supporting solution that helps buyers achieve the core promise. Its connection to the core outcome is immediately obvious without explanation.
D5 — Delivery Sustainability | Can this bonus continue to be delivered at the stated quality indefinitely without disproportionate maintenance cost? | High maintenance cost with no sustainable update process. OR the bonus references tools, platforms, or information that have already become outdated. | Moderate maintenance cost. Requires annual update. No dedicated process exists but updates are manageable. | Low maintenance cost. Evergreen content requiring minimal updates. OR a systematic update process exists that is already documented.

The Verdict Thresholds

After scoring all five dimensions (maximum 25 points), map the total to a verdict using these thresholds. The verdict thresholds are hard — rounding up out of attachment to a bonus is the most common audit failure mode.

KEEP Total score 18–25 — Bonus is earning its place in the stack This bonus solves a real sub-problem, buyers find it useful and actually access it, it is coherent with the core promise, and it is deliverable sustainably. It stays in the stack. Update the Airtable record with current scores. Schedule next audit in 6 months.

REFORM Total score 10–17 — Bonus has merit but a specific weakness to fix This bonus has real value but is underperforming on one or more dimensions. It is not cut — it is improved. The specific dimensions scoring below 3 identify exactly what the reform should address. Reform must be completed before the next cohort or within 60 days. If reform is not completed by the deadline, the verdict is automatically changed to Cut.

CUT Total score 0–9 — Bonus is failing the discipline standard This bonus does not solve a named sub-problem (or solves the wrong one), is not used by most buyers, and is likely contributing to Clarity Collapse in the stack. It is removed from the stack. Existing buyers retain access for 90 days per the Entitlement Policy (Product Versioning SOP). The sales page is updated within 14 days. See Phase 5 for the Cut Execution Protocol.

The Mandatory Override Rules

Two rules override the scoring system and produce automatic verdicts regardless of total score:

Automatic Cut Rule — D1 Score of 1 Any bonus scoring 1 on Dimension D1 (Sub-Problem Specificity) is automatically cut regardless of its total score. A bonus that does not solve a named sub-problem has no legitimate place in a disciplined stack — not even if it is beloved by buyers, consistently accessed, and easy to maintain. The discipline starts with the sub-problem test. A bonus that fails it does not belong in the stack.

Automatic Reform Rule — D2+D3 Both Score 1 Any bonus where both Dimension D2 (Buyer Utility Score) AND Dimension D3 (Access Rate) score 1 is automatically set to Reform or Cut, not Keep, regardless of other dimension scores. A bonus that buyers rate as useless AND that most buyers never access is producing negative value — it is contributing to the buyer's perception that the stack is padded, which undermines the credibility of the bonuses that are genuinely useful.

PHASE 3 The Stack Maximum Rule and Clarity Index How many bonuses is the right number — and how to measure stack clarity

The Stack Maximum Rule

There is no universally correct number of bonuses. The right number is offer-specific and depends on the number of real sub-problems that exist on the path to the core promise. However, every stack has a maximum beyond which adding another bonus, regardless of its quality, will degrade clarity.

Offer Type | Recommended Bonus Count | Maximum Before Clarity Risk | Rationale
Entry-point / Tripwire ($7–$97) | 1–2 bonuses | 3 | At this price point, clarity of the core promise is paramount. More than 3 bonuses at entry-level suggests either Filler Accumulation or that the core offer is not strong enough alone.
MVO / Frontend Offer ($97–$497) | 2–4 bonuses | 5 | The MVO must have a clear core deliverable that can pass the Flagship Promise Test. 5+ bonuses at this tier is the most common trigger for Clarity Collapse because the buyer has not yet fully committed and is more susceptible to confusion.
Core Offer ($497–$4,997) | 3–6 bonuses | 7 | More complex transformation means more real sub-problems. A 6-bonus stack for a 90-day programme with 4 implementation phases is disciplined if each bonus solves a distinct phase-specific sub-problem.
High-Ticket / DWY ($2,500–$25,000) | 1–3 bonuses | 4 | At this price point, the stack is less important than the access and proximity being sold. Heavy bonus stacking at high-ticket suggests the operator lacks confidence in the core offer. Buyers at this tier are buying the operator's time and expertise — not template packs.
Continuity / MRR ($47–$997/mo) | 0–2 bonuses per renewal cycle | 3 | Continuity bonuses are best delivered as monthly value drops — new mechanisms, tools, and templates that justify the recurring payment. They are not a static stack. A fixed continuity bonus stack beyond 3 items signals membership bloat, not membership value.

The Clarity Index

The Clarity Index is the Flagship Promise Test score: the percentage of 5 avatar-matched testers who can state the core promise accurately after reviewing the full offer description. It is calculated after the audit and compared against the pre-audit baseline.

Clarity Index | Interpretation | Action
5/5 (100%) | Maximum clarity. The stack is fully disciplined. Every bonus is supporting the core promise without competing with it. | Maintain the current stack. Run the Clarity Index again at the next quarterly audit.
4/5 (80%) | Good clarity with a minor gap. One tester was distracted by a bonus. | Identify which tester cited a bonus outcome rather than the core promise. Which bonus generated that distraction? Review that bonus's D4 (Promise Coherence) score.
3/5 (60%) | Clarity is degrading. Two testers are confused about what the offer primarily does. | The stack is approaching or has reached Clarity Collapse. At least one bonus needs to be cut or repositioned. Run the Flagship Promise Test on each bonus individually to identify the confuser.
2/5 or below (below 60%) | Clarity Collapse confirmed. The stack is obscuring the core promise. | Immediate action required. Apply the Stack Maximum Rule: cut the stack to the recommended maximum for this offer type regardless of individual bonus scores. Retain the highest-scoring bonuses within that maximum.

PHASE 4 The Reform Protocol What to do with a bonus that earns Reform — the exact fixes for each weakness

Reform vs Cut: The Decision Point

The Reform verdict means the bonus has real merit — it solves a real sub-problem (D1 scores at least 3), but it is underperforming on at least one other dimension. Reform is not an indefinite suspension. Every bonus in Reform status must have a specific remediation action, a named owner, and a 60-day deadline. If reform is not completed on time, the verdict changes to Cut automatically.

The Reform Deadline Rule A Reform bonus that has been in Reform status for more than 60 days without a documented completion is automatically Cut at the next monthly review. There is no second Reform cycle. If the fix could not be done in 60 days, the bonus is not a current-version asset — it either needs to be retired or rebuilt as a new bonus for a future version of the offer.

Reform Prescriptions by Dimension

Weak Dimension | Score | Prescribed Reform | Implementation
D1 — Sub-Problem Specificity | Score 3 (vague or broad) | Rewrite the sub-problem statement in the one-sentence format: 'The buyer is struggling with [specific obstacle] at [specific stage] of the [specific journey].' Then rewrite the bonus name and description to make the connection to that sub-problem explicit and immediate. | Update bonus name and description on sales page, Stack Slide, and course platform. Update Airtable record with revised sub-problem statement. Confirm with the next exit interview cohort that the connection is now clear.
D2 — Buyer Utility Score | Score 3 (utility 5.0–6.9) | The bonus is mildly useful but not compelling. Two possible fixes: (1) Upgrade the format — if a PDF, convert to a template. If a template, add a worked example. If a recording, add a structured reference guide alongside. (2) Narrow the scope — a broadly useful bonus with a 6.0 score is often a narrowly useful bonus with a 9.0 score hiding inside. Remove the generic elements and focus on the highest-value specific element. | Test the upgraded format with 3–5 buyers from the current cohort before redeploying. Re-survey for utility score. Target: 7.0+ before returning to active stack.
D3 — Access Rate | Score 3 (30–49% access) | Low access rate usually has one of three causes: (1) The bonus is buried in the course platform — move it to a more prominent location (Day 1 or within the first module). (2) The bonus is not referenced in the onboarding email sequence — add a specific mention with a direct link. (3) Buyers do not understand when to use it — add a trigger statement: 'Use this when you reach Step 3 of Module 2.' | Add one-sentence placement instruction to each point where the bonus could be used. Add a direct link to the bonus in the Day 1 onboarding email. Re-measure access rate after the next cohort.
D4 — Promise Coherence | Score 3 (adjacent but not obvious) | The bonus is genuinely related to the core promise but the connection is not clear. Two fixes: (1) Rename the bonus to make the connection explicit. 'The Lead Gen Template Pack' becomes 'The Outreach-to-Booked-Call Template Pack' — now the connection to the call-booking core promise is immediate. (2) Add a one-sentence context statement to the Stack Slide: 'This solves the outreach problem that stops most people at Step 4 of the method.' | Update bonus name and Stack Slide context statement. Run Flagship Promise Test after the update to confirm Clarity Index has improved.
D5 — Delivery Sustainability | Score 3 (moderate maintenance, annual update needed) | Create an update schedule and document it. Add the bonus to the Quarterly Refresh Calendar (first Monday of October or the equivalent in your planning cycle). Assign a specific owner for the annual update. If the bonus references time-sensitive information (platform features, pricing data), add a 'Last updated' date to the deliverable. | Log in Airtable: update frequency, owner, next update date. Add to the quarterly planning calendar. Deliver the first scheduled update within 90 days of the Reform verdict.

PHASE 5 The Cut Execution Protocol Removing a bonus cleanly — without damaging existing buyer relationships

The Clean Cut Principle

Cutting a bonus is not a crisis event. It is a routine product iteration that improves the offer's clarity and focus. The execution must be clean: existing buyers are protected, the sales page is updated correctly, and the bonus is archived rather than deleted — because a bonus cut from one offer may become the foundation of a standalone tool unbundle or a future offer's bonus stack.

The Cut Execution Checklist

1. Record the Cut decision in Airtable: verdict date, total audit score, which dimensions scored low, and the specific reason for the Cut verdict. This becomes the institutional memory for future offer design.

2. Determine existing buyer entitlement. Per the Product Versioning SOP (Phase 4 — Existing Buyer Entitlement Policy): all buyers who purchased any prior version of the offer retain access to the cut bonus for a minimum of 90 days after removal from the sales page.

3. Do not announce the cut to the general market. A sales page update removing a bonus does not require a public announcement. It requires a Minor version changelog entry (CAT-O: Offer Stack Change) per the Product Versioning SOP.

4. If any existing buyer has specifically referenced the cut bonus in a support ticket, community post, or direct message within the past 30 days — send a proactive personal email within 24 hours explaining the change and confirming their continued access. This is a surgical notification, not a broadcast.

5. Update the sales page bonus stack section. Remove the bonus from the Stack Slide visual. Recalculate the total stated value. Confirm the remaining stack still passes the Flagship Promise Test.

6. Update the email sequence. Remove any email that specifically introduces or promotes the cut bonus (typically Day 10 — Bonus Explanation). If the bonus was a core reason-to-buy in the sequence, rewrite the section with the most compelling remaining bonus.

7. Archive the bonus deliverable in Google Drive under 'Offer Archive > [Offer Name] > Cut Bonuses > [Version]'. Tag with date of removal and cut reason. This preserves the IP for potential repurposing.

8. Evaluate the cut bonus for unbundle potential. Per the Offer Stacking & Unbundling Strategy SOP: if the cut bonus has a standalone Unbundle Score of 7+ in the IP Asset Inventory, it is a candidate for a Tool Unbundle or Entry Point Unbundle product.

9. Update the Offer Scorecard (D5 — Offer Stack Strength) for the next monthly session. The stack reduction should improve D5 if the remaining bonuses are stronger.

Handling 'But Buyers Bought Because of That Bonus'

The most common resistance to cutting a bonus is the belief that it was a primary purchase driver — 'we'll lose sales if we remove it.' This belief is worth examining with data before using it to override an audit verdict.

Claim | How to Test It | What the Data Usually Shows
'Buyers mention that bonus as their reason for purchasing.' | Pull exit interview transcripts. Count how many buyers cite the bonus by name as their primary purchase reason (not just as something they appreciate). Compare to how many cite the core transformation. | In most cases, buyers who cite a bonus as their purchase reason are buying the sub-problem solution, not the bonus itself. If 8/10 buyers cite the bonus as the reason, the bonus IS the product — and should be promoted to a standalone offer with a proper core promise, not kept as a supporting element.
'Removing it will reduce conversion.' | A/B test: run the offer with and without the bonus for 100 visitors each. Measure conversion. If conversion drops 20%+, the bonus was a significant driver and the offer needs a replacement bonus of equivalent strength before the cut is executed. | Most bonus cuts produce no measurable conversion change when the remaining stack is strong. The fear of conversion loss from cutting a weak bonus is almost always larger than the actual impact.
'It was expensive to create.' | Sunk cost. The cost of creation is irrelevant to whether the bonus is earning its place in the stack today. | The cost is already spent. The question is only whether the bonus is producing value relative to its continuation cost (maintenance and confusion tax on the stack).

PHASE 6 New Bonus Design System Building bonuses that pass the discipline test before they enter the stack

The Pre-Entry Standard

The most efficient version of the Bonus Discipline Audit is one where the Cut verdict is rare — because new bonuses are designed to pass the discipline standard before they are added to the stack. Every new bonus must clear the Pre-Entry Gate before it is announced publicly or added to the sales page.

The Pre-Entry Gate Before any new bonus is added to any offer stack: it must have a documented sub-problem statement, a named source of evidence that the sub-problem exists (Objection Bank entry, exit interview data, or buyer support ticket), a specific format that solves the sub-problem with minimum effort from the buyer, and a preliminary Flagship Promise Test run with 3 avatar-matched individuals confirming that adding it does not reduce the Clarity Index.

The Six Bonus Design Templates

Every high-performing bonus fits one of six design templates. Building within a template ensures structural discipline — each template is built around a specific sub-problem type and a specific delivery format.

TEMPLATE 1 The Implementation Shortcut
Use when The buyer needs to complete a specific implementation task on the path to the core promise. Without this bonus, they would need to figure it out from scratch, taking significantly longer or making common errors. This bonus pre-solves the task.
Best formats Done-for-you template. Swipe file. Fill-in-the-blank system. Pre-built framework the buyer customises.
RISER Nation examples 30-Day DM Outreach Playbook (solves: writing outreach from scratch). Sales Page Copy Swipe File (solves: blank-page paralysis on copy). Hook Formula Template (solves: not knowing how to start short-form content).
Naming convention The [Adjective] [Task Name] [Container]: 'The 14-Day Email Welcome Sequence Template.' 'The Hook Engineering Swipe File.' Name should make the task and the shortcut immediately obvious.
Perceived value range $97–$297 (high perceived value because it saves hours of work the buyer would otherwise have to do).

TEMPLATE 2 The Diagnostic Tool
Use when The buyer needs to assess their specific situation before they can execute a step in the core programme. Without this bonus, they would guess or use generic advice that may not apply to their context.
Best formats Scorecard. Quiz with scored outputs. Diagnostic checklist. Assessment framework with interpretation guide.
RISER Nation examples The Niche Viability Scorecard (solves: not knowing if a niche is viable before building). The Offer Health Quick-Check (solves: not knowing which part of the offer is underperforming). The Avatar Validation Survey Template (solves: building an avatar without buyer validation).
Naming convention The [Subject] [Diagnostic Noun]: 'The Niche Viability Scorecard.' 'The Copy Health Diagnostic.' 'The Audience Readiness Assessment.'
Perceived value range $47–$197 (valuable because it replaces expensive professional assessment).

TEMPLATE 3 The Decision Accelerator
Use when The buyer faces a decision point during implementation where multiple options exist and choosing the wrong one will cost significant time or money. Without this bonus, they would research extensively or guess.
Best formats Comparison guide. Decision tree. Vendor/platform evaluation rubric. 'Should I...' flowchart.
RISER Nation examples The Platform Priority Map (solves: not knowing which platform to prioritise for content distribution). The Tech Stack Decision Guide for Operators (solves: which tools to use at each stage). The Paid Traffic Platform Selector (solves: which ad platform is right for this offer at this stage).
Naming convention The [Subject] [Decision Noun]: 'The Platform Priority Map.' 'The Tech Stack Selector.' 'The Traffic Source Decision Tree.'
Perceived value range $47–$197 (perceived value: saves the cost of trying three wrong options first).

TEMPLATE 4 The Expert Shortcut
Use when The buyer needs input, feedback, or perspective from someone with direct experience in their specific situation. Without this bonus, they would need to find and pay for that expertise separately — or go without.
Best formats Group Q&A call. Hot seat recording. Live review session. Expert office hours. Panel of practitioners.
RISER Nation examples Live Implementation Workshop (solves: getting stuck mid-programme without expert guidance). Offer Teardown Hot Seat Recording (solves: not knowing if the offer design is sound). Sales Call Practice Session (solves: lack of confidence on live calls before the first real ones).
Naming convention The [Expert Activity] [Container]: 'The Live Implementation Workshop.' 'The Offer Teardown Session.' Avoid vague names like 'Expert Coaching Call' — name the specific expert activity.
Perceived value range $197–$497 (high perceived value because expert access is the most expensive item in any knowledge business).

TEMPLATE 5 The Social Proof Accelerator
Use when The buyer needs credibility signals, case study examples, or reference materials to use in their own business as they implement the core programme. Without this bonus, they would need to build those signals from scratch.
Best formats Case study bank. Testimonial script. Proof-collection system. Before/after documentation template.
RISER Nation examples The Client Results Documentation System (solves: not having a professional way to capture and display results). The Testimonial Extraction Interview Guide (solves: getting generic testimonials instead of specific-metric ones). The Trust Signal Library Template (solves: no organised way to display credibility).
Naming convention The [Outcome] [System/Tool]: 'The Results Documentation System.' 'The Social Proof Collection Kit.' 'The Credibility Asset Builder.'
Perceived value range $97–$247 (perceived value: replaces professional brand or PR work).

TEMPLATE 6 The Safety Net
Use when The buyer carries a specific risk or fear about what happens if one element of the implementation does not go as expected. This bonus addresses that specific 'what if' scenario directly, removing the implementation fear that might otherwise prevent them from committing or executing.
Best formats Contingency playbook. 'What if it doesn't work' protocol. Risk mitigation guide. Recovery framework.
RISER Nation examples The Launch Recovery Protocol (solves: fear of what to do if the launch underperforms). The Refund-Rate Rescue Playbook (solves: fear of post-launch refund spikes). The Tech Failure Response Guide (solves: fear of technical problems during live delivery).
Naming convention The [Risk Scenario] [Protocol/Playbook]: 'The Launch Recovery Protocol.' 'The Risk Mitigation Playbook.' Make the specific risk visible in the name — it signals that you anticipated and planned for the buyer's exact fear.
Perceived value range $97–$297 (perceived value: risk insurance is priced against the potential cost of the risk materialising).

PHASE 7 The Bonus Naming and Value Assignment System Every bonus needs a name that earns attention and a value that earns credibility

The Naming Criteria

A bonus name that buyers cannot remember is a bonus that is not doing its job. The name appears on the sales page, in the Stack Slide, in the email sequence, and in conversations where buyers describe the offer to friends. It must be immediately comprehensible, memorable, and specific enough to signal what sub-problem it solves.

Naming Criterion | Test | Pass Example | Fail Example
Describes the output, not the process | Does the name tell the buyer what they will have after using this bonus — not what they will do to get it? | 'The 30-Day DM Outreach Playbook' — buyer knows they will have a playbook of DM sequences. | 'The Outreach Training' — buyer knows they will learn about outreach. No sense of deliverable.
Contains a specificity signal | Does the name contain a number, a timeframe, a named format, or a named method that implies precision? | 'The 14-Day Email Welcome Sequence Template' — '14-Day' implies a specific, complete structure. | 'The Email Templates' — no specificity. Could be 3 emails or 300.
Implies the sub-problem it solves | Without reading any description, can a buyer in your target avatar hear the name and immediately understand what problem it addresses? | 'The Blank-Page Hook Eliminator' — implies it solves the blank-page problem in hook writing. | 'Creative Assets Pack' — no sub-problem implied. Could be anything.
Passes the 48-hour recall test | Read the bonus name once to an avatar-matched individual. Ask them to recall it 48 hours later. If they can recall it accurately — the name is working. | Name recalled accurately by 4 of 5 testers. | Name recalled with wrong specifics or not at all by 3+ testers.

The Value Assignment Protocol

Every bonus must have a stated standalone value assigned on the sales page. The value assignment is not arbitrary — it must be defensible. A stated value that the buyer immediately dismisses as inflated undermines the entire stack's credibility.

Valuation Method | When to Use | How to Calculate | Example
Market equivalence | When a comparable service, tool, or programme is available for purchase somewhere in the market | Research the market price for a comparable solution. The standalone value should be the low-to-mid range of comparable pricing, not the highest-priced alternative. | A template pack of 14 sales copy frameworks: comparable standalone products on Gumroad, Etsy, and Creative Market sell at $27–$67. Stated value: $47.
Service substitution | When the bonus replaces a professional service the buyer would otherwise hire out | Research the going rate for the service in the buyer's market. The bonus value is what the buyer saves by not hiring it out. | A sales call recording review with scoring rubric: a sales coach charges $150–$300/hour. The bonus covers this function for the duration of the programme. Stated value: $197.
Time substitution | When the bonus saves the buyer a specific number of hours they would otherwise spend researching, deciding, or building from scratch | Calculate the buyer's approximate hourly rate × hours saved. The stated value should reflect actual time saved, not an inflated estimate. | A platform comparison guide that saves 4 hours of research for a buyer whose time is worth $75/hour: stated value = $297 (4 × $75 = $300 rounded to nearest $47 price point).
Proprietary method premium | When the bonus contains a proprietary framework, diagnostic, or process that cannot be found elsewhere | Base the value on comparable courses or workshops that teach the closest available equivalent methodology | A proprietary scoring rubric that does not exist in the market. Comparable diagnostic tools: $47–$197. Stated value: $147.

The Value Assignment Hard Rules

• Never assign a value above $297 to a bonus in a sub-$500 offer unless the bonus is a live coaching session or an expert access component. A $500 bonus in a $297 offer produces scepticism, not conviction.

• The total stated stack value should be 5–10× the asking price. Below 5× fails to create the 'so good they feel stupid saying no' reaction. Above 15× produces scepticism about the validity of the individual values.

• If you cannot assign a defensible standalone value — the bonus should not be in the stack. A bonus without a legitimate standalone value is a filler item with cosmetic value.

• Every stated value should survive this question: 'If this bonus were sold alone on Gumroad, what price would a stranger who has never heard of you pay for it?' If the answer is 'they wouldn't pay anything' — the stated value is fiction.

PHASE 8 The Audit Cadence and Trigger System When to run the audit and what events fire it outside the quarterly schedule

The Quarterly Cadence

The Bonus Discipline Audit runs every quarter as part of the quarterly planning cycle. The recommended timing is the first full week of each quarter — before any new cohort launches and after the prior quarter's exit interview data has been collected and processed.

Quarter | Timing | Scope | Preparation Required
Q1 Audit | First week of January | All active offer stacks. Priority on any stack that received buyer feedback in Q4 suggesting bonus confusion or low utility. | Pull Q4 exit interview utility scores. Pull Q4 access rate data from course platform. Run Flagship Promise Test with fresh testers.
Q2 Audit | First week of April | All active offer stacks. Add any new offers launched in Q1. | Pull Q1 data. Confirm any Q1 Reform verdicts have been executed. Check if any Q1 Cut bonuses have been archived correctly.
Q3 Audit | First week of July | All active offer stacks. Highest-value audit of the year — full-year buyer data available. | Pull H1 exit interview data (6 months of utility scores and access rates). Strong basis for cut decisions. Incorporate into August/September relaunch planning.
Q4 Audit | First week of October | All active offer stacks. Pre-launch preparation for any Q1 launches. | Use Q4 audit to finalise stacks for next year's first cohort. Any Cut verdict executed in Q4 improves the January launch.

Event-Based Audit Triggers

The quarterly cadence is the baseline. These specific events trigger an immediate targeted bonus audit outside the scheduled cycle:

Trigger Event | What to Audit | Urgency | Why
Offer Scorecard D5 (Offer Stack Strength) scores 2 or below | All bonuses in that offer's stack. Full 5-dimension scoring. | Within 14 days of scorecard session | D5 below 3 is a signal that the stack is failing the buyer. Cannot wait for quarterly cadence.
Exit interview utility survey produces an average below 5.0 for any single bonus | That specific bonus — full 5-dimension scoring. Other bonuses in the stack are not triggered. | Within 7 days of survey processing | A below-5.0 utility score from buyers who have used the bonus is immediate signal that the bonus is not earning its place.
Post-MVO Forensic Audit Loop Phase 2 (Value Equation Audit) shows Effort & Sacrifice degrading | Review all bonuses for evidence of creating effort confusion rather than effort reduction. Check D4 (Promise Coherence) specifically. | Within the 30-day window post-forensic audit | A degrading Effort & Sacrifice score in the Value Equation may indicate bonuses are adding perceived complexity rather than reducing friction.
A new Major or Minor version of any offer is being planned (CAT-O change from Product Versioning SOP) | Full bonus inventory audit for that offer before the new version is designed | Before finalising the new version's offer stack | A version change is the natural moment to refresh the stack. Audit first, build second.
Buyer language mining data reveals a new high-frequency sub-problem not currently addressed by any bonus | Not an audit trigger — a new bonus design trigger. Run the Pre-Entry Gate for a new bonus designed around the newly-identified sub-problem. | Within 30 days of the mining data being flagged | New buyer language data revealing an unaddressed sub-problem is a direct brief for a new bonus. Build immediately per the New Bonus Design System (Phase 6).

The Bonus Discipline Audit Scorecard

Complete one scorecard per bonus per audit session. File all completed scorecards in Airtable under Bonus Audit Records.

Bonus Audit Session Record

Complete this record in Airtable after scoring all bonuses in a session. File under Bonus Audit Records, linked to the relevant Offers and Changelog entries.

Master Bonus Discipline Audit Checklist

System Setup (One-Time)

☐ Create Bonus Records table in Airtable with fields from the Bonus Inventory Template (Phase 1)

☐ Create Bonus Audit Records table with all fields from the Audit Session Record

☐ Complete the Bonus Inventory for all active offers — one row per bonus

☐ Pull access rate data from Kajabi for all current bonuses — add to inventory

☐ Pull utility scores from most recent exit survey — add to inventory

☐ Run the Memory Test on your most important offer's stack — note any bonuses you could not name from memory

☐ Set quarterly audit calendar reminders: January, April, July, October — first week of each

Pre-Audit Preparation (Before Every Quarterly Session)

☐ Pull access rate data from course platform for all bonuses in scope

☐ Pull utility scores from exit interviews and pulse surveys (last quarter)

☐ Pull Objection Bank entries related to bonus sub-problems — confirm evidence is current

☐ Run the Flagship Promise Test with 5 fresh avatar-matched testers — record the pre-audit Clarity Index

☐ Pull the prior quarter's Bonus Audit Session Record — check that all Reform deadlines from last quarter were met

Audit Session (Every Quarterly Audit)

☐ Complete the Bonus Inventory for all bonuses in scope — confirm all fields are current

☐ Score all five dimensions for every bonus — using data, not impression

☐ Apply Automatic Override Rules: any D1=1 is auto-Cut. Any D2+D3 both=1 is auto-Reform/Cut.

☐ Record verdict for each bonus: Keep / Reform / Cut

☐ For every Reform verdict: document the specific Action Definition Format with owner and 60-day deadline

☐ For every Cut verdict: initiate the Cut Execution Checklist (Phase 5)

☐ Check Stack Maximum Rule: does the post-audit bonus count stay within the recommended maximum for this offer type?

☐ Run the post-audit Flagship Promise Test — record the Clarity Index. Confirm improvement from pre-audit.

☐ Evaluate each Cut bonus for unbundle potential using the IP Asset Inventory Unbundle Score

☐ Generate new bonus design briefs for any unaddressed sub-problems identified during the audit

☐ Complete Bonus Audit Session Record in Airtable

☐ Create CAT-O changelog entry in Product Versioning SOP for any stack changes resulting from this audit

Post-Audit Execution (Within 60 Days)

☐ Execute all Cut verdicts: sales page updated, email sequence updated, archival completed

☐ Execute all Reform actions by their documented deadlines

☐ For each Reform completion: re-run D2 and D3 scoring with fresh buyer data to confirm improvement

☐ Any Reform bonus that missed its 60-day deadline: automatically change verdict to Cut and execute

☐ Run the Pre-Entry Gate for any new bonuses designed to fill sub-problem gaps identified in the audit

☐ Add new bonuses to the Bonus Inventory before adding to the live offer stack

☐ Update Offer Scorecard D5 (Offer Stack Strength) in the next monthly session

RISER Nation Master Operating System | Bonus Discipline Audit SOP | Version 1.0 | 2026 Edition

Kennedy × Hormozi × Brunson | risernation.com

word/header1.xml: RISER Nation | Bonus Discipline Audit SOP | V1.0
word/footer1.xml: Page of
word/footnotes.xml:

word/endnotes.xml:

RISER-Build-References-for-C7.md

Carry the C6 inputs into the C7 architecture

The legacy build reference places C7 between C6 provisioning and C8 economics, followed by sustainability and transition readiness. Inputs are Offer v1.1, customer feedback, onboarding playbook, first-sale analysis, operator reality, operating cadence, financial baseline and a validated Sailboat Ready Attestation with instructor co-sign. They inform replacement architecture, decomposition/anti-promises, lifecycle, audience continuity, capacity, time tracking and enrollment respectively. These are legacy crosswalks; preserve current spreadsheet placements.

Hand the six C7 outputs to economics

Offer v2.0 becomes C8’s baseline; capacity analysis feeds the concurrent-customer ceiling; bandwidth audit feeds labor cost; SOPs feed deliverable cost; lifecycle maps feed stage cost/value; the architecture document supplies the proposed validated enrollment gate. Continue operator-versus-agency distinction, the source’s 6% iteration heuristic, 85-minute rhythm, human review, anti-promises and iteration without drift. New clauses concern honest capacity, architecture-versus-pivot and SOP operability. These are program conventions, not universal effectiveness claims.

Reconcile production scope and review gates

The build spec’s nine listed groups total 52–54 files and 71,500–86,000 target words; its header says about 48–52 files and 45–52K words, and total row says 52–56 files with 45–52K words. Retain and resolve the mismatch. It specifies Sailboat Teal #3B9EA0, fifty active hours over five-to-seven weeks and a fourteen-day measurement floor. Capacity review proposes 72 hours; final validator and instructor gates each propose 24–72 hours. Five Sonnet reviewers cover decomposition, SOPs, lifecycle, capacity and offer v2; an Opus 4.7 validator is a named source role, not a verified installed model or service commitment.

Preserve cases and deployment caveats

Maya’s second phase takes 1.5× the estimate and the offer cannot promise closed licensing deals. Darius’s smaller cohort leads to a Solo variant. Priya compares narrowing scope with expansion plus repricing. The bespoke trap overfits the first one-to-three buyers; separate universal work from customer exceptions before v2.1. The source’s deployment sequence lists build, QM audit, a ten-section SOP, ZIP and enrollment. Its 92/94 audit and 8.3-video rationale conflict with the official rubric reviewed in D0624/D0625; neither a file nor a local score certifies the course. Historical paths and claimed video production are not evidence of a live lesson.

Apply the Brunson and Hormozi teaching frame

Complete original source text

# RISER Build References for C7

**Course:** C7 Offer Architecture
**Type:** Internal build reference document
**Audience:** RISER Maritime Academy build team

---

## Purpose

This document is the build-team-facing reference for C7 deployment. It captures the inter-course dependencies, the artifacts that move across courses, and the Stage 2 transition mechanics that C7 contributes. It is not student-facing; it documents how C7 fits into the larger curriculum at the build-team level.

---

## C7's Position in the Curriculum

C7 is the **second course of Stage 2 (Sailboat)**, following C6 Sailboat Provisioning. The full Stage 2 sequence:

1. **C6 Sailboat Provisioning** — Operator achieves first-paying-customer state, articulates Offer v1.1, runs first iteration cycle.
2. **C7 Offer Architecture** — Operator structures the offer (deliverables, SOPs, lifecycle, capacity), produces Offer v2.0.
3. **C8 Unit Economics** — Operator measures and prices the v2.0 offer with honest unit economics; introduces waitlist construction.
4. **C9 Operator Sustainability** — Operator establishes sustainable working rhythm, recovery cadence, and personal economic stability at Stage 2.
5. **C10 Stage 2 to Stage 3 Transition Readiness** — Operator validates Stage 2 stability and prepares for Stage 3 (Hopper) transition decision.

C7 is the **architecture course**. C8 follows directly, taking the v2.0 architecture and applying unit-economics measurement.

---

## Inputs from C6

C7 begins with the following C6 outputs:

| C6 Output | Used in C7 At | How |
|-----------|---------------|-----|
| Offer v1.1 (M6.5) | M7.1 | The "document" that v2.0 will replace as the architecture |
| Customer Feedback Loop (M6.4) | M7.2, M7.7 | Source of v1.x signal informing what to decompose and what to anti-promise |
| Customer Onboarding Playbook (M6.3) | M7.4 | First lifecycle artifact, integrated into the broader lifecycle map |
| First-Sale Signal Analysis (M6.2) | M7.1, M7.7 | Customer profile understanding; validates anti-pivot statement |
| Operator Reality Statement (M6.1) | M7.5 | Operator working-time constraints feed into capacity analysis |
| Stage 2 Operating Cadence (M6.6) | M7.6 | Existing cadence is the time-tracking starting baseline |
| Financial Tracking Baseline (M6.7) | M7.6 | Cross-references to ensure time-tracking is consistent with financial accounting |
| Sailboat Ready Attestation (M6.8) | C7 enrollment gate | Required: VALIDATED with instructor co-sign |

---

## Outputs to C8

C7 produces the following artifacts that C8 will consume:

| C7 Output | Used in C8 At | How |
|-----------|---------------|-----|
| Offer v2.0 (M7.7) | C8 M8.1 | The architectural baseline that C8 will measure unit economics against |
| Capacity Constraint Analysis (M7.5) | C8 M8.2 | Concurrent-customer ceiling feeds the revenue-ceiling math |
| Operator Bandwidth Audit (M7.6) | C8 M8.3 | Per-customer hours feeds the operator-cost-per-customer figure |
| Fulfillment SOP Library (M7.3) | C8 M8.4 | Per-deliverable time estimates feed the per-deliverable cost figure |
| Customer Lifecycle Map (M7.4) | C8 M8.5 | Lifecycle stages feed the per-stage cost-and-value attribution |
| Offer Architecture Document (M7.8) | C8 enrollment gate | Required: VALIDATED with instructor co-sign |

---

## Cross-Course Doctrine Continuity

The following doctrines continue from prior courses into C7 and onward:

| Doctrine | First Introduced | C7 Usage |
|----------|------------------|----------|
| Operator-vs-Agency Distinction | C1 | Architecture is operator-shaped |
| 6% Rule (signal:noise in iteration) | C5 | Applied to SOP standardization (16+ touchpoints, 1-2 high-leverage SOPs per cohort cycle) |
| 85-Minute Rhythm | C2 | Continues per C6 modulation; informs operator working-time inventory at M7.5 |
| HITL Discipline | C3 | Mandatory at M7.5 (capacity), M7.7 (v2.0 capacity statement), M7.8 (Opus + instructor co-sign) |
| Anti-Promise Discipline | C5 | Extended to capacity anti-promises (M7.5) and architectural anti-promises (M7.7) |
| Iteration Without Drift | C6 | v1.x iteration discipline preserved; v2.0 introduced as architectural release distinct from v1.x |

C7 introduces **three new doctrines**:

| Doctrine | Introduced At | Captured In |
|----------|---------------|-------------|
| Honest Capacity | M7.5 | C7 Honest Capacity Clause |
| Architecture-vs-Pivot Distinction | M7.7 | C7 Architecture-vs-Pivot Distinction Clause |
| SOP Operability | M7.3 | C7 SOP Operability Clause |

---

## C7 Build Specs (for the build team)

### File Count and Word Count

Target: ~48-52 files, ~45-52K words across 8 folders. C7 mirrors C6's structure exactly.

| Folder | File Count | Word Count Target |
|--------|-----------:|-------------------:|
| Course README + Folder 00 (Overview) | 6 | 9,000-11,000 |
| Folder 01 (Module Lessons) | 9 (8 + M7.1 video spec) | 26,000-30,000 |
| Folder 02 (Resources) | 12-14 | 11,000-13,000 |
| Folder 03 (Scripts and Prompts) | 9 (6 Claude prompts + scripts + chain) | 4,500-5,500 |
| Folder 04 (Tools and Infrastructure) | 4 | 5,500-6,500 |
| Folder 05 (Checkpoints and Tests) | 3 | 3,000-4,000 |
| Folder 06 (SOPs) | 4 | 3,500-4,500 |
| Folder 07 (Case Studies and Examples) | 4 | 8,000-10,000 |
| Folder 08 (Community Prompts) | 1 | 1,000-1,500 |
| **Total** | **52-56** | **45,000-52,000** |

### Stage Color

Sailboat Teal #3B9EA0 throughout — Mermaid diagrams, video spec slides, deployment SOP cover.

### Active Hours

50 active hours / 5-7 elapsed weeks. The 14-day measurement window in M7.6 sets a calendar floor on completion time.

### HITL Checkpoints

- **M7.5 (Capacity Analysis HITL):** Mandatory instructor review with 72-hour SLA, co-reviewed with M7.6 audit
- **M7.7 (Offer v2.0 capacity statement HITL):** Mandatory instructor sign-off, typically same instructor as M7.5
- **M7.8 (Opus 4.7 validator + instructor co-sign):** Mandatory two-gate process; Opus validates first, instructor co-signs after; 24-72 hour SLA each

### Sonnet Reviewer Cycles

Five Sonnet reviewers + one Opus 4.7 validator:

- M7.2 deliverable-decomposition-reviewer (Sonnet)
- M7.3 fulfillment-sop-reviewer (Sonnet, runs per SOP)
- M7.4 customer-lifecycle-reviewer (Sonnet)
- M7.5 capacity-analysis-reviewer (Sonnet, runs after HITL clearance)
- M7.7 offer-v2-reviewer (Sonnet)
- M7.8 offer-architecture-validator (Opus 4.7)

---

## Cross-Case Narrative Continuity

The C7 case studies advance the established cross-course narrative:

- **Maya (Teacher operator, illustrator licensing):** v1.1 cohort completes; Phase 2 took 1.5x estimate; v2.0 corrects timeline + adds anti-promise on licensing deal closure (Method produces opportunities, not closed deals).
- **Darius (Builder operator, platform engineering coaching):** Cohort dynamics differ at half-size; v2.0 introduces Reading Club Solo variant.
- **Priya (Service operator, fractional CFO):** Series B Readiness Track scope decision; v2.0 explores both narrow-scope and expand-scope-with-price paths.

A new C7 failure case is introduced:

- **Bespoke Architecture Trap:** Operator over-fits architecture to first 1-3 customers. Recovery via universal-vs-customer-specific separation. Rebuild produces v2.1.

---

## Deployment Path

1. C7 build complete (this build)
2. QM HE Rubric audit run; expected outcome ~92/94 (97.9%), NOT_CERTIFIED blocked by SRS 8.3 (only M7.1 video produced)
3. Deployment SOP authored (10-section docx, Sailboat Teal cover)
4. Final zip produced at `/mnt/user-data/outputs/C7-Offer-Architecture-v2.0.zip`
5. Cohort enrollment opens for Sailboat-Ready operators with verified C6 attestation

---

*This document is internal to the RISER Maritime Academy build team. It is not exposed to students.*

riser-offer-stack

Read the export together with the pricing code

This native document contains audience/mode labels, a monetization timeline and a diagnostic/sprint split, but none of the dynamically generated offer cards. D0637 preserves the underlying HTML and pricing data. Read them together so the missing dynamic content is not mistaken for a complete pricing specification. The source footer uses risernation.com; the current brand destination is risernationcorp.com.

Make timing and entry paths consistent

The source says launch for the first hundred buyers but introduces evergreen after twenty sales and testimonials; these are conflicting transition rules. It proposes purchase-day main/bump, week-two DFY, week-four community, month-three premium and month-six affiliate invitations. Match invitations to demonstrated readiness and consent, not calendar age alone. Diagnostic addresses uncertainty; sprint addresses an identified implementation task. The export’s $197 diagnostic and $500 sprint combine prices from different default modes; use the approved price matrix rather than those static fallback labels.

Apply the Brunson and Hormozi teaching frame

Complete original source text

RISER Nation — Offer Stack & Pricing Architecture

Interactive pricing tool — adjust audience type and pricing mode to see all tiers recalibrate

________________

Audience type









Consumer

Dog training, nutrition, personal finance





Prosumer

Freelancers, side hustlers, solopreneurs





Business owner

Realtors, consultants, service companies

Pricing mode:

Launch (first 100 buyers) Evergreen

Introduce evergreen prices after 20 sales + testimonials

Backend monetization timeline









Purchase day

Main + order bump

One decision only





Week 2

OTO: DFY stage

After first friction





Week 4

Community invite

After first attempts





Month 3

High-ticket offer

After early results





Month 6+

Affiliate invite

Results = best sellers

Split-path landing page









Not sure what's wrong with your offer yet?

Start with the Diagnostic →

$197 · clarity first





Already know what you need built?

Go straight to the Sprint →

$500 · implementation now

________________

RISER Nation · Offer Stack v2 · risernation.com

Native Google Doc text and original links


RISER Nation — Offer Stack & Pricing Architecture
Interactive pricing tool — adjust audience type and pricing mode to see all tiers recalibrate
Audience type


Consumer
Dog training, nutrition, personal finance

Prosumer
Freelancers, side hustlers, solopreneurs

Business owner
Realtors, consultants, service companies
Pricing mode:
Launch (first 100 buyers) Evergreen
Introduce evergreen prices after 20 sales + testimonials
Backend monetization timeline


Purchase day
Main + order bump
One decision only

Week 2
OTO: DFY stage
After first friction

Week 4
Community invite
After first attempts

Month 3
High-ticket offer
After early results

Month 6+
Affiliate invite
Results = best sellers
Split-path landing page


Not sure what's wrong with your offer yet?
Start with the Diagnostic →
$197 · clarity first

Already know what you need built?
Go straight to the Sprint →
$500 · implementation now
RISER Nation · Offer Stack v2 · risernation.com

riser-offer-stack (1).html

Preserve the executable source without embedding it

Both supplied HTML variants are byte-for-byte identical as retrieved text. They define a local pricing display, not a working checkout, customer database or installed product. The lesson preserves the code as inert text. Audience selectors are clickable divs without native button semantics and the split cards have no destination; before reuse, implement keyboard controls, selected-state announcements and real links, then verify all six audience/mode combinations.

Consumer illustrative price matrix

Diagnostic, Sprint, Launch Bundle and OS Full Access are priced at these launch / evergreen amounts respectively: $147 / $197; $297 / $350; $397 / $497; $797 / $997. These are source proposal values, not current checkout offers. The program indexes with mode="evergreen" although the price objects use key "ev". Switching to evergreen therefore yields undefined prices and NaN calculations. Resolve the key mismatch in a reviewed derivative before any live calculator uses these values.

Prosumer illustrative price matrix

Diagnostic, Sprint, Launch Bundle and OS Full Access are priced at these launch / evergreen amounts respectively: $197 / $247; $350 / $500; $497 / $647; $997 / $1297. These are source proposal values, not current checkout offers. The program indexes with mode="evergreen" although the price objects use key "ev". Switching to evergreen therefore yields undefined prices and NaN calculations. Resolve the key mismatch in a reviewed derivative before any live calculator uses these values.

Business illustrative price matrix

Diagnostic, Sprint, Launch Bundle and OS Full Access are priced at these launch / evergreen amounts respectively: $247 / $297; $500 / $750; $647 / $897; $1197 / $1497. These are source proposal values, not current checkout offers. The program indexes with mode="evergreen" although the price objects use key "ev". Switching to evergreen therefore yields undefined prices and NaN calculations. Resolve the key mismatch in a reviewed derivative before any live calculator uses these values.

Explain diagnostic inclusions and boundaries

Consumer diagnostics include profile/content audit, top-three fixes, action PDF, Loom breakdown and quick-wins checklist valued at 250/150/100/200/100. Prosumer diagnostics include offer forensic audit, psychology gaps, mechanism draft, conversion fixes and Loom/action plan at 400/300/200/150/200. Business diagnostics include full audit, competitor/market gaps, mechanism/positioning, buyer profile and priority plan at 700/500/300/250/250. Totals are $800/$1,250/$2,000; the unused prosumer VALUES.diag constant says $1,200. None of these assigned values is independent market proof. Exclusions are implementation, revisions, unlimited Q&A, custom builds and ongoing strategy. The 24–72-hour turnaround, +$27 scorecard and 8–12% conversion figure remain proposed terms or unsupported targets.

Explain the sprint and corrected order value

The sprint allocates perceived value 30/20/15/10/15/10 percent to the ten-stage 60-minute pipeline, deployment package, future updates, 21-day Notion template, social sales package and first-sale guarantee. Audience totals are $1,200/$2,500/$5,000. A 60-minute pipeline, 3–7-day handoff and 21-day implementation template are different time measures. Future updates and a thirty-day first-sale guarantee need defined, supportable terms before sale; the source provides no full guarantee. Exclusions cover open consulting, extra deliverables, unlimited support, pivots and extra tech setup. For a $97 upsell at twenty-percent uptake, expected pre-credit order value is sprint price + $19.40, not sprint price × 1.2. Model actual credits and other costs separately.

Calculate credits and distinguish the remaining tiers

The code rounds half the diagnostic amount to a whole-dollar seven-day credit and subtracts it from sprint price. Launch credits are $74/$99/$124, leaving $223/$251/$376 for consumer/prosumer/business sprint upgrades. Total customer outlay includes the diagnostic already paid; it is not just the remaining sprint amount. Define eligibility, expiration and truthful availability. Bundle includes both tools, three social-media volumes and a niche-customization gate. OS Full Access claims 55 courses and 110+ SOPs and requires fifty Tier-2 sales plus ten testimonials; this does not describe the current twelve-course build or verify assets. The 10:1 value goal and 30–40% upgrade claim are unvalidated heuristics, not reasons to inflate value.

Apply the Brunson and Hormozi teaching frame

Complete original source text

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>RISER Nation — Offer Stack & Pricing</title>
<style>
:root{
  --bg:#FFFFFF;--bg2:#F8F8F6;--bg3:#F1F0EC;
  --bs:#EAF3DE;--bt:#FFFBEB;--bi:#EFF6FF;--bd:#FEF2F2;
  --ts:#166534;--tt:#B45309;--ti:#1E40AF;--td:#991B1B;
  --t1:#111827;--t2:#6B7280;--t3:#9CA3AF;
  --b1:rgba(0,0,0,0.4);--b2:rgba(0,0,0,0.2);--b3:rgba(0,0,0,0.1);
  --bs-border:rgba(22,101,52,0.3);--bi-border:rgba(30,64,175,0.3);
  --mono:'DM Mono','Courier New',monospace;--sans:'DM Sans',system-ui,sans-serif;
  --r1:8px;--r2:12px;
}
@media(prefers-color-scheme:dark){:root{
  --bg:#161B22;--bg2:#1C2430;--bg3:#0D1117;
  --bs:#14532d;--bt:#78350f;--bi:#1e3a5f;--bd:#7f1d1d;
  --ts:#4ade80;--tt:#fbbf24;--ti:#93c5fd;--td:#fca5a5;
  --t1:#E6EDF3;--t2:#8B949E;--t3:#6E7681;
  --b1:rgba(255,255,255,0.4);--b2:rgba(255,255,255,0.2);--b3:rgba(255,255,255,0.1);
  --bs-border:rgba(74,222,128,0.3);--bi-border:rgba(147,197,253,0.3);
}}
*{box-sizing:border-box;margin:0;padding:0}
body{background:var(--bg3);color:var(--t1);font-family:var(--sans);font-size:14px;line-height:1.6;padding:24px 16px;min-height:100vh}
.page-wrap{max-width:740px;margin:0 auto}
.page-header{margin-bottom:24px;padding-bottom:16px;border-bottom:0.5px solid var(--b3)}
.page-header h1{font-size:18px;font-weight:500;margin-bottom:2px}
.page-header p{font-size:13px;color:var(--t2)}
.sec-label{font-size:11px;font-family:var(--mono);color:var(--t2);text-transform:uppercase;letter-spacing:.05em;margin:16px 0 8px}
.aud-row{display:flex;gap:6px;margin-bottom:14px;flex-wrap:wrap}
.aud-btn{flex:1;min-width:120px;padding:8px;border:0.5px solid var(--b2);border-radius:var(--r1);font-size:12px;text-align:center;cursor:pointer;transition:all .15s;background:var(--bg2);color:var(--t2);font-family:var(--sans)}
.aud-btn.active{border:1.5px solid var(--bi-border);background:var(--bi);color:var(--ti)}
.aud-btn .ab-title{font-weight:500;margin-bottom:2px}
.aud-btn .ab-ex{font-size:10px;opacity:.8}
.toggle-row{display:flex;align-items:center;gap:8px;margin-bottom:14px;flex-wrap:wrap}
.toggle-label{font-size:12px;color:var(--t2)}
.toggle-wrap{display:flex;border:0.5px solid var(--b2);border-radius:var(--r1);overflow:hidden}
.toggle-opt{padding:5px 14px;font-size:12px;cursor:pointer;transition:all .15s;color:var(--t2);background:var(--bg2);font-family:var(--sans);border:none}
.toggle-opt.active{background:var(--bi);color:var(--ti);font-weight:500}
#pricing-note{font-size:11px;color:var(--t3)}
.offer-card{background:var(--bg);border:0.5px solid var(--b3);border-radius:var(--r2);margin-bottom:10px;overflow:hidden}
.offer-card.featured{border:2px solid var(--bs-border)}
.offer-head{padding:12px 14px;display:flex;align-items:flex-start;gap:10px;flex-wrap:wrap}
.offer-badge{font-size:10px;padding:2px 8px;border-radius:20px;flex-shrink:0;margin-top:2px;white-space:nowrap}
.offer-name{font-size:14px;font-weight:500;flex:1;min-width:120px}
.price-col{text-align:right;flex-shrink:0}
.price-main{font-size:20px;font-weight:500;font-family:var(--mono);line-height:1}
.price-was{font-size:11px;color:var(--t2);text-decoration:line-through;font-family:var(--mono)}
.price-save{font-size:11px;color:var(--ts)}
.offer-body{border-top:0.5px solid var(--b3);padding:12px 14px;display:grid;grid-template-columns:1fr 1fr;gap:10px}
@media(max-width:500px){.offer-body{grid-template-columns:1fr}}
.ob-col{font-size:12px}
.ob-label{font-weight:500;font-size:11px;color:var(--t2);text-transform:uppercase;letter-spacing:.04em;font-family:var(--mono);margin-bottom:5px}
.inc-item{display:flex;justify-content:space-between;align-items:baseline;padding:3px 0;border-bottom:0.5px solid var(--b3)}
.inc-item:last-child{border-bottom:none}
.inc-name{font-size:12px;color:var(--t1);padding-right:8px}
.inc-val{font-size:11px;color:var(--t2);font-family:var(--mono);flex-shrink:0}
.not-item{font-size:11px;color:var(--t2);display:flex;gap:5px;margin-bottom:3px}
.not-item::before{content:'✕';font-size:10px;color:var(--td);flex-shrink:0;margin-top:2px}
.pv-bar-wrap{margin-top:8px}
.pv-label-row{display:flex;justify-content:space-between;font-size:11px;color:var(--t2);margin-bottom:4px}
.pv-bar{height:8px;border-radius:4px;background:var(--bg2);overflow:hidden}
.pv-fill{height:100%;border-radius:4px;background:var(--bs);transition:width .4s}
.conv-pill{display:inline-block;font-size:10px;padding:2px 8px;border-radius:20px;background:var(--bt);color:var(--tt);margin-top:6px}
.credit-box{background:var(--bs);border-radius:var(--r1);padding:10px 12px;margin:8px 0}
.credit-label{font-size:11px;font-weight:500;color:var(--ts);margin-bottom:4px}
.credit-math{font-size:13px;color:var(--ts);font-family:var(--mono)}
.offer-footer{padding:8px 14px;background:var(--bg2);display:flex;align-items:center;flex-wrap:wrap;gap:6px}
.footer-tag{font-size:10px;padding:2px 8px;border-radius:20px;background:var(--bg3);color:var(--t2)}
.timeline-row{display:flex;gap:0;overflow-x:auto;margin:4px 0}
.tl-item{flex:1;min-width:110px;border-left:2px solid var(--b2);padding:6px 10px}
.tl-item:first-child{border-left-color:var(--bs-border)}
.tl-time{font-size:10px;font-family:var(--mono);color:var(--t2);margin-bottom:2px}
.tl-action{font-size:12px;font-weight:500}
.tl-detail{font-size:11px;color:var(--t2)}
.split-wrap{display:grid;grid-template-columns:1fr 1fr;gap:8px;margin-top:4px}
@media(max-width:400px){.split-wrap{grid-template-columns:1fr}}
.split-card{background:var(--bg);border:0.5px solid var(--b3);border-radius:var(--r1);padding:10px 12px;cursor:pointer}
.split-card:hover{border-color:var(--b1)}
.split-q{font-size:12px;color:var(--t2);margin-bottom:4px}
.split-cta{font-size:13px;font-weight:500}
.split-price{font-size:12px;color:var(--t2);font-family:var(--mono);margin-top:2px}
.two-grid{display:grid;grid-template-columns:1fr 1fr;gap:8px}
@media(max-width:400px){.two-grid{grid-template-columns:1fr}}
.mini-card{background:var(--bg);border:0.5px solid var(--b3);border-radius:var(--r2);padding:10px 12px}
.page-footer{margin-top:24px;padding-top:12px;border-top:0.5px solid var(--b3);font-size:11px;color:var(--t3);text-align:center}
</style>
</head>
<body>
<div class="page-wrap">

<div class="page-header">
  <h1>RISER Nation — Offer Stack & Pricing Architecture</h1>
  <p>Interactive pricing tool — adjust audience type and pricing mode to see all tiers recalibrate</p>
</div>

<div class="sec-label">Audience type</div>
<div class="aud-row">
  <div class="aud-btn" onclick="setAud('consumer',this)"><div class="ab-title">Consumer</div><div class="ab-ex">Dog training, nutrition, personal finance</div></div>
  <div class="aud-btn active" onclick="setAud('prosumer',this)"><div class="ab-title">Prosumer</div><div class="ab-ex">Freelancers, side hustlers, solopreneurs</div></div>
  <div class="aud-btn" onclick="setAud('business',this)"><div class="ab-title">Business owner</div><div class="ab-ex">Realtors, consultants, service companies</div></div>
</div>

<div class="toggle-row">
  <span class="toggle-label">Pricing mode:</span>
  <div class="toggle-wrap">
    <button class="toggle-opt active" onclick="setPricing('launch',this)">Launch (first 100 buyers)</button>
    <button class="toggle-opt" onclick="setPricing('evergreen',this)">Evergreen</button>
  </div>
  <span id="pricing-note">Introduce evergreen prices after 20 sales + testimonials</span>
</div>

<div id="offer-stack"></div>

<div class="sec-label" style="margin-top:20px">Backend monetization timeline</div>
<div class="timeline-row">
  <div class="tl-item" style="border-left-color:var(--bs-border)"><div class="tl-time">Purchase day</div><div class="tl-action">Main + order bump</div><div class="tl-detail">One decision only</div></div>
  <div class="tl-item"><div class="tl-time">Week 2</div><div class="tl-action">OTO: DFY stage</div><div class="tl-detail">After first friction</div></div>
  <div class="tl-item"><div class="tl-time">Week 4</div><div class="tl-action">Community invite</div><div class="tl-detail">After first attempts</div></div>
  <div class="tl-item"><div class="tl-time">Month 3</div><div class="tl-action">High-ticket offer</div><div class="tl-detail">After early results</div></div>
  <div class="tl-item"><div class="tl-time">Month 6+</div><div class="tl-action">Affiliate invite</div><div class="tl-detail">Results = best sellers</div></div>
</div>

<div class="sec-label">Split-path landing page</div>
<div class="split-wrap">
  <div class="split-card">
    <div class="split-q">Not sure what's wrong with your offer yet?</div>
    <div class="split-cta">Start with the Diagnostic →</div>
    <div class="split-price" id="split-p1">$197 · clarity first</div>
  </div>
  <div class="split-card">
    <div class="split-q">Already know what you need built?</div>
    <div class="split-cta">Go straight to the Sprint →</div>
    <div class="split-price" id="split-p2">$500 · implementation now</div>
  </div>
</div>

<div class="page-footer">RISER Nation · Offer Stack v2 · risernation.com</div>
</div>

<script>
const PRICES={
  consumer:{diag:{launch:147,ev:197},sprint:{launch:297,ev:350},bundle:{launch:397,ev:497},os:{launch:797,ev:997}},
  prosumer:{diag:{launch:197,ev:247},sprint:{launch:350,ev:500},bundle:{launch:497,ev:647},os:{launch:997,ev:1297}},
  business:{diag:{launch:247,ev:297},sprint:{launch:500,ev:750},bundle:{launch:647,ev:897},os:{launch:1197,ev:1497}},
};
const VALUES={consumer:{diag:800,sprint:1200},prosumer:{diag:1200,sprint:2500},business:{diag:2000,sprint:5000}};
const DIAG_ITEMS={
  consumer:['Profile/content audit review','Top 3 priority fixes','Action plan PDF','Loom video breakdown','Quick-wins checklist'],
  prosumer:['Offer structure forensic audit','Buyer psychology gap analysis','Mechanism statement draft','Top 3 conversion fixes','Loom review + action plan'],
  business:['Full forensic offer audit','Market gap & competitor analysis','Mechanism statement + positioning','Buyer intelligence profile','Written priority action plan'],
};
const DIAG_VALS={consumer:[250,150,100,200,100],prosumer:[400,300,200,150,200],business:[700,500,300,250,250]};
const NOT_DIAG=['Implementation or execution','Revisions or rewrites','Unlimited Q&A after delivery','Custom build work','Ongoing strategy sessions'];
const NOT_SPRINT=['Open-ended consulting','Deliverables outside agreed scope','Unlimited support after handoff','Strategy overhaul or pivoting','Additional tech setup'];

let aud='prosumer',mode='launch';

function setAud(a,el){aud=a;document.querySelectorAll('.aud-btn').forEach(b=>b.classList.remove('active'));el.classList.add('active');render();}
function setPricing(m,el){mode=m;document.querySelectorAll('.toggle-opt').forEach(b=>b.classList.remove('active'));el.classList.add('active');document.getElementById('pricing-note').textContent=m==='launch'?'Introduce evergreen prices after 20+ sales and first testimonials':'Standard pricing after launch period closes';render();}

function render(){
  const p=PRICES[aud],v=VALUES[aud],di=DIAG_ITEMS[aud],dv=DIAG_VALS[aud];
  const dp=p.diag[mode],sp=p.sprint[mode],dp_ev=p.diag.ev,sp_ev=p.sprint.ev;
  const credit=Math.round(dp*0.5),sprint_after=sp-credit;
  const totalDV=dv.reduce((a,b)=>a+b,0);
  const diagRatio=Math.round(totalDV/dp),sprintRatio=Math.round(v.sprint/sp);
  const diagPct=Math.min(100,Math.round(dp/totalDV*100)),sprintPct=Math.min(100,Math.round(sp/v.sprint*100));
  document.getElementById('split-p1').textContent=`$${dp} · clarity first`;
  document.getElementById('split-p2').textContent=`$${sp} · implementation now`;
  document.getElementById('offer-stack').innerHTML=`
<div class="offer-card">
  <div class="offer-head">
    <span class="offer-badge" style="background:var(--bs);color:var(--ts)">Tier 1 — Entry</span>
    <div class="offer-name">First Dollar Forge <span style="font-size:11px;color:var(--t2)">/ The Diagnostic</span></div>
    <div class="price-col">
      <div class="price-main" style="color:var(--ts)">$${dp}</div>
      ${mode==='launch'?`<div class="price-was">$${dp_ev}</div><div class="price-save">Save $${dp_ev-dp} at launch</div>`:'<div style="height:32px"></div>'}
    </div>
  </div>
  <div class="offer-body">
    <div class="ob-col">
      <div class="ob-label">Included + perceived value</div>
      ${di.map((item,i)=>`<div class="inc-item"><span class="inc-name">${item}</span><span class="inc-val">$${dv[i]}</span></div>`).join('')}
      <div class="inc-item" style="font-weight:500"><span class="inc-name">Total perceived value</span><span class="inc-val" style="color:var(--ts)">$${totalDV}</span></div>
      <div class="conv-pill">Conv. rate: 8–12% from content</div>
    </div>
    <div class="ob-col">
      <div class="ob-label">NOT included</div>
      ${NOT_DIAG.map(n=>`<div class="not-item">${n}</div>`).join('')}
      <div class="pv-bar-wrap">
        <div class="pv-label-row"><span>Price $${dp}</span><span>Perceived value $${totalDV}</span></div>
        <div class="pv-bar"><div class="pv-fill" style="width:${diagPct}%"></div></div>
        <div style="font-size:10px;color:var(--t2);margin-top:3px">Value ratio: ${diagRatio}:1 ${diagRatio>=10?'✓':'⚠ aim for 10:1+'}</div>
      </div>
      <div class="credit-box">
        <div class="credit-label">Credit-based ascension (7-day window)</div>
        <div class="credit-math">$${dp} paid → $${credit} credit → Sprint costs $${sprint_after} if upgraded within 7 days</div>
      </div>
    </div>
  </div>
  <div class="offer-footer">
    <span class="footer-tag">Checkout: Gumroad or Stripe</span>
    <span class="footer-tag">Turnaround: 24–72 hours</span>
    <span class="footer-tag">Order bump: +$27 Niche Scorecard</span>
  </div>
</div>
<div style="text-align:center;font-size:12px;color:var(--t2);padding:3px 0">↓ Credit expires in 7 days — creates upgrade urgency</div>
<div class="offer-card featured">
  <div class="offer-head">
    <span class="offer-badge" style="background:var(--bs);color:var(--ts)">Tier 2 — Primary ★</span>
    <div class="offer-name">Ignition Engine <span style="font-size:11px;color:var(--t2)">/ The Sprint</span></div>
    <div class="price-col">
      <div class="price-main">$${sp}</div>
      ${mode==='launch'?`<div class="price-was">$${sp_ev}</div><div class="price-save">Save $${sp_ev-sp} at launch</div>`:'<div style="height:32px"></div>'}
    </div>
  </div>
  <div class="offer-body">
    <div class="ob-col">
      <div class="ob-label">Included + perceived value</div>
      <div class="inc-item"><span class="inc-name">10-stage AI pipeline (60 min)</span><span class="inc-val">$${Math.round(v.sprint*.3)}</span></div>
      <div class="inc-item"><span class="inc-name">Complete deployment package</span><span class="inc-val">$${Math.round(v.sprint*.2)}</span></div>
      <div class="inc-item"><span class="inc-name">All future version updates</span><span class="inc-val">$${Math.round(v.sprint*.15)}</span></div>
      <div class="inc-item"><span class="inc-name">21-day Notion sprint template</span><span class="inc-val">$${Math.round(v.sprint*.1)}</span></div>
      <div class="inc-item"><span class="inc-name">Social Media Sales Package</span><span class="inc-val">$${Math.round(v.sprint*.15)}</span></div>
      <div class="inc-item"><span class="inc-name">30-day first-sale guarantee</span><span class="inc-val">$${Math.round(v.sprint*.1)}</span></div>
      <div class="inc-item" style="font-weight:500"><span class="inc-name">Total perceived value</span><span class="inc-val" style="color:var(--ts)">$${v.sprint.toLocaleString()}</span></div>
      <div class="conv-pill">Conv. rate: 30–40% from Diagnostic buyers</div>
    </div>
    <div class="ob-col">
      <div class="ob-label">NOT included</div>
      ${NOT_SPRINT.map(n=>`<div class="not-item">${n}</div>`).join('')}
      <div class="pv-bar-wrap" style="margin-top:8px">
        <div class="pv-label-row"><span>Price $${sp}</span><span>Value $${v.sprint.toLocaleString()}</span></div>
        <div class="pv-bar"><div class="pv-fill" style="width:${sprintPct}%"></div></div>
        <div style="font-size:10px;color:var(--t2);margin-top:3px">Value ratio: ${sprintRatio}:1 ${sprintRatio>=10?'✓':'⚠ aim for 10:1+'}</div>
      </div>
      <div style="margin-top:8px;font-size:11px;color:var(--t2);padding:8px;background:var(--bg2);border-radius:var(--r1)">
        With Diagnostic credit: effective price $${sprint_after}<br>
        Avg order value with OTO (20% take): ~$${Math.round(sp*1.2)}
      </div>
    </div>
  </div>
  <div class="offer-footer">
    <span class="footer-tag">Checkout: Stripe Payment Link</span>
    <span class="footer-tag">Turnaround: 3–7 days</span>
    <span class="footer-tag">OTO: Stage 1+2 DFY +$97</span>
  </div>
</div>
<div class="two-grid">
<div class="mini-card">
  <div style="display:flex;justify-content:space-between;align-items:flex-start;margin-bottom:6px">
    <span class="offer-badge" style="background:var(--bt);color:var(--tt);font-size:10px;padding:2px 8px;border-radius:20px">Tier 3</span>
    <span style="font-size:17px;font-weight:500;font-family:var(--mono)">$${p.bundle[mode]}</span>
  </div>
  <div style="font-size:13px;font-weight:500;margin-bottom:4px">Launch Bundle</div>
  <div style="font-size:11px;color:var(--t2)">Both tools + Social Media Package (all 3 volumes) + Niche Customisation Gate. For buyers who want to build and sell simultaneously.${mode==='launch'?` Save $${p.bundle.ev-p.bundle.launch} at launch.`:''}</div>
</div>
<div class="mini-card">
  <div style="display:flex;justify-content:space-between;align-items:flex-start;margin-bottom:6px">
    <span class="offer-badge" style="background:var(--bi);color:var(--ti);font-size:10px;padding:2px 8px;border-radius:20px">Tier 4</span>
    <span style="font-size:17px;font-weight:500;font-family:var(--mono)">$${p.os[mode]}</span>
  </div>
  <div style="font-size:13px;font-weight:500;margin-bottom:4px">RISER OS Full Access</div>
  <div style="font-size:11px;color:var(--t2)">All 55 courses, 110+ SOPs, all tools. Launch only after 50 Tier 2 sales + 10 testimonials. Not before.</div>
</div>
</div>`;
}
render();
</script>
</body>
</html>

Complete source variant 2

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>RISER Nation — Offer Stack & Pricing</title>
<style>
:root{
  --bg:#FFFFFF;--bg2:#F8F8F6;--bg3:#F1F0EC;
  --bs:#EAF3DE;--bt:#FFFBEB;--bi:#EFF6FF;--bd:#FEF2F2;
  --ts:#166534;--tt:#B45309;--ti:#1E40AF;--td:#991B1B;
  --t1:#111827;--t2:#6B7280;--t3:#9CA3AF;
  --b1:rgba(0,0,0,0.4);--b2:rgba(0,0,0,0.2);--b3:rgba(0,0,0,0.1);
  --bs-border:rgba(22,101,52,0.3);--bi-border:rgba(30,64,175,0.3);
  --mono:'DM Mono','Courier New',monospace;--sans:'DM Sans',system-ui,sans-serif;
  --r1:8px;--r2:12px;
}
@media(prefers-color-scheme:dark){:root{
  --bg:#161B22;--bg2:#1C2430;--bg3:#0D1117;
  --bs:#14532d;--bt:#78350f;--bi:#1e3a5f;--bd:#7f1d1d;
  --ts:#4ade80;--tt:#fbbf24;--ti:#93c5fd;--td:#fca5a5;
  --t1:#E6EDF3;--t2:#8B949E;--t3:#6E7681;
  --b1:rgba(255,255,255,0.4);--b2:rgba(255,255,255,0.2);--b3:rgba(255,255,255,0.1);
  --bs-border:rgba(74,222,128,0.3);--bi-border:rgba(147,197,253,0.3);
}}
*{box-sizing:border-box;margin:0;padding:0}
body{background:var(--bg3);color:var(--t1);font-family:var(--sans);font-size:14px;line-height:1.6;padding:24px 16px;min-height:100vh}
.page-wrap{max-width:740px;margin:0 auto}
.page-header{margin-bottom:24px;padding-bottom:16px;border-bottom:0.5px solid var(--b3)}
.page-header h1{font-size:18px;font-weight:500;margin-bottom:2px}
.page-header p{font-size:13px;color:var(--t2)}
.sec-label{font-size:11px;font-family:var(--mono);color:var(--t2);text-transform:uppercase;letter-spacing:.05em;margin:16px 0 8px}
.aud-row{display:flex;gap:6px;margin-bottom:14px;flex-wrap:wrap}
.aud-btn{flex:1;min-width:120px;padding:8px;border:0.5px solid var(--b2);border-radius:var(--r1);font-size:12px;text-align:center;cursor:pointer;transition:all .15s;background:var(--bg2);color:var(--t2);font-family:var(--sans)}
.aud-btn.active{border:1.5px solid var(--bi-border);background:var(--bi);color:var(--ti)}
.aud-btn .ab-title{font-weight:500;margin-bottom:2px}
.aud-btn .ab-ex{font-size:10px;opacity:.8}
.toggle-row{display:flex;align-items:center;gap:8px;margin-bottom:14px;flex-wrap:wrap}
.toggle-label{font-size:12px;color:var(--t2)}
.toggle-wrap{display:flex;border:0.5px solid var(--b2);border-radius:var(--r1);overflow:hidden}
.toggle-opt{padding:5px 14px;font-size:12px;cursor:pointer;transition:all .15s;color:var(--t2);background:var(--bg2);font-family:var(--sans);border:none}
.toggle-opt.active{background:var(--bi);color:var(--ti);font-weight:500}
#pricing-note{font-size:11px;color:var(--t3)}
.offer-card{background:var(--bg);border:0.5px solid var(--b3);border-radius:var(--r2);margin-bottom:10px;overflow:hidden}
.offer-card.featured{border:2px solid var(--bs-border)}
.offer-head{padding:12px 14px;display:flex;align-items:flex-start;gap:10px;flex-wrap:wrap}
.offer-badge{font-size:10px;padding:2px 8px;border-radius:20px;flex-shrink:0;margin-top:2px;white-space:nowrap}
.offer-name{font-size:14px;font-weight:500;flex:1;min-width:120px}
.price-col{text-align:right;flex-shrink:0}
.price-main{font-size:20px;font-weight:500;font-family:var(--mono);line-height:1}
.price-was{font-size:11px;color:var(--t2);text-decoration:line-through;font-family:var(--mono)}
.price-save{font-size:11px;color:var(--ts)}
.offer-body{border-top:0.5px solid var(--b3);padding:12px 14px;display:grid;grid-template-columns:1fr 1fr;gap:10px}
@media(max-width:500px){.offer-body{grid-template-columns:1fr}}
.ob-col{font-size:12px}
.ob-label{font-weight:500;font-size:11px;color:var(--t2);text-transform:uppercase;letter-spacing:.04em;font-family:var(--mono);margin-bottom:5px}
.inc-item{display:flex;justify-content:space-between;align-items:baseline;padding:3px 0;border-bottom:0.5px solid var(--b3)}
.inc-item:last-child{border-bottom:none}
.inc-name{font-size:12px;color:var(--t1);padding-right:8px}
.inc-val{font-size:11px;color:var(--t2);font-family:var(--mono);flex-shrink:0}
.not-item{font-size:11px;color:var(--t2);display:flex;gap:5px;margin-bottom:3px}
.not-item::before{content:'✕';font-size:10px;color:var(--td);flex-shrink:0;margin-top:2px}
.pv-bar-wrap{margin-top:8px}
.pv-label-row{display:flex;justify-content:space-between;font-size:11px;color:var(--t2);margin-bottom:4px}
.pv-bar{height:8px;border-radius:4px;background:var(--bg2);overflow:hidden}
.pv-fill{height:100%;border-radius:4px;background:var(--bs);transition:width .4s}
.conv-pill{display:inline-block;font-size:10px;padding:2px 8px;border-radius:20px;background:var(--bt);color:var(--tt);margin-top:6px}
.credit-box{background:var(--bs);border-radius:var(--r1);padding:10px 12px;margin:8px 0}
.credit-label{font-size:11px;font-weight:500;color:var(--ts);margin-bottom:4px}
.credit-math{font-size:13px;color:var(--ts);font-family:var(--mono)}
.offer-footer{padding:8px 14px;background:var(--bg2);display:flex;align-items:center;flex-wrap:wrap;gap:6px}
.footer-tag{font-size:10px;padding:2px 8px;border-radius:20px;background:var(--bg3);color:var(--t2)}
.timeline-row{display:flex;gap:0;overflow-x:auto;margin:4px 0}
.tl-item{flex:1;min-width:110px;border-left:2px solid var(--b2);padding:6px 10px}
.tl-item:first-child{border-left-color:var(--bs-border)}
.tl-time{font-size:10px;font-family:var(--mono);color:var(--t2);margin-bottom:2px}
.tl-action{font-size:12px;font-weight:500}
.tl-detail{font-size:11px;color:var(--t2)}
.split-wrap{display:grid;grid-template-columns:1fr 1fr;gap:8px;margin-top:4px}
@media(max-width:400px){.split-wrap{grid-template-columns:1fr}}
.split-card{background:var(--bg);border:0.5px solid var(--b3);border-radius:var(--r1);padding:10px 12px;cursor:pointer}
.split-card:hover{border-color:var(--b1)}
.split-q{font-size:12px;color:var(--t2);margin-bottom:4px}
.split-cta{font-size:13px;font-weight:500}
.split-price{font-size:12px;color:var(--t2);font-family:var(--mono);margin-top:2px}
.two-grid{display:grid;grid-template-columns:1fr 1fr;gap:8px}
@media(max-width:400px){.two-grid{grid-template-columns:1fr}}
.mini-card{background:var(--bg);border:0.5px solid var(--b3);border-radius:var(--r2);padding:10px 12px}
.page-footer{margin-top:24px;padding-top:12px;border-top:0.5px solid var(--b3);font-size:11px;color:var(--t3);text-align:center}
</style>
</head>
<body>
<div class="page-wrap">

<div class="page-header">
  <h1>RISER Nation — Offer Stack & Pricing Architecture</h1>
  <p>Interactive pricing tool — adjust audience type and pricing mode to see all tiers recalibrate</p>
</div>

<div class="sec-label">Audience type</div>
<div class="aud-row">
  <div class="aud-btn" onclick="setAud('consumer',this)"><div class="ab-title">Consumer</div><div class="ab-ex">Dog training, nutrition, personal finance</div></div>
  <div class="aud-btn active" onclick="setAud('prosumer',this)"><div class="ab-title">Prosumer</div><div class="ab-ex">Freelancers, side hustlers, solopreneurs</div></div>
  <div class="aud-btn" onclick="setAud('business',this)"><div class="ab-title">Business owner</div><div class="ab-ex">Realtors, consultants, service companies</div></div>
</div>

<div class="toggle-row">
  <span class="toggle-label">Pricing mode:</span>
  <div class="toggle-wrap">
    <button class="toggle-opt active" onclick="setPricing('launch',this)">Launch (first 100 buyers)</button>
    <button class="toggle-opt" onclick="setPricing('evergreen',this)">Evergreen</button>
  </div>
  <span id="pricing-note">Introduce evergreen prices after 20 sales + testimonials</span>
</div>

<div id="offer-stack"></div>

<div class="sec-label" style="margin-top:20px">Backend monetization timeline</div>
<div class="timeline-row">
  <div class="tl-item" style="border-left-color:var(--bs-border)"><div class="tl-time">Purchase day</div><div class="tl-action">Main + order bump</div><div class="tl-detail">One decision only</div></div>
  <div class="tl-item"><div class="tl-time">Week 2</div><div class="tl-action">OTO: DFY stage</div><div class="tl-detail">After first friction</div></div>
  <div class="tl-item"><div class="tl-time">Week 4</div><div class="tl-action">Community invite</div><div class="tl-detail">After first attempts</div></div>
  <div class="tl-item"><div class="tl-time">Month 3</div><div class="tl-action">High-ticket offer</div><div class="tl-detail">After early results</div></div>
  <div class="tl-item"><div class="tl-time">Month 6+</div><div class="tl-action">Affiliate invite</div><div class="tl-detail">Results = best sellers</div></div>
</div>

<div class="sec-label">Split-path landing page</div>
<div class="split-wrap">
  <div class="split-card">
    <div class="split-q">Not sure what's wrong with your offer yet?</div>
    <div class="split-cta">Start with the Diagnostic →</div>
    <div class="split-price" id="split-p1">$197 · clarity first</div>
  </div>
  <div class="split-card">
    <div class="split-q">Already know what you need built?</div>
    <div class="split-cta">Go straight to the Sprint →</div>
    <div class="split-price" id="split-p2">$500 · implementation now</div>
  </div>
</div>

<div class="page-footer">RISER Nation · Offer Stack v2 · risernation.com</div>
</div>

<script>
const PRICES={
  consumer:{diag:{launch:147,ev:197},sprint:{launch:297,ev:350},bundle:{launch:397,ev:497},os:{launch:797,ev:997}},
  prosumer:{diag:{launch:197,ev:247},sprint:{launch:350,ev:500},bundle:{launch:497,ev:647},os:{launch:997,ev:1297}},
  business:{diag:{launch:247,ev:297},sprint:{launch:500,ev:750},bundle:{launch:647,ev:897},os:{launch:1197,ev:1497}},
};
const VALUES={consumer:{diag:800,sprint:1200},prosumer:{diag:1200,sprint:2500},business:{diag:2000,sprint:5000}};
const DIAG_ITEMS={
  consumer:['Profile/content audit review','Top 3 priority fixes','Action plan PDF','Loom video breakdown','Quick-wins checklist'],
  prosumer:['Offer structure forensic audit','Buyer psychology gap analysis','Mechanism statement draft','Top 3 conversion fixes','Loom review + action plan'],
  business:['Full forensic offer audit','Market gap & competitor analysis','Mechanism statement + positioning','Buyer intelligence profile','Written priority action plan'],
};
const DIAG_VALS={consumer:[250,150,100,200,100],prosumer:[400,300,200,150,200],business:[700,500,300,250,250]};
const NOT_DIAG=['Implementation or execution','Revisions or rewrites','Unlimited Q&A after delivery','Custom build work','Ongoing strategy sessions'];
const NOT_SPRINT=['Open-ended consulting','Deliverables outside agreed scope','Unlimited support after handoff','Strategy overhaul or pivoting','Additional tech setup'];

let aud='prosumer',mode='launch';

function setAud(a,el){aud=a;document.querySelectorAll('.aud-btn').forEach(b=>b.classList.remove('active'));el.classList.add('active');render();}
function setPricing(m,el){mode=m;document.querySelectorAll('.toggle-opt').forEach(b=>b.classList.remove('active'));el.classList.add('active');document.getElementById('pricing-note').textContent=m==='launch'?'Introduce evergreen prices after 20+ sales and first testimonials':'Standard pricing after launch period closes';render();}

function render(){
  const p=PRICES[aud],v=VALUES[aud],di=DIAG_ITEMS[aud],dv=DIAG_VALS[aud];
  const dp=p.diag[mode],sp=p.sprint[mode],dp_ev=p.diag.ev,sp_ev=p.sprint.ev;
  const credit=Math.round(dp*0.5),sprint_after=sp-credit;
  const totalDV=dv.reduce((a,b)=>a+b,0);
  const diagRatio=Math.round(totalDV/dp),sprintRatio=Math.round(v.sprint/sp);
  const diagPct=Math.min(100,Math.round(dp/totalDV*100)),sprintPct=Math.min(100,Math.round(sp/v.sprint*100));
  document.getElementById('split-p1').textContent=`$${dp} · clarity first`;
  document.getElementById('split-p2').textContent=`$${sp} · implementation now`;
  document.getElementById('offer-stack').innerHTML=`
<div class="offer-card">
  <div class="offer-head">
    <span class="offer-badge" style="background:var(--bs);color:var(--ts)">Tier 1 — Entry</span>
    <div class="offer-name">First Dollar Forge <span style="font-size:11px;color:var(--t2)">/ The Diagnostic</span></div>
    <div class="price-col">
      <div class="price-main" style="color:var(--ts)">$${dp}</div>
      ${mode==='launch'?`<div class="price-was">$${dp_ev}</div><div class="price-save">Save $${dp_ev-dp} at launch</div>`:'<div style="height:32px"></div>'}
    </div>
  </div>
  <div class="offer-body">
    <div class="ob-col">
      <div class="ob-label">Included + perceived value</div>
      ${di.map((item,i)=>`<div class="inc-item"><span class="inc-name">${item}</span><span class="inc-val">$${dv[i]}</span></div>`).join('')}
      <div class="inc-item" style="font-weight:500"><span class="inc-name">Total perceived value</span><span class="inc-val" style="color:var(--ts)">$${totalDV}</span></div>
      <div class="conv-pill">Conv. rate: 8–12% from content</div>
    </div>
    <div class="ob-col">
      <div class="ob-label">NOT included</div>
      ${NOT_DIAG.map(n=>`<div class="not-item">${n}</div>`).join('')}
      <div class="pv-bar-wrap">
        <div class="pv-label-row"><span>Price $${dp}</span><span>Perceived value $${totalDV}</span></div>
        <div class="pv-bar"><div class="pv-fill" style="width:${diagPct}%"></div></div>
        <div style="font-size:10px;color:var(--t2);margin-top:3px">Value ratio: ${diagRatio}:1 ${diagRatio>=10?'✓':'⚠ aim for 10:1+'}</div>
      </div>
      <div class="credit-box">
        <div class="credit-label">Credit-based ascension (7-day window)</div>
        <div class="credit-math">$${dp} paid → $${credit} credit → Sprint costs $${sprint_after} if upgraded within 7 days</div>
      </div>
    </div>
  </div>
  <div class="offer-footer">
    <span class="footer-tag">Checkout: Gumroad or Stripe</span>
    <span class="footer-tag">Turnaround: 24–72 hours</span>
    <span class="footer-tag">Order bump: +$27 Niche Scorecard</span>
  </div>
</div>
<div style="text-align:center;font-size:12px;color:var(--t2);padding:3px 0">↓ Credit expires in 7 days — creates upgrade urgency</div>
<div class="offer-card featured">
  <div class="offer-head">
    <span class="offer-badge" style="background:var(--bs);color:var(--ts)">Tier 2 — Primary ★</span>
    <div class="offer-name">Ignition Engine <span style="font-size:11px;color:var(--t2)">/ The Sprint</span></div>
    <div class="price-col">
      <div class="price-main">$${sp}</div>
      ${mode==='launch'?`<div class="price-was">$${sp_ev}</div><div class="price-save">Save $${sp_ev-sp} at launch</div>`:'<div style="height:32px"></div>'}
    </div>
  </div>
  <div class="offer-body">
    <div class="ob-col">
      <div class="ob-label">Included + perceived value</div>
      <div class="inc-item"><span class="inc-name">10-stage AI pipeline (60 min)</span><span class="inc-val">$${Math.round(v.sprint*.3)}</span></div>
      <div class="inc-item"><span class="inc-name">Complete deployment package</span><span class="inc-val">$${Math.round(v.sprint*.2)}</span></div>
      <div class="inc-item"><span class="inc-name">All future version updates</span><span class="inc-val">$${Math.round(v.sprint*.15)}</span></div>
      <div class="inc-item"><span class="inc-name">21-day Notion sprint template</span><span class="inc-val">$${Math.round(v.sprint*.1)}</span></div>
      <div class="inc-item"><span class="inc-name">Social Media Sales Package</span><span class="inc-val">$${Math.round(v.sprint*.15)}</span></div>
      <div class="inc-item"><span class="inc-name">30-day first-sale guarantee</span><span class="inc-val">$${Math.round(v.sprint*.1)}</span></div>
      <div class="inc-item" style="font-weight:500"><span class="inc-name">Total perceived value</span><span class="inc-val" style="color:var(--ts)">$${v.sprint.toLocaleString()}</span></div>
      <div class="conv-pill">Conv. rate: 30–40% from Diagnostic buyers</div>
    </div>
    <div class="ob-col">
      <div class="ob-label">NOT included</div>
      ${NOT_SPRINT.map(n=>`<div class="not-item">${n}</div>`).join('')}
      <div class="pv-bar-wrap" style="margin-top:8px">
        <div class="pv-label-row"><span>Price $${sp}</span><span>Value $${v.sprint.toLocaleString()}</span></div>
        <div class="pv-bar"><div class="pv-fill" style="width:${sprintPct}%"></div></div>
        <div style="font-size:10px;color:var(--t2);margin-top:3px">Value ratio: ${sprintRatio}:1 ${sprintRatio>=10?'✓':'⚠ aim for 10:1+'}</div>
      </div>
      <div style="margin-top:8px;font-size:11px;color:var(--t2);padding:8px;background:var(--bg2);border-radius:var(--r1)">
        With Diagnostic credit: effective price $${sprint_after}<br>
        Avg order value with OTO (20% take): ~$${Math.round(sp*1.2)}
      </div>
    </div>
  </div>
  <div class="offer-footer">
    <span class="footer-tag">Checkout: Stripe Payment Link</span>
    <span class="footer-tag">Turnaround: 3–7 days</span>
    <span class="footer-tag">OTO: Stage 1+2 DFY +$97</span>
  </div>
</div>
<div class="two-grid">
<div class="mini-card">
  <div style="display:flex;justify-content:space-between;align-items:flex-start;margin-bottom:6px">
    <span class="offer-badge" style="background:var(--bt);color:var(--tt);font-size:10px;padding:2px 8px;border-radius:20px">Tier 3</span>
    <span style="font-size:17px;font-weight:500;font-family:var(--mono)">$${p.bundle[mode]}</span>
  </div>
  <div style="font-size:13px;font-weight:500;margin-bottom:4px">Launch Bundle</div>
  <div style="font-size:11px;color:var(--t2)">Both tools + Social Media Package (all 3 volumes) + Niche Customisation Gate. For buyers who want to build and sell simultaneously.${mode==='launch'?` Save $${p.bundle.ev-p.bundle.launch} at launch.`:''}</div>
</div>
<div class="mini-card">
  <div style="display:flex;justify-content:space-between;align-items:flex-start;margin-bottom:6px">
    <span class="offer-badge" style="background:var(--bi);color:var(--ti);font-size:10px;padding:2px 8px;border-radius:20px">Tier 4</span>
    <span style="font-size:17px;font-weight:500;font-family:var(--mono)">$${p.os[mode]}</span>
  </div>
  <div style="font-size:13px;font-weight:500;margin-bottom:4px">RISER OS Full Access</div>
  <div style="font-size:11px;color:var(--t2)">All 55 courses, 110+ SOPs, all tools. Launch only after 50 Tier 2 sales + 10 testimonials. Not before.</div>
</div>
</div>`;
}
render();
</script>
</body>
</html>

RISER-Value-Ladder-Architecture-SOP (1).docx

Distinguish the six-rung plan from the assigned curriculum

This legacy SOP labels itself Course 14 of 14, elsewhere refers to Courses 6–15 and proposes six product rungs. These are source labels, not a change to our twelve-course curriculum. Build order is 1, 3, 2, 4, 5, 6: validate a useful lead magnet and core offer before adding acquisition, continuity, premium and optional done-for-you layers. The checklist places Rung 1 in week ten but core in weeks seven/eight; follow validated dependencies and resolve the calendar rather than treating both schedules as executable.

Correct acquisition and cohort arithmetic

The printed $850 × 50% = $425 example is a per-buyer allowance under a simplified margin assumption, not cost per lead. A comparable per-lead allowance must include lead-to-buyer probability: at an illustrative two-percent conversion, $425 × 0.02 = $8.50 per lead before other acquisition costs. Model delivery cost, refunds, timing and required contribution separately. In the immediate funnel example, 25% of 85 decliners is 21.25 expected purchases, producing $8,436.25; the source rounds to 21 actual buyers and $8,337. Use either an expected forecast or observed integer count consistently. A conditional downsell take rate must be multiplied by the OTO-decline share before adding it to per-original-buyer LTV.

Correct renewal and weighted-LTV assumptions

The 90-day template assumes three paid continuity months even when membership starts later; use actual joining dates, paid months and churn. A ten-percentage-point continuity increase adds 0.10 × monthly price × expected paid duration per original buyer, not the full member value. An additional five-percent premium conversion adds 0.05 × premium price per eligible member, then multiply by the eligible-member fraction to express it per original cohort buyer. Under constant churn and a simple geometric model, 1/0.05=20 months and 1/0.03≈33.33 months, a 66.67% increase, not exactly 65%; this is an assumption-based expectation, not observed retention.

Compare revenue periods and preserve buyer choice

Compare annual recurring revenue with annual launch/premium projections or monthly with monthly; the source mixes monthly floor language with annual ceiling inputs. A recurring run rate is neither guaranteed cash nor profit, and its ceiling omits some optional income streams. Member targets round up correctly: 52×97=$5,044;104×97=$10,088;26×197=$5,122;51×197=$10,047. Continuity churn and delivery costs still apply. Deliver the full promised outcome at every rung; do not deliberately weaken a lead magnet or paid product to force ascension. Provide a clear decline, cancellation and appropriate exit path.

Treat benchmark bands as provisional operating targets

The source’s 80/20 split, conversion ranges, highest-margin DFY claim and completion/LTV multipliers lack evidence here. They are hypotheses to test by cohort and traffic source. Its health bands leave exact values such as 30% opt-in, 3% SLO, 2% core, 15% premium and 80% DFY incompletely classified; decimal gaps also occur. Set inclusive non-overlapping boundaries. Renew-or-refer is not the same measure as satisfaction or renewal alone. The quarterly form omits a DFY line despite the six-rung scorecard; include it when active. Five sales with zero refunds is a validation step, not proof of a stable sub-ten-percent refund rate.

Source worksheet 1

Work through this source worksheet in order. The Value Ladder Is Not Built All at Once — It Is Built in Sequence The most common value ladder error among new knowledge business operators is attempting to build all rungs simultaneously before any rung has been validated. The value ladder in this SOP defines the complete architecture. The build sequence defines the order in which rungs are created, which is: Rung 1 (Traffic Hook / Lead Magnet) — Rung 3 (Core Offer) — Rung 2 (Self-Liquidating Offer) — Rung 4 (Continuity) — Rung 5 (Premium) — Rung 6 (Done-For-You). An operator building all six rungs before Rung 3 is validated is building infrastructure for a business whose commercial viability is still unconfirmed. Record actual evidence and applicable definitions; source targets and examples do not establish a completed result.

Source worksheet 2

Work through this source worksheet in order. The Hormone of Trust — Why the Value Ladder Works Commercially Dan Kennedy's foundational insight on the economics of the value ladder: buyers do not maximise the price they pay — they maximise the amount of value they receive in exchange for the investment they are willing to make. A buyer who receives genuine value at Rung 2 does not think 'I have now spent enough.' They think 'this person has already given me real value. What else do they offer?' The ascension from one rung to the next is not a sell — it is the natural next step for a buyer who has experienced the transformation the prior rung produced. The value ladder works because trust, not transactions, drives ascension. Record actual evidence and applicable definitions; source targets and examples do not establish a completed result.

Source worksheet 3

Work through this source worksheet in order. The 80/20 of Value Ladder Revenue — The Front End Funds the Business, the Back End Builds Wealth In a mature knowledge business value ladder, approximately 80% of total revenue comes from 20% of buyers — the buyers at the premium and done-for-you rungs. The front-end offers (Rungs 1–3) are not the primary revenue source. They are the buyer qualification and trust-building system that identifies and nurtures the 20% who will eventually invest at the premium level. An operator who measures their business exclusively on front-end conversion rates is measuring the wrong thing. The front end's job is not to maximise immediate revenue. Its job is to maximise the number of qualified, trust-established buyers entering the ascension path. Record actual evidence and applicable definitions; source targets and examples do not establish a completed result.

Worksheet 4, item 1 — 1

Apply this source entry using the definitions and corrections in this lesson. Rung: 1 Name: Traffic Hook (Lead Magnet) Investment Level: Free (time investment only) Buyer State at Entry: Unaware to Problem Aware. The buyer has encountered the operator's content and is curious enough to exchange their email address for something specific. Primary Function: Converts anonymous traffic into identified subscribers. Provides the first experience of the operator's perspective and demonstrates that the operator understands the buyer's problem. Primary Business Outcome: List building. Every email subscriber is a named, contactable buyer who has self-selected as relevant to the operator's offer ecosystem. The Traffic Hook is the front door of the entire business. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 4, item 2 — 2

Apply this source entry using the definitions and corrections in this lesson. Rung: 2 Name: Self-Liquidating Offer (SLO) Investment Level: $7–$97 (typically $17–$47) Buyer State at Entry: Problem Aware to Solution Aware. The buyer has consumed the Traffic Hook, is building trust with the operator, and has demonstrated willingness to invest time by engaging with the free content. Primary Function: Converts email subscribers into first-time buyers. The transformation from subscriber to buyer is the most commercially significant transition in the entire value ladder — it establishes the purchase relationship. The SLO price point is set to be an easy yes. Primary Business Outcome: First-buyer conversion at a price point that self-liquidates the cost of subscriber acquisition. An operator whose SLO revenue equals or exceeds their email acquisition cost is effectively building their buyer list for free. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 4, item 3 — 3

Apply this source entry using the definitions and corrections in this lesson. Rung: 3 Name: Core Offer Investment Level: $297–$2,000 (typically $497–$997) Buyer State at Entry: Solution Aware to Product Aware. The buyer has experienced value at Rung 1 or 2, trusts the operator's approach, and is actively seeking a comprehensive solution. Primary Function: Delivers the primary transformation the business is built around. This is the offer that the entire marketing system from Courses 6–15 is designed to sell. It is the proof-of-concept offer: if this offer converts organically and produces results for buyers, the business model is validated. Primary Business Outcome: Primary revenue generation. The Core Offer's conversion rate and buyer quality metrics are the primary indicators of business health in the first 12–18 months. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 4, item 4 — 4

Apply this source entry using the definitions and corrections in this lesson. Rung: 4 Name: Continuity (Recurring Revenue) Investment Level: $47–$297/month (typically $97–$197/month) Buyer State at Entry: Product Aware to Most Aware. The buyer has purchased the Core Offer, received genuine value, and is seeking ongoing access, community, or continued development beyond the programme's conclusion. Primary Function: Creates the income floor. Continuity revenue is the recurring monthly income that the business generates regardless of launch activity. It is the financial stability layer that makes every other decision less fraught. Primary Business Outcome: Revenue floor. A business with $10,000/month in continuity revenue before any launch activity has a fundamentally different financial psychology than a business entirely dependent on launch revenue. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 4, item 5 — 5

Apply this source entry using the definitions and corrections in this lesson. Rung: 5 Name: Premium Offer Investment Level: $2,000–$15,000+ (group or intensive formats) Buyer State at Entry: Most Aware buyers at the highest commitment level. These buyers have consumed multiple rungs and are ready for a higher-access, higher-accountability, higher-investment experience. Primary Function: Serves the most committed 10–20% of the buyer base who want more: more accountability, more access, more personalisation, more speed. The premium offer is the highest-value relationship in the business. Primary Business Outcome: Revenue ceiling expansion. The 80/20 revenue dynamic means the premium rung often generates more total revenue than all lower rungs combined, from a small number of highly committed buyers. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 4, item 6 — 6

Apply this source entry using the definitions and corrections in this lesson. Rung: 6 Name: Done-For-You (DFY) / Highest Tier Investment Level: $5,000–$50,000+ per engagement Buyer State at Entry: The most committed buyers who want the result without the implementation work. Typically a subset of Premium Offer buyers. Primary Function: Removes the implementation burden for buyers who have the financial capacity to pay for it and the business context where it makes sense. DFY is not appropriate for all business models — it requires significant operator or team capacity. Primary Business Outcome: Highest-margin, lowest-volume revenue. DFY engagements are typically the highest average transaction value in the business. They are also the highest fulfilment intensity and the most operator-time-dependent unless fully systematised. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Source worksheet 5

Work through this source worksheet in order. THE ASCENSION PATH The Design of the Journey from Rung 1 to Rung 5 How each rung creates the conditions for the natural next step Record actual evidence and applicable definitions; source targets and examples do not establish a completed result.

Worksheet 6, item 1 — Rung 1 → Rung 2 (Subscriber to SLO Buyer)

Apply this source entry using the definitions and corrections in this lesson. Transition: Rung 1 → Rung 2 (Subscriber to SLO Buyer) What Creates the Natural Next Step: The Traffic Hook delivers a specific, valuable outcome and simultaneously reveals a next level of depth that the Traffic Hook alone cannot provide. The buyer recognises that the free asset gave them something real — and that there is more where it came from. The Specific Mechanism: The Traffic Hook's thank-you page presents the SLO as the immediate next step for buyers who found the Lead Magnet valuable. The welcome email sequence reinforces this with a story and a specific prompt within the first 24–48 hours. What Prevents Natural Ascension: A Traffic Hook that is either too complete (delivers everything the buyer needs, leaving no felt gap) or too thin (delivers too little value to generate trust in the operator's depth). The SLO offer must be presented while the buyer is still in the state of value-recognition from the Traffic Hook. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 6, item 2 — Rung 2 → Rung 3 (SLO Buyer to Core Offer Buyer)

Apply this source entry using the definitions and corrections in this lesson. Transition: Rung 2 → Rung 3 (SLO Buyer to Core Offer Buyer) What Creates the Natural Next Step: The SLO delivers a specific, quick result — the buyer achieves something concrete within hours or days of purchase. This result creates two things simultaneously: proof that the operator's approach works for this buyer specifically, and a new awareness of the larger gap that the quick win has revealed. The Specific Mechanism: The SLO's final section or email follow-up explicitly frames the result achieved and names the next challenge: 'You have now [quick win]. The next step is [deeper challenge that the Core Offer addresses].' The transition is logical, not promotional. What Prevents Natural Ascension: An SLO that delivers a complete, standalone result with no natural next step. The SLO must be designed so that the quick win it produces is a first step in a larger journey — not a complete destination. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 6, item 3 — Rung 3 → Rung 4 (Core Offer Buyer to Continuity Member)

Apply this source entry using the definitions and corrections in this lesson. Transition: Rung 3 → Rung 4 (Core Offer Buyer to Continuity Member) What Creates the Natural Next Step: The Core Offer programme approaches completion. The buyer has achieved a significant transformation. The new challenge is: how do I sustain this, continue developing, and stay connected to a community that understands where I am now? The Specific Mechanism: The final module of the Core Offer programme introduces the continuity offering as the natural home for programme graduates. The graduation experience is framed as a beginning, not an ending: 'You have completed the foundation. The next stage is [Continuity Offer].' What Prevents Natural Ascension: A Core Offer that ends with a graduation email rather than a graduation-plus-invitation. Buyers who receive no next step at programme completion often return to their prior patterns within 60 days — the window for continuity conversion closes quickly after completion. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 6, item 4 — Rung 4 → Rung 5 (Continuity Member to Premium Buyer)

Apply this source entry using the definitions and corrections in this lesson. Transition: Rung 4 → Rung 5 (Continuity Member to Premium Buyer) What Creates the Natural Next Step: The continuity member has been in the community long enough to identify their next specific challenge — one that requires more support, more accountability, or more speed than the community format can provide. The premium offer is positioned as the intensive for members who are ready to go deeper. The Specific Mechanism: The continuity community includes periodic premium programme invitations specifically for members who have reached a defined milestone. The invitation is personalised: based on the member's activity, their questions, and their stated next goal. Not a mass promotion — a milestone-based invitation. What Prevents Natural Ascension: Mass-market promotion of the premium offer to all continuity members regardless of their readiness stage. Premature promotion to members who are not yet at the relevant milestone produces rejections that reduce future openness. The ascension must be milestone-triggered, not calendar-triggered. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 7, item 1 — Community Membership

Apply this source entry using the definitions and corrections in this lesson. Continuity Type: Community Membership What It Provides: Ongoing access to a curated community of peers, regular live sessions, and a shared resource library. The primary value is belonging and peer connection. Optimal Price Range: $47–$197/month Buyer Qualification Threshold: Core Offer completers or verified professionals in the niche. The community quality is the product — unqualified members degrade the product for everyone else. Key Design Requirement: A specific, visible quality bar for admission or continued participation. A community without standards deteriorates. The standards are enforced even at the cost of short-term revenue. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 7, item 2 — Coaching Continuity

Apply this source entry using the definitions and corrections in this lesson. Continuity Type: Coaching Continuity What It Provides: Ongoing access to the operator or operator's team for implementation support, Q&A, and coaching. The primary value is accountability and personalised guidance. Optimal Price Range: $197–$497/month Buyer Qualification Threshold: Core Offer completers or buyers at an equivalent readiness stage. Coaching continuity for buyers who have not done the foundational work produces poor outcomes and high churn. Key Design Requirement: Defined office hours or response SLAs so members know exactly what they are paying for. Coaching continuity without clear access terms produces either buyer disappointment (insufficient access) or operator exhaustion (unlimited demand). Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 7, item 3 — Content Continuity

Apply this source entry using the definitions and corrections in this lesson. Continuity Type: Content Continuity What It Provides: Monthly or weekly delivery of proprietary research, analysis, templates, or tools that are updated to reflect current conditions in the niche. The primary value is information currency and implementation assets. Optimal Price Range: $27–$97/month Buyer Qualification Threshold: Anyone who benefits from the niche-specific content. Lowest barrier entry, widest potential membership base. Key Design Requirement: Genuine information advantage. Content continuity only sustains if the content is genuinely differentiated from what is freely available. Curated aggregation is insufficient — the content must include the operator's specific synthesis and perspective. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 7, item 4 — Software or Tool Access

Apply this source entry using the definitions and corrections in this lesson. Continuity Type: Software or Tool Access What It Provides: Monthly access to a proprietary tool, calculator, framework, or system that automates or significantly simplifies a recurring task in the niche. Optimal Price Range: $47–$297/month Buyer Qualification Threshold: Any buyer who performs the task the tool addresses. Often accessible to non-Core Offer buyers. Key Design Requirement: The tool must save the member more time or produce better outcomes than their current approach in a way they can verify. Software continuity is the most defensible (switching costs are real) and the most demanding to build (requires technical infrastructure). Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 7, item 5 — Mastermind or Peer Group

Apply this source entry using the definitions and corrections in this lesson. Continuity Type: Mastermind or Peer Group What It Provides: Small-group peer-to-peer learning with operator facilitation. Typically 8–20 members per cohort meeting regularly (weekly or biweekly). The primary value is peer accountability, peer learning, and deliberate small-group relationship building. Optimal Price Range: $297–$1,500/month Buyer Qualification Threshold: Buyers with specific readiness criteria — typically at a business development stage where peer learning is more valuable than operator instruction. Often positioned as the bridge between Core Offer and Premium. Key Design Requirement: A rigorous selection process. The quality of a mastermind is determined almost entirely by the quality of its members. Size and selection must be managed deliberately. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Source worksheet 8

Work through this source worksheet in order. The Continuity Churn Problem — Why Most Continuity Programmes Fail The most common continuity failure mode: members join, receive value in Month 1, reduce engagement in Month 2, and cancel by Month 3. The cause is not price or content quality. It is unclear value delivery between joining and cancellation. A member who cannot clearly see what they received for their last month's payment has no reason to continue. The fix: the continuity programme must produce a specific, visible output for every member every month. Not just 'access to the community' but 'the specific insight, connection, or asset the member received this month.' If the member cannot name it: the programme's value is invisible, and invisible value does not sustain payment. Record actual evidence and applicable definitions; source targets and examples do not establish a completed result.

Source worksheet 9

Work through this source worksheet in order. REVENUE ARCHITECTURE ANALYSIS — Calculate for current state and 12-month target THE REVENUE FLOOR CALCULATION Revenue Floor = Continuity Membership Revenue (recurring monthly) Current active continuity members: [N] Average monthly continuity price: [$X] Monthly continuity revenue: [N x $X] Annual continuity revenue (floor): [monthly x 12] THE REVENUE CEILING CALCULATION Revenue Ceiling = Continuity Floor + Launch/Promotional Event Revenue Estimated Core Offer buyers per launch event: [N] Average Core Offer revenue per buyer (including upsells/order bumps): [$X] Number of Core Offer launches per year: [N] Core Offer annual revenue: [buyers x revenue x launches] Estimated Premium Offer buyers per year: [N] Average Premium Offer investment: [$X] Premium annual revenue: [N x $X] Total Revenue Ceiling: [Floor + Core Launch Revenue + Premium Revenue] THE FLOOR/CEILING RATIO HEALTH CHECK Healthy ratio target: Revenue Floor should be at least 30% of Revenue Ceiling High risk (Floor <10% of Ceiling): The business is entirely launch-dependent. One failed launch produces a financial crisis. Moderate risk (Floor 10–29% of Ceiling): Some stability but significant dependence on launch performance. Healthy (Floor 30–49% of Ceiling): Meaningful income floor. Launch performance matters but is not existential. Strong (Floor 50%+ of Ceiling): The business generates reliable income regardless of launch activity. Launches add to a solid foundation. THE CONTINUITY MEMBER COUNT TARGETS To reach a $5,000/month Revenue Floor at $97/month membership: 52 active members To reach a $10,000/month Revenue Floor at $97/month: 104 active members To reach a $5,000/month Revenue Floor at $197/month: 26 active members To reach a $10,000/month Revenue Floor at $197/month: 51 active members These targets clarify the relative priority of continuity growth vs Core Offer launch activity. Record actual evidence and applicable definitions; source targets and examples do not establish a completed result.

Source worksheet 10

Work through this source worksheet in order. THE UPSELL AND DOWNSELL INFRASTRUCTURE Maximising Revenue From Every Transaction The funnel architecture that captures value across the full range of buyer readiness Record actual evidence and applicable definitions; source targets and examples do not establish a completed result.

Worksheet 11, item 1 — Order Bump

Apply this source entry using the definitions and corrections in this lesson. Type: Order Bump Definition: A low-price complementary offer presented on the primary offer's checkout page as a checkbox add-on. The buyer adds it with a single click without leaving the checkout flow. Placement: On the checkout page, below the primary offer details and above the payment button. Optimal Price: 15–30% of the primary offer's price. At this ratio, the order bump converts 20–40% of buyers. Design Principle: The order bump must be a specific, immediate-value complement to the primary offer — something the buyer will use in the first week of the primary programme. A template pack, a quick-start guide, a tool. Not a separate product that requires its own learning curve. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 11, item 2 — One-Time Offer (OTO) Upsell

Apply this source entry using the definitions and corrections in this lesson. Type: One-Time Offer (OTO) Upsell Definition: A higher-price upgrade offer presented immediately after the primary offer is purchased, on a dedicated page the buyer reaches before the confirmation page. Placement: Immediately post-purchase, before the thank-you or delivery confirmation page. Optimal Price: 150–300% of the primary offer's price. At this price ratio, OTO upsells convert 10–25% of buyers. Design Principle: The OTO must be a genuine upgrade — not a continuation of the primary offer but a faster path to the result, a higher level of access, or a complementary system that amplifies the primary offer's value. 'Buy the same thing at a higher price' is not an OTO. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 11, item 3 — Downsell

Apply this source entry using the definitions and corrections in this lesson. Type: Downsell Definition: A lower-price alternative offered to buyers who decline the OTO upsell. The downsell captures revenue from buyers who said no to the full upsell price but are still in a state of purchase engagement. Placement: Immediately after the OTO decline button is clicked. Optimal Price: 40–60% of the OTO price. Converts 20–40% of OTO decliners. Design Principle: The downsell is a genuine step-down in access or scope — not the same offer at a different price. A video-only version of a live programme, a single module extraction, or a lower-tier membership. The buyer who declines the OTO and accepts the downsell is a legitimate buyer — not a consolation conversion. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 11, item 4 — Post-Purchase Upsell

Apply this source entry using the definitions and corrections in this lesson. Type: Post-Purchase Upsell Definition: An offer presented in the post-purchase delivery sequence (welcome email or onboarding sequence) for buyers who did not purchase the OTO. Placement: Day 3–7 of the post-purchase welcome sequence, after the buyer has had their first positive experience with the primary offer. Optimal Price: Same range as the OTO. Design Principle: Presented when the buyer has experienced genuine early value from the primary offer and is in a state of positive engagement. 'Based on where you are now in the programme, the next most useful thing is [offer].' Contextualised, not mass-broadcast. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 12, item 1 — 1 — Checkout page with Order Bump

Apply this source entry using the definitions and corrections in this lesson. Step: 1 — Checkout page with Order Bump What Happens: Buyer arrives at checkout for the Core Offer. The Order Bump is visible below the offer details. No action required to decline — it is opt-in. Revenue Contribution: 20–40% of Core Offer buyers add the Order Bump. At a $97 order bump and 30% conversion on 100 buyers: $2,910 incremental revenue per 100 buyers with zero additional marketing cost. Error to Avoid: Making the Order Bump too large (in scope or price). An Order Bump that requires significant explanation is already too complex. It must be immediately obvious and immediately desirable. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 12, item 2 — 2 — OTO presented post-purchase

Apply this source entry using the definitions and corrections in this lesson. Step: 2 — OTO presented post-purchase What Happens: Immediately after payment, before the confirmation page, the buyer is presented with the OTO. They cannot return to the primary checkout — the primary purchase is confirmed regardless. Revenue Contribution: 15% of Core Offer buyers take the OTO. At a $997 OTO and 15% conversion on 100 buyers: $14,955 incremental revenue per 100 buyers. Error to Avoid: Presenting the OTO before confirming the primary purchase. This creates buyer anxiety about the purchase they just made. The primary purchase confirmation must be clear before the OTO is presented. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 12, item 3 — 3 — Downsell presented if OTO is declined

Apply this source entry using the definitions and corrections in this lesson. Step: 3 — Downsell presented if OTO is declined What Happens: If the buyer clicks 'No thanks' on the OTO, they are immediately presented with the Downsell — a genuine step-down alternative. Revenue Contribution: 25% of OTO decliners take the Downsell. At a $397 Downsell: 85 buyers declined the OTO, 21 take the Downsell = $8,337 incremental revenue per 100 buyers. Error to Avoid: A Downsell page that creates guilt ('Are you sure you want to miss out on this?'). Downsell pages that use pressure or shame convert at a short-term rate but produce a buyer who felt manipulated. The Downsell must be a genuine alternative presented with full respect for the buyer's decision. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 12, item 4 — 4 — Thank-you page with soft next step

Apply this source entry using the definitions and corrections in this lesson. Step: 4 — Thank-you page with soft next step What Happens: The buyer reaches the confirmation page. A soft mention (not a full OTO) of the next logical step is included — typically the Continuity Offer or the Premium Waitlist. Revenue Contribution: Low direct conversion on the thank-you page (3–8%) but high awareness-building for the next ascension step. Error to Avoid: A thank-you page that is purely logistical ('Your confirmation is in your email'). The thank-you page is the highest-trust moment in the entire funnel and a significant missed opportunity if it contains only logistics. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 12, item 5 — 5 — Post-purchase sequence Day 3–7

Apply this source entry using the definitions and corrections in this lesson. Step: 5 — Post-purchase sequence Day 3–7 What Happens: Buyers who did not take the OTO receive a contextualised post-purchase upsell in the welcome sequence, after their first week of programme engagement. Revenue Contribution: 5–10% additional OTO conversion from non-OTO buyers. These are buyers who declined in the moment of purchase but became more open after experiencing early value. Error to Avoid: Sending the post-purchase upsell before the buyer has had time to experience value from the primary offer. Day 1 upsell attempts to buyers who just paid feel like immediate reselling. Day 3–7, after a positive early experience, feels like a natural next step. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 13, item 1 — Entry Points

Apply this source entry using the definitions and corrections in this lesson. Ecosystem Element: Entry Points What It Documents: Which offers a new buyer (who has no prior relationship with the operator) can enter the ecosystem through. Typically Rung 1 and Rung 2. Why It Is Required: Ensures every marketing channel and every traffic source has a clearly defined offer destination that matches the awareness level of the incoming traffic. What Happens Without It: Traffic from different channels lands on offers inappropriate for the awareness level of that traffic. Cold traffic landing on a $5,000 premium offer without a prior relationship path does not convert. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 13, item 2 — Prerequisites

Apply this source entry using the definitions and corrections in this lesson. Ecosystem Element: Prerequisites What It Documents: Whether any offer has required prior purchases or conditions for entry. Why It Is Required: Prevents buyers from purchasing offers they are not ready for, which produces poor results, high refunds, and frustrated buyers. What Happens Without It: Buyers purchase the Premium Offer without the Core Offer's foundational work. They cannot implement the advanced content, produce no results, and attribute the failure to the programme. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 13, item 3 — Logical Next Steps

Apply this source entry using the definitions and corrections in this lesson. Ecosystem Element: Logical Next Steps What It Documents: The specific offer each buyer should be presented with upon completing or reaching a milestone in the current offer. Why It Is Required: Automates the ascension path by ensuring that the completion trigger for each offer fires the appropriate next-step offer or invitation. What Happens Without It: Completers receive a thank-you email and are never contacted about the next natural step. The conversion window closes. The buyer finds another provider for their next stage. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 13, item 4 — Exit Paths

Apply this source entry using the definitions and corrections in this lesson. Ecosystem Element: Exit Paths What It Documents: What options exist for buyers who reach each rung and are not ready or willing to ascend further. Why It Is Required: Ensures every buyer has a dignified, value-maintaining exit path that preserves the relationship even if they do not ascend. What Happens Without It: Buyers who reach an exit point without an exit path either churn silently or produce negative word-of-mouth when they feel they have been pressure-sold beyond their commitment level. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 13, item 5 — Cross-Offer Synergies

Apply this source entry using the definitions and corrections in this lesson. Ecosystem Element: Cross-Offer Synergies What It Documents: Where the content, community, or results from one offer enhances the value of another offer in the ecosystem. Why It Is Required: Creates compounding buyer value: buyers who have completed multiple rungs have cumulative advantages that make each successive rung more valuable. What Happens Without It: Offers are designed and delivered as independent products with no connection to each other. Buyers do not experience the cumulative value that the full ecosystem can provide. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Source worksheet 14

Work through this source worksheet in order. PRODUCT ECOSYSTEM MAP — Complete for the full value ladder RUNG 1 — TRAFFIC HOOK / LEAD MAGNET Offer name: [working title] Format: [PDF guide / Video series / Scorecard / Template / Mini-course] Delivery mechanism: [Email delivery / Gated page / Immediate download] Prerequisite: None Entry point for traffic from: [all channels — this is the universal entry point] Natural next step after delivery: Rung 2 SLO (presented on thank-you page and in Email 1) Exit path if buyer does not proceed: Continues in email nurture sequence RUNG 2 — SELF-LIQUIDATING OFFER Offer name: Price: [$X] Format: [Video workshop / Workbook / Mini-course / Template pack] Prerequisite: None (can be purchased without Rung 1) Primary entry source: Rung 1 thank-you page + Email sequence Days 1–3 Natural next step after completion: Core Offer (presented in Rung 2 delivery) Order Bump on Rung 2 checkout: [name and price] OTO after Rung 2 purchase: [name and price, if applicable] Exit path: Continues in email sequence if no Core Offer purchase RUNG 3 — CORE OFFER Offer name: Price: [$X] Format: [Group programme / Self-paced course / Cohort / Live workshops] Prerequisite: Rung 2 buyer status (ideal) or verified readiness (via application or screening) Primary entry source: Email sequence Days 5–14 + Sales page + Launch events Order Bump on checkout: [name and price] OTO after purchase: [name and price] Downsell if OTO declined: [name and price] Natural next step upon completion: Continuity Offer (presented in final module + graduation email) Exit path: Continued email relationship with periodic Core Offer re-engagement campaigns RUNG 4 — CONTINUITY Offer name: Monthly price: [$X/month] Format: [Community / Coaching sessions / Content library / Mastermind] Prerequisite: Core Offer completion or verified equivalent experience Primary entry source: Core Offer completion sequence + Community invitation Cancellation exit path: Exit interview + 3-month win-back sequence Natural next step for high-engagement members: Premium Offer invitation (milestone-triggered) RUNG 5 — PREMIUM OFFER Offer name: Price: [$X for [duration/format]] Format: [High-touch group coaching / Intensive / Mastermind / Accelerator] Prerequisite: Core Offer completion + minimum [N] months in Continuity (or equivalent) Primary entry source: Milestone-triggered personal invitation from Continuity Application or call required: [Yes / No] Natural next step: DFY engagement for qualified buyers / continued Premium for ongoing support RUNG 6 — DONE-FOR-YOU (if applicable) Offer name: Price: [$X per engagement or retainer] Format: [Specific deliverable description] Prerequisite: Premium Offer participation or equivalent documented context Capacity constraint: Maximum [N] concurrent DFY clients Natural next step: Long-term retainer / referral to network if capacity reached Record actual evidence and applicable definitions; source targets and examples do not establish a completed result.

Worksheet 15, item 1 — Step 1

Apply this source entry using the definitions and corrections in this lesson. Build Order: Step 1 Rung Built: Rung 1 — Traffic Hook Dependency: None. This is the first thing built. Milestone to Pass Before Building Next Rung: Minimum 100 email subscribers from organic sources. Opt-in rate above 25% from warm sources. Why This Order: The Traffic Hook validates the operator's ability to attract and capture the target audience before any paid offer exists. It is also the list-building infrastructure that every subsequent offer will be sold to. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 15, item 2 — Step 2

Apply this source entry using the definitions and corrections in this lesson. Build Order: Step 2 Rung Built: Rung 3 — Core Offer Dependency: Traffic Hook live and building the list. Milestone to Pass Before Building Next Rung: First 5 sales of the Core Offer at full price, from organic sources. Refund rate below 10%. Why This Order: The Core Offer is built second, not the SLO, because the Core Offer is the proof-of-concept for the entire business. Validating the Core Offer first confirms the business model. The SLO is built to self-liquidate the cost of Core Offer buyer acquisition — but only after the Core Offer is confirmed as viable. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 15, item 3 — Step 3

Apply this source entry using the definitions and corrections in this lesson. Build Order: Step 3 Rung Built: Rung 2 — Self-Liquidating Offer Dependency: Core Offer validated with first sales. Milestone to Pass Before Building Next Rung: SLO revenue equals or exceeds the cost of email subscriber acquisition from paid sources. (Only relevant once paid traffic begins.) SLO conversion rate above 3% from email subscribers. Why This Order: The SLO is built third because its purpose is to self-liquidate paid traffic costs. Building it before the Core Offer is validated means building an acquisition path for an offer whose commercial viability is unconfirmed. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 15, item 4 — Step 4

Apply this source entry using the definitions and corrections in this lesson. Build Order: Step 4 Rung Built: Rung 4 — Continuity Dependency: Core Offer generating regular buyers with above-threshold completion rates and positive testimonials. Milestone to Pass Before Building Next Rung: Minimum 20 continuity members paying the monthly fee. Churn rate below 5% per month. Why This Order: Continuity requires buyers who have experienced genuine Core Offer transformation and want to continue. It cannot be launched to a list that has no buyers — the members are the product. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 15, item 5 — Step 5

Apply this source entry using the definitions and corrections in this lesson. Build Order: Step 5 Rung Built: Rung 5 — Premium Offer Dependency: Active continuity community with milestone-ready members. Milestone to Pass Before Building Next Rung: Minimum 5 Premium Offer buyers with documented premium-level results. Premium offer ROI confirmed: buyers are receiving more than the premium price in value. Why This Order: The Premium Offer is built when the operator has enough continuity members to identify the specific 20% who are ready for higher-access support. Building it earlier produces an offer with no qualified buyers. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 15, item 6 — Step 6

Apply this source entry using the definitions and corrections in this lesson. Build Order: Step 6 Rung Built: Rung 6 — Done-For-You Dependency: Premium Offer validated with results evidence. Operator has capacity (or team capacity) for DFY delivery. Milestone to Pass Before Building Next Rung: DFY delivery system fully documented and tested with 2–3 pilot engagements. Operator or team can sustain DFY delivery without degrading Core Offer or Premium Offer quality. Why This Order: DFY is the highest-fulfilment-intensity rung. It is built last because it requires the operator's maximum capacity. Building it before the lower rungs are systematised produces a situation where DFY clients consume all available operator time, preventing the lower-rung business from functioning. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Source worksheet 16

Work through this source worksheet in order. LTV CALCULATION TEMPLATE — Complete for each buyer cohort (monthly cohort recommended) COHORT DEFINITION Cohort entry date: [Month/Year] Cohort size: [N buyers who purchased the Core Offer in this month] Cohort entry offer: [Core Offer name and price] 30-DAY LTV Core Offer revenue per buyer: [$X] Order Bump uptake: [N% x $bump price] OTO uptake: [N% x $OTO price] Downsell uptake: [N% x $downsell price] 30-Day LTV = [Core Offer + (Order Bump rate x price) + (OTO rate x price) + (Downsell rate x price)] 30-Day LTV benchmark: Above 1.3x the Core Offer base price 90-DAY LTV 30-Day LTV (from above) Plus: Continuity conversion rate from this cohort: [N% joining at $X/month x 3 months of membership] Plus: Any second Core Offer purchase (returning buyers or upsells within cohort period) 90-Day LTV benchmark: Above 1.6x the Core Offer base price 12-MONTH LTV 90-Day LTV (from above) Plus: Continuity revenue months 4–12 for members who did not churn Plus: Premium Offer conversion from this cohort: [N% x $premium price] 12-Month LTV benchmark: Above 2.5x the Core Offer base price for a healthy value ladder THE MAXIMUM VIABLE CPL CALCULATION Maximum Viable CPL = 90-Day LTV x (1 - minimum required gross margin) Example: 90-Day LTV = $850 | Required gross margin = 50% Maximum Viable CPL = $850 x 50% = $425 An operator whose paid traffic CPL is below their Maximum Viable CPL has a commercially sustainable paid acquisition channel. An operator whose CPL exceeds their Maximum Viable CPL must either increase LTV (by improving the back-end conversion rates) or reduce CPL (by improving front-end conversion rates) before scaling paid traffic. Record actual evidence and applicable definitions; source targets and examples do not establish a completed result.

Worksheet 17, item 1 — 1 — Improve Order Bump Conversion

Apply this source entry using the definitions and corrections in this lesson. Lever: 1 — Improve Order Bump Conversion How It Works: Test different Order Bump offers, prices, and copy. An Order Bump converting at 30% vs 15% doubles the order bump revenue contribution to LTV. The LTV Impact: Each 10 percentage point increase in Order Bump conversion adds approximately 3–5% to 30-Day LTV. Implementation Priority: High. Order Bump testing has zero incremental traffic cost and immediate LTV impact. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 17, item 2 — 2 — Improve OTO Conversion

Apply this source entry using the definitions and corrections in this lesson. Lever: 2 — Improve OTO Conversion How It Works: Test different OTO offers, prices, and framing. The OTO is the highest-value single conversion opportunity in the immediate post-purchase window. The LTV Impact: Each 5 percentage point increase in OTO conversion adds 10–15% to 30-Day LTV at a typical OTO price ratio. Implementation Priority: High. Same zero-traffic-cost testing environment as the Order Bump. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 17, item 3 — 3 — Improve Core Offer Completion Rate

Apply this source entry using the definitions and corrections in this lesson. Lever: 3 — Improve Core Offer Completion Rate How It Works: Buyers who complete the programme are 3–5x more likely to join continuity, purchase premium, and generate testimonials than buyers who do not complete. The LTV Impact: A 20 percentage point improvement in Core Offer completion rate (from 40% to 60%) can increase 90-Day LTV by 20–30% through downstream continuity and premium conversion improvement. Implementation Priority: Very high. Programme completion is the multiplier for every downstream LTV lever. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 17, item 4 — 4 — Improve Continuity Conversion

Apply this source entry using the definitions and corrections in this lesson. Lever: 4 — Improve Continuity Conversion How It Works: Test the timing, framing, and format of the continuity offer presentation at Core Offer completion. Earlier vs later presentation, community preview vs feature description. The LTV Impact: Each 10 percentage point improvement in continuity conversion from Core Offer buyers adds the full monthly continuity value x average membership duration to cohort LTV. Implementation Priority: High, especially as the business matures. Continuity is the compounding LTV lever. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 17, item 5 — 5 — Reduce Continuity Churn

Apply this source entry using the definitions and corrections in this lesson. Lever: 5 — Reduce Continuity Churn How It Works: Improve the monthly value delivery visibility so members can clearly see what they received. Reduce the monthly churn rate. The LTV Impact: A reduction from 5% monthly churn to 3% increases the average membership duration from 20 months to 33 months — a 65% increase in continuity LTV per member. Implementation Priority: Very high for mature continuity programmes. The compounding effect of lower churn dramatically outperforms the effect of higher new member acquisition. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 17, item 6 — 6 — Improve Premium Conversion from Continuity

Apply this source entry using the definitions and corrections in this lesson. Lever: 6 — Improve Premium Conversion from Continuity How It Works: Develop the milestone-triggered invitation system. Personalise invitations based on member activity and stated goals. Test different premium offer formats. The LTV Impact: Each additional 5% of continuity members who convert to Premium adds the full premium price to cohort LTV. Implementation Priority: Medium for early-stage businesses (Premium offer may not yet exist). High for mature businesses where Premium is the primary profit driver. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 18, item 1 — Rung 1 — Traffic Hook

Apply this source entry using the definitions and corrections in this lesson. Rung: Rung 1 — Traffic Hook Primary Health Metric: Opt-in rate from primary traffic sources Healthy Benchmark: Above 30% from warm sources Requires Attention: 20–29% Urgent Action Required: Below 20%. The Traffic Hook offer, the headline, or the traffic source alignment is broken. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 18, item 2 — Rung 2 — SLO

Apply this source entry using the definitions and corrections in this lesson. Rung: Rung 2 — SLO Primary Health Metric: Conversion rate from email subscribers Healthy Benchmark: Above 3% Requires Attention: 1.5–2.9% Urgent Action Required: Below 1.5%. The SLO offer's price-to-value ratio, the offer's specificity, or the email sequence presenting it requires review. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 18, item 3 — Rung 3 — Core Offer

Apply this source entry using the definitions and corrections in this lesson. Rung: Rung 3 — Core Offer Primary Health Metric: 30-day subscriber-to-buyer conversion rate Healthy Benchmark: Above 2% Requires Attention: 1–1.9% Urgent Action Required: Below 1%. The organic funnel has not yet passed the Hard Organic Proof Threshold and should not be scaled with paid traffic. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 18, item 4 — Rung 4 — Continuity

Apply this source entry using the definitions and corrections in this lesson. Rung: Rung 4 — Continuity Primary Health Metric: Monthly churn rate Healthy Benchmark: Below 3% Requires Attention: 3–6% Urgent Action Required: Above 6% monthly churn. The monthly value delivery is not visible to members, or the entry qualification standards are allowing buyers who are not ready. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 18, item 5 — Rung 5 — Premium

Apply this source entry using the definitions and corrections in this lesson. Rung: Rung 5 — Premium Primary Health Metric: Conversion rate from milestone-invited continuity members Healthy Benchmark: Above 15% of eligible invitees accept Requires Attention: 8–14% Urgent Action Required: Below 8%. The invitation timing, the premium offer format, or the milestone qualification criteria requires review. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 18, item 6 — Rung 6 — DFY (if active)

Apply this source entry using the definitions and corrections in this lesson. Rung: Rung 6 — DFY (if active) Primary Health Metric: Client satisfaction and renewal rate Healthy Benchmark: Above 80% of DFY clients renew or refer Requires Attention: 65–79% renewal/referral Urgent Action Required: Below 65%. The DFY delivery quality or scope definition requires review. Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Source worksheet 19

Work through this source worksheet in order. VALUE LADDER HEALTH ASSESSMENT — Quarterly Review Protocol PREPARATION (before the review meeting) Pull the current metrics for each active rung from the Airtable tracking system. Calculate the current cohort LTV at 30-day and 90-day marks. Calculate the current Revenue Floor (continuity monthly total) and Revenue Ceiling (Floor + launch projections). Calculate the current Floor/Ceiling ratio. THE ASSESSMENT (30 minutes) Rung 1: [current opt-in rate] — Benchmark status: [Healthy / Attention / Urgent] Rung 2: [current SLO conversion rate] — Benchmark status: [same format] Rung 3: [current Core Offer conversion rate] — Benchmark status: Rung 4: [current churn rate] — Benchmark status: Rung 5 (if active): [premium conversion rate] — Benchmark status: Revenue Floor: [$X/month] | Floor/Ceiling ratio: [X%] — Benchmark status: 30-Day LTV: [$X] | 90-Day LTV: [$X] — Benchmark status: THE PRIORITY ACTION Identify the single most underperforming rung (the lowest benchmark status with the highest LTV impact). For this rung: what specifically is the action to move it from its current status to the next benchmark tier? Name the action, the person responsible, and the date by which it will be implemented. Do not attempt to fix multiple rungs simultaneously. One rung at a time. Record actual evidence and applicable definitions; source targets and examples do not establish a completed result.

Worksheet 20, item 1 — Rung Number

Apply this source entry using the definitions and corrections in this lesson. Field: Rung Number Type: Number Notes: 1–6 Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 20, item 2 — Rung Name

Apply this source entry using the definitions and corrections in this lesson. Field: Rung Name Type: Short text Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 20, item 3 — Offer Name

Apply this source entry using the definitions and corrections in this lesson. Field: Offer Name Type: Short text Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 20, item 4 — Price

Apply this source entry using the definitions and corrections in this lesson. Field: Price Type: Currency Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 20, item 5 — Format

Apply this source entry using the definitions and corrections in this lesson. Field: Format Type: Single select Notes: Lead Magnet / SLO / Core Offer / Continuity / Premium / DFY Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 20, item 6 — Status

Apply this source entry using the definitions and corrections in this lesson. Field: Status Type: Single select Notes: Planned / In Development / Active / Retired Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 20, item 7 — Launch Date

Apply this source entry using the definitions and corrections in this lesson. Field: Launch Date Type: Date Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 20, item 8 — Prerequisite Rung

Apply this source entry using the definitions and corrections in this lesson. Field: Prerequisite Rung Type: Number Notes: Which rung must be purchased first (if any) Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 20, item 9 — Natural Next Step

Apply this source entry using the definitions and corrections in this lesson. Field: Natural Next Step Type: Link → Value Ladder Configuration Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 20, item 10 — Primary Entry Source

Apply this source entry using the definitions and corrections in this lesson. Field: Primary Entry Source Type: Short text Notes: Which channel/campaign delivers buyers to this rung Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 20, item 11 — Order Bump

Apply this source entry using the definitions and corrections in this lesson. Field: Order Bump Type: Short text Notes: Name and price of the Order Bump on this offer's checkout Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 20, item 12 — OTO

Apply this source entry using the definitions and corrections in this lesson. Field: OTO Type: Short text Notes: Name and price of the OTO presented post-purchase Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 20, item 13 — Downsell

Apply this source entry using the definitions and corrections in this lesson. Field: Downsell Type: Short text Notes: Name and price of the Downsell Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 20, item 14 — Monthly Revenue (active offers)

Apply this source entry using the definitions and corrections in this lesson. Field: Monthly Revenue (active offers) Type: Currency Notes: Calculated from buyer count x average price (for continuity) Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 20, item 15 — Notes

Apply this source entry using the definitions and corrections in this lesson. Field: Notes Type: Long text Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 21, item 1 — Cohort Month

Apply this source entry using the definitions and corrections in this lesson. Field: Cohort Month Type: Short text Notes: Format: YYYY-MM Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 21, item 2 — Cohort Size

Apply this source entry using the definitions and corrections in this lesson. Field: Cohort Size Type: Number Notes: Buyers entering at Core Offer in this month Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 21, item 3 — Core Offer Revenue

Apply this source entry using the definitions and corrections in this lesson. Field: Core Offer Revenue Type: Currency Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 21, item 4 — Order Bump Revenue

Apply this source entry using the definitions and corrections in this lesson. Field: Order Bump Revenue Type: Currency Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 21, item 5 — OTO Revenue

Apply this source entry using the definitions and corrections in this lesson. Field: OTO Revenue Type: Currency Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 21, item 6 — Downsell Revenue

Apply this source entry using the definitions and corrections in this lesson. Field: Downsell Revenue Type: Currency Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 21, item 7 — 30-Day Total LTV per Buyer

Apply this source entry using the definitions and corrections in this lesson. Field: 30-Day Total LTV per Buyer Type: Formula Notes: Sum of above ÷ cohort size Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 21, item 8 — Continuity Conversions from Cohort

Apply this source entry using the definitions and corrections in this lesson. Field: Continuity Conversions from Cohort Type: Number Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 21, item 9 — Continuity Revenue Month 1–3

Apply this source entry using the definitions and corrections in this lesson. Field: Continuity Revenue Month 1–3 Type: Currency Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 21, item 10 — 90-Day Total LTV per Buyer

Apply this source entry using the definitions and corrections in this lesson. Field: 90-Day Total LTV per Buyer Type: Formula Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 21, item 11 — Premium Conversions from Cohort

Apply this source entry using the definitions and corrections in this lesson. Field: Premium Conversions from Cohort Type: Number Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 21, item 12 — Premium Revenue from Cohort

Apply this source entry using the definitions and corrections in this lesson. Field: Premium Revenue from Cohort Type: Currency Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 21, item 13 — 12-Month Total LTV per Buyer

Apply this source entry using the definitions and corrections in this lesson. Field: 12-Month Total LTV per Buyer Type: Formula Record the relevant evidence, decision and responsible owner rather than treating a template or proposed threshold as an observed fact.

Worksheet 21, item 14 — Notes

Execution checklist 1

Work through these actions: ☐ Six Rung Framework reviewed — each rung's function understood and relevant to the committed niche ☐ Product Ecosystem Map drafted: all six rungs defined with prerequisites, entry sources, natural next steps, and exit paths ☐ Revenue Floor target set: specific continuity member count and price to reach the target floor ☐ Revenue Floor / Revenue Ceiling ratio target defined Document completion separately from planned work. Apply the resolved rubric, current commitments and relevant source links at each decision.

Execution checklist 2

Work through these actions: ☐ Traffic Hook offer defined: format, specific promise, and delivery mechanism ☐ Opt-in page live with tested Traffic Hook headline ☐ Welcome email sequence active: Email 1 through Email 7 built with Rung 2 SLO presented in Email 1 and Email 3 ☐ Core Offer structure defined: delivery format, programme length, number of modules, live vs asynchronous Document completion separately from planned work. Apply the resolved rubric, current commitments and relevant source links at each decision.

Execution checklist 3

Work through these actions: ☐ Core Offer sales page built with Story Asset Library stories deployed ☐ Order Bump defined and added to checkout ☐ OTO defined and post-purchase page built ☐ Downsell defined and decline page built Document completion separately from planned work. Apply the resolved rubric, current commitments and relevant source links at each decision.

Execution checklist 4

Work through these actions: ☐ Core Offer delivery infrastructure tested: all modules accessible, email delivery confirmed ☐ First 5 sales target set with a specific date ☐ SLO offer defined: a fast-result, specific, low-risk complement to or preview of the Core Offer ☐ SLO price confirmed at 15–30% of Core Offer price Document completion separately from planned work. Apply the resolved rubric, current commitments and relevant source links at each decision.

Execution checklist 5

Work through these actions: ☐ SLO added to Traffic Hook thank-you page and Email sequence Day 1–3 ☐ Continuity format selected from the five model types ☐ Continuity monthly value delivery structure designed: what specific output does each member receive each month? ☐ Continuity entry criteria defined and enforced Document completion separately from planned work. Apply the resolved rubric, current commitments and relevant source links at each decision.

Execution checklist 6

Work through these actions: ☐ Core Offer graduation sequence updated with continuity invitation ☐ Churn prevention system in place: monthly value visibility mechanism ☐ All active rung metrics pulled: opt-in rate, SLO conversion, Core Offer conversion, churn rate ☐ 30-Day and 90-Day LTV calculated for most recent cohort Document completion separately from planned work. Apply the resolved rubric, current commitments and relevant source links at each decision.

Execution checklist 7

Work through these actions: ☐ Floor/Ceiling ratio calculated ☐ Single priority rung identified for improvement action ☐ Action assigned to responsible person with completion date Document completion separately from planned work. Apply the resolved rubric, current commitments and relevant source links at each decision.

Connect a coherent ladder to the offer promise

Use Brunson’s progression from relevant entry point to deeper useful service, and Hormozi’s focus on credible outcomes with less unnecessary effort and delay. Neither requires six products, artificial dependency, relentless upselling or unsupported value ratios. Validate one deliverable offer and measure its results before committing capacity to the next rung.

Apply the Brunson and Hormozi teaching frame

Complete original source text

RISER NATION
MASTER OPERATING SYSTEM — COURSE 14 — TRACK 3: BUILD YOUR OFFER
SOP — VALUE LADDER ARCHITECTURE
The Complete System for Designing a Multi-Product Revenue Architecture That Guides Buyers from Free Entry to Premium Relationships — The Six Rung Framework, the Ascension Path Design Protocol, the Continuity Engine, the Product Ecosystem Map, the Revenue Floor vs Revenue Ceiling Architecture, the Downsell and Upsell Infrastructure, the LTV Maximisation System, and the Value Ladder Health Assessment
Track 3: Build Your Offer — Course 14 of 14 | 2026 Framework
Version 1.0 | 2026 Edition | RISER Nation Master Operating System
SOP Overview — Why a Single Offer Is a Structurally Fragile Business
A knowledge business with a single offer is a business with a single revenue event. Every buyer either purchases the one offer or they do not. Buyers who are not ready for the price point have nowhere to start. Buyers who complete the offer and want more have nowhere to go. Buyers who are committed but need a different format or a different level of support have no alternative path. The single-offer business is maximally dependent on the conversion rate of the one thing it sells, and maximally exposed to any change in that conversion rate.
The value ladder is the architecture that addresses every one of these constraints. It creates a range of entry points so buyers at different commitment and investment levels can find the right starting place. It creates an ascension path so buyers who receive value naturally progress to deeper engagement rather than leaving. It creates a revenue floor (recurring income from continuity) that makes the business financially stable between launch events. It creates a revenue ceiling (premium offers) that allows the business to maximise the LTV of its most committed buyers without needing to find new ones. And it creates a referral architecture where buyers at every rung have specific, natural ways to recommend the business to people in their network.
This SOP covers: the foundational logic of the value ladder and why it is built from a specific philosophy rather than assembled opportunistically, the six rung framework and what each rung is designed to accomplish, the Ascension Path Design Protocol, the Continuity Engine and why recurring revenue is the business's income floor, the Downsell and Upsell infrastructure, the LTV Maximisation System, the Product Ecosystem Map, the Revenue Floor versus Revenue Ceiling analysis, the Value Ladder Build Sequence for new operators, and the Value Ladder Health Assessment.
The Six Rung Framework
Every rung in the value ladder serves a specific commercial and relational function. The architecture of the ladder is not arbitrary — each rung is designed to produce a specific outcome for the buyer and a specific economic contribution to the business. Understanding what each rung is for prevents the common error of building rungs that duplicate each other's function rather than ascending the buyer's commitment and investment.
The ascension path is the deliberate design of the transition between every adjacent pair of rungs in the value ladder. It is not left to chance or to the buyer's initiative. The ascension path is built into the delivery of every rung: the completion of Rung 2 naturally surfaces the need for Rung 3; the completion of Rung 3 naturally surfaces the need for Rung 4. The buyer does not have to be talked into ascending — the delivery creates the conditions for the next step to feel like the obvious one.
The Ascension Path Design Protocol
The Continuity Engine — Building the Business's Income Floor
Continuity — recurring monthly revenue from ongoing memberships, communities, coaching programmes, or software subscriptions — is the most structurally important revenue type in a knowledge business. It is not the most glamorous, the most frequently discussed, or the most aspirational. It is the most stabilising. A business with a functioning continuity engine makes better decisions, takes better risks, and serves its buyers more generously than a business entirely dependent on launch revenue, because the financial pressure of the next launch is structurally reduced.
The Five Continuity Model Types
The Revenue Floor vs Revenue Ceiling Analysis
The Revenue Floor is the recurring monthly revenue the business generates without any launch or promotional activity. It is the income the operator can rely on in a month with zero selling. The Revenue Ceiling is the theoretical maximum revenue the business can generate in a high-activity month with a full launch. Understanding the relationship between these two numbers is the primary lever for financial planning in the knowledge business.
The Revenue Architecture Calculation
The upsell and downsell infrastructure is the set of offers presented immediately before or immediately after a buyer's primary purchase decision. It is not an afterthought or an add-on — it is a planned component of the value ladder that captures revenue from buyers at the exact moment their purchase intent is highest, without requiring a second marketing campaign to generate it.
The Four Transaction Enhancement Types
The Transaction Enhancement Sequence — The Complete Funnel Architecture
The Product Ecosystem Map — How All Offers Connect
The Product Ecosystem Map is the visual and strategic overview of how every offer in the value ladder relates to every other offer: how buyers move between them, what each offer's prerequisite is, and how the offers together produce a coherent, progressive buyer journey rather than a collection of independent products.
The Product Ecosystem Map Elements
The Product Ecosystem Map Template
The Value Ladder Build Sequence for New Operators
The value ladder described in this SOP is the complete architecture. New operators do not build all six rungs before the business generates revenue. The Build Sequence below defines the order in which rungs are built, the dependency each rung has on the prior rung's validation, and the milestone that must be passed before building the next rung.
The LTV Maximisation System
Lifetime Value (LTV) is the total revenue a single buyer generates across all rungs of the value ladder over the entire duration of their relationship with the business. LTV is the single most important metric for assessing the long-term health of a knowledge business and the primary input for calculating the maximum sustainable Cost Per Lead (CPL) for paid traffic.
The LTV Calculation by Buyer Cohort
The Six LTV Enhancement Levers
The Value Ladder Health Assessment
The Value Ladder Health Assessment is a structured quarterly review of every rung in the current value ladder. It identifies which rungs are performing at or above standard, which are underperforming, and what specific action is required to address each underperforming rung. It is not a general sense-check — it is a scored assessment against specific benchmarks.
The Rung-by-Rung Health Scorecard
Airtable Schema — Value Ladder Tracking Database
Table 1 — Value Ladder Configuration
Table 2 — Monthly LTV Tracker
Master Value Ladder Architecture Checklist
Architecture Design (Complete Before Building)
☐ Six Rung Framework reviewed — each rung's function understood and relevant to the committed niche
☐ Product Ecosystem Map drafted: all six rungs defined with prerequisites, entry sources, natural next steps, and exit paths
☐ Revenue Floor target set: specific continuity member count and price to reach the target floor
☐ Revenue Floor / Revenue Ceiling ratio target defined
Rung 1 Build (Complete in Week 10 — first 14 days)
☐ Traffic Hook offer defined: format, specific promise, and delivery mechanism
☐ Opt-in page live with tested Traffic Hook headline
☐ Welcome email sequence active: Email 1 through Email 7 built with Rung 2 SLO presented in Email 1 and Email 3
Rung 3 Build (Complete in Weeks 7–8 after Course 11 and 12)
☐ Core Offer structure defined: delivery format, programme length, number of modules, live vs asynchronous
☐ Core Offer sales page built with Story Asset Library stories deployed
☐ Order Bump defined and added to checkout
☐ OTO defined and post-purchase page built
☐ Downsell defined and decline page built
☐ Core Offer delivery infrastructure tested: all modules accessible, email delivery confirmed
☐ First 5 sales target set with a specific date
Rung 2 Build (After first 5 Core Offer sales confirmed)
☐ SLO offer defined: a fast-result, specific, low-risk complement to or preview of the Core Offer
☐ SLO price confirmed at 15–30% of Core Offer price
☐ SLO added to Traffic Hook thank-you page and Email sequence Day 1–3
Rung 4 Build (After Core Offer is generating regular buyers and above-threshold completion rates)
☐ Continuity format selected from the five model types
☐ Continuity monthly value delivery structure designed: what specific output does each member receive each month?
☐ Continuity entry criteria defined and enforced
☐ Core Offer graduation sequence updated with continuity invitation
☐ Churn prevention system in place: monthly value visibility mechanism
Value Ladder Health Assessment (Quarterly)
☐ All active rung metrics pulled: opt-in rate, SLO conversion, Core Offer conversion, churn rate
☐ 30-Day and 90-Day LTV calculated for most recent cohort
☐ Floor/Ceiling ratio calculated
☐ Single priority rung identified for improvement action
☐ Action assigned to responsible person with completion date
RISER Nation Master Operating System | Value Ladder Architecture SOP | Course 14 | Version 1.0 | 2026 Edition
Track 3: Build Your Offer — Course 14 of 14 | risernation.com
The Value Ladder Is Not Built All at Once — It Is Built in Sequence
The most common value ladder error among new knowledge business operators is attempting to build all rungs simultaneously before any rung has been validated. The value ladder in this SOP defines the complete architecture. The build sequence defines the order in which rungs are created, which is: Rung 1 (Traffic Hook / Lead Magnet) — Rung 3 (Core Offer) — Rung 2 (Self-Liquidating Offer) — Rung 4 (Continuity) — Rung 5 (Premium) — Rung 6 (Done-For-You). An operator building all six rungs before Rung 3 is validated is building infrastructure for a business whose commercial viability is still unconfirmed.
The Hormone of Trust — Why the Value Ladder Works Commercially
Dan Kennedy's foundational insight on the economics of the value ladder: buyers do not maximise the price they pay — they maximise the amount of value they receive in exchange for the investment they are willing to make. A buyer who receives genuine value at Rung 2 does not think 'I have now spent enough.' They think 'this person has already given me real value. What else do they offer?' The ascension from one rung to the next is not a sell — it is the natural next step for a buyer who has experienced the transformation the prior rung produced. The value ladder works because trust, not transactions, drives ascension.
The 80/20 of Value Ladder Revenue — The Front End Funds the Business, the Back End Builds Wealth
In a mature knowledge business value ladder, approximately 80% of total revenue comes from 20% of buyers — the buyers at the premium and done-for-you rungs. The front-end offers (Rungs 1–3) are not the primary revenue source. They are the buyer qualification and trust-building system that identifies and nurtures the 20% who will eventually invest at the premium level. An operator who measures their business exclusively on front-end conversion rates is measuring the wrong thing. The front end's job is not to maximise immediate revenue. Its job is to maximise the number of qualified, trust-established buyers entering the ascension path.
Rung
Name
Investment Level
Buyer State at Entry
Primary Function
Primary Business Outcome
1
Traffic Hook (Lead Magnet)
Free (time investment only)
Unaware to Problem Aware. The buyer has encountered the operator's content and is curious enough to exchange their email address for something specific.
Converts anonymous traffic into identified subscribers. Provides the first experience of the operator's perspective and demonstrates that the operator understands the buyer's problem.
List building. Every email subscriber is a named, contactable buyer who has self-selected as relevant to the operator's offer ecosystem. The Traffic Hook is the front door of the entire business.
2
Self-Liquidating Offer (SLO)
$7–$97 (typically $17–$47)
Problem Aware to Solution Aware. The buyer has consumed the Traffic Hook, is building trust with the operator, and has demonstrated willingness to invest time by engaging with the free content.
Converts email subscribers into first-time buyers. The transformation from subscriber to buyer is the most commercially significant transition in the entire value ladder — it establishes the purchase relationship. The SLO price point is set to be an easy yes.
First-buyer conversion at a price point that self-liquidates the cost of subscriber acquisition. An operator whose SLO revenue equals or exceeds their email acquisition cost is effectively building their buyer list for free.
3
Core Offer
$297–$2,000 (typically $497–$997)
Solution Aware to Product Aware. The buyer has experienced value at Rung 1 or 2, trusts the operator's approach, and is actively seeking a comprehensive solution.
Delivers the primary transformation the business is built around. This is the offer that the entire marketing system from Courses 6–15 is designed to sell. It is the proof-of-concept offer: if this offer converts organically and produces results for buyers, the business model is validated.
Primary revenue generation. The Core Offer's conversion rate and buyer quality metrics are the primary indicators of business health in the first 12–18 months.
4
Continuity (Recurring Revenue)
$47–$297/month (typically $97–$197/month)
Product Aware to Most Aware. The buyer has purchased the Core Offer, received genuine value, and is seeking ongoing access, community, or continued development beyond the programme's conclusion.
Creates the income floor. Continuity revenue is the recurring monthly income that the business generates regardless of launch activity. It is the financial stability layer that makes every other decision less fraught.
Revenue floor. A business with $10,000/month in continuity revenue before any launch activity has a fundamentally different financial psychology than a business entirely dependent on launch revenue.
5
Premium Offer
$2,000–$15,000+ (group or intensive formats)
Most Aware buyers at the highest commitment level. These buyers have consumed multiple rungs and are ready for a higher-access, higher-accountability, higher-investment experience.
Serves the most committed 10–20% of the buyer base who want more: more accountability, more access, more personalisation, more speed. The premium offer is the highest-value relationship in the business.
Revenue ceiling expansion. The 80/20 revenue dynamic means the premium rung often generates more total revenue than all lower rungs combined, from a small number of highly committed buyers.
6
Done-For-You (DFY) / Highest Tier
$5,000–$50,000+ per engagement
The most committed buyers who want the result without the implementation work. Typically a subset of Premium Offer buyers.
Removes the implementation burden for buyers who have the financial capacity to pay for it and the business context where it makes sense. DFY is not appropriate for all business models — it requires significant operator or team capacity.
Highest-margin, lowest-volume revenue. DFY engagements are typically the highest average transaction value in the business. They are also the highest fulfilment intensity and the most operator-time-dependent unless fully systematised.
THE ASCENSION PATH
The Design of the Journey from Rung 1 to Rung 5
How each rung creates the conditions for the natural next step
Transition
What Creates the Natural Next Step
The Specific Mechanism
What Prevents Natural Ascension
Rung 1 → Rung 2
(Subscriber to SLO Buyer)
The Traffic Hook delivers a specific, valuable outcome and simultaneously reveals a next level of depth that the Traffic Hook alone cannot provide. The buyer recognises that the free asset gave them something real — and that there is more where it came from.
The Traffic Hook's thank-you page presents the SLO as the immediate next step for buyers who found the Lead Magnet valuable. The welcome email sequence reinforces this with a story and a specific prompt within the first 24–48 hours.
A Traffic Hook that is either too complete (delivers everything the buyer needs, leaving no felt gap) or too thin (delivers too little value to generate trust in the operator's depth). The SLO offer must be presented while the buyer is still in the state of value-recognition from the Traffic Hook.
Rung 2 → Rung 3
(SLO Buyer to Core Offer Buyer)
The SLO delivers a specific, quick result — the buyer achieves something concrete within hours or days of purchase. This result creates two things simultaneously: proof that the operator's approach works for this buyer specifically, and a new awareness of the larger gap that the quick win has revealed.
The SLO's final section or email follow-up explicitly frames the result achieved and names the next challenge: 'You have now [quick win]. The next step is [deeper challenge that the Core Offer addresses].' The transition is logical, not promotional.
An SLO that delivers a complete, standalone result with no natural next step. The SLO must be designed so that the quick win it produces is a first step in a larger journey — not a complete destination.
Rung 3 → Rung 4
(Core Offer Buyer to Continuity Member)
The Core Offer programme approaches completion. The buyer has achieved a significant transformation. The new challenge is: how do I sustain this, continue developing, and stay connected to a community that understands where I am now?
The final module of the Core Offer programme introduces the continuity offering as the natural home for programme graduates. The graduation experience is framed as a beginning, not an ending: 'You have completed the foundation. The next stage is [Continuity Offer].'
A Core Offer that ends with a graduation email rather than a graduation-plus-invitation. Buyers who receive no next step at programme completion often return to their prior patterns within 60 days — the window for continuity conversion closes quickly after completion.
Rung 4 → Rung 5
(Continuity Member to Premium Buyer)
The continuity member has been in the community long enough to identify their next specific challenge — one that requires more support, more accountability, or more speed than the community format can provide. The premium offer is positioned as the intensive for members who are ready to go deeper.
The continuity community includes periodic premium programme invitations specifically for members who have reached a defined milestone. The invitation is personalised: based on the member's activity, their questions, and their stated next goal. Not a mass promotion — a milestone-based invitation.
Mass-market promotion of the premium offer to all continuity members regardless of their readiness stage. Premature promotion to members who are not yet at the relevant milestone produces rejections that reduce future openness. The ascension must be milestone-triggered, not calendar-triggered.
Continuity Type
What It Provides
Optimal Price Range
Buyer Qualification Threshold
Key Design Requirement
Community Membership
Ongoing access to a curated community of peers, regular live sessions, and a shared resource library. The primary value is belonging and peer connection.
$47–$197/month
Core Offer completers or verified professionals in the niche. The community quality is the product — unqualified members degrade the product for everyone else.
A specific, visible quality bar for admission or continued participation. A community without standards deteriorates. The standards are enforced even at the cost of short-term revenue.
Coaching Continuity
Ongoing access to the operator or operator's team for implementation support, Q&A, and coaching. The primary value is accountability and personalised guidance.
$197–$497/month
Core Offer completers or buyers at an equivalent readiness stage. Coaching continuity for buyers who have not done the foundational work produces poor outcomes and high churn.
Defined office hours or response SLAs so members know exactly what they are paying for. Coaching continuity without clear access terms produces either buyer disappointment (insufficient access) or operator exhaustion (unlimited demand).
Content Continuity
Monthly or weekly delivery of proprietary research, analysis, templates, or tools that are updated to reflect current conditions in the niche. The primary value is information currency and implementation assets.
$27–$97/month
Anyone who benefits from the niche-specific content. Lowest barrier entry, widest potential membership base.
Genuine information advantage. Content continuity only sustains if the content is genuinely differentiated from what is freely available. Curated aggregation is insufficient — the content must include the operator's specific synthesis and perspective.
Software or Tool Access
Monthly access to a proprietary tool, calculator, framework, or system that automates or significantly simplifies a recurring task in the niche.
$47–$297/month
Any buyer who performs the task the tool addresses. Often accessible to non-Core Offer buyers.
The tool must save the member more time or produce better outcomes than their current approach in a way they can verify. Software continuity is the most defensible (switching costs are real) and the most demanding to build (requires technical infrastructure).
Mastermind or Peer Group
Small-group peer-to-peer learning with operator facilitation. Typically 8–20 members per cohort meeting regularly (weekly or biweekly). The primary value is peer accountability, peer learning, and deliberate small-group relationship building.
$297–$1,500/month
Buyers with specific readiness criteria — typically at a business development stage where peer learning is more valuable than operator instruction. Often positioned as the bridge between Core Offer and Premium.
A rigorous selection process. The quality of a mastermind is determined almost entirely by the quality of its members. Size and selection must be managed deliberately.
The Continuity Churn Problem — Why Most Continuity Programmes Fail
The most common continuity failure mode: members join, receive value in Month 1, reduce engagement in Month 2, and cancel by Month 3. The cause is not price or content quality. It is unclear value delivery between joining and cancellation. A member who cannot clearly see what they received for their last month's payment has no reason to continue. The fix: the continuity programme must produce a specific, visible output for every member every month. Not just 'access to the community' but 'the specific insight, connection, or asset the member received this month.' If the member cannot name it: the programme's value is invisible, and invisible value does not sustain payment.
REVENUE ARCHITECTURE ANALYSIS — Calculate for current state and 12-month target
THE REVENUE FLOOR CALCULATION
Revenue Floor = Continuity Membership Revenue (recurring monthly)
Current active continuity members: [N]
Average monthly continuity price: [$X]
Monthly continuity revenue: [N x $X]
Annual continuity revenue (floor): [monthly x 12]

THE REVENUE CEILING CALCULATION
Revenue Ceiling = Continuity Floor + Launch/Promotional Event Revenue
Estimated Core Offer buyers per launch event: [N]
Average Core Offer revenue per buyer (including upsells/order bumps): [$X]
Number of Core Offer launches per year: [N]
Core Offer annual revenue: [buyers x revenue x launches]

Estimated Premium Offer buyers per year: [N]
Average Premium Offer investment: [$X]
Premium annual revenue: [N x $X]

Total Revenue Ceiling: [Floor + Core Launch Revenue + Premium Revenue]

THE FLOOR/CEILING RATIO HEALTH CHECK
Healthy ratio target: Revenue Floor should be at least 30% of Revenue Ceiling
High risk (Floor <10% of Ceiling): The business is entirely launch-dependent. One failed launch produces a financial crisis.
Moderate risk (Floor 10–29% of Ceiling): Some stability but significant dependence on launch performance.
Healthy (Floor 30–49% of Ceiling): Meaningful income floor. Launch performance matters but is not existential.
Strong (Floor 50%+ of Ceiling): The business generates reliable income regardless of launch activity. Launches add to a solid foundation.

THE CONTINUITY MEMBER COUNT TARGETS
To reach a $5,000/month Revenue Floor at $97/month membership: 52 active members
To reach a $10,000/month Revenue Floor at $97/month: 104 active members
To reach a $5,000/month Revenue Floor at $197/month: 26 active members
To reach a $10,000/month Revenue Floor at $197/month: 51 active members

These targets clarify the relative priority of continuity growth vs Core Offer launch activity.
THE UPSELL AND DOWNSELL INFRASTRUCTURE
Maximising Revenue From Every Transaction
The funnel architecture that captures value across the full range of buyer readiness
Type
Definition
Placement
Optimal Price
Design Principle
Order Bump
A low-price complementary offer presented on the primary offer's checkout page as a checkbox add-on. The buyer adds it with a single click without leaving the checkout flow.
On the checkout page, below the primary offer details and above the payment button.
15–30% of the primary offer's price. At this ratio, the order bump converts 20–40% of buyers.
The order bump must be a specific, immediate-value complement to the primary offer — something the buyer will use in the first week of the primary programme. A template pack, a quick-start guide, a tool. Not a separate product that requires its own learning curve.
One-Time Offer (OTO) Upsell
A higher-price upgrade offer presented immediately after the primary offer is purchased, on a dedicated page the buyer reaches before the confirmation page.
Immediately post-purchase, before the thank-you or delivery confirmation page.
150–300% of the primary offer's price. At this price ratio, OTO upsells convert 10–25% of buyers.
The OTO must be a genuine upgrade — not a continuation of the primary offer but a faster path to the result, a higher level of access, or a complementary system that amplifies the primary offer's value. 'Buy the same thing at a higher price' is not an OTO.
Downsell
A lower-price alternative offered to buyers who decline the OTO upsell. The downsell captures revenue from buyers who said no to the full upsell price but are still in a state of purchase engagement.
Immediately after the OTO decline button is clicked.
40–60% of the OTO price. Converts 20–40% of OTO decliners.
The downsell is a genuine step-down in access or scope — not the same offer at a different price. A video-only version of a live programme, a single module extraction, or a lower-tier membership. The buyer who declines the OTO and accepts the downsell is a legitimate buyer — not a consolation conversion.
Post-Purchase Upsell
An offer presented in the post-purchase delivery sequence (welcome email or onboarding sequence) for buyers who did not purchase the OTO.
Day 3–7 of the post-purchase welcome sequence, after the buyer has had their first positive experience with the primary offer.
Same range as the OTO.
Presented when the buyer has experienced genuine early value from the primary offer and is in a state of positive engagement. 'Based on where you are now in the programme, the next most useful thing is [offer].' Contextualised, not mass-broadcast.
Step
What Happens
Revenue Contribution
Error to Avoid
1 — Checkout page with Order Bump
Buyer arrives at checkout for the Core Offer. The Order Bump is visible below the offer details. No action required to decline — it is opt-in.
20–40% of Core Offer buyers add the Order Bump. At a $97 order bump and 30% conversion on 100 buyers: $2,910 incremental revenue per 100 buyers with zero additional marketing cost.
Making the Order Bump too large (in scope or price). An Order Bump that requires significant explanation is already too complex. It must be immediately obvious and immediately desirable.
2 — OTO presented post-purchase
Immediately after payment, before the confirmation page, the buyer is presented with the OTO. They cannot return to the primary checkout — the primary purchase is confirmed regardless.
15% of Core Offer buyers take the OTO. At a $997 OTO and 15% conversion on 100 buyers: $14,955 incremental revenue per 100 buyers.
Presenting the OTO before confirming the primary purchase. This creates buyer anxiety about the purchase they just made. The primary purchase confirmation must be clear before the OTO is presented.
3 — Downsell presented if OTO is declined
If the buyer clicks 'No thanks' on the OTO, they are immediately presented with the Downsell — a genuine step-down alternative.
25% of OTO decliners take the Downsell. At a $397 Downsell: 85 buyers declined the OTO, 21 take the Downsell = $8,337 incremental revenue per 100 buyers.
A Downsell page that creates guilt ('Are you sure you want to miss out on this?'). Downsell pages that use pressure or shame convert at a short-term rate but produce a buyer who felt manipulated. The Downsell must be a genuine alternative presented with full respect for the buyer's decision.
4 — Thank-you page with soft next step
The buyer reaches the confirmation page. A soft mention (not a full OTO) of the next logical step is included — typically the Continuity Offer or the Premium Waitlist.
Low direct conversion on the thank-you page (3–8%) but high awareness-building for the next ascension step.
A thank-you page that is purely logistical ('Your confirmation is in your email'). The thank-you page is the highest-trust moment in the entire funnel and a significant missed opportunity if it contains only logistics.
5 — Post-purchase sequence Day 3–7
Buyers who did not take the OTO receive a contextualised post-purchase upsell in the welcome sequence, after their first week of programme engagement.
5–10% additional OTO conversion from non-OTO buyers. These are buyers who declined in the moment of purchase but became more open after experiencing early value.
Sending the post-purchase upsell before the buyer has had time to experience value from the primary offer. Day 1 upsell attempts to buyers who just paid feel like immediate reselling. Day 3–7, after a positive early experience, feels like a natural next step.
Ecosystem Element
What It Documents
Why It Is Required
What Happens Without It
Entry Points
Which offers a new buyer (who has no prior relationship with the operator) can enter the ecosystem through. Typically Rung 1 and Rung 2.
Ensures every marketing channel and every traffic source has a clearly defined offer destination that matches the awareness level of the incoming traffic.
Traffic from different channels lands on offers inappropriate for the awareness level of that traffic. Cold traffic landing on a $5,000 premium offer without a prior relationship path does not convert.
Prerequisites
Whether any offer has required prior purchases or conditions for entry.
Prevents buyers from purchasing offers they are not ready for, which produces poor results, high refunds, and frustrated buyers.
Buyers purchase the Premium Offer without the Core Offer's foundational work. They cannot implement the advanced content, produce no results, and attribute the failure to the programme.
Logical Next Steps
The specific offer each buyer should be presented with upon completing or reaching a milestone in the current offer.
Automates the ascension path by ensuring that the completion trigger for each offer fires the appropriate next-step offer or invitation.
Completers receive a thank-you email and are never contacted about the next natural step. The conversion window closes. The buyer finds another provider for their next stage.
Exit Paths
What options exist for buyers who reach each rung and are not ready or willing to ascend further.
Ensures every buyer has a dignified, value-maintaining exit path that preserves the relationship even if they do not ascend.
Buyers who reach an exit point without an exit path either churn silently or produce negative word-of-mouth when they feel they have been pressure-sold beyond their commitment level.
Cross-Offer Synergies
Where the content, community, or results from one offer enhances the value of another offer in the ecosystem.
Creates compounding buyer value: buyers who have completed multiple rungs have cumulative advantages that make each successive rung more valuable.
Offers are designed and delivered as independent products with no connection to each other. Buyers do not experience the cumulative value that the full ecosystem can provide.
PRODUCT ECOSYSTEM MAP — Complete for the full value ladder
RUNG 1 — TRAFFIC HOOK / LEAD MAGNET
Offer name: [working title]
Format: [PDF guide / Video series / Scorecard / Template / Mini-course]
Delivery mechanism: [Email delivery / Gated page / Immediate download]
Prerequisite: None
Entry point for traffic from: [all channels — this is the universal entry point]
Natural next step after delivery: Rung 2 SLO (presented on thank-you page and in Email 1)
Exit path if buyer does not proceed: Continues in email nurture sequence

RUNG 2 — SELF-LIQUIDATING OFFER
Offer name:
Price: [$X]
Format: [Video workshop / Workbook / Mini-course / Template pack]
Prerequisite: None (can be purchased without Rung 1)
Primary entry source: Rung 1 thank-you page + Email sequence Days 1–3
Natural next step after completion: Core Offer (presented in Rung 2 delivery)
Order Bump on Rung 2 checkout: [name and price]
OTO after Rung 2 purchase: [name and price, if applicable]
Exit path: Continues in email sequence if no Core Offer purchase

RUNG 3 — CORE OFFER
Offer name:
Price: [$X]
Format: [Group programme / Self-paced course / Cohort / Live workshops]
Prerequisite: Rung 2 buyer status (ideal) or verified readiness (via application or screening)
Primary entry source: Email sequence Days 5–14 + Sales page + Launch events
Order Bump on checkout: [name and price]
OTO after purchase: [name and price]
Downsell if OTO declined: [name and price]
Natural next step upon completion: Continuity Offer (presented in final module + graduation email)
Exit path: Continued email relationship with periodic Core Offer re-engagement campaigns

RUNG 4 — CONTINUITY
Offer name:
Monthly price: [$X/month]
Format: [Community / Coaching sessions / Content library / Mastermind]
Prerequisite: Core Offer completion or verified equivalent experience
Primary entry source: Core Offer completion sequence + Community invitation
Cancellation exit path: Exit interview + 3-month win-back sequence
Natural next step for high-engagement members: Premium Offer invitation (milestone-triggered)

RUNG 5 — PREMIUM OFFER
Offer name:
Price: [$X for [duration/format]]
Format: [High-touch group coaching / Intensive / Mastermind / Accelerator]
Prerequisite: Core Offer completion + minimum [N] months in Continuity (or equivalent)
Primary entry source: Milestone-triggered personal invitation from Continuity
Application or call required: [Yes / No]
Natural next step: DFY engagement for qualified buyers / continued Premium for ongoing support

RUNG 6 — DONE-FOR-YOU (if applicable)
Offer name:
Price: [$X per engagement or retainer]
Format: [Specific deliverable description]
Prerequisite: Premium Offer participation or equivalent documented context
Capacity constraint: Maximum [N] concurrent DFY clients
Natural next step: Long-term retainer / referral to network if capacity reached
Build Order
Rung Built
Dependency
Milestone to Pass Before Building Next Rung
Why This Order
Step 1
Rung 1 — Traffic Hook
None. This is the first thing built.
Minimum 100 email subscribers from organic sources. Opt-in rate above 25% from warm sources.
The Traffic Hook validates the operator's ability to attract and capture the target audience before any paid offer exists. It is also the list-building infrastructure that every subsequent offer will be sold to.
Step 2
Rung 3 — Core Offer
Traffic Hook live and building the list.
First 5 sales of the Core Offer at full price, from organic sources. Refund rate below 10%.
The Core Offer is built second, not the SLO, because the Core Offer is the proof-of-concept for the entire business. Validating the Core Offer first confirms the business model. The SLO is built to self-liquidate the cost of Core Offer buyer acquisition — but only after the Core Offer is confirmed as viable.
Step 3
Rung 2 — Self-Liquidating Offer
Core Offer validated with first sales.
SLO revenue equals or exceeds the cost of email subscriber acquisition from paid sources. (Only relevant once paid traffic begins.) SLO conversion rate above 3% from email subscribers.
The SLO is built third because its purpose is to self-liquidate paid traffic costs. Building it before the Core Offer is validated means building an acquisition path for an offer whose commercial viability is unconfirmed.
Step 4
Rung 4 — Continuity
Core Offer generating regular buyers with above-threshold completion rates and positive testimonials.
Minimum 20 continuity members paying the monthly fee. Churn rate below 5% per month.
Continuity requires buyers who have experienced genuine Core Offer transformation and want to continue. It cannot be launched to a list that has no buyers — the members are the product.
Step 5
Rung 5 — Premium Offer
Active continuity community with milestone-ready members.
Minimum 5 Premium Offer buyers with documented premium-level results. Premium offer ROI confirmed: buyers are receiving more than the premium price in value.
The Premium Offer is built when the operator has enough continuity members to identify the specific 20% who are ready for higher-access support. Building it earlier produces an offer with no qualified buyers.
Step 6
Rung 6 — Done-For-You
Premium Offer validated with results evidence. Operator has capacity (or team capacity) for DFY delivery.
DFY delivery system fully documented and tested with 2–3 pilot engagements. Operator or team can sustain DFY delivery without degrading Core Offer or Premium Offer quality.
DFY is the highest-fulfilment-intensity rung. It is built last because it requires the operator's maximum capacity. Building it before the lower rungs are systematised produces a situation where DFY clients consume all available operator time, preventing the lower-rung business from functioning.
LTV CALCULATION TEMPLATE — Complete for each buyer cohort (monthly cohort recommended)
COHORT DEFINITION
Cohort entry date: [Month/Year]
Cohort size: [N buyers who purchased the Core Offer in this month]
Cohort entry offer: [Core Offer name and price]

30-DAY LTV
Core Offer revenue per buyer: [$X]
Order Bump uptake: [N% x $bump price]
OTO uptake: [N% x $OTO price]
Downsell uptake: [N% x $downsell price]
30-Day LTV = [Core Offer + (Order Bump rate x price) + (OTO rate x price) + (Downsell rate x price)]
30-Day LTV benchmark: Above 1.3x the Core Offer base price

90-DAY LTV
30-Day LTV (from above)
Plus: Continuity conversion rate from this cohort: [N% joining at $X/month x 3 months of membership]
Plus: Any second Core Offer purchase (returning buyers or upsells within cohort period)
90-Day LTV benchmark: Above 1.6x the Core Offer base price

12-MONTH LTV
90-Day LTV (from above)
Plus: Continuity revenue months 4–12 for members who did not churn
Plus: Premium Offer conversion from this cohort: [N% x $premium price]
12-Month LTV benchmark: Above 2.5x the Core Offer base price for a healthy value ladder

THE MAXIMUM VIABLE CPL CALCULATION
Maximum Viable CPL = 90-Day LTV x (1 - minimum required gross margin)
Example: 90-Day LTV = $850 | Required gross margin = 50%
Maximum Viable CPL = $850 x 50% = $425

An operator whose paid traffic CPL is below their Maximum Viable CPL has a commercially sustainable paid acquisition channel.
An operator whose CPL exceeds their Maximum Viable CPL must either increase LTV (by improving the back-end conversion rates) or reduce CPL (by improving front-end conversion rates) before scaling paid traffic.
Lever
How It Works
The LTV Impact
Implementation Priority
1 — Improve Order Bump Conversion
Test different Order Bump offers, prices, and copy. An Order Bump converting at 30% vs 15% doubles the order bump revenue contribution to LTV.
Each 10 percentage point increase in Order Bump conversion adds approximately 3–5% to 30-Day LTV.
High. Order Bump testing has zero incremental traffic cost and immediate LTV impact.
2 — Improve OTO Conversion
Test different OTO offers, prices, and framing. The OTO is the highest-value single conversion opportunity in the immediate post-purchase window.
Each 5 percentage point increase in OTO conversion adds 10–15% to 30-Day LTV at a typical OTO price ratio.
High. Same zero-traffic-cost testing environment as the Order Bump.
3 — Improve Core Offer Completion Rate
Buyers who complete the programme are 3–5x more likely to join continuity, purchase premium, and generate testimonials than buyers who do not complete.
A 20 percentage point improvement in Core Offer completion rate (from 40% to 60%) can increase 90-Day LTV by 20–30% through downstream continuity and premium conversion improvement.
Very high. Programme completion is the multiplier for every downstream LTV lever.
4 — Improve Continuity Conversion
Test the timing, framing, and format of the continuity offer presentation at Core Offer completion. Earlier vs later presentation, community preview vs feature description.
Each 10 percentage point improvement in continuity conversion from Core Offer buyers adds the full monthly continuity value x average membership duration to cohort LTV.
High, especially as the business matures. Continuity is the compounding LTV lever.
5 — Reduce Continuity Churn
Improve the monthly value delivery visibility so members can clearly see what they received. Reduce the monthly churn rate.
A reduction from 5% monthly churn to 3% increases the average membership duration from 20 months to 33 months — a 65% increase in continuity LTV per member.
Very high for mature continuity programmes. The compounding effect of lower churn dramatically outperforms the effect of higher new member acquisition.
6 — Improve Premium Conversion from Continuity
Develop the milestone-triggered invitation system. Personalise invitations based on member activity and stated goals. Test different premium offer formats.
Each additional 5% of continuity members who convert to Premium adds the full premium price to cohort LTV.
Medium for early-stage businesses (Premium offer may not yet exist). High for mature businesses where Premium is the primary profit driver.
Rung
Primary Health Metric
Healthy Benchmark
Requires Attention
Urgent Action Required
Rung 1 — Traffic Hook
Opt-in rate from primary traffic sources
Above 30% from warm sources
20–29%
Below 20%. The Traffic Hook offer, the headline, or the traffic source alignment is broken.
Rung 2 — SLO
Conversion rate from email subscribers
Above 3%
1.5–2.9%
Below 1.5%. The SLO offer's price-to-value ratio, the offer's specificity, or the email sequence presenting it requires review.
Rung 3 — Core Offer
30-day subscriber-to-buyer conversion rate
Above 2%
1–1.9%
Below 1%. The organic funnel has not yet passed the Hard Organic Proof Threshold and should not be scaled with paid traffic.
Rung 4 — Continuity
Monthly churn rate
Below 3%
3–6%
Above 6% monthly churn. The monthly value delivery is not visible to members, or the entry qualification standards are allowing buyers who are not ready.
Rung 5 — Premium
Conversion rate from milestone-invited continuity members
Above 15% of eligible invitees accept
8–14%
Below 8%. The invitation timing, the premium offer format, or the milestone qualification criteria requires review.
Rung 6 — DFY (if active)
Client satisfaction and renewal rate
Above 80% of DFY clients renew or refer
65–79% renewal/referral
Below 65%. The DFY delivery quality or scope definition requires review.
VALUE LADDER HEALTH ASSESSMENT — Quarterly Review Protocol
PREPARATION (before the review meeting)
Pull the current metrics for each active rung from the Airtable tracking system.
Calculate the current cohort LTV at 30-day and 90-day marks.
Calculate the current Revenue Floor (continuity monthly total) and Revenue Ceiling (Floor + launch projections).
Calculate the current Floor/Ceiling ratio.

THE ASSESSMENT (30 minutes)
Rung 1: [current opt-in rate] — Benchmark status: [Healthy / Attention / Urgent]
Rung 2: [current SLO conversion rate] — Benchmark status: [same format]
Rung 3: [current Core Offer conversion rate] — Benchmark status:
Rung 4: [current churn rate] — Benchmark status:
Rung 5 (if active): [premium conversion rate] — Benchmark status:

Revenue Floor: [$X/month] | Floor/Ceiling ratio: [X%] — Benchmark status:
30-Day LTV: [$X] | 90-Day LTV: [$X] — Benchmark status:

THE PRIORITY ACTION
Identify the single most underperforming rung (the lowest benchmark status with the highest LTV impact).
For this rung: what specifically is the action to move it from its current status to the next benchmark tier?
Name the action, the person responsible, and the date by which it will be implemented.
Do not attempt to fix multiple rungs simultaneously. One rung at a time.
Field
Type
Notes
Rung Number
Number
1–6
Rung Name
Short text
Offer Name
Short text
Price
Currency
Format
Single select
Lead Magnet / SLO / Core Offer / Continuity / Premium / DFY
Status
Single select
Planned / In Development / Active / Retired
Launch Date
Date
Prerequisite Rung
Number
Which rung must be purchased first (if any)
Natural Next Step
Link → Value Ladder Configuration
Primary Entry Source
Short text
Which channel/campaign delivers buyers to this rung
Order Bump
Short text
Name and price of the Order Bump on this offer's checkout
OTO
Short text
Name and price of the OTO presented post-purchase
Downsell
Short text
Name and price of the Downsell
Monthly Revenue (active offers)
Currency
Calculated from buyer count x average price (for continuity)
Notes
Long text
Field
Type
Notes
Cohort Month
Short text
Format: YYYY-MM
Cohort Size
Number
Buyers entering at Core Offer in this month
Core Offer Revenue
Currency
Order Bump Revenue
Currency
OTO Revenue
Currency
Downsell Revenue
Currency
30-Day Total LTV per Buyer
Formula
Sum of above ÷ cohort size
Continuity Conversions from Cohort
Number
Continuity Revenue Month 1–3
Currency
90-Day Total LTV per Buyer
Formula
Premium Conversions from Cohort
Number
Premium Revenue from Cohort
Currency
12-Month Total LTV per Buyer
Formula
Notes
Long text

Original Word reading order, tables, headers and footers

RISER NATION

MASTER OPERATING SYSTEM — COURSE 14 — TRACK 3: BUILD YOUR OFFER

SOP — VALUE LADDER ARCHITECTURE

The Complete System for Designing a Multi-Product Revenue Architecture That Guides Buyers from Free Entry to Premium Relationships — The Six Rung Framework, the Ascension Path Design Protocol, the Continuity Engine, the Product Ecosystem Map, the Revenue Floor vs Revenue Ceiling Architecture, the Downsell and Upsell Infrastructure, the LTV Maximisation System, and the Value Ladder Health Assessment

Track 3: Build Your Offer — Course 14 of 14 | 2026 Framework

Version 1.0 | 2026 Edition | RISER Nation Master Operating System

SOP Overview — Why a Single Offer Is a Structurally Fragile Business

A knowledge business with a single offer is a business with a single revenue event. Every buyer either purchases the one offer or they do not. Buyers who are not ready for the price point have nowhere to start. Buyers who complete the offer and want more have nowhere to go. Buyers who are committed but need a different format or a different level of support have no alternative path. The single-offer business is maximally dependent on the conversion rate of the one thing it sells, and maximally exposed to any change in that conversion rate.

The value ladder is the architecture that addresses every one of these constraints. It creates a range of entry points so buyers at different commitment and investment levels can find the right starting place. It creates an ascension path so buyers who receive value naturally progress to deeper engagement rather than leaving. It creates a revenue floor (recurring income from continuity) that makes the business financially stable between launch events. It creates a revenue ceiling (premium offers) that allows the business to maximise the LTV of its most committed buyers without needing to find new ones. And it creates a referral architecture where buyers at every rung have specific, natural ways to recommend the business to people in their network.

This SOP covers: the foundational logic of the value ladder and why it is built from a specific philosophy rather than assembled opportunistically, the six rung framework and what each rung is designed to accomplish, the Ascension Path Design Protocol, the Continuity Engine and why recurring revenue is the business's income floor, the Downsell and Upsell infrastructure, the LTV Maximisation System, the Product Ecosystem Map, the Revenue Floor versus Revenue Ceiling analysis, the Value Ladder Build Sequence for new operators, and the Value Ladder Health Assessment.

The Value Ladder Is Not Built All at Once — It Is Built in Sequence The most common value ladder error among new knowledge business operators is attempting to build all rungs simultaneously before any rung has been validated. The value ladder in this SOP defines the complete architecture. The build sequence defines the order in which rungs are created, which is: Rung 1 (Traffic Hook / Lead Magnet) — Rung 3 (Core Offer) — Rung 2 (Self-Liquidating Offer) — Rung 4 (Continuity) — Rung 5 (Premium) — Rung 6 (Done-For-You). An operator building all six rungs before Rung 3 is validated is building infrastructure for a business whose commercial viability is still unconfirmed.

The Hormone of Trust — Why the Value Ladder Works Commercially Dan Kennedy's foundational insight on the economics of the value ladder: buyers do not maximise the price they pay — they maximise the amount of value they receive in exchange for the investment they are willing to make. A buyer who receives genuine value at Rung 2 does not think 'I have now spent enough.' They think 'this person has already given me real value. What else do they offer?' The ascension from one rung to the next is not a sell — it is the natural next step for a buyer who has experienced the transformation the prior rung produced. The value ladder works because trust, not transactions, drives ascension.

The 80/20 of Value Ladder Revenue — The Front End Funds the Business, the Back End Builds Wealth In a mature knowledge business value ladder, approximately 80% of total revenue comes from 20% of buyers — the buyers at the premium and done-for-you rungs. The front-end offers (Rungs 1–3) are not the primary revenue source. They are the buyer qualification and trust-building system that identifies and nurtures the 20% who will eventually invest at the premium level. An operator who measures their business exclusively on front-end conversion rates is measuring the wrong thing. The front end's job is not to maximise immediate revenue. Its job is to maximise the number of qualified, trust-established buyers entering the ascension path.

The Six Rung Framework

Every rung in the value ladder serves a specific commercial and relational function. The architecture of the ladder is not arbitrary — each rung is designed to produce a specific outcome for the buyer and a specific economic contribution to the business. Understanding what each rung is for prevents the common error of building rungs that duplicate each other's function rather than ascending the buyer's commitment and investment.

Rung | Name | Investment Level | Buyer State at Entry | Primary Function | Primary Business Outcome
1 | Traffic Hook (Lead Magnet) | Free (time investment only) | Unaware to Problem Aware. The buyer has encountered the operator's content and is curious enough to exchange their email address for something specific. | Converts anonymous traffic into identified subscribers. Provides the first experience of the operator's perspective and demonstrates that the operator understands the buyer's problem. | List building. Every email subscriber is a named, contactable buyer who has self-selected as relevant to the operator's offer ecosystem. The Traffic Hook is the front door of the entire business.
2 | Self-Liquidating Offer (SLO) | $7–$97 (typically $17–$47) | Problem Aware to Solution Aware. The buyer has consumed the Traffic Hook, is building trust with the operator, and has demonstrated willingness to invest time by engaging with the free content. | Converts email subscribers into first-time buyers. The transformation from subscriber to buyer is the most commercially significant transition in the entire value ladder — it establishes the purchase relationship. The SLO price point is set to be an easy yes. | First-buyer conversion at a price point that self-liquidates the cost of subscriber acquisition. An operator whose SLO revenue equals or exceeds their email acquisition cost is effectively building their buyer list for free.
3 | Core Offer | $297–$2,000 (typically $497–$997) | Solution Aware to Product Aware. The buyer has experienced value at Rung 1 or 2, trusts the operator's approach, and is actively seeking a comprehensive solution. | Delivers the primary transformation the business is built around. This is the offer that the entire marketing system from Courses 6–15 is designed to sell. It is the proof-of-concept offer: if this offer converts organically and produces results for buyers, the business model is validated. | Primary revenue generation. The Core Offer's conversion rate and buyer quality metrics are the primary indicators of business health in the first 12–18 months.
4 | Continuity (Recurring Revenue) | $47–$297/month (typically $97–$197/month) | Product Aware to Most Aware. The buyer has purchased the Core Offer, received genuine value, and is seeking ongoing access, community, or continued development beyond the programme's conclusion. | Creates the income floor. Continuity revenue is the recurring monthly income that the business generates regardless of launch activity. It is the financial stability layer that makes every other decision less fraught. | Revenue floor. A business with $10,000/month in continuity revenue before any launch activity has a fundamentally different financial psychology than a business entirely dependent on launch revenue.
5 | Premium Offer | $2,000–$15,000+ (group or intensive formats) | Most Aware buyers at the highest commitment level. These buyers have consumed multiple rungs and are ready for a higher-access, higher-accountability, higher-investment experience. | Serves the most committed 10–20% of the buyer base who want more: more accountability, more access, more personalisation, more speed. The premium offer is the highest-value relationship in the business. | Revenue ceiling expansion. The 80/20 revenue dynamic means the premium rung often generates more total revenue than all lower rungs combined, from a small number of highly committed buyers.
6 | Done-For-You (DFY) / Highest Tier | $5,000–$50,000+ per engagement | The most committed buyers who want the result without the implementation work. Typically a subset of Premium Offer buyers. | Removes the implementation burden for buyers who have the financial capacity to pay for it and the business context where it makes sense. DFY is not appropriate for all business models — it requires significant operator or team capacity. | Highest-margin, lowest-volume revenue. DFY engagements are typically the highest average transaction value in the business. They are also the highest fulfilment intensity and the most operator-time-dependent unless fully systematised.

THE ASCENSION PATH The Design of the Journey from Rung 1 to Rung 5 How each rung creates the conditions for the natural next step

The ascension path is the deliberate design of the transition between every adjacent pair of rungs in the value ladder. It is not left to chance or to the buyer's initiative. The ascension path is built into the delivery of every rung: the completion of Rung 2 naturally surfaces the need for Rung 3; the completion of Rung 3 naturally surfaces the need for Rung 4. The buyer does not have to be talked into ascending — the delivery creates the conditions for the next step to feel like the obvious one.

The Ascension Path Design Protocol

Transition | What Creates the Natural Next Step | The Specific Mechanism | What Prevents Natural Ascension
Rung 1 → Rung 2 (Subscriber to SLO Buyer) | The Traffic Hook delivers a specific, valuable outcome and simultaneously reveals a next level of depth that the Traffic Hook alone cannot provide. The buyer recognises that the free asset gave them something real — and that there is more where it came from. | The Traffic Hook's thank-you page presents the SLO as the immediate next step for buyers who found the Lead Magnet valuable. The welcome email sequence reinforces this with a story and a specific prompt within the first 24–48 hours. | A Traffic Hook that is either too complete (delivers everything the buyer needs, leaving no felt gap) or too thin (delivers too little value to generate trust in the operator's depth). The SLO offer must be presented while the buyer is still in the state of value-recognition from the Traffic Hook.
Rung 2 → Rung 3 (SLO Buyer to Core Offer Buyer) | The SLO delivers a specific, quick result — the buyer achieves something concrete within hours or days of purchase. This result creates two things simultaneously: proof that the operator's approach works for this buyer specifically, and a new awareness of the larger gap that the quick win has revealed. | The SLO's final section or email follow-up explicitly frames the result achieved and names the next challenge: 'You have now [quick win]. The next step is [deeper challenge that the Core Offer addresses].' The transition is logical, not promotional. | An SLO that delivers a complete, standalone result with no natural next step. The SLO must be designed so that the quick win it produces is a first step in a larger journey — not a complete destination.
Rung 3 → Rung 4 (Core Offer Buyer to Continuity Member) | The Core Offer programme approaches completion. The buyer has achieved a significant transformation. The new challenge is: how do I sustain this, continue developing, and stay connected to a community that understands where I am now? | The final module of the Core Offer programme introduces the continuity offering as the natural home for programme graduates. The graduation experience is framed as a beginning, not an ending: 'You have completed the foundation. The next stage is [Continuity Offer].' | A Core Offer that ends with a graduation email rather than a graduation-plus-invitation. Buyers who receive no next step at programme completion often return to their prior patterns within 60 days — the window for continuity conversion closes quickly after completion.
Rung 4 → Rung 5 (Continuity Member to Premium Buyer) | The continuity member has been in the community long enough to identify their next specific challenge — one that requires more support, more accountability, or more speed than the community format can provide. The premium offer is positioned as the intensive for members who are ready to go deeper. | The continuity community includes periodic premium programme invitations specifically for members who have reached a defined milestone. The invitation is personalised: based on the member's activity, their questions, and their stated next goal. Not a mass promotion — a milestone-based invitation. | Mass-market promotion of the premium offer to all continuity members regardless of their readiness stage. Premature promotion to members who are not yet at the relevant milestone produces rejections that reduce future openness. The ascension must be milestone-triggered, not calendar-triggered.

The Continuity Engine — Building the Business's Income Floor

Continuity — recurring monthly revenue from ongoing memberships, communities, coaching programmes, or software subscriptions — is the most structurally important revenue type in a knowledge business. It is not the most glamorous, the most frequently discussed, or the most aspirational. It is the most stabilising. A business with a functioning continuity engine makes better decisions, takes better risks, and serves its buyers more generously than a business entirely dependent on launch revenue, because the financial pressure of the next launch is structurally reduced.

The Five Continuity Model Types

Continuity Type | What It Provides | Optimal Price Range | Buyer Qualification Threshold | Key Design Requirement
Community Membership | Ongoing access to a curated community of peers, regular live sessions, and a shared resource library. The primary value is belonging and peer connection. | $47–$197/month | Core Offer completers or verified professionals in the niche. The community quality is the product — unqualified members degrade the product for everyone else. | A specific, visible quality bar for admission or continued participation. A community without standards deteriorates. The standards are enforced even at the cost of short-term revenue.
Coaching Continuity | Ongoing access to the operator or operator's team for implementation support, Q&A, and coaching. The primary value is accountability and personalised guidance. | $197–$497/month | Core Offer completers or buyers at an equivalent readiness stage. Coaching continuity for buyers who have not done the foundational work produces poor outcomes and high churn. | Defined office hours or response SLAs so members know exactly what they are paying for. Coaching continuity without clear access terms produces either buyer disappointment (insufficient access) or operator exhaustion (unlimited demand).
Content Continuity | Monthly or weekly delivery of proprietary research, analysis, templates, or tools that are updated to reflect current conditions in the niche. The primary value is information currency and implementation assets. | $27–$97/month | Anyone who benefits from the niche-specific content. Lowest barrier entry, widest potential membership base. | Genuine information advantage. Content continuity only sustains if the content is genuinely differentiated from what is freely available. Curated aggregation is insufficient — the content must include the operator's specific synthesis and perspective.
Software or Tool Access | Monthly access to a proprietary tool, calculator, framework, or system that automates or significantly simplifies a recurring task in the niche. | $47–$297/month | Any buyer who performs the task the tool addresses. Often accessible to non-Core Offer buyers. | The tool must save the member more time or produce better outcomes than their current approach in a way they can verify. Software continuity is the most defensible (switching costs are real) and the most demanding to build (requires technical infrastructure).
Mastermind or Peer Group | Small-group peer-to-peer learning with operator facilitation. Typically 8–20 members per cohort meeting regularly (weekly or biweekly). The primary value is peer accountability, peer learning, and deliberate small-group relationship building. | $297–$1,500/month | Buyers with specific readiness criteria — typically at a business development stage where peer learning is more valuable than operator instruction. Often positioned as the bridge between Core Offer and Premium. | A rigorous selection process. The quality of a mastermind is determined almost entirely by the quality of its members. Size and selection must be managed deliberately.

The Continuity Churn Problem — Why Most Continuity Programmes Fail The most common continuity failure mode: members join, receive value in Month 1, reduce engagement in Month 2, and cancel by Month 3. The cause is not price or content quality. It is unclear value delivery between joining and cancellation. A member who cannot clearly see what they received for their last month's payment has no reason to continue. The fix: the continuity programme must produce a specific, visible output for every member every month. Not just 'access to the community' but 'the specific insight, connection, or asset the member received this month.' If the member cannot name it: the programme's value is invisible, and invisible value does not sustain payment.

The Revenue Floor vs Revenue Ceiling Analysis

The Revenue Floor is the recurring monthly revenue the business generates without any launch or promotional activity. It is the income the operator can rely on in a month with zero selling. The Revenue Ceiling is the theoretical maximum revenue the business can generate in a high-activity month with a full launch. Understanding the relationship between these two numbers is the primary lever for financial planning in the knowledge business.

The Revenue Architecture Calculation

REVENUE ARCHITECTURE ANALYSIS — Calculate for current state and 12-month target THE REVENUE FLOOR CALCULATION Revenue Floor = Continuity Membership Revenue (recurring monthly) Current active continuity members: [N] Average monthly continuity price: [$X] Monthly continuity revenue: [N x $X] Annual continuity revenue (floor): [monthly x 12] THE REVENUE CEILING CALCULATION Revenue Ceiling = Continuity Floor + Launch/Promotional Event Revenue Estimated Core Offer buyers per launch event: [N] Average Core Offer revenue per buyer (including upsells/order bumps): [$X] Number of Core Offer launches per year: [N] Core Offer annual revenue: [buyers x revenue x launches] Estimated Premium Offer buyers per year: [N] Average Premium Offer investment: [$X] Premium annual revenue: [N x $X] Total Revenue Ceiling: [Floor + Core Launch Revenue + Premium Revenue] THE FLOOR/CEILING RATIO HEALTH CHECK Healthy ratio target: Revenue Floor should be at least 30% of Revenue Ceiling High risk (Floor <10% of Ceiling): The business is entirely launch-dependent. One failed launch produces a financial crisis. Moderate risk (Floor 10–29% of Ceiling): Some stability but significant dependence on launch performance. Healthy (Floor 30–49% of Ceiling): Meaningful income floor. Launch performance matters but is not existential. Strong (Floor 50%+ of Ceiling): The business generates reliable income regardless of launch activity. Launches add to a solid foundation. THE CONTINUITY MEMBER COUNT TARGETS To reach a $5,000/month Revenue Floor at $97/month membership: 52 active members To reach a $10,000/month Revenue Floor at $97/month: 104 active members To reach a $5,000/month Revenue Floor at $197/month: 26 active members To reach a $10,000/month Revenue Floor at $197/month: 51 active members These targets clarify the relative priority of continuity growth vs Core Offer launch activity.

THE UPSELL AND DOWNSELL INFRASTRUCTURE Maximising Revenue From Every Transaction The funnel architecture that captures value across the full range of buyer readiness

The upsell and downsell infrastructure is the set of offers presented immediately before or immediately after a buyer's primary purchase decision. It is not an afterthought or an add-on — it is a planned component of the value ladder that captures revenue from buyers at the exact moment their purchase intent is highest, without requiring a second marketing campaign to generate it.

The Four Transaction Enhancement Types

Type | Definition | Placement | Optimal Price | Design Principle
Order Bump | A low-price complementary offer presented on the primary offer's checkout page as a checkbox add-on. The buyer adds it with a single click without leaving the checkout flow. | On the checkout page, below the primary offer details and above the payment button. | 15–30% of the primary offer's price. At this ratio, the order bump converts 20–40% of buyers. | The order bump must be a specific, immediate-value complement to the primary offer — something the buyer will use in the first week of the primary programme. A template pack, a quick-start guide, a tool. Not a separate product that requires its own learning curve.
One-Time Offer (OTO) Upsell | A higher-price upgrade offer presented immediately after the primary offer is purchased, on a dedicated page the buyer reaches before the confirmation page. | Immediately post-purchase, before the thank-you or delivery confirmation page. | 150–300% of the primary offer's price. At this price ratio, OTO upsells convert 10–25% of buyers. | The OTO must be a genuine upgrade — not a continuation of the primary offer but a faster path to the result, a higher level of access, or a complementary system that amplifies the primary offer's value. 'Buy the same thing at a higher price' is not an OTO.
Downsell | A lower-price alternative offered to buyers who decline the OTO upsell. The downsell captures revenue from buyers who said no to the full upsell price but are still in a state of purchase engagement. | Immediately after the OTO decline button is clicked. | 40–60% of the OTO price. Converts 20–40% of OTO decliners. | The downsell is a genuine step-down in access or scope — not the same offer at a different price. A video-only version of a live programme, a single module extraction, or a lower-tier membership. The buyer who declines the OTO and accepts the downsell is a legitimate buyer — not a consolation conversion.
Post-Purchase Upsell | An offer presented in the post-purchase delivery sequence (welcome email or onboarding sequence) for buyers who did not purchase the OTO. | Day 3–7 of the post-purchase welcome sequence, after the buyer has had their first positive experience with the primary offer. | Same range as the OTO. | Presented when the buyer has experienced genuine early value from the primary offer and is in a state of positive engagement. 'Based on where you are now in the programme, the next most useful thing is [offer].' Contextualised, not mass-broadcast.

The Transaction Enhancement Sequence — The Complete Funnel Architecture

Step | What Happens | Revenue Contribution | Error to Avoid
1 — Checkout page with Order Bump | Buyer arrives at checkout for the Core Offer. The Order Bump is visible below the offer details. No action required to decline — it is opt-in. | 20–40% of Core Offer buyers add the Order Bump. At a $97 order bump and 30% conversion on 100 buyers: $2,910 incremental revenue per 100 buyers with zero additional marketing cost. | Making the Order Bump too large (in scope or price). An Order Bump that requires significant explanation is already too complex. It must be immediately obvious and immediately desirable.
2 — OTO presented post-purchase | Immediately after payment, before the confirmation page, the buyer is presented with the OTO. They cannot return to the primary checkout — the primary purchase is confirmed regardless. | 15% of Core Offer buyers take the OTO. At a $997 OTO and 15% conversion on 100 buyers: $14,955 incremental revenue per 100 buyers. | Presenting the OTO before confirming the primary purchase. This creates buyer anxiety about the purchase they just made. The primary purchase confirmation must be clear before the OTO is presented.
3 — Downsell presented if OTO is declined | If the buyer clicks 'No thanks' on the OTO, they are immediately presented with the Downsell — a genuine step-down alternative. | 25% of OTO decliners take the Downsell. At a $397 Downsell: 85 buyers declined the OTO, 21 take the Downsell = $8,337 incremental revenue per 100 buyers. | A Downsell page that creates guilt ('Are you sure you want to miss out on this?'). Downsell pages that use pressure or shame convert at a short-term rate but produce a buyer who felt manipulated. The Downsell must be a genuine alternative presented with full respect for the buyer's decision.
4 — Thank-you page with soft next step | The buyer reaches the confirmation page. A soft mention (not a full OTO) of the next logical step is included — typically the Continuity Offer or the Premium Waitlist. | Low direct conversion on the thank-you page (3–8%) but high awareness-building for the next ascension step. | A thank-you page that is purely logistical ('Your confirmation is in your email'). The thank-you page is the highest-trust moment in the entire funnel and a significant missed opportunity if it contains only logistics.
5 — Post-purchase sequence Day 3–7 | Buyers who did not take the OTO receive a contextualised post-purchase upsell in the welcome sequence, after their first week of programme engagement. | 5–10% additional OTO conversion from non-OTO buyers. These are buyers who declined in the moment of purchase but became more open after experiencing early value. | Sending the post-purchase upsell before the buyer has had time to experience value from the primary offer. Day 1 upsell attempts to buyers who just paid feel like immediate reselling. Day 3–7, after a positive early experience, feels like a natural next step.

The Product Ecosystem Map — How All Offers Connect

The Product Ecosystem Map is the visual and strategic overview of how every offer in the value ladder relates to every other offer: how buyers move between them, what each offer's prerequisite is, and how the offers together produce a coherent, progressive buyer journey rather than a collection of independent products.

The Product Ecosystem Map Elements

Ecosystem Element | What It Documents | Why It Is Required | What Happens Without It
Entry Points | Which offers a new buyer (who has no prior relationship with the operator) can enter the ecosystem through. Typically Rung 1 and Rung 2. | Ensures every marketing channel and every traffic source has a clearly defined offer destination that matches the awareness level of the incoming traffic. | Traffic from different channels lands on offers inappropriate for the awareness level of that traffic. Cold traffic landing on a $5,000 premium offer without a prior relationship path does not convert.
Prerequisites | Whether any offer has required prior purchases or conditions for entry. | Prevents buyers from purchasing offers they are not ready for, which produces poor results, high refunds, and frustrated buyers. | Buyers purchase the Premium Offer without the Core Offer's foundational work. They cannot implement the advanced content, produce no results, and attribute the failure to the programme.
Logical Next Steps | The specific offer each buyer should be presented with upon completing or reaching a milestone in the current offer. | Automates the ascension path by ensuring that the completion trigger for each offer fires the appropriate next-step offer or invitation. | Completers receive a thank-you email and are never contacted about the next natural step. The conversion window closes. The buyer finds another provider for their next stage.
Exit Paths | What options exist for buyers who reach each rung and are not ready or willing to ascend further. | Ensures every buyer has a dignified, value-maintaining exit path that preserves the relationship even if they do not ascend. | Buyers who reach an exit point without an exit path either churn silently or produce negative word-of-mouth when they feel they have been pressure-sold beyond their commitment level.
Cross-Offer Synergies | Where the content, community, or results from one offer enhances the value of another offer in the ecosystem. | Creates compounding buyer value: buyers who have completed multiple rungs have cumulative advantages that make each successive rung more valuable. | Offers are designed and delivered as independent products with no connection to each other. Buyers do not experience the cumulative value that the full ecosystem can provide.

The Product Ecosystem Map Template

PRODUCT ECOSYSTEM MAP — Complete for the full value ladder RUNG 1 — TRAFFIC HOOK / LEAD MAGNET Offer name: [working title] Format: [PDF guide / Video series / Scorecard / Template / Mini-course] Delivery mechanism: [Email delivery / Gated page / Immediate download] Prerequisite: None Entry point for traffic from: [all channels — this is the universal entry point] Natural next step after delivery: Rung 2 SLO (presented on thank-you page and in Email 1) Exit path if buyer does not proceed: Continues in email nurture sequence RUNG 2 — SELF-LIQUIDATING OFFER Offer name: Price: [$X] Format: [Video workshop / Workbook / Mini-course / Template pack] Prerequisite: None (can be purchased without Rung 1) Primary entry source: Rung 1 thank-you page + Email sequence Days 1–3 Natural next step after completion: Core Offer (presented in Rung 2 delivery) Order Bump on Rung 2 checkout: [name and price] OTO after Rung 2 purchase: [name and price, if applicable] Exit path: Continues in email sequence if no Core Offer purchase RUNG 3 — CORE OFFER Offer name: Price: [$X] Format: [Group programme / Self-paced course / Cohort / Live workshops] Prerequisite: Rung 2 buyer status (ideal) or verified readiness (via application or screening) Primary entry source: Email sequence Days 5–14 + Sales page + Launch events Order Bump on checkout: [name and price] OTO after purchase: [name and price] Downsell if OTO declined: [name and price] Natural next step upon completion: Continuity Offer (presented in final module + graduation email) Exit path: Continued email relationship with periodic Core Offer re-engagement campaigns RUNG 4 — CONTINUITY Offer name: Monthly price: [$X/month] Format: [Community / Coaching sessions / Content library / Mastermind] Prerequisite: Core Offer completion or verified equivalent experience Primary entry source: Core Offer completion sequence + Community invitation Cancellation exit path: Exit interview + 3-month win-back sequence Natural next step for high-engagement members: Premium Offer invitation (milestone-triggered) RUNG 5 — PREMIUM OFFER Offer name: Price: [$X for [duration/format]] Format: [High-touch group coaching / Intensive / Mastermind / Accelerator] Prerequisite: Core Offer completion + minimum [N] months in Continuity (or equivalent) Primary entry source: Milestone-triggered personal invitation from Continuity Application or call required: [Yes / No] Natural next step: DFY engagement for qualified buyers / continued Premium for ongoing support RUNG 6 — DONE-FOR-YOU (if applicable) Offer name: Price: [$X per engagement or retainer] Format: [Specific deliverable description] Prerequisite: Premium Offer participation or equivalent documented context Capacity constraint: Maximum [N] concurrent DFY clients Natural next step: Long-term retainer / referral to network if capacity reached

The Value Ladder Build Sequence for New Operators

The value ladder described in this SOP is the complete architecture. New operators do not build all six rungs before the business generates revenue. The Build Sequence below defines the order in which rungs are built, the dependency each rung has on the prior rung's validation, and the milestone that must be passed before building the next rung.

Build Order | Rung Built | Dependency | Milestone to Pass Before Building Next Rung | Why This Order
Step 1 | Rung 1 — Traffic Hook | None. This is the first thing built. | Minimum 100 email subscribers from organic sources. Opt-in rate above 25% from warm sources. | The Traffic Hook validates the operator's ability to attract and capture the target audience before any paid offer exists. It is also the list-building infrastructure that every subsequent offer will be sold to.
Step 2 | Rung 3 — Core Offer | Traffic Hook live and building the list. | First 5 sales of the Core Offer at full price, from organic sources. Refund rate below 10%. | The Core Offer is built second, not the SLO, because the Core Offer is the proof-of-concept for the entire business. Validating the Core Offer first confirms the business model. The SLO is built to self-liquidate the cost of Core Offer buyer acquisition — but only after the Core Offer is confirmed as viable.
Step 3 | Rung 2 — Self-Liquidating Offer | Core Offer validated with first sales. | SLO revenue equals or exceeds the cost of email subscriber acquisition from paid sources. (Only relevant once paid traffic begins.) SLO conversion rate above 3% from email subscribers. | The SLO is built third because its purpose is to self-liquidate paid traffic costs. Building it before the Core Offer is validated means building an acquisition path for an offer whose commercial viability is unconfirmed.
Step 4 | Rung 4 — Continuity | Core Offer generating regular buyers with above-threshold completion rates and positive testimonials. | Minimum 20 continuity members paying the monthly fee. Churn rate below 5% per month. | Continuity requires buyers who have experienced genuine Core Offer transformation and want to continue. It cannot be launched to a list that has no buyers — the members are the product.
Step 5 | Rung 5 — Premium Offer | Active continuity community with milestone-ready members. | Minimum 5 Premium Offer buyers with documented premium-level results. Premium offer ROI confirmed: buyers are receiving more than the premium price in value. | The Premium Offer is built when the operator has enough continuity members to identify the specific 20% who are ready for higher-access support. Building it earlier produces an offer with no qualified buyers.
Step 6 | Rung 6 — Done-For-You | Premium Offer validated with results evidence. Operator has capacity (or team capacity) for DFY delivery. | DFY delivery system fully documented and tested with 2–3 pilot engagements. Operator or team can sustain DFY delivery without degrading Core Offer or Premium Offer quality. | DFY is the highest-fulfilment-intensity rung. It is built last because it requires the operator's maximum capacity. Building it before the lower rungs are systematised produces a situation where DFY clients consume all available operator time, preventing the lower-rung business from functioning.

The LTV Maximisation System

Lifetime Value (LTV) is the total revenue a single buyer generates across all rungs of the value ladder over the entire duration of their relationship with the business. LTV is the single most important metric for assessing the long-term health of a knowledge business and the primary input for calculating the maximum sustainable Cost Per Lead (CPL) for paid traffic.

The LTV Calculation by Buyer Cohort

LTV CALCULATION TEMPLATE — Complete for each buyer cohort (monthly cohort recommended) COHORT DEFINITION Cohort entry date: [Month/Year] Cohort size: [N buyers who purchased the Core Offer in this month] Cohort entry offer: [Core Offer name and price] 30-DAY LTV Core Offer revenue per buyer: [$X] Order Bump uptake: [N% x $bump price] OTO uptake: [N% x $OTO price] Downsell uptake: [N% x $downsell price] 30-Day LTV = [Core Offer + (Order Bump rate x price) + (OTO rate x price) + (Downsell rate x price)] 30-Day LTV benchmark: Above 1.3x the Core Offer base price 90-DAY LTV 30-Day LTV (from above) Plus: Continuity conversion rate from this cohort: [N% joining at $X/month x 3 months of membership] Plus: Any second Core Offer purchase (returning buyers or upsells within cohort period) 90-Day LTV benchmark: Above 1.6x the Core Offer base price 12-MONTH LTV 90-Day LTV (from above) Plus: Continuity revenue months 4–12 for members who did not churn Plus: Premium Offer conversion from this cohort: [N% x $premium price] 12-Month LTV benchmark: Above 2.5x the Core Offer base price for a healthy value ladder THE MAXIMUM VIABLE CPL CALCULATION Maximum Viable CPL = 90-Day LTV x (1 - minimum required gross margin) Example: 90-Day LTV = $850 | Required gross margin = 50% Maximum Viable CPL = $850 x 50% = $425 An operator whose paid traffic CPL is below their Maximum Viable CPL has a commercially sustainable paid acquisition channel. An operator whose CPL exceeds their Maximum Viable CPL must either increase LTV (by improving the back-end conversion rates) or reduce CPL (by improving front-end conversion rates) before scaling paid traffic.

The Six LTV Enhancement Levers

Lever | How It Works | The LTV Impact | Implementation Priority
1 — Improve Order Bump Conversion | Test different Order Bump offers, prices, and copy. An Order Bump converting at 30% vs 15% doubles the order bump revenue contribution to LTV. | Each 10 percentage point increase in Order Bump conversion adds approximately 3–5% to 30-Day LTV. | High. Order Bump testing has zero incremental traffic cost and immediate LTV impact.
2 — Improve OTO Conversion | Test different OTO offers, prices, and framing. The OTO is the highest-value single conversion opportunity in the immediate post-purchase window. | Each 5 percentage point increase in OTO conversion adds 10–15% to 30-Day LTV at a typical OTO price ratio. | High. Same zero-traffic-cost testing environment as the Order Bump.
3 — Improve Core Offer Completion Rate | Buyers who complete the programme are 3–5x more likely to join continuity, purchase premium, and generate testimonials than buyers who do not complete. | A 20 percentage point improvement in Core Offer completion rate (from 40% to 60%) can increase 90-Day LTV by 20–30% through downstream continuity and premium conversion improvement. | Very high. Programme completion is the multiplier for every downstream LTV lever.
4 — Improve Continuity Conversion | Test the timing, framing, and format of the continuity offer presentation at Core Offer completion. Earlier vs later presentation, community preview vs feature description. | Each 10 percentage point improvement in continuity conversion from Core Offer buyers adds the full monthly continuity value x average membership duration to cohort LTV. | High, especially as the business matures. Continuity is the compounding LTV lever.
5 — Reduce Continuity Churn | Improve the monthly value delivery visibility so members can clearly see what they received. Reduce the monthly churn rate. | A reduction from 5% monthly churn to 3% increases the average membership duration from 20 months to 33 months — a 65% increase in continuity LTV per member. | Very high for mature continuity programmes. The compounding effect of lower churn dramatically outperforms the effect of higher new member acquisition.
6 — Improve Premium Conversion from Continuity | Develop the milestone-triggered invitation system. Personalise invitations based on member activity and stated goals. Test different premium offer formats. | Each additional 5% of continuity members who convert to Premium adds the full premium price to cohort LTV. | Medium for early-stage businesses (Premium offer may not yet exist). High for mature businesses where Premium is the primary profit driver.

The Value Ladder Health Assessment

The Value Ladder Health Assessment is a structured quarterly review of every rung in the current value ladder. It identifies which rungs are performing at or above standard, which are underperforming, and what specific action is required to address each underperforming rung. It is not a general sense-check — it is a scored assessment against specific benchmarks.

The Rung-by-Rung Health Scorecard

Rung | Primary Health Metric | Healthy Benchmark | Requires Attention | Urgent Action Required
Rung 1 — Traffic Hook | Opt-in rate from primary traffic sources | Above 30% from warm sources | 20–29% | Below 20%. The Traffic Hook offer, the headline, or the traffic source alignment is broken.
Rung 2 — SLO | Conversion rate from email subscribers | Above 3% | 1.5–2.9% | Below 1.5%. The SLO offer's price-to-value ratio, the offer's specificity, or the email sequence presenting it requires review.
Rung 3 — Core Offer | 30-day subscriber-to-buyer conversion rate | Above 2% | 1–1.9% | Below 1%. The organic funnel has not yet passed the Hard Organic Proof Threshold and should not be scaled with paid traffic.
Rung 4 — Continuity | Monthly churn rate | Below 3% | 3–6% | Above 6% monthly churn. The monthly value delivery is not visible to members, or the entry qualification standards are allowing buyers who are not ready.
Rung 5 — Premium | Conversion rate from milestone-invited continuity members | Above 15% of eligible invitees accept | 8–14% | Below 8%. The invitation timing, the premium offer format, or the milestone qualification criteria requires review.
Rung 6 — DFY (if active) | Client satisfaction and renewal rate | Above 80% of DFY clients renew or refer | 65–79% renewal/referral | Below 65%. The DFY delivery quality or scope definition requires review.

VALUE LADDER HEALTH ASSESSMENT — Quarterly Review Protocol PREPARATION (before the review meeting) Pull the current metrics for each active rung from the Airtable tracking system. Calculate the current cohort LTV at 30-day and 90-day marks. Calculate the current Revenue Floor (continuity monthly total) and Revenue Ceiling (Floor + launch projections). Calculate the current Floor/Ceiling ratio. THE ASSESSMENT (30 minutes) Rung 1: [current opt-in rate] — Benchmark status: [Healthy / Attention / Urgent] Rung 2: [current SLO conversion rate] — Benchmark status: [same format] Rung 3: [current Core Offer conversion rate] — Benchmark status: Rung 4: [current churn rate] — Benchmark status: Rung 5 (if active): [premium conversion rate] — Benchmark status: Revenue Floor: [$X/month] | Floor/Ceiling ratio: [X%] — Benchmark status: 30-Day LTV: [$X] | 90-Day LTV: [$X] — Benchmark status: THE PRIORITY ACTION Identify the single most underperforming rung (the lowest benchmark status with the highest LTV impact). For this rung: what specifically is the action to move it from its current status to the next benchmark tier? Name the action, the person responsible, and the date by which it will be implemented. Do not attempt to fix multiple rungs simultaneously. One rung at a time.

Airtable Schema — Value Ladder Tracking Database

Table 1 — Value Ladder Configuration

Table 2 — Monthly LTV Tracker

Master Value Ladder Architecture Checklist

Architecture Design (Complete Before Building)

☐ Six Rung Framework reviewed — each rung's function understood and relevant to the committed niche

☐ Product Ecosystem Map drafted: all six rungs defined with prerequisites, entry sources, natural next steps, and exit paths

☐ Revenue Floor target set: specific continuity member count and price to reach the target floor

☐ Revenue Floor / Revenue Ceiling ratio target defined

Rung 1 Build (Complete in Week 10 — first 14 days)

☐ Traffic Hook offer defined: format, specific promise, and delivery mechanism

☐ Opt-in page live with tested Traffic Hook headline

☐ Welcome email sequence active: Email 1 through Email 7 built with Rung 2 SLO presented in Email 1 and Email 3

Rung 3 Build (Complete in Weeks 7–8 after Course 11 and 12)

☐ Core Offer structure defined: delivery format, programme length, number of modules, live vs asynchronous

☐ Core Offer sales page built with Story Asset Library stories deployed

☐ Order Bump defined and added to checkout

☐ OTO defined and post-purchase page built

☐ Downsell defined and decline page built

☐ Core Offer delivery infrastructure tested: all modules accessible, email delivery confirmed

☐ First 5 sales target set with a specific date

Rung 2 Build (After first 5 Core Offer sales confirmed)

☐ SLO offer defined: a fast-result, specific, low-risk complement to or preview of the Core Offer

☐ SLO price confirmed at 15–30% of Core Offer price

☐ SLO added to Traffic Hook thank-you page and Email sequence Day 1–3

Rung 4 Build (After Core Offer is generating regular buyers and above-threshold completion rates)

☐ Continuity format selected from the five model types

☐ Continuity monthly value delivery structure designed: what specific output does each member receive each month?

☐ Continuity entry criteria defined and enforced

☐ Core Offer graduation sequence updated with continuity invitation

☐ Churn prevention system in place: monthly value visibility mechanism

Value Ladder Health Assessment (Quarterly)

☐ All active rung metrics pulled: opt-in rate, SLO conversion, Core Offer conversion, churn rate

☐ 30-Day and 90-Day LTV calculated for most recent cohort

☐ Floor/Ceiling ratio calculated

☐ Single priority rung identified for improvement action

☐ Action assigned to responsible person with completion date

RISER Nation Master Operating System | Value Ladder Architecture SOP | Course 14 | Version 1.0 | 2026 Edition

Track 3: Build Your Offer — Course 14 of 14 | risernation.com

word/header1.xml: RISER Nation | Value Ladder Architecture SOP | Course 14 | V1.0
word/footer1.xml: Page of
word/footnotes.xml:

word/endnotes.xml:

SECTION 38 — THE AUTOMATION STACK (MAKE

Build the four levels as an unverified specification

The source proposes GPT-to-webhook-to-Make-to-Sheets, YouTube metadata retrieval, triggered notifications and client-facing outputs. Its claim that level one already functions is historical and unverified here. Define all seventy-two fields, types and validation rules before mapping them; this document does not provide the full schema. Establish authentication, permitted destinations, retry handling, deduplication, safe text insertion and an error queue before enabling consequential actions. A URL alone does not supply a full video audit or prove seven modules ran.

Distinguish public metadata from owner analytics

The videos.list example requests snippet, statistics and contentDetails. It can support available title, description, tags, publish metadata and counts. Retention and other channel analytics require the appropriate authorized reporting interface; the authorizing user must own the channel. The source’s generic “YT Studio API” description and public request do not grant competitor retention or earnings. Keep missing values unknown, timestamp retrieved data and map field identifiers explicitly. An API reduces reliance on generated guesses but does not guarantee zero errors or hallucination.

Review alert criteria before sending notifications

Proposed alerts use score below fifty, score above ninety, predicted CTR below 2.5% and predicted retention below thirty percent. Predictions are not measured performance or proof of virality; calibrate them and define equality boundaries and false-positive handling. Proposed Trello lists are thumbnails, hooks, script, editing and CTA. Record a dynamic actual score rather than the example’s fixed 54. The fifty-point client PDF differs from the seventy-two-field dataset and needs a documented mapping. No alert, email, card or client report is sent by preparing this lesson.

Define the client deliverables and commercial limits

The PDF plan includes summary, thumbnail, hook, retention forecast, psychology, funnel, five fixes and three alternatives. The dashboard plan includes CTR history, retention overlays, grades, virality estimates, hooks, weak videos, emotional spikes and thumbnail comparisons. The weekly digest includes three winners, three weak performers, priority fixes, research, angles and backlog. Label inferred emotions and forecasts as estimates. The $5,000/month service and $97–$297 dashboard prices are proposed offers, not evidence of demand or retention gains. Confirm ownership, visibility and deliverable scope before white-label use.

Version and test changes rather than appending blindly

The source calls for named workflow versions, a locked seventy-two-field export, one active webhook, logging, archived bundles and a thirty-day review of knowledge files, workflows, columns and quota. Preserve field compatibility with explicit mappings and schema versions; JSON object key order is not a sound schema contract. Appending instructions at the bottom does not prevent conflicts. Its twenty-file limit and preferred sixteen-file set are historical product assumptions to check in the actual platform before setup. Multiple authenticated versioned webhooks may be appropriate; the one-webhook instruction is this source’s simplification, not a universal requirement.

Apply the Brunson and Hormozi teaching frame

Complete original source text

SECTION 38 — THE AUTOMATION STACK (MAKE.COM + GPT + YOUTUBE + SHEETS)

Pages ~2,720–2,920 — Building the fully-automated, end-to-end VCI System

________________





In this section, we turn your VCI GPT into a complete automated machine, capable of:

* pulling data from YouTube



* receiving URLs from GPT



* generating the 72-field audit



* inserting rows into Google Sheets



* creating reports



* tracking performance over time



* triggering alerts



* notifying teams



* running workflows without manual action



This is your “AI-First Content Automation System.”

We break this into 4 levels:

   1. Level 1 — GPT → Webhook → Make.com → Sheets (already functioning)



   2. Level 2 — YouTube Data API Integration



   3. Level 3 — Triggered Automations & Notifications



   4. Level 4 — Client-Ready Automations (PDFs, emails, Slack, Trello, etc.)



Let's build the entire stack.

________________





🟦 38.1 LEVEL 1 — YOUR CURRENT WORKING AUTOMATION (Baseline System)

You've already successfully built:

Flow A: User sends URL → GPT → Webhook → Make.com → Google Sheets

The system currently does:

      1. User pastes URL into VCI GPT



      2. GPT runs the full 7-module inspection



      3. GPT outputs the 72-field JSON



      4. Send JSON → Make.com webhook



      5. Make inserts the row



      6. Google Sheet populates with your dataset



This section documents how to rebuild it from zero if needed.

________________





🔧 CORE COMPONENT 1 — The Webhook

Make.com → Webhooks → Custom Webhook → Add

Save:

VCI Video Intake

Copy the webhook URL into GPT (Actions → Add Action → POST method).

________________





🔧 CORE COMPONENT 2 — JSON Parser

Make module:

Tools → JSON → Parse JSON

Paste a valid example payload once.

This generates the 72 keys Make needs.

________________





🔧 CORE COMPONENT 3 — Google Sheets (Add a Row)

Connect your account.

Select the sheet.

Map the 72 fields.

Save.

✔ “Advanced Settings → Insert Row Unformatted (Yes)”

✔ “Use Map Mode → Yes”

________________





🟧 38.2 LEVEL 2 — YOUTUBE API INTEGRATION (Auto-pull titles, stats, thumbnails)

This turns your system into a full analytical intelligence engine, not just a GPT reader.

What this lets you do automatically:

         * Pull video title



         * Pull description



         * Pull thumbnail



         * Pull tags/keywords



         * Pull view count



         * Pull likes / comments



         * Pull audience retention charts (YT Studio API)



         * Pull RPM & monetization data



         * Pull publish time



         * Pull traffic sources



         * Pull impression click-through rates



🔌 Required Setup

You need:

            1. Google Cloud Platform Project



            2. YouTube Data API v3 enabled



            3. API key + OAuth credentials



            4. Make.com → HTTP module



HTTP Module Setup Example

GET https://www.googleapis.com/youtube/v3/videos

?part=snippet,statistics,contentDetails

&id={{VideoID}}

&key={{YourAPIKey}}





You then map:

               * title → Field 5



               * description → Field 6



               * tags → Field 7



               * viewCount → Field 52



               * likeCount → Field 53



               * commentCount → Field 54



This reduces GPT hallucination to 0% in these fields.

________________





🟦 38.3 LEVEL 3 — TRIGGERED AUTOMATIONS & NOTIFICATIONS

You can now add layers:

Automation Layer A → Slack / Email Alerts

Example triggers:

✔ Video scored < 50 → “Needs rebuild” alert

✔ Video scored > 90 → “High-potential viral hit” alert

✔ Thumbnail CTR predicted < 2.5% → “Thumbnail rewrite required”

✔ Retention predicted < 30% → “Retention audit needed”

Automation Layer B → Trello Cards

Make.com → Trello → "Create Card"

Card title:

“VCI Fix Required: {{Video Title}} (Score: 54)”

List assignment:

                  * Thumbnails



                  * Hooks



                  * Script Rewrite



                  * Editing Fix



                  * CTA Optimization



This converts VCI results into actionable production tasks.

Automation Layer C → Google Drive PDFs

Create:

                     * a PDF report



                     * with 50-point client version



                     * auto-attached to client record



________________





🟧 38.4 LEVEL 4 — CLIENT-READY AUTOMATIONS (WHITE-LABEL SERVICE)

This is where your system becomes a $5,000/month done-for-you agency machine.

________________





Client Output 1 — Auto-Generated PDF Audit

Make.com → PDF → Create PDF from HTML

Your GPT outputs structured HTML markup for:

                        * executive summary



                        * thumbnail analysis



                        * hook analysis



                        * retention forecast



                        * psychology alignment



                        * CTA/funnel analysis



                        * top 5 fixes



                        * 3 beat-this versions



Creates a polished PDF instantly.

________________





Client Output 2 — White-Label VCI Dashboard

Built in Google Data Studio / Looker:

                           * CTR over time



                           * retention curve overlays



                           * content grade history



                           * virality score trend



                           * top performing hooks



                           * worst performing videos



                           * emotional spikes



                           * thumbnail CTR comparisons



You can charge $97–$297/mo for “dashboard access.”

________________





Client Output 3 — Weekly “Action Report” Email

Auto-send a weekly digest:

                              * top 3 winners



                              * bottom 3 losers



                              * priority fixes



                              * research insights



                              * recommended angles



                              * content backlog updates



Client retention skyrockets when they see weekly progress.

________________





🟧 38.5 CHECKPOINT — FUTURE-PROOFING YOUR AUTOMATION

Here’s how you stay future-ready:

✔ Inline Versioning

Always number automations:

VCI Intake v1.2

 VCI Retention Engine v2.0

✔ Schema Locking

NEVER change your 72-field order.

If you must, create a new schema “v2”.

✔ GPT Upgrade Method

When adding instructions:

                                 * add new instructions at bottom



                                 * NEVER change the JSON exporter



                                 * keep knowledge files under 20 (limit)



                                 * prioritize 16 top files (you already did this)



✔ Make.com Hygiene

                                    * Archive old bundles



                                    * Keep only ONE active webhook



                                    * Add logging modules



✔ Monthly Refactoring

Every 30 days, review:

                                       * GPT knowledge files



                                       * Make workflows



                                       * Sheet column structure



                                       * YouTube API quota usage



________________

Native Google Doc text and original links

Control separators are labeled in this readable display. Download exact original text

SECTION 38 — THE AUTOMATION STACK (MAKE.COM + GPT + YOUTUBE + SHEETS)
Pages ~2,720–2,920 — Building the fully-automated, end-to-end VCI System

In this section, we turn your VCI GPT into a complete automated machine, capable of:
pulling data from YouTube
[Source control separator U+000B]

receiving URLs from GPT
[Source control separator U+000B]

generating the 72-field audit
[Source control separator U+000B]

inserting rows into Google Sheets
[Source control separator U+000B]

creating reports
[Source control separator U+000B]

tracking performance over time
[Source control separator U+000B]

triggering alerts
[Source control separator U+000B]

notifying teams
[Source control separator U+000B]

running workflows without manual action
[Source control separator U+000B]

This is your “AI-First Content Automation System.”
We break this into 4 levels:
Level 1 — GPT → Webhook → Make.com → Sheets (already functioning)
[Source control separator U+000B]

Level 2 — YouTube Data API Integration
[Source control separator U+000B]

Level 3 — Triggered Automations & Notifications
[Source control separator U+000B]

Level 4 — Client-Ready Automations (PDFs, emails, Slack, Trello, etc.)
[Source control separator U+000B]

Let's build the entire stack.

🟦 38.1 LEVEL 1 — YOUR CURRENT WORKING AUTOMATION (Baseline System)
You've already successfully built:
Flow A: User sends URL → GPT → Webhook → Make.com → Google Sheets
The system currently does:
User pastes URL into VCI GPT
[Source control separator U+000B]

GPT runs the full 7-module inspection
[Source control separator U+000B]

GPT outputs the 72-field JSON
[Source control separator U+000B]

Send JSON → Make.com webhook
[Source control separator U+000B]

Make inserts the row
[Source control separator U+000B]

Google Sheet populates with your dataset
[Source control separator U+000B]

This section documents how to rebuild it from zero if needed.

🔧 CORE COMPONENT 1 — The Webhook
Make.com → Webhooks → Custom Webhook → Add
Save:
VCI Video Intake
Copy the webhook URL into GPT (Actions → Add Action → POST method).

🔧 CORE COMPONENT 2 — JSON Parser
Make module:
[Source control separator U+000B]
 Tools → JSON → Parse JSON
Paste a valid example payload once.
[Source control separator U+000B]
 This generates the 72 keys Make needs.

🔧 CORE COMPONENT 3 — Google Sheets (Add a Row)
Connect your account.
[Source control separator U+000B]
 Select the sheet.
[Source control separator U+000B]
 Map the 72 fields.
[Source control separator U+000B]
 Save.
✔ “Advanced Settings → Insert Row Unformatted (Yes)”
[Source control separator U+000B]
 ✔ “Use Map Mode → Yes”

🟧 38.2 LEVEL 2 — YOUTUBE API INTEGRATION (Auto-pull titles, stats, thumbnails)
This turns your system into a full analytical intelligence engine, not just a GPT reader.
What this lets you do automatically:
Pull video title
[Source control separator U+000B]

Pull description
[Source control separator U+000B]

Pull thumbnail
[Source control separator U+000B]

Pull tags/keywords
[Source control separator U+000B]

Pull view count
[Source control separator U+000B]

Pull likes / comments
[Source control separator U+000B]

Pull audience retention charts (YT Studio API)
[Source control separator U+000B]

Pull RPM & monetization data
[Source control separator U+000B]

Pull publish time
[Source control separator U+000B]

Pull traffic sources
[Source control separator U+000B]

Pull impression click-through rates
[Source control separator U+000B]

🔌 Required Setup
You need:
Google Cloud Platform Project
[Source control separator U+000B]

YouTube Data API v3 enabled
[Source control separator U+000B]

API key + OAuth credentials
[Source control separator U+000B]

Make.com → HTTP module
[Source control separator U+000B]

HTTP Module Setup Example
GET https://www.googleapis.com/youtube/v3/videos
?part=snippet,statistics,contentDetails
&id={{VideoID}}
&key={{YourAPIKey}}

You then map:
title → Field 5
[Source control separator U+000B]

description → Field 6
[Source control separator U+000B]

tags → Field 7
[Source control separator U+000B]

viewCount → Field 52
[Source control separator U+000B]

likeCount → Field 53
[Source control separator U+000B]

commentCount → Field 54
[Source control separator U+000B]

This reduces GPT hallucination to 0% in these fields.

🟦 38.3 LEVEL 3 — TRIGGERED AUTOMATIONS & NOTIFICATIONS
You can now add layers:
Automation Layer A → Slack / Email Alerts
Example triggers:
✔ Video scored < 50 → “Needs rebuild” alert
[Source control separator U+000B]
 ✔ Video scored > 90 → “High-potential viral hit” alert
[Source control separator U+000B]
 ✔ Thumbnail CTR predicted < 2.5% → “Thumbnail rewrite required”
[Source control separator U+000B]
 ✔ Retention predicted < 30% → “Retention audit needed”
Automation Layer B → Trello Cards
Make.com → Trello → "Create Card"
Card title:
“VCI Fix Required: {{Video Title}} (Score: 54)”
List assignment:
Thumbnails
[Source control separator U+000B]

Hooks
[Source control separator U+000B]

Script Rewrite
[Source control separator U+000B]

Editing Fix
[Source control separator U+000B]

CTA Optimization
[Source control separator U+000B]

This converts VCI results into actionable production tasks.
Automation Layer C → Google Drive PDFs
Create:
a PDF report
[Source control separator U+000B]

with 50-point client version
[Source control separator U+000B]

auto-attached to client record
[Source control separator U+000B]


🟧 38.4 LEVEL 4 — CLIENT-READY AUTOMATIONS (WHITE-LABEL SERVICE)
This is where your system becomes a $5,000/month done-for-you agency machine.

Client Output 1 — Auto-Generated PDF Audit
Make.com → PDF → Create PDF from HTML
Your GPT outputs structured HTML markup for:
executive summary
[Source control separator U+000B]

thumbnail analysis
[Source control separator U+000B]

hook analysis
[Source control separator U+000B]

retention forecast
[Source control separator U+000B]

psychology alignment
[Source control separator U+000B]

CTA/funnel analysis
[Source control separator U+000B]

top 5 fixes
[Source control separator U+000B]

3 beat-this versions
[Source control separator U+000B]

Creates a polished PDF instantly.

Client Output 2 — White-Label VCI Dashboard
Built in Google Data Studio / Looker:
CTR over time
[Source control separator U+000B]

retention curve overlays
[Source control separator U+000B]

content grade history
[Source control separator U+000B]

virality score trend
[Source control separator U+000B]

top performing hooks
[Source control separator U+000B]

worst performing videos
[Source control separator U+000B]

emotional spikes
[Source control separator U+000B]

thumbnail CTR comparisons
[Source control separator U+000B]

You can charge $97–$297/mo for “dashboard access.”

Client Output 3 — Weekly “Action Report” Email
Auto-send a weekly digest:
top 3 winners
[Source control separator U+000B]

bottom 3 losers
[Source control separator U+000B]

priority fixes
[Source control separator U+000B]

research insights
[Source control separator U+000B]

recommended angles
[Source control separator U+000B]

content backlog updates
[Source control separator U+000B]

Client retention skyrockets when they see weekly progress.

🟧 38.5 CHECKPOINT — FUTURE-PROOFING YOUR AUTOMATION
Here’s how you stay future-ready:
✔ Inline Versioning
Always number automations:
[Source control separator U+000B]
 VCI Intake v1.2
[Source control separator U+000B]
 VCI Retention Engine v2.0
✔ Schema Locking
NEVER change your 72-field order.
[Source control separator U+000B]
 If you must, create a new schema “v2”.
✔ GPT Upgrade Method
When adding instructions:
add new instructions at bottom
[Source control separator U+000B]

NEVER change the JSON exporter
[Source control separator U+000B]

keep knowledge files under 20 (limit)
[Source control separator U+000B]

prioritize 16 top files (you already did this)
[Source control separator U+000B]

✔ Make.com Hygiene
Archive old bundles
[Source control separator U+000B]

Keep only ONE active webhook
[Source control separator U+000B]

Add logging modules
[Source control separator U+000B]

✔ Monthly Refactoring
Every 30 days, review:
GPT knowledge files
[Source control separator U+000B]

Make workflows
[Source control separator U+000B]

Sheet column structure
[Source control separator U+000B]

YouTube API quota usage
[Source control separator U+000B]

Lesson 03.2 — sources for the added teaching sections

SOP_13.1_Real-Time_AI_Avatars.docx

Understand the four avatar components

A conversational avatar combines appearance, voice, language responses and rendering. A recorded talking-head video and a live interactive system are different deliverables. Define whether the role is presenter, educator, sales guide or support; start with one bounded use case and measure usefulness before expanding. The source’s instant reactions and 24/7 interaction are goals, not guaranteed latency or availability.

Select tools by their actual role

The source groups HeyGen, Synthesia and Soul Machines as avatar platforms; ElevenLabs and Resemble AI as voices; NVIDIA Audio2Face and Unreal MetaHuman as animation components; ChatGPT/Custom GPTs and CrewAI as response/orchestration options; OBS, StreamYard and ManyCam as broadcast/integration tools. These are not interchangeable plug-and-play parts. Verify each proposed connection and account entitlement. Current official references identify HeyGen LiveAvatar and Synthesia Interactive Avatar; the source’s /live URLs are retained as historical links, with current documentation alongside.

Build and verify one presenter

Choose the platform, design a brand-appropriate appearance, use an authorized voice, connect a tested script or response service, then record or broadcast through a supported path. The suggested three-to-five-minute sample is not a universal voice-cloning requirement. Obtain the person’s permission and follow the provider’s verification process. Before release, check lip sync, eye contact, sound, contrast, latency, disclosure and a fallback for wrong or unavailable answers. An under-two-second target needs a measured end-to-end definition.

Bound live data and maintenance

For Q&A, give the avatar only appropriate CRM, Notion or Sheets records through a controlled interface; a language model does not gain authorized real-time data merely by being prompted. Streamlit/Gradio are proposed interface choices. Review scripts monthly, voice quality quarterly, appearance by campaign and hardware on a defined schedule: the source’s bi-monthly wording is ambiguous. Idle animation, expressive voice and sub-ninety-second segments are design suggestions to test, not guaranteed engagement improvements. Keep a human handoff and a text alternative.

Apply the direct-marketing teaching frame

Use Brunson’s hook, story and offer structure to make the lesson relevant and easy to act on. Apply the Hormozi value lens to improve credible outcomes and reduce avoidable delay and effort. Keep demonstrations truthful, promises bounded, bonuses relevant and customer choice intact. Frameworks support explanation; they do not validate untested products or claims.

Complete original source text

🧠 RISER Nation SOP #13.1 — Real-Time AI Avatars
**Subtitle:** How to Create, Manage, and Stream Humanlike AI Avatars for Video, Events, and Marketing
🎯 Purpose
To teach your team how to build and operate real-time, talking AI avatars that can act as brand presenters, educators, or sales representatives — without needing human video shoots.
🧩 Overview (What It Is)
A real-time AI avatar is a digital character that moves, talks, and reacts instantly to your text or voice — like a virtual spokesperson. It combines a visual model (the avatar’s face/body), a voice engine (the personality and tone), a language model (what it says), and a render engine (that makes it move).
These avatars are used by YouTubers, brands, and coaches to scale video production, automate webinars, and interact with audiences 24/7.
⚙️ Core Tools (Clickable Links)
Avatar Creation: HeyGen Live – https://www.heygen.com/live
Avatar Creation: Synthesia Live – https://www.synthesia.io/live
Avatar Creation: Soul Machines – https://www.soulmachines.com
Voice & Expression: ElevenLabs – https://elevenlabs.io
Voice & Expression: Resemble AI – https://www.resemble.ai
Animation / Facial Sync: NVIDIA Omniverse Audio2Face – https://developer.nvidia.com/nvidia-omniverse-audio2face
Animation / Facial Sync: Unreal MetaHuman – https://www.unrealengine.com/en-US/metahuman
Brain / Chat: ChatGPT (Custom GPTs) – https://chat.openai.com
Brain / Chat: CrewAI – https://www.crewai.com
Streaming / Integration: OBS Studio – https://obsproject.com
Streaming / Integration: StreamYard – https://streamyard.com
Streaming / Integration: ManyCam – https://manycam.com
🧱 Step-by-Step Process
1️⃣ Choose Your Avatar Platform
Pick between HeyGen Live, Soul Machines, and NVIDIA Audio2Face. Start simple before moving to advanced Unreal setups.
2️⃣ Create Your Avatar’s Look
Upload or design your avatar (face, body, clothing). For brand avatars, match brand colors, tone, and energy.
3️⃣ Generate or Clone Voice
Use ElevenLabs or Resemble AI to create or clone a matching voice tone. Record 3–5 minutes for best results.
4️⃣ Connect Script or AI Brain
Plug in a Custom GPT or scripted response system to allow your avatar to speak or respond in real-time.
5️⃣ Go Live or Record
Use OBS Studio or StreamYard to broadcast your avatar to YouTube, Zoom, or websites.
6️⃣ Quality Control
Before publishing, check lip-sync, eye contact, latency, and disclosure compliance.
🚀 Advanced Setup (Optional)
For live Q&A avatars: connect your GPT to a live data source (CRM, Notion, or Sheets). Train it to pull and answer real data in conversations, integrating with Streamlit or Gradio for interface.
🧰 Maintenance & Optimization
• Re-Train Avatar Voice — Quarterly using ElevenLabs
• Update Scripts / GPT — Monthly using ChatGPT / Claude
• Hardware Performance Test — Bi-Monthly using OBS / GPU Benchmark
• Brand Outfit Refresh — Each Campaign using Midjourney / Leonardo
⚠️ Common Mistakes
• Starting too complex — begin with one avatar.
• Ignoring latency — aim for under 2 seconds delay.
• Forgetting disclosure labels.
• Using poor lighting or contrast.
💡 Expert Tips
• Add idle animations (breathing, eye blink) for realism.
• Use emotion-based voice models for tone control.
• Keep each segment under 90 seconds to maintain attention.
🧠 Final Notes
Real-time AI avatars are the future of automation and branding. Start with one avatar, test engagement, and scale across multiple roles (sales, support, education).

Original Word reading order, tables, headers and footers

STAR, STORY, SOLUTION

1. Pattern interrupt

Open with a relevant, truthful hook. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

2. Core desire questions

Ask about a real desired outcome without presuming everyone wants to quit a job or start a business. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

3. Past failures

Acknowledge obstacles respectfully; avoid blaming the viewer for stopping or struggling. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

4. One promise

State what this video will explain and actually deliver it. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

5. Introduce the star

Use a leader, reluctant hero, adventurer or reporter perspective that fits the real narrator. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

6. Start in the action

Show a specific turning point. The bills-and-empty-bank scene in the source is an illustrative script, not verified autobiography. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

7. Backstory and wall

Explain relevant context and prior attempts. The single-father/ClickBank/debt narrative must not be attributed to a real person without confirmation. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

8. Identify the problem

Name the specific obstacle and evidence. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

9. Epiphany

Explain what changed in the person’s understanding without fabricating a revelation. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

10. Search for a solution

Describe actual attempts, what improved and what did not. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

11. First success

Show a bounded, verifiable result with timing and conditions. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

12. Conspiracy claim

Replace unsupported blame with a documented structural obstacle. Do not invent a conspiracy. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

13. Big lie

Challenge a particular unsupported assumption with evidence, not blanket accusations. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

14. Common enemy

Focus on a problem or ineffective practice rather than vilifying people. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

15. Growth

Report measured change with a baseline and timeframe; rapid growth is not automatic. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

16. Case studies

Use authentic cases with permission and context; distinguish selected examples from typical results. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

17. Hidden benefits

State secondary benefits only when supported. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

18. Introduce the product

Name the actual offer and how it addresses the demonstrated problem. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

19. Creation cost

Use accurate time/cost information when relevant; sunk cost alone does not prove customer value. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

20. Ease

Demonstrate which work becomes easier and what effort remains. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

21. Speed

Compare equivalent tasks and conditions, including setup/review time. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

22. Feature-to-benefit bridge

Explain what a feature enables. The source’s fat-burning and autopilot-email phrases are unsupported examples, not claims to repeat. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

23. Social proof

Never fill testimonial blanks with invented customers or results. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

24. Present the offer

State scope, actual price and access; a meal-for-two analogy is not a reliable price disclosure. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

25. Bonuses

Add relevant problem-solving assets that can actually be delivered. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

26. Price anchor

Use defensible comparisons rather than inflated total values. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

27. Emotional close

Describe a plausible useful outcome; do not imply the product guarantees a dream home or quitting work. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

28. Actual price

State total, recurring charges and material conditions clearly; do not invent a former selling price. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

29. Guarantee

Specify eligibility, remedy and process. A guarantee does not remove all risk. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

30. Urgency

Use an actual deadline or capacity limit with a reason; avoid fabricated FOMO. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

31. Future pacing

Invite the viewer to imagine implementation while preserving uncertainty and effort. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

32. Call to action

Link to a real tested next step; only claim secure checkout and immediate access when verified. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

33. After purchase

Explain onboarding usefully rather than making nonbuyers feel excluded. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

34. Buyer choice

Replace the source’s shaming take-away close with a clear fit statement and freedom to decline. Declining this offer does not mean someone’s life cannot improve. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

35. Recap

Restate deliverables, terms and next step without introducing new unsupported promises. Use the original template as a planning aid; replace blanks with verified details or leave the claim out of the published sales message.

Apply the direct-marketing teaching frame

Complete original source text

STAR, STORY, SOLUTION

1.- PATTERN INTERRUPT

HEADLINE/HOOK

2.CORE DESIRE QUESTIONS

“I have a quick question for you………”

HAVE YOU EVER WANTED TO WORK FROM HOME?

OWN YOUR OWN BUSINESS?

YOU KNOW YOU WANT THAT INDEPENDENT LIFESTYLE!

3. AGITATE PAST FAILURES

SO, why haven’t you started yet?

Why did you quit?

When is it your turn?

4. The Big Promise - The ONE THING!

When you watch this video to the end, you will discover…..

5. “THE STAR” (The Leader, The Reluctant Hero, The Adventurer, The Reporter)

“Hi, I am Eric and a few years ago I was just like you...sitting in that chair…wondering…

6. HIGH DRAMA

START YOUR STORY IN THE MIDDLE OF THE ACTION!

I opened my mailbox to find a stack of bills. The power bill, overdue. The rent, due next week. I sat down to check my bank account and credit card balances, hoping for a miracle. My heart sank.

7. Backstory WALL

As a single dad, every day was a struggle to make ends meet. I thought affiliate marketing on ClickBank.com would be my ticket out. Each night, after putting my daughter to bed, I'd sit at the computer, buying courses and internet tools on my credit cards, convinced the next one would be the key to success.

But weeks turned into months, and the money wasn't coming in. My inbox was filled with promises of easy money, each one requiring just one more purchase. I was drowning in a sea of debt, but I kept telling myself I was one course away from turning it all around.

Then one day, I opened my mailbox to find a stack of bills. The power bill, overdue. The rent, due next week. I sat down to check my bank account and credit card balances, hoping for a miracle. My heart sank. Every card was maxed out.

I stared at the numbers, feeling a knot in my stomach tighten. There was no money left. No way to pay the rent. The realization hit me hard: I'd been chasing a dream, and now I was out of time and options.

I had no idea what to do next.

8. IDENTIFY THE PROBLEM

“The problem I had was_______________________________”

9.EPIPHANY OR DECLARATION OF INDEPENDENCE

And, at that moment was when it hit me, that BIG AH HAH MOMENT

IT HIT ME SO HARD I HAD TO CHANGE TODAY

10.YOUR PATH TO FINDING THE ULTIMATE SOLUTION

So, First I tried ___________________________________

Then I tried __________________________________, and things got a little better……..success.

11. FIRST SIGN OF SUCCESS

And, So I finally tried ____________________and guess what? THIS TIME IT ALL WORKED!!!

12. CONSPIRACY

And I realized it wasn’t even my fault! It was because _______________________ its no wonder I struggled so long!

13. THE BIG LIE

For years I had been told ________________________, and when I figured out that it wasn’t true that was when I was finally able to break out of their oversight and get the results I was working for!

14. COMMON ENEMY

The real problem is ____________________________, they were the ones keeping me from________________

15. RAPID GROWTH

Once I Realized ______________________, that's when I started to ______________________very fast!

16.) CASE STUDIES

But it hasn’t been just me, take a look at what it has done for others!

17. HIDDEN BENEFITS

I didn;t realize that once I started that not only does it ___________________________, but it also______________, _____________________ and __________________________!

18.) FORMAL INTRODUCTION (INTRODUCE PRODUCT)

And that is why I created _______________________________!!!

19. PAIN AND COST

THIS TOOK (TIME)__________________TO CREATE, AND COST ME _______________________. But it has all really been worth it!!

20. EASE

IT MAKES _______________________SO MUCH EASIER!

21. SPEED

WHAT USED TO TAKE ME (TIME)________________________, I NOW GET DONE_________________(TIME)

22. “SO” Benefits”

“Burns fat while you sleep, So ______________________

Builds your email list on Autopilot, So ________________________

23. SOCIAL PROOF

But don’t take my word for it. Here's what others are saying about it!!

“This _______________saves me time and effort every day!! I Love how it _______________ and _________________!!

24. MAKE THE OFFER

But before we get started, let me ask you a question…..

Would you like to get access to ______________________?

For less than a meal for 2, you can get access to everything inside of _________________

Now, while it would be impossible to show you all the benefits of _________________, I want to show you some of the things that you’ll experience as soon as you are on the inside!

25. BUILD VALUE (ad BONUSES!)

PLUS, you’ll get ________________, _________________ and ___________________

26. PRICE ANCHOR

THE TOTAL VALUE OF ALL OF THIS IS _________________________ BECAUSE_______________

27. EMOTIONAL CLOSE (IF/ALL)

“If all this did is give you the house of your dreams, would it be worth it?

(TOWARDS THEIR EMOTIONS)

“If all this did was let you quit your job, would it be worth it?

(Away from the pain)

28. REVEAL THE REAL PRICE

I’m not going to charge you $_____________I’m only going to charge you $_____________!!

29. GUARANTEE (LOGIC)

I’m going to take all of the risk out of this and give you my (CRAZY NAME) _______________________GUARENTEE!!

30. FOMO (Fear Of Missing Out)

“But you must act now because ______________________________

31. FUTURE PACING

Just imagine what your life will be like when _______________________

32. CALL TO ACTION

33. POST SELLING (Give your reader/buyer feel left behind if they don’t take action now!)

“For those of you who are already signed up, this is what will happen next!”

34. TAKE AWAY SELLING (EXPLAIN THEY NEED TO DECIDE FOR THEM, IT DOESN’T AFFECT YOU!)

You see……it doesn’t matter to me if you sign up right now or not…

I will still keep going about my daily business, hitting my goals, paying my bills

However, if you don’t take this offer you will still have all of your original pains, nothing will change

I know it may sound harsh, but I think you would agree with me when you look in the mirror.

35. CLOSE WITH REMINDER

Remember, you get ________________________ (OFFER RECAP)

Native Google Doc text and original links

STAR, STORY, SOLUTION

1.- PATTERN INTERRUPT
HEADLINE/HOOK
2.CORE DESIRE QUESTIONS
“I have a quick question for you………”
HAVE YOU EVER WANTED TO WORK FROM HOME?
OWN YOUR OWN BUSINESS?
YOU KNOW YOU WANT THAT INDEPENDENT LIFESTYLE!
3. AGITATE PAST FAILURES
SO, why haven’t you started yet?
Why did you quit?
When is it your turn?
4. The Big Promise - The ONE THING!
When you watch this video to the end, you will discover…..
5. “THE STAR” (The Leader, The Reluctant Hero, The Adventurer, The Reporter)
“Hi, I am Eric and a few years ago I was just like you...sitting in that chair…wondering…
6. HIGH DRAMA
START YOUR STORY IN THE MIDDLE OF THE ACTION!
I opened my mailbox to find a stack of bills. The power bill, overdue. The rent, due next week. I sat down to check my bank account and credit card balances, hoping for a miracle. My heart sank.
7. Backstory WALL
As a single dad, every day was a struggle to make ends meet. I thought affiliate marketing on ClickBank.com would be my ticket out. Each night, after putting my daughter to bed, I'd sit at the computer, buying courses and internet tools on my credit cards, convinced the next one would be the key to success.
But weeks turned into months, and the money wasn't coming in. My inbox was filled with promises of easy money, each one requiring just one more purchase. I was drowning in a sea of debt, but I kept telling myself I was one course away from turning it all around.
Then one day, I opened my mailbox to find a stack of bills. The power bill, overdue. The rent, due next week. I sat down to check my bank account and credit card balances, hoping for a miracle. My heart sank. Every card was maxed out.
I stared at the numbers, feeling a knot in my stomach tighten. There was no money left. No way to pay the rent. The realization hit me hard: I'd been chasing a dream, and now I was out of time and options.
I had no idea what to do next.
8. IDENTIFY THE PROBLEM
“The problem I had was_______________________________”
9.EPIPHANY OR DECLARATION OF INDEPENDENCE
And, at that moment was when it hit me, that BIG AH HAH MOMENT
IT HIT ME SO HARD I HAD TO CHANGE TODAY
10.YOUR PATH TO FINDING THE ULTIMATE SOLUTION
So, First I tried ___________________________________
Then I tried __________________________________, and things got a little better……..success.
11. FIRST SIGN OF SUCCESS

And, So I finally tried ____________________and guess what? THIS TIME IT ALL WORKED!!!

12. CONSPIRACY
And I realized it wasn’t even my fault! It was because _______________________ its no wonder I struggled so long!

13. THE BIG LIE

14. COMMON ENEMY
The real problem is ____________________________, they were the ones keeping me from________________

15. RAPID GROWTH

Once I Realized ______________________, that's when I started to ______________________very fast!

16.) CASE STUDIES

But it hasn’t been just me, take a look at what it has done for others!

17. HIDDEN BENEFITS

I didn;t realize that once I started that not only does it ___________________________, but it also______________, _____________________ and __________________________!

18.) FORMAL INTRODUCTION (INTRODUCE PRODUCT)

And that is why I created _______________________________!!!

19. PAIN AND COST

THIS TOOK (TIME)__________________TO CREATE, AND COST ME _______________________. But it has all really been worth it!!

20. EASE

IT MAKES _______________________SO MUCH EASIER!

21. SPEED

WHAT USED TO TAKE ME (TIME)________________________, I NOW GET DONE_________________(TIME)

22. “SO” Benefits”

“Burns fat while you sleep, So ______________________
Builds your email list on Autopilot, So ________________________

23. SOCIAL PROOF

But don’t take my word for it. Here's what others are saying about it!!
“This _______________saves me time and effort every day!! I Love how it _______________ and _________________!!

24. MAKE THE OFFER

But before we get started, let me ask you a question…..
Would you like to get access to ______________________?
For less than a meal for 2, you can get access to everything inside of _________________

Now, while it would be impossible to show you all the benefits of _________________, I want to show you some of the things that you’ll experience as soon as you are on the inside!

25. BUILD VALUE (ad BONUSES!)

PLUS, you’ll get ________________, _________________ and ___________________

26. PRICE ANCHOR

THE TOTAL VALUE OF ALL OF THIS IS _________________________ BECAUSE_______________

27. EMOTIONAL CLOSE (IF/ALL)

“If all this did is give you the house of your dreams, would it be worth it?
(TOWARDS THEIR EMOTIONS)
“If all this did was let you quit your job, would it be worth it?
(Away from the pain)

28. REVEAL THE REAL PRICE

I’m not going to charge you $_____________I’m only going to charge you $_____________!!

29. GUARANTEE (LOGIC)
I’m going to take all of the risk out of this and give you my (CRAZY NAME) _______________________GUARENTEE!!

30. FOMO (Fear Of Missing Out)
“But you must act now because ______________________________

31. FUTURE PACING

Just imagine what your life will be like when _______________________

32. CALL TO ACTION

So, click the button below right now, and you will be taken to a secure order form. After you put in your credit card information you’ll be taken to a secure members area where you can download _______________, even if it’s 2:00 in the morning!
33. POST SELLING (Give your reader/buyer feel left behind if they don’t take action now!)
“For those of you who are already signed up, this is what will happen next!”

34. TAKE AWAY SELLING (EXPLAIN THEY NEED TO DECIDE FOR THEM, IT DOESN’T AFFECT YOU!)

You see……it doesn’t matter to me if you sign up right now or not…
I will still keep going about my daily business, hitting my goals, paying my bills
However, if you don’t take this offer you will still have all of your original pains, nothing will change
I know it may sound harsh, but I think you would agree with me when you look in the mirror.
35. CLOSE WITH REMINDER
Remember, you get ________________________ (OFFER RECAP)

Supabase-C7-Schema.md

Read this schema as a proposal

The document describes eight core deliverable tables and a ninth optional time-entry table, plus three functions and five indexes. It supplies no executable migration or implemented access policy. Its claims that RLS is enabled and migration is reversible are not deployment evidence. Dropping populated tables loses data and may affect dependencies; a tested backup and rollback plan is required before a real migration. No schema or database is changed by this lesson.

c7_distinction_statements — fields 1–4

id is uuid: Primary key. user_id is uuid: Foreign key to users. cohort_id is uuid: Foreign key to cohorts. submitted_at is timestamptz: Submission timestamp. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_distinction_statements — fields 5–8

document_path is text: Path to the markdown distinction statement. three_customer_test_answer is text: YES / NO. three_customer_test_explanation is text: Operator's reasoning. identified_failure_mode is text: iteration_loop / pivot_disguised_as_architecture / mixed. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_distinction_statements — fields 9–12

cohort_partner_id is uuid: Foreign key to users; cohort partner reviewer. cohort_partner_signoff_at is timestamptz: Partner sign-off timestamp. cohort_partner_notes is text: Partner's flagged items. reviewer_status is text: PENDING / APPROVED / NEEDS_REVISION. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_distinction_statements — fields 13–14

reviewer_findings is jsonb: Structured reviewer output (cohort partner notes). reviewed_at is timestamptz: Review timestamp. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_deliverable_decompositions — fields 1–4

c7_deliverable_decompositions — fields 5–8

document_path is text: Path to the markdown decomposition. deliverables_data is jsonb: Structured deliverable inventory (D-01 through D-XX). total_deliverable_count is integer: Should be in 16-40 range. lifecycle_phase_count is integer: Number of phases identified. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_deliverable_decompositions — fields 9–12

cohort_variant is text: none / standard / standard_with_solo_variant. six_percent_rule_candidates is jsonb: Identified high-leverage standardization candidates. sonnet_reviewer_status is text: PENDING / APPROVED / NEEDS_REVISION. sonnet_reviewer_findings is jsonb: Structured reviewer JSON output. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_deliverable_decompositions — fields 13–13

reviewed_at is timestamptz: Sonnet reviewer timestamp. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_fulfillment_sops — fields 1–4

id is uuid: Primary key. user_id is uuid: Foreign key to users. cohort_id is uuid: Foreign key to cohorts. sop_id_internal is text: Operator's internal SOP ID (SOP-01, SOP-02, ...). These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_fulfillment_sops — fields 5–8

sop_name is text: SOP title. version is text: v1.0, v1.1, etc.. deliverable_id_internal is text: Tied to M7.2 deliverable ID (D-XX). audience is text: operator_only / operator_and_assistant / contractor. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_fulfillment_sops — fields 9–12

expected_execution_time_minutes is integer: Time per execution. document_path is text: Path to the markdown SOP. sop_data is jsonb: Structured SOP content (steps, inputs, outputs, failure modes). six_percent_high_leverage is boolean: Is this one of the 1-2 high-leverage standardizations. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_fulfillment_sops — fields 13–16

sonnet_reviewer_status is text: PENDING / APPROVED / NEEDS_REVISION. sonnet_reviewer_findings is jsonb: Structured reviewer output. submitted_at is timestamptz: the source supplies no further rule. reviewed_at is timestamptz: the source supplies no further rule. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_customer_lifecycle_maps — fields 1–4

c7_customer_lifecycle_maps — fields 5–8

document_path is text: Path to the markdown lifecycle map. stages_data is jsonb: Structured stage details (entry, exit, deliverables, gates). total_stage_count is integer: Should be 5-8. total_gate_count is integer: One less than stage count, plus exit. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_customer_lifecycle_maps — fields 9–12

total_touchpoint_count is integer: Aggregated from M7.4 Section 7. off_path_scenarios_data is jsonb: Documented off-path scenarios. mermaid_diagram_present is boolean: Required. sonnet_reviewer_status is text: PENDING / APPROVED / NEEDS_REVISION. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_customer_lifecycle_maps — fields 13–14

sonnet_reviewer_findings is jsonb: Structured reviewer output. reviewed_at is timestamptz: the source supplies no further rule. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_capacity_analyses — fields 1–4

c7_capacity_analyses — fields 5–8

document_path is text: Path to the markdown analysis. bottleneck_activity is text: Synchronous review / deep work / async comm / emotional load / other. bottleneck_activity_other is text: If "other," named here. bottleneck_hours_per_week_available is numeric(5,2): Available hours for the bottleneck. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_capacity_analyses — fields 9–12

bottleneck_hours_per_customer_per_week is numeric(5,2): Per-customer requirement. bottleneck_ceiling is integer: Calculated from bottleneck math. total_hours_ceiling is integer: Calculated from total-hours math. operative_ceiling is integer: LOWER of the two. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_capacity_analyses — fields 13–16

quality_thresholds_data is jsonb: 3-5 named thresholds with values and measurement. cohort_variant_ceiling is integer: If cohort-delivered, total customers under cohort math. anti_promises_data is jsonb: Capacity anti-promises (waitlist, drift trigger, etc.). hitl_instructor_id is uuid: Foreign key to users; instructor reviewer. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_capacity_analyses — fields 17–20

hitl_signoff_at is timestamptz: Instructor sign-off timestamp. hitl_notes is text: Instructor's review notes. sonnet_reviewer_status is text: PENDING / APPROVED / NEEDS_REVISION. sonnet_reviewer_findings is jsonb: Structured reviewer output. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_capacity_analyses — fields 21–21

c7_bandwidth_audits — fields 1–4

id is uuid: Primary key. user_id is uuid: Foreign key to users. cohort_id is uuid: Foreign key to cohorts. measurement_window_start is date: the source supplies no further rule. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_bandwidth_audits — fields 5–8

measurement_window_end is date: the source supplies no further rule. measurement_window_days is integer: Should be ≥ 14. time_tracking_tool is text: toggl / harvest / clockify / other. customers_active_during_window is integer: the source supplies no further rule. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_bandwidth_audits — fields 9–12

total_logged_hours is numeric(7,2): the source supplies no further rule. per_customer_per_week_measured is numeric(5,2): The operative number for M7.5. total_per_customer_full_engagement is numeric(5,2): Full-engagement total. hidden_costs_data is jsonb: Hidden cost breakdown by category. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_bandwidth_audits — fields 13–16

hidden_costs_percentage is numeric(5,2): Hidden costs as % of total. estimate_vs_measured_delta_pct is numeric(5,2): M7.2 estimate vs M7.6 measured. bottleneck_activity_identified is text: Same as M7.5. anomalies_data is jsonb: Documented anomalies. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_bandwidth_audits — fields 17–20

hitl_instructor_id is uuid: Foreign key to users. hitl_signoff_at is timestamptz: the source supplies no further rule. hitl_notes is text: the source supplies no further rule. document_path is text: Path to the markdown audit. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_bandwidth_audits — fields 21–21

submitted_at is timestamptz: the source supplies no further rule. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_offer_v2 — fields 1–4

id is uuid: Primary key. user_id is uuid: Foreign key to users. cohort_id is uuid: Foreign key to cohorts. version is text: v2.0, v2.1, etc.. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_offer_v2 — fields 5–8

predecessor_version is text: v1.1 typically. effective_date is date: When v2.0 supersedes v1.1. mechanism_unchanged_confirmed is boolean: Anti-pivot statement confirmed. customer_unchanged_confirmed is boolean: Anti-pivot statement confirmed. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_offer_v2 — fields 9–12

problem_unchanged_confirmed is boolean: Anti-pivot statement confirmed. stated_capacity_ceiling is integer: Should match c7_capacity_analyses.operative_ceiling. anti_promises_outcome_count is integer: At least 3. anti_promises_scope_count is integer: At least 3. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_offer_v2 — fields 13–16

architectural_changes_data is jsonb: List of changes from v1.1 to v2.0. iteration_v2_1_earliest_date is date: At least 60 days post-deployment. iteration_v3_0_earliest_date is date: At least 6 months post-v2.0. cohort_partner_signoff_at is timestamptz: the source supplies no further rule. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_offer_v2 — fields 17–20

instructor_signoff_at is timestamptz: Per M7.5 HITL on capacity statement. sonnet_reviewer_status is text: PENDING / APPROVED / NEEDS_REVISION. sonnet_reviewer_findings is jsonb: Structured reviewer output. document_path is text: Path to the markdown v2.0 document. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_offer_v2 — fields 21–21

c7_offer_architecture_docs — fields 1–4

id is uuid: Primary key. user_id is uuid: Foreign key to users. cohort_id is uuid: Foreign key to cohorts. document_path is text: Path to the markdown capstone document. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_offer_architecture_docs — fields 5–8

document_version is text: v1.0, v1.1 (revision after Opus NEEDS_REVISION). attestation_signed_at is timestamptz: Operator attestation timestamp. attestation_clauses_data is jsonb: Per-clause attestation status. attachment_1_distinction_statement_id is uuid: FK to c7_distinction_statements. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_offer_architecture_docs — fields 9–12

attachment_2_decomposition_id is uuid: FK to c7_deliverable_decompositions. attachment_3_sop_library is jsonb: Array of FKs to c7_fulfillment_sops. attachment_4_lifecycle_map_id is uuid: FK to c7_customer_lifecycle_maps. attachment_5_capacity_analysis_id is uuid: FK to c7_capacity_analyses (with HITL clearance). These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_offer_architecture_docs — fields 13–16

attachment_6_bandwidth_audit_id is uuid: FK to c7_bandwidth_audits (with HITL clearance). attachment_7_offer_v2_id is uuid: FK to c7_offer_v2 (with sign-offs). internal_consistency_check_clean is boolean: Operator self-check Section 9. bespoke_self_check_indicators_fired is integer: Operator self-check Section 10. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_offer_architecture_docs — fields 17–20

opus_validator_status is text: PENDING / VALIDATED / NEEDS_REVISION / REJECTED. opus_validator_findings is jsonb: Full validator JSON output. opus_validator_at is timestamptz: the source supplies no further rule. opus_validator_revision_count is integer: Number of times revised after NEEDS_REVISION. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_offer_architecture_docs — fields 21–24

instructor_cosign_id is uuid: FK to users. instructor_cosign_at is timestamptz: Final co-sign timestamp. instructor_cosign_notes is text: the source supplies no further rule. c8_enrollment_authorized is boolean: Set true when Opus VALIDATED + instructor co-sign clear. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_offer_architecture_docs — fields 25–26

c8_enrollment_authorized_at is timestamptz: the source supplies no further rule. submitted_at is timestamptz: the source supplies no further rule. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_time_tracking_entries — fields 1–4

id is uuid: Primary key. audit_id is uuid: FK to c7_bandwidth_audits. user_id is uuid: Foreign key to users. customer_code is text: C-01, C-02, ..., or INTERNAL. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_time_tracking_entries — fields 5–8

deliverable_id_internal is text: D-XX, or category (ADMIN, FOLLOWUP, COMM, REWORK, SCOPE-CREEP). lifecycle_stage is text: L1-PRESALE, L2-ENROLL, L3-ONBOARD, L4-CORE, L5-MIDCHECK, L6-DEBRIEF, L7-POSTENG. entry_date is date: the source supplies no further rule. duration_minutes is integer: the source supplies no further rule. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

c7_time_tracking_entries — fields 9–9

description is text: Optional. These are intended field meanings. Implement required types, nullability, bounds and relationship checks explicitly; descriptive notes do not enforce constraints. Keep student-authored evidence separate from protected reviewer decisions.

Bind evidence to the same learner cohort and version

The distinction statement supports the three-customer test; decomposition maps deliverables; SOP rows build a library; lifecycle describes stages and gates; capacity chooses the lower ceiling; bandwidth supplies measured time; offer v2 records continuity and sign-offs; the capstone links all seven attachments. The optional time entries retain customer/category/stage/date/duration. Ensure every attached record belongs to the same learner, cohort and reviewed version. An array described as foreign keys inside JSON is not automatically enforced as relational foreign keys. Counts such as 16–40 deliverables, 5–8 stages, 3–5 quality measures and at least fourteen measured days need explicit policies and approved exceptions.

Make the enrollment gate precise

check_c7_enrollment_eligible proposes validated C6 attestation, instructor co-sign, at least one paying engagement that is neither cancelled nor pre-engagement, and C6 completion within the past fourteen days. Define timestamps, timezone, inclusive boundaries, permitted engagement states and what happens after that window expires. Bind the query to the authorized caller and relevant cohort. A paying label alone does not demonstrate collected revenue or successful delivery.

Make completion and progression idempotent

check_c7_completion requires eight approved artifact groups, a target number of approved SOPs (typically eight-to-fifteen), human capacity/bandwidth approvals, partner and instructor offer sign-offs, and final C8 authorization. Define the target and current version rather than counting any historical approvals. update_stage_2_progress must only process a real authorization transition once; repeated updates must not increment artifact counts repeatedly. The source equates C8 enrollment with Stage 2-to-3 eligibility, but C8 is still within Stage 2 in the build references. Separate these gates and define revocation handling and audit history.

Protect approval columns and reviewer access

An own-row UPDATE policy cannot by itself stop a learner from editing reviewer statuses, signatures, self-check flags or c8_enrollment_authorized on that row. Restrict those columns or use separate review tables and trusted operations. Instructor cohort access and invited-partner access need validated membership and invitation checks. The source calls service-role bypass SELECT access, but bypassing RLS does not itself impose read-only privileges. Use limited grants and server-side credential handling; never expose administrative keys to learners. Test allowed and denied operations for each role.

Validate indexes and migration dependencies

The five proposed indexes cover capstone user/status/authorization; capacity user/signoff; bandwidth user/window end; SOP user/status; and time entries audit/customer. Confirm actual query patterns and constraints before accepting them. Migration order follows stable C6, creates tables/functions, extends progress and applies policies; the final “backfill” note says existing C6 records already exist and does not specify copying. Document what is actually required, including optional-table installation and rollback effects.

Apply the direct-marketing teaching frame

Complete original source text

# Supabase C7 Schema

**Course:** C7 Offer Architecture
**Type:** Database schema documentation
**Database:** Supabase (PostgreSQL)

---

## Purpose

Document the Supabase tables, functions, and access patterns that support C7 module submissions and validation. This schema extends the RISER Maritime Academy core schema (cohorts, users, progress tracking) and the C6 schema (customers, feedback loops, iteration logs). C7 adds eight new tables for the M7.1-M7.8 deliverables and three new functions for cross-document validation, completion gating, and Stage 2 progress tracking.

---

## Tables

### c7_distinction_statements

Stores M7.1 Document vs Architecture Distinction Statement submissions.

| Column | Type | Notes |
|--------|------|-------|
| id | uuid | Primary key |
| user_id | uuid | Foreign key to users |
| cohort_id | uuid | Foreign key to cohorts |
| submitted_at | timestamptz | Submission timestamp |
| document_path | text | Path to the markdown distinction statement |
| three_customer_test_answer | text | YES / NO |
| three_customer_test_explanation | text | Operator's reasoning |
| identified_failure_mode | text | iteration_loop / pivot_disguised_as_architecture / mixed |
| cohort_partner_id | uuid | Foreign key to users; cohort partner reviewer |
| cohort_partner_signoff_at | timestamptz | Partner sign-off timestamp |
| cohort_partner_notes | text | Partner's flagged items |
| reviewer_status | text | PENDING / APPROVED / NEEDS_REVISION |
| reviewer_findings | jsonb | Structured reviewer output (cohort partner notes) |
| reviewed_at | timestamptz | Review timestamp |

### c7_deliverable_decompositions

Stores M7.2 Deliverable Decomposition submissions.

| Column | Type | Notes |
|--------|------|-------|
| id | uuid | Primary key |
| user_id | uuid | Foreign key to users |
| cohort_id | uuid | Foreign key to cohorts |
| submitted_at | timestamptz | Submission timestamp |
| document_path | text | Path to the markdown decomposition |
| deliverables_data | jsonb | Structured deliverable inventory (D-01 through D-XX) |
| total_deliverable_count | integer | Should be in 16-40 range |
| lifecycle_phase_count | integer | Number of phases identified |
| cohort_variant | text | none / standard / standard_with_solo_variant |
| six_percent_rule_candidates | jsonb | Identified high-leverage standardization candidates |
| sonnet_reviewer_status | text | PENDING / APPROVED / NEEDS_REVISION |
| sonnet_reviewer_findings | jsonb | Structured reviewer JSON output |
| reviewed_at | timestamptz | Sonnet reviewer timestamp |

### c7_fulfillment_sops

Stores M7.3 Fulfillment SOP submissions. Each row is one SOP; an operator's library is multiple rows tied to the same user_id.

| Column | Type | Notes |
|--------|------|-------|
| id | uuid | Primary key |
| user_id | uuid | Foreign key to users |
| cohort_id | uuid | Foreign key to cohorts |
| sop_id_internal | text | Operator's internal SOP ID (SOP-01, SOP-02, ...) |
| sop_name | text | SOP title |
| version | text | v1.0, v1.1, etc. |
| deliverable_id_internal | text | Tied to M7.2 deliverable ID (D-XX) |
| audience | text | operator_only / operator_and_assistant / contractor |
| expected_execution_time_minutes | integer | Time per execution |
| document_path | text | Path to the markdown SOP |
| sop_data | jsonb | Structured SOP content (steps, inputs, outputs, failure modes) |
| six_percent_high_leverage | boolean | Is this one of the 1-2 high-leverage standardizations |
| sonnet_reviewer_status | text | PENDING / APPROVED / NEEDS_REVISION |
| sonnet_reviewer_findings | jsonb | Structured reviewer output |
| submitted_at | timestamptz | |
| reviewed_at | timestamptz | |

### c7_customer_lifecycle_maps

Stores M7.4 Customer Lifecycle Map submissions.

| Column | Type | Notes |
|--------|------|-------|
| id | uuid | Primary key |
| user_id | uuid | Foreign key to users |
| cohort_id | uuid | Foreign key to cohorts |
| submitted_at | timestamptz | Submission timestamp |
| document_path | text | Path to the markdown lifecycle map |
| stages_data | jsonb | Structured stage details (entry, exit, deliverables, gates) |
| total_stage_count | integer | Should be 5-8 |
| total_gate_count | integer | One less than stage count, plus exit |
| total_touchpoint_count | integer | Aggregated from M7.4 Section 7 |
| off_path_scenarios_data | jsonb | Documented off-path scenarios |
| mermaid_diagram_present | boolean | Required |
| sonnet_reviewer_status | text | PENDING / APPROVED / NEEDS_REVISION |
| sonnet_reviewer_findings | jsonb | Structured reviewer output |
| reviewed_at | timestamptz | |

### c7_capacity_analyses

Stores M7.5 Capacity Constraint Analysis submissions. HITL clearance is required before Sonnet review.

| Column | Type | Notes |
|--------|------|-------|
| id | uuid | Primary key |
| user_id | uuid | Foreign key to users |
| cohort_id | uuid | Foreign key to cohorts |
| submitted_at | timestamptz | Submission timestamp |
| document_path | text | Path to the markdown analysis |
| bottleneck_activity | text | Synchronous review / deep work / async comm / emotional load / other |
| bottleneck_activity_other | text | If "other," named here |
| bottleneck_hours_per_week_available | numeric(5,2) | Available hours for the bottleneck |
| bottleneck_hours_per_customer_per_week | numeric(5,2) | Per-customer requirement |
| bottleneck_ceiling | integer | Calculated from bottleneck math |
| total_hours_ceiling | integer | Calculated from total-hours math |
| operative_ceiling | integer | LOWER of the two |
| quality_thresholds_data | jsonb | 3-5 named thresholds with values and measurement |
| cohort_variant_ceiling | integer | If cohort-delivered, total customers under cohort math |
| anti_promises_data | jsonb | Capacity anti-promises (waitlist, drift trigger, etc.) |
| hitl_instructor_id | uuid | Foreign key to users; instructor reviewer |
| hitl_signoff_at | timestamptz | Instructor sign-off timestamp |
| hitl_notes | text | Instructor's review notes |
| sonnet_reviewer_status | text | PENDING / APPROVED / NEEDS_REVISION |
| sonnet_reviewer_findings | jsonb | Structured reviewer output |
| reviewed_at | timestamptz | Sonnet reviewer timestamp |

### c7_bandwidth_audits

Stores M7.6 Operator Bandwidth Audit submissions. HITL clearance is required (co-reviewed with M7.5).

| Column | Type | Notes |
|--------|------|-------|
| id | uuid | Primary key |
| user_id | uuid | Foreign key to users |
| cohort_id | uuid | Foreign key to cohorts |
| measurement_window_start | date | |
| measurement_window_end | date | |
| measurement_window_days | integer | Should be ≥ 14 |
| time_tracking_tool | text | toggl / harvest / clockify / other |
| customers_active_during_window | integer | |
| total_logged_hours | numeric(7,2) | |
| per_customer_per_week_measured | numeric(5,2) | The operative number for M7.5 |
| total_per_customer_full_engagement | numeric(5,2) | Full-engagement total |
| hidden_costs_data | jsonb | Hidden cost breakdown by category |
| hidden_costs_percentage | numeric(5,2) | Hidden costs as % of total |
| estimate_vs_measured_delta_pct | numeric(5,2) | M7.2 estimate vs M7.6 measured |
| bottleneck_activity_identified | text | Same as M7.5 |
| anomalies_data | jsonb | Documented anomalies |
| hitl_instructor_id | uuid | Foreign key to users |
| hitl_signoff_at | timestamptz | |
| hitl_notes | text | |
| document_path | text | Path to the markdown audit |
| submitted_at | timestamptz | |

### c7_offer_v2

Stores M7.7 Offer v2.0 Document submissions.

| Column | Type | Notes |
|--------|------|-------|
| id | uuid | Primary key |
| user_id | uuid | Foreign key to users |
| cohort_id | uuid | Foreign key to cohorts |
| version | text | v2.0, v2.1, etc. |
| predecessor_version | text | v1.1 typically |
| effective_date | date | When v2.0 supersedes v1.1 |
| mechanism_unchanged_confirmed | boolean | Anti-pivot statement confirmed |
| customer_unchanged_confirmed | boolean | Anti-pivot statement confirmed |
| problem_unchanged_confirmed | boolean | Anti-pivot statement confirmed |
| stated_capacity_ceiling | integer | Should match c7_capacity_analyses.operative_ceiling |
| anti_promises_outcome_count | integer | At least 3 |
| anti_promises_scope_count | integer | At least 3 |
| architectural_changes_data | jsonb | List of changes from v1.1 to v2.0 |
| iteration_v2_1_earliest_date | date | At least 60 days post-deployment |
| iteration_v3_0_earliest_date | date | At least 6 months post-v2.0 |
| cohort_partner_signoff_at | timestamptz | |
| instructor_signoff_at | timestamptz | Per M7.5 HITL on capacity statement |
| sonnet_reviewer_status | text | PENDING / APPROVED / NEEDS_REVISION |
| sonnet_reviewer_findings | jsonb | Structured reviewer output |
| document_path | text | Path to the markdown v2.0 document |
| submitted_at | timestamptz | |

### c7_offer_architecture_docs

Stores M7.8 Offer Architecture Document submissions. Opus 4.7 validator + instructor co-sign required.

| Column | Type | Notes |
|--------|------|-------|
| id | uuid | Primary key |
| user_id | uuid | Foreign key to users |
| cohort_id | uuid | Foreign key to cohorts |
| document_path | text | Path to the markdown capstone document |
| document_version | text | v1.0, v1.1 (revision after Opus NEEDS_REVISION) |
| attestation_signed_at | timestamptz | Operator attestation timestamp |
| attestation_clauses_data | jsonb | Per-clause attestation status |
| attachment_1_distinction_statement_id | uuid | FK to c7_distinction_statements |
| attachment_2_decomposition_id | uuid | FK to c7_deliverable_decompositions |
| attachment_3_sop_library | jsonb | Array of FKs to c7_fulfillment_sops |
| attachment_4_lifecycle_map_id | uuid | FK to c7_customer_lifecycle_maps |
| attachment_5_capacity_analysis_id | uuid | FK to c7_capacity_analyses (with HITL clearance) |
| attachment_6_bandwidth_audit_id | uuid | FK to c7_bandwidth_audits (with HITL clearance) |
| attachment_7_offer_v2_id | uuid | FK to c7_offer_v2 (with sign-offs) |
| internal_consistency_check_clean | boolean | Operator self-check Section 9 |
| bespoke_self_check_indicators_fired | integer | Operator self-check Section 10 |
| opus_validator_status | text | PENDING / VALIDATED / NEEDS_REVISION / REJECTED |
| opus_validator_findings | jsonb | Full validator JSON output |
| opus_validator_at | timestamptz | |
| opus_validator_revision_count | integer | Number of times revised after NEEDS_REVISION |
| instructor_cosign_id | uuid | FK to users |
| instructor_cosign_at | timestamptz | Final co-sign timestamp |
| instructor_cosign_notes | text | |
| c8_enrollment_authorized | boolean | Set true when Opus VALIDATED + instructor co-sign clear |
| c8_enrollment_authorized_at | timestamptz | |
| submitted_at | timestamptz | |

### c7_time_tracking_entries

(Optional supporting table) Stores time-tracking entries for the M7.6 measurement window. Most operators will use their external time-tracking tool (Toggl, Harvest, Clockify) as the source of truth, but the audit summary lands here for the schema's records.

| Column | Type | Notes |
|--------|------|-------|
| id | uuid | Primary key |
| audit_id | uuid | FK to c7_bandwidth_audits |
| user_id | uuid | Foreign key to users |
| customer_code | text | C-01, C-02, ..., or INTERNAL |
| deliverable_id_internal | text | D-XX, or category (ADMIN, FOLLOWUP, COMM, REWORK, SCOPE-CREEP) |
| lifecycle_stage | text | L1-PRESALE, L2-ENROLL, L3-ONBOARD, L4-CORE, L5-MIDCHECK, L6-DEBRIEF, L7-POSTENG |
| entry_date | date | |
| duration_minutes | integer | |
| description | text | Optional |

This table is populated by an export from the operator's external time-tracking tool, run at the end of the measurement window.

---

## Functions

### check_c7_enrollment_eligible(user_id uuid) RETURNS boolean

Returns TRUE if the user is eligible for C7 enrollment. Required predicates:

- C6 Sailboat Ready Attestation has VALIDATED status in c6_sailboat_attestations
- C6 instructor co-sign is documented
- User has at least 1 paying customer engagement (per c6_customers, engagement_type = 'paying', status NOT IN ('cancelled', 'pre-engagement'))
- User has completed C6 in the past 14 days (calendar gating to ensure the operator is in the right cadence)

Used by the cohort-management UI to gate enrollment.

### check_c7_completion(user_id uuid) RETURNS boolean

Returns TRUE if the user has completed C7. Required predicates:

- c7_distinction_statements has APPROVED entry for user_id
- c7_deliverable_decompositions has APPROVED entry
- c7_fulfillment_sops has at least N APPROVED entries (where N is operator-target, typically 8-15)
- c7_customer_lifecycle_maps has APPROVED entry
- c7_capacity_analyses has APPROVED entry with HITL signoff
- c7_bandwidth_audits has entry with HITL signoff
- c7_offer_v2 has APPROVED entry with cohort_partner_signoff and instructor_signoff
- c7_offer_architecture_docs has c8_enrollment_authorized = TRUE

Used to gate C8 enrollment. Returns TRUE only when all eight conditions clear.

### update_stage_2_progress(user_id uuid)

Trigger function. Fires on update to c7_offer_architecture_docs.c8_enrollment_authorized. When set to TRUE, updates the user's stage_2_progress record:

- stage_2_status changes to 'sailboat_architected'
- stage_2_artifact_count increments
- Stage 2 → Stage 3 transition eligibility is set TRUE (C8 enrollment opens)

Logs the transition in stage_2_progress_history.

---

## Indexes

For query performance:

- c7_offer_architecture_docs(user_id, opus_validator_status, c8_enrollment_authorized)
- c7_capacity_analyses(user_id, hitl_signoff_at)
- c7_bandwidth_audits(user_id, measurement_window_end)
- c7_fulfillment_sops(user_id, sonnet_reviewer_status)
- c7_time_tracking_entries(audit_id, customer_code)

---

## Row-Level Security (RLS)

All c7_* tables have RLS enabled with the same patterns as c6_*:

- Users can SELECT/INSERT/UPDATE their own rows (where user_id = auth.uid())
- Cohort instructors can SELECT all rows for their cohort
- Cohort partners can SELECT specific peer rows when invited (managed via cohort_partner_invitations table from C5)
- Anthropic Sonnet/Opus reviewer service accounts have SELECT access via service-role bypass

---

## Migration Notes

C7 schema deploys after C6 deployment is stable. The migration:

1. Creates the eight new c7_* tables
2. Creates the three new functions
3. Adds Stage 2 transition extension to existing stage_2_progress
4. Adds RLS policies
5. Backfills any in-flight customer engagements from c6_customers (no schema migration needed; data already in c6 schema)

Migration is reversible. C7 tables can be dropped without affecting C6 schema.

---

*This schema document is referenced in the C7 Course README, in the C7 Module Map (which artifacts land where), and in the cohort-management application that gates enrollment.*

The "Problem-Agitate-Solution" (PAS) Formula

1. Problem

Name the buyer’s actual difficulty and context. This source expands the three-part PAS idea into a nine-step sales message. Tailor and test the complete message against customer evidence; the formula alone does not guarantee conversion.

2. Agitation

Explain supported consequences without exaggerating fear or exploiting insecurity. This source expands the three-part PAS idea into a nine-step sales message. Tailor and test the complete message against customer evidence; the formula alone does not guarantee conversion.

3. Solution

Explain the relevant mechanism and limits. This source expands the three-part PAS idea into a nine-step sales message. Tailor and test the complete message against customer evidence; the formula alone does not guarantee conversion.

4. Features and benefits

Connect each feature to a need; comparative superiority requires evidence. This source expands the three-part PAS idea into a nine-step sales message. Tailor and test the complete message against customer evidence; the formula alone does not guarantee conversion.

5. Social proof

Use authentic, appropriately permitted examples with context. This source expands the three-part PAS idea into a nine-step sales message. Tailor and test the complete message against customer evidence; the formula alone does not guarantee conversion.

6. Offer

State scope, total price, payment options and useful bonuses; scarcity must be real. This source expands the three-part PAS idea into a nine-step sales message. Tailor and test the complete message against customer evidence; the formula alone does not guarantee conversion.

7. Risk reversal

Explain the remedy and conditions instead of saying every risk disappears. This source expands the three-part PAS idea into a nine-step sales message. Tailor and test the complete message against customer evidence; the formula alone does not guarantee conversion.

8. Call to action

Give one clear, available next step and its commitment. This source expands the three-part PAS idea into a nine-step sales message. Tailor and test the complete message against customer evidence; the formula alone does not guarantee conversion.

9. Closing

Recap the useful outcome and terms, thank the reader and preserve the choice to decline. This source expands the three-part PAS idea into a nine-step sales message. Tailor and test the complete message against customer evidence; the formula alone does not guarantee conversion.

Apply the direct-marketing teaching frame

Complete original source text

The "Problem-Agitate-Solution" (PAS) Formula

Steps:

1. Problem: Start by identifying and addressing the primary problem or pain point that your target audience is experiencing. Clearly articulate the challenges they face and the negative consequences of not solving these problems. This sets the stage for your solution.

2. Agitation: Dive deeper into the problem and agitate the pain points to intensify the audience's desire for a solution. Use emotional language and vivid imagery to evoke strong feelings of frustration, discomfort, or dissatisfaction. Paint a compelling picture of how their lives could improve if the problem were solved.

3. Solution: Introduce your product or service as the solution to the audience's problems. Highlight the benefits, features, and unique selling points that make your solution stand out. Clearly demonstrate how your offering can alleviate their pain points and fulfill their needs.

4. Features and Benefits: Provide a detailed breakdown of the features and benefits of your product or service. Focus on how each feature addresses a specific pain point or fulfills a desired outcome for the audience. Use persuasive language to emphasize the value proposition and highlight why your solution is superior to alternatives.

5. Social Proof: Incorporate testimonials, case studies, reviews, or endorsements from satisfied customers to build credibility and trust. Show real-life examples of how others have benefited from your product or service, providing evidence of its effectiveness and reliability.

6. Offer: Present your offer clearly and concisely, including pricing, payment options, and any bonuses or incentives. Create a sense of urgency or scarcity to motivate immediate action, such as limited-time discounts or exclusive bonuses for early adopters.

7. Risk Reversal: Offer a strong guarantee or risk-reversal policy to reassure potential customers and alleviate any concerns or objections they may have. This could include a money-back guarantee, satisfaction guarantee, or free trial period to remove the perceived risk of making a purchase.

8. Call to Action (CTA): Clearly instruct the audience on the next steps to take, such as clicking a button to make a purchase, signing up for a free trial, or contacting your sales team for more information. Use persuasive language and compelling visuals to encourage action.

9. Closing: Summarize the key points of your offer and reiterate the benefits of taking action. Encourage the audience to act now before the opportunity is lost. Thank them for their time and express confidence in the value and effectiveness of your solution.

By following the PAS formula, you can create a persuasive and compelling sales message that resonates with your target audience, addresses their pain points, and motivates them to take action. Tailor your messaging to the specific needs, desires, and preferences of your audience, and continuously test and optimize your sales letter or landing page for maximum effectiveness.

Native Google Doc text and original links

The "Problem-Agitate-Solution" (PAS) Formula
Steps:
Problem: Start by identifying and addressing the primary problem or pain point that your target audience is experiencing. Clearly articulate the challenges they face and the negative consequences of not solving these problems. This sets the stage for your solution.
Agitation: Dive deeper into the problem and agitate the pain points to intensify the audience's desire for a solution. Use emotional language and vivid imagery to evoke strong feelings of frustration, discomfort, or dissatisfaction. Paint a compelling picture of how their lives could improve if the problem were solved.
Solution: Introduce your product or service as the solution to the audience's problems. Highlight the benefits, features, and unique selling points that make your solution stand out. Clearly demonstrate how your offering can alleviate their pain points and fulfill their needs.
Features and Benefits: Provide a detailed breakdown of the features and benefits of your product or service. Focus on how each feature addresses a specific pain point or fulfills a desired outcome for the audience. Use persuasive language to emphasize the value proposition and highlight why your solution is superior to alternatives.
Social Proof: Incorporate testimonials, case studies, reviews, or endorsements from satisfied customers to build credibility and trust. Show real-life examples of how others have benefited from your product or service, providing evidence of its effectiveness and reliability.
Offer: Present your offer clearly and concisely, including pricing, payment options, and any bonuses or incentives. Create a sense of urgency or scarcity to motivate immediate action, such as limited-time discounts or exclusive bonuses for early adopters.
Risk Reversal: Offer a strong guarantee or risk-reversal policy to reassure potential customers and alleviate any concerns or objections they may have. This could include a money-back guarantee, satisfaction guarantee, or free trial period to remove the perceived risk of making a purchase.
Call to Action (CTA): Clearly instruct the audience on the next steps to take, such as clicking a button to make a purchase, signing up for a free trial, or contacting your sales team for more information. Use persuasive language and compelling visuals to encourage action.
Closing: Summarize the key points of your offer and reiterate the benefits of taking action. Encourage the audience to act now before the opportunity is lost. Thank them for their time and express confidence in the value and effectiveness of your solution.
By following the PAS formula, you can create a persuasive and compelling sales message that resonates with your target audience, addresses their pain points, and motivates them to take action. Tailor your messaging to the specific needs, desires, and preferences of your audience, and continuously test and optimize your sales letter or landing page for maximum effectiveness.

The "Star, Story, Solution" Method

1. Star

Introduce a relevant person and situation. Identify a fictional persona as illustrative. This ten-step source is an expanded Star, Story, Solution framework. Keep its source version distinct from the separate thirty-five-step script.

2. Story

Describe the journey with honest context; a fictional story must not masquerade as a testimonial. This ten-step source is an expanded Star, Story, Solution framework. Keep its source version distinct from the separate thirty-five-step script.

3. Solution

Demonstrate how the offer helps and what remains uncertain. This ten-step source is an expanded Star, Story, Solution framework. Keep its source version distinct from the separate thirty-five-step script.

4. Objections

Answer real questions with evidence and limitations. This ten-step source is an expanded Star, Story, Solution framework. Keep its source version distinct from the separate thirty-five-step script.

5. Call to action

Offer a clear next step appropriate to readiness. This ten-step source is an expanded Star, Story, Solution framework. Keep its source version distinct from the separate thirty-five-step script.

6. Bonuses

Include useful, deliverable support rather than cosmetic stack size. This ten-step source is an expanded Star, Story, Solution framework. Keep its source version distinct from the separate thirty-five-step script.

7. Risk reversal

State actual guarantee or trial terms; trying it may still require time, effort or expense. This ten-step source is an expanded Star, Story, Solution framework. Keep its source version distinct from the separate thirty-five-step script.

8. Urgency

Use real, consistently applied limits rather than resetting timers. This ten-step source is an expanded Star, Story, Solution framework. Keep its source version distinct from the separate thirty-five-step script.

9. Social proof

Use verified customer feedback and results with permission. This ten-step source is an expanded Star, Story, Solution framework. Keep its source version distinct from the separate thirty-five-step script.

10. Closing

Recap scope and next step without suggesting every buyer will undergo the same transformation. This ten-step source is an expanded Star, Story, Solution framework. Keep its source version distinct from the separate thirty-five-step script.

Apply the direct-marketing teaching frame

Complete original source text

The "Star, Story, Solution" Method

Steps:

1. Star: Begin by introducing the main character of your story, also known as the "star." This could be your target customer or a relatable persona who embodies their struggles and desires. Paint a vivid picture of their current situation and the challenges they're facing.

2. Story: Dive into a compelling narrative that resonates with your audience's emotions. Share a personal or relatable story that illustrates the journey from struggle to success. This could be your own story, a customer success story, or a fictional narrative that mirrors your audience's experiences.

3. Solution: Introduce your product or service as the hero of the story—the solution to your audience's problems. Highlight how it has transformed the lives or businesses of the characters in your story. Focus on the benefits and outcomes they can expect from using your offering.

4. Objection Handling: Address common objections or concerns that your audience may have about your product/service. Provide reassurance and counterarguments to overcome their skepticism and build trust.

5. Call to Action: Clearly articulate the next steps for the reader to take, whether it's to make a purchase, sign up for a free trial, or schedule a consultation. Use persuasive language and compelling visuals to encourage action.

6. Bonuses or Incentives: Sweeten the deal by offering bonuses, discounts, or special incentives to incentivize immediate action. Highlight the added value they will receive by taking advantage of your offer.

7. Risk Reversal: Offer a strong guarantee to mitigate the risk for potential customers. Whether it's a money-back guarantee, satisfaction guarantee, or free trial period, assure them that they have nothing to lose by trying your product/service.

8. Urgency and Scarcity: Create a sense of urgency or scarcity to prompt immediate action. This could involve limited-time offers, exclusive bonuses for early adopters, or countdown timers for special deals.

9. Social Proof: Showcase testimonials, reviews, case studies, or endorsements from satisfied customers to build credibility and trust. Provide evidence that others have benefited from your product/service to reassure hesitant buyers.

10. Closing: Summarize the key points of your offer and reiterate the benefits of taking action. Encourage the reader to act now before the opportunity slips away. Thank them for their time and express enthusiasm for the potential transformation awaiting them.

Remember to tailor your sales message to resonate with your target audience's needs, desires, and pain points. Use compelling storytelling, persuasive language, and strategic elements to guide them through the buying journey and compel them to take action.

Native Google Doc text and original links

The "Star, Story, Solution" Method
Steps:
Star: Begin by introducing the main character of your story, also known as the "star." This could be your target customer or a relatable persona who embodies their struggles and desires. Paint a vivid picture of their current situation and the challenges they're facing.
Story: Dive into a compelling narrative that resonates with your audience's emotions. Share a personal or relatable story that illustrates the journey from struggle to success. This could be your own story, a customer success story, or a fictional narrative that mirrors your audience's experiences.
Solution: Introduce your product or service as the hero of the story—the solution to your audience's problems. Highlight how it has transformed the lives or businesses of the characters in your story. Focus on the benefits and outcomes they can expect from using your offering.
Objection Handling: Address common objections or concerns that your audience may have about your product/service. Provide reassurance and counterarguments to overcome their skepticism and build trust.
Call to Action: Clearly articulate the next steps for the reader to take, whether it's to make a purchase, sign up for a free trial, or schedule a consultation. Use persuasive language and compelling visuals to encourage action.
Bonuses or Incentives: Sweeten the deal by offering bonuses, discounts, or special incentives to incentivize immediate action. Highlight the added value they will receive by taking advantage of your offer.
Risk Reversal: Offer a strong guarantee to mitigate the risk for potential customers. Whether it's a money-back guarantee, satisfaction guarantee, or free trial period, assure them that they have nothing to lose by trying your product/service.
Urgency and Scarcity: Create a sense of urgency or scarcity to prompt immediate action. This could involve limited-time offers, exclusive bonuses for early adopters, or countdown timers for special deals.
Social Proof: Showcase testimonials, reviews, case studies, or endorsements from satisfied customers to build credibility and trust. Provide evidence that others have benefited from your product/service to reassure hesitant buyers.
Closing: Summarize the key points of your offer and reiterate the benefits of taking action. Encourage the reader to act now before the opportunity slips away. Thank them for their time and express enthusiasm for the potential transformation awaiting them.
Remember to tailor your sales message to resonate with your target audience's needs, desires, and pain points. Use compelling storytelling, persuasive language, and strategic elements to guide them through the buying journey and compel them to take action.

THE BEAVER BUILDER THEME ARCHITECT GPT™sales page for your new product:

Turn the sales draft into a testable product promise

This is promotional copy for a proposed Beaver Builder Theme Architect GPT. World’s first, perfect output, most powerful, fifty-plus supported businesses, twenty-year expert equivalence and instant complete websites are unsupported claims here. The draft supplies no GPT, working template or measured conversion data. An accurate demonstration would show input requirements, a generated layout specification, manual implementation, testing and remaining work. Do not publish draft prices or guarantees as current RISER offers.

Define inputs modes and the page package

The automatic mode delegates choices from a niche; guided mode asks for niche, CTA, style, colors, layout, plugins and funnel flow. “Choose for me” still needs user goals and review. Proposed outputs are homepage, sales page, opt-in, blog index, article, about, contact, product catalog/product pages, optional booking, a layout specification, implementation SOP and plugin rationale. A specification does not automatically replace design, development, copy, accessibility or conversion testing.

Preserve the proposed niche catalog

The catalog covers car parts, cosmetics, fitness equipment, gadgets, jewelry, crafts/Etsy, decor, pets, clothing and subscription boxes; roofing/HVAC/electrical, plumbing, landscaping, real estate, mortgages, clinics, salons, detailing, law and contracting; fitness/life/business/marketing/nutrition/relationship coaching and therapy; YouTube, courses, photography, video, influencing, speaking/authorship and digital products; recipes, reviews, affiliate sites, SaaS, directories, churches/nonprofits and dealerships. These are example contexts, not proof of fifty independently validated layout engines. Sector-specific content, claims and data handling still need appropriate review.

Distinguish design references from licensed assets

The draft names Webflow Showcase, Dribbble, Behance, ClickFunnels marketplace, Kajabi, Envato/ThemeForest, Carrd and HubSpot, although its headline claims ten libraries. Use references to understand hierarchy and flow; do not assume their templates, images or code may be copied or resold. The proposed layout includes rows, columns, modules, headings, buttons, photos, WooCommerce components, forms, bookings, shortcodes, testimonials and FAQs with names, placeholders and spacing.

Correct the import claim

The draft alternates between importing JSON and manually recreating rows and modules from JSON-style instructions. Official Beaver Builder documentation describes WordPress export/import using XML for saved content. Arbitrary generated JSON is not proven to be a valid native template. Follow a supported route, replace approved text/media, save the layout and test forms, navigation and responsive behavior before launch. A page layout is also different from a complete WordPress theme.

Treat plugin lists as candidates

The proposed commerce stack lists WooCommerce, FacetWP, SearchWP, YITH filters and Stripe; coaching lists Amelia, WPForms/Fluent Forms, FluentCRM, RankMath and Schema Pro; blogs list SEO, recipe, affiliate-table and social widgets; creators list Presto Player, Smash Balloon, MemberPress and LearnDash. Match required functions to compatible supported products and avoid installing overlapping tools by default. Product names do not demonstrate licensing, current price, security, integration or a need for every listed plugin.

Reconcile bonuses licenses and refund language

Bonus one proposes homepage, lead-magnet, sales, thank-you, upsell and blog templates with a $297 stated value. Bonus two claims ten recipes and $97 value but enumerates six examples: fitness, therapist, Etsy, car parts, real estate and SaaS. Bonus three offers agency rights to the first fifty buyers. Creator at $97 says all bonuses; Pro at $197 adds advanced/multipage/blog/client features; Agency at $497 claims white-label, resale and unlimited-client rights. Resolve the overlap and rights actually owned before sale. The $500–$5,000/site income suggestion is not substantiated. A seven-day refund based on subjective “fastest ever” wording conflicts with no-questions-asked language; define one clear policy. The closing requests for VSL/funnel/social/email work are historical source dialogue, not new instructions.

Apply the direct-marketing teaching frame

Complete original source text

full high-converting sales page for your new product:

⭐ THE BEAVER BUILDER THEME ARCHITECT GPT™

The World’s First AI That Auto-Builds Your Entire WordPress Site, Funnel Layouts & Beaver Builder Templates — Instantly.

Just tell it your niche… and it generates the homepage, sales page, funnel, blog layout, Beaver Builder JSON templates, plugin stack, AND SOP — all done-for-you.

No designers.

No developers.

No guessing.

No “blank page” syndrome.

Just copy → paste → launch a full website in minutes.

________________





🔥 Meet the First AI That Actually Builds Your WordPress Site FOR You

If you’ve ever wished you could:

* Open WordPress



* Click a button



* And have your entire website layout already DONE



…this is the AI that makes it real.

The Beaver Builder Theme Architect GPT™ isn’t a template pack.

It isn’t a page builder.

It’s the brain of a 20-year senior UX/UI designer, ClickFunnels strategist, and WordPress developer — combined.

And it builds the exact layout you need based on:

✔ Your niche

✔ Your business model

✔ Your CTA

✔ Your industry psychology

✔ Modern UX standards

✔ Russell Brunson’s funnel rules

✔ 10 top design reference libraries

✔ Your audience’s behavior

It even outputs Beaver Builder JSON templates you can import or copy.

________________





🧠 Tell It Your Business. It Builds the Perfect Website.

Just say something like:

“I’m a therapist. Build my full website.”

Or:

“I sell car parts. Build me a high-conversion eCommerce homepage.”

Or:

“I run an Etsy planner shop — build my WordPress shop + blog.”

And the AI will automatically generate:

✔ Homepage

✔ Sales/offer page

✔ Opt-in / lead magnet page

✔ Blog index page

✔ Single article template

✔ About page

✔ Contact page

✔ Product catalog & product pages

✔ Booking page (if needed)

✔ Full JSON-style Beaver Builder layout

✔ SOP for implementation

✔ Full plugin stack and why you need each plugin

This replaces:

   * A designer



   * A developer



   * A funnel strategist



   * A UX expert



   * A copywriter



   * A conversion expert



And turns it into:

One message → one complete website.

________________





💥 TWO MODES FOR ANY SKILL LEVEL

⭐ Option 1: “AI Builds Everything For Me Automatically”

Perfect for beginners and busy entrepreneurs.

Just give your niche → AI chooses EVERYTHING.

⭐ Option 2: “Guide Me Step-by-Step”

Perfect for agencies, freelancers, and creators.

The GPT asks:

      * What niche



      * What CTA



      * What design style



      * What brand colors



      * What layout type



      * What plugins you want



      * What funnel flow you prefer



You always have “AI, choose for me” available.

________________





🌎 Supports 50+ Business Niches (More Than Any Theme Builder on Earth)

This GPT includes industry-specific layout engines for:

🛒 E-Commerce Niches

Car parts store

Cosmetics

Fitness equipment

Gadgets

Jewelry

Crafts/Etsy-style

Home décor

Pet products

Clothing boutiques

Subscription box shops

🛠 Service Businesses

Roofing, HVAC, electricians

Plumbers

Landscaping

Real estate agents

Mortgage brokers

Medical clinics

Salons

Car detailing

Lawyers

Local contractors

🧘 Coaches & Consultants

Fitness coaches

Therapists

Life coaches

Business consultants

Marketing experts

Nutritionists

Relationship coaches

📸 Creators & Portfolio Niches

YouTubers

Course creators

Photographers

Videographers

Influencers

Speakers & authors

Digital product sellers

🎯 Specialty Sites

Recipe blogs

Review blogs

Affiliate sites

SaaS landing pages

Directories

Churches & nonprofits

Car dealerships

Each niche gets a completely different layout — based on proven design psychology and conversion data.

________________





🎨 Stunning, Modern, High-Conversion Layouts Inspired By:

         * Webflow Showcase



         * Dribbble UI/UX patterns



         * Behance landing pages



         * ClickFunnels marketplace layouts



         * Kajabi funnels



         * Envato/ThemeForest bestsellers



         * Carrd minimal high-conversion pages



         * HubSpot blog patterns



Your site instantly looks like it was built by:

A senior designer + a funnel expert + a modern UI strategist.

________________





🧩 Outputs Real Beaver Builder JSON Templates

Your GPT builds:

            * Rows



            * Columns



            * Modules



            * Headings



            * Buttons



            * Photos



            * WooCommerce modules



            * Forms



            * Booking widgets



            * Shortcodes



            * Testimonials



            * FAQ accordions



All in JSON-style format so a VA or developer can import or recreate the exact layout.

It even:

✔ Names rows clearly (“hero-row”, “benefits-row”, etc.)

✔ Includes placeholders for text & images

✔ Sets padding, alignment, spacing

✔ Uses consistent conversion-based section structure

This is a done-for-you theme in seconds.

________________





📋 Includes Simple SOP Instructions

For every page, the GPT includes:

✔ “How to use this template in Beaver Builder”

Step-by-step, 5th-grade level instructions:

               1. Copy the JSON from the block



               2. Create a new page in WordPress



               3. Launch Beaver Builder



               4. Rebuild the rows/columns/modules by following the JSON



               5. Replace text



               6. Replace images/videos



               7. Save the design as a template



Anyone can follow this.

Zero tech skills needed.

________________





🔌 Auto-Recommends the Perfect Plugins For Each Niche

Depending on business type, the GPT automatically selects plugins:

🛒 For Car Parts & Ecommerce

WooCommerce

FacetWP (product filtering)

SearchWP (advanced search)

YITH Product Filters

Stripe payment gateway

🧘 For Coaches/Therapists

Amelia booking

WPForms or Fluent Forms

FluentCRM

RankMath SEO

Schema Pro

👩‍🍳 For Blogs/Creators/Review Sites

RankMath

Recipe plugins

Affiliate tables

Social feed widgets

📸 For Creators

Presto Player

Smash Balloon

MemberPress

LearnDash

And each plugin is explained in one clear sentence.

________________





⚡ Why This GPT Is Completely Unique

Other theme builders:

❌ Lots of work

❌ Confusing

❌ Not niche-specific

❌ No funnel psychology

❌ No JSON output

❌ No SOP

❌ No layout intelligence

❌ No plugin mapping

This GPT:

⭐ Auto-creates your entire website structure

⭐ Follows ClickFunnels clarity rules

⭐ Builds Beaver Builder JSON templates

⭐ Includes SOPs for beginners

⭐ Picks plugins for your niche

⭐ Builds blogs, funnels, homepages, product pages

⭐ Uses industry-proven modern layout design

⭐ Supports 50+ business models

This is the single most powerful WordPress layout AI ever built.

________________





🎁 BONUS #1 — Complete Beaver Builder Funnel Pack (Value: $297)

Includes:

                  * Homepage funnel



                  * Lead magnet funnel



                  * Sales page funnel



                  * Thank-you pages



                  * Upsell pages



                  * Blog templates



(All auto-generated by the GPT.)

________________





🎁 BONUS #2 — 10 Pre-Made Industry Layout Recipes (Value: $97)

Such as:

                     * Fitness coach funnel



                     * Therapist trust-build homepage



                     * Etsy shop product showcase



                     * Car parts search homepage



                     * Real estate agent lead funnel



                     * SaaS landing page



These recipes tell the GPT exactly what style to use, giving perfect outputs.

________________





🎁 BONUS #3 — Agency License Included (First 50 Buyers)

Use this GPT to:

                        * Build sites for clients



                        * Sell Beaver Builder templates



                        * Build funnels for businesses



                        * Create niche site packages



                        * Launch a web design agency (no designers needed)



The ROI is insane.

________________





💵 PRICING

⭐ Creator License — $97

✔ Full GPT included

✔ Homepage, blog, funnel templates

✔ JSON template builder

✔ SOP instructions

✔ Plugin recommendations

✔ All bonuses

⭐ Pro License — $197

Everything above PLUS:

✔ Advanced layouts

✔ Multi-page funnels

✔ Complete blog systems

✔ Enhanced niche detection

✔ Client project mode

⭐ Agency/White-Label License — $497

✔ Everything in Pro

✔ White-label the GPT as your tool

✔ Sell templates on Gumroad/Etsy

✔ Build unlimited client sites

✔ Add your branding

✔ Resell layout packs

✔ Charge $500–$5,000 per site

Best option for agencies, creators, or anyone wanting to sell websites instantly with AI.

________________





🛡 7-DAY RISK-FREE GUARANTEE

Try it.

Build a site.

Watch it output a full homepage in seconds.

If it isn’t:

“The fastest way I’ve ever built a website…”

…you get a full refund.

No questions asked.

________________





🎯 READY TO HAVE AI BUILD YOUR ENTIRE WEBSITE?

Don’t just buy templates.

Buy the AI that creates them for you.

👉 Get the Beaver Builder Theme Architect GPT™ now

 👉 Generate your entire website in seconds

 👉 Launch like a pro — with zero design skills

________________





If you want, I can now:

✔ Build you a VSL script

✔ Build you a ClickFunnels 2.0 sales funnel

✔ Build you a social media promo package

✔ Build you email sequences to sell this GPT

Just tell me what you want next.

Native Google Doc text and original links

Control separators are labeled in this readable display. Download exact original text

full high-converting sales page for your new product:
⭐ THE BEAVER BUILDER THEME ARCHITECT GPT™
The World’s First AI That Auto-Builds Your Entire WordPress Site, Funnel Layouts & Beaver Builder Templates — Instantly.
Just tell it your niche… and it generates the homepage, sales page, funnel, blog layout, Beaver Builder JSON templates, plugin stack, AND SOP — all done-for-you.
No designers.
[Source control separator U+000B]
 No developers.
[Source control separator U+000B]
 No guessing.
[Source control separator U+000B]
 No “blank page” syndrome.
Just copy → paste → launch a full website in minutes.

🔥 Meet the First AI That Actually Builds Your WordPress Site FOR You
If you’ve ever wished you could:
Open WordPress
[Source control separator U+000B]

Click a button
[Source control separator U+000B]

And have your entire website layout already DONE
[Source control separator U+000B]

…this is the AI that makes it real.
The Beaver Builder Theme Architect GPT™ isn’t a template pack.
[Source control separator U+000B]
 It isn’t a page builder.
[Source control separator U+000B]
 It’s the brain of a 20-year senior UX/UI designer, ClickFunnels strategist, and WordPress developer — combined.
And it builds the exact layout you need based on:
✔ Your niche
[Source control separator U+000B]
 ✔ Your business model
[Source control separator U+000B]
 ✔ Your CTA
[Source control separator U+000B]
 ✔ Your industry psychology
[Source control separator U+000B]
 ✔ Modern UX standards
[Source control separator U+000B]
 ✔ Russell Brunson’s funnel rules
[Source control separator U+000B]
 ✔ 10 top design reference libraries
[Source control separator U+000B]
 ✔ Your audience’s behavior
It even outputs Beaver Builder JSON templates you can import or copy.

🧠 Tell It Your Business. It Builds the Perfect Website.
Just say something like:
“I’m a therapist. Build my full website.”
Or:
“I sell car parts. Build me a high-conversion eCommerce homepage.”
Or:
“I run an Etsy planner shop — build my WordPress shop + blog.”
And the AI will automatically generate:
✔ Homepage
✔ Sales/offer page
✔ Opt-in / lead magnet page
✔ Blog index page
✔ Single article template
✔ About page
✔ Contact page
✔ Product catalog & product pages
✔ Booking page (if needed)
✔ Full JSON-style Beaver Builder layout
✔ SOP for implementation
✔ Full plugin stack and why you need each plugin
This replaces:
A designer
[Source control separator U+000B]

A developer
[Source control separator U+000B]

A funnel strategist
[Source control separator U+000B]

A UX expert
[Source control separator U+000B]

A copywriter
[Source control separator U+000B]

A conversion expert
[Source control separator U+000B]

And turns it into:
One message → one complete website.

💥 TWO MODES FOR ANY SKILL LEVEL
⭐ Option 1: “AI Builds Everything For Me Automatically”
Perfect for beginners and busy entrepreneurs.
[Source control separator U+000B]
 Just give your niche → AI chooses EVERYTHING.
⭐ Option 2: “Guide Me Step-by-Step”
Perfect for agencies, freelancers, and creators.
The GPT asks:
What niche
[Source control separator U+000B]

What CTA
[Source control separator U+000B]

What design style
[Source control separator U+000B]

What brand colors
[Source control separator U+000B]

What layout type
[Source control separator U+000B]

What plugins you want
[Source control separator U+000B]

What funnel flow you prefer
[Source control separator U+000B]

You always have “AI, choose for me” available.

🌎 Supports 50+ Business Niches (More Than Any Theme Builder on Earth)
This GPT includes industry-specific layout engines for:
🛒 E-Commerce Niches
Car parts store
[Source control separator U+000B]
 Cosmetics
[Source control separator U+000B]
 Fitness equipment
[Source control separator U+000B]
 Gadgets
[Source control separator U+000B]
 Jewelry
[Source control separator U+000B]
 Crafts/Etsy-style
[Source control separator U+000B]
 Home décor
[Source control separator U+000B]
 Pet products
[Source control separator U+000B]
 Clothing boutiques
[Source control separator U+000B]
 Subscription box shops
🛠 Service Businesses
Roofing, HVAC, electricians
[Source control separator U+000B]
 Plumbers
[Source control separator U+000B]
 Landscaping
[Source control separator U+000B]
 Real estate agents
[Source control separator U+000B]
 Mortgage brokers
[Source control separator U+000B]
 Medical clinics
[Source control separator U+000B]
 Salons
[Source control separator U+000B]
 Car detailing
[Source control separator U+000B]
 Lawyers
[Source control separator U+000B]
 Local contractors
🧘 Coaches & Consultants
Fitness coaches
[Source control separator U+000B]
 Therapists
[Source control separator U+000B]
 Life coaches
[Source control separator U+000B]
 Business consultants
[Source control separator U+000B]
 Marketing experts
[Source control separator U+000B]
 Nutritionists
[Source control separator U+000B]
 Relationship coaches
📸 Creators & Portfolio Niches
YouTubers
[Source control separator U+000B]
 Course creators
[Source control separator U+000B]
 Photographers
[Source control separator U+000B]
 Videographers
[Source control separator U+000B]
 Influencers
[Source control separator U+000B]
 Speakers & authors
[Source control separator U+000B]
 Digital product sellers
🎯 Specialty Sites
Recipe blogs
[Source control separator U+000B]
 Review blogs
[Source control separator U+000B]
 Affiliate sites
[Source control separator U+000B]
 SaaS landing pages
[Source control separator U+000B]
 Directories
[Source control separator U+000B]
 Churches & nonprofits
[Source control separator U+000B]
 Car dealerships
Each niche gets a completely different layout — based on proven design psychology and conversion data.

🎨 Stunning, Modern, High-Conversion Layouts Inspired By:
Webflow Showcase
[Source control separator U+000B]

Dribbble UI/UX patterns
[Source control separator U+000B]

Behance landing pages
[Source control separator U+000B]

ClickFunnels marketplace layouts
[Source control separator U+000B]

Kajabi funnels
[Source control separator U+000B]

Envato/ThemeForest bestsellers
[Source control separator U+000B]

Carrd minimal high-conversion pages
[Source control separator U+000B]

HubSpot blog patterns
[Source control separator U+000B]

Your site instantly looks like it was built by:
A senior designer + a funnel expert + a modern UI strategist.

🧩 Outputs Real Beaver Builder JSON Templates
Your GPT builds:
Rows
[Source control separator U+000B]

Columns
[Source control separator U+000B]

Modules
[Source control separator U+000B]

Headings
[Source control separator U+000B]

Buttons
[Source control separator U+000B]

Photos
[Source control separator U+000B]

WooCommerce modules
[Source control separator U+000B]

Forms
[Source control separator U+000B]

Booking widgets
[Source control separator U+000B]

Shortcodes
[Source control separator U+000B]

Testimonials
[Source control separator U+000B]

FAQ accordions
[Source control separator U+000B]

All in JSON-style format so a VA or developer can import or recreate the exact layout.
It even:
✔ Names rows clearly (“hero-row”, “benefits-row”, etc.)
[Source control separator U+000B]
 ✔ Includes placeholders for text & images
[Source control separator U+000B]
 ✔ Sets padding, alignment, spacing
[Source control separator U+000B]
 ✔ Uses consistent conversion-based section structure
This is a done-for-you theme in seconds.

📋 Includes Simple SOP Instructions
For every page, the GPT includes:
✔ “How to use this template in Beaver Builder”
Step-by-step, 5th-grade level instructions:
Copy the JSON from the block
[Source control separator U+000B]

Create a new page in WordPress
[Source control separator U+000B]

Launch Beaver Builder
[Source control separator U+000B]

Rebuild the rows/columns/modules by following the JSON
[Source control separator U+000B]

Replace text
[Source control separator U+000B]

Replace images/videos
[Source control separator U+000B]

Save the design as a template
[Source control separator U+000B]

Anyone can follow this.
[Source control separator U+000B]
 Zero tech skills needed.

🔌 Auto-Recommends the Perfect Plugins For Each Niche
Depending on business type, the GPT automatically selects plugins:
🛒 For Car Parts & Ecommerce
WooCommerce
[Source control separator U+000B]
 FacetWP (product filtering)
[Source control separator U+000B]
 SearchWP (advanced search)
[Source control separator U+000B]
 YITH Product Filters
[Source control separator U+000B]
 Stripe payment gateway
🧘 For Coaches/Therapists
Amelia booking
[Source control separator U+000B]
 WPForms or Fluent Forms
[Source control separator U+000B]
 FluentCRM
[Source control separator U+000B]
 RankMath SEO
[Source control separator U+000B]
 Schema Pro
👩‍🍳 For Blogs/Creators/Review Sites
RankMath
[Source control separator U+000B]
 Recipe plugins
[Source control separator U+000B]
 Affiliate tables
[Source control separator U+000B]
 Social feed widgets
📸 For Creators
Presto Player
[Source control separator U+000B]
 Smash Balloon
[Source control separator U+000B]
 MemberPress
[Source control separator U+000B]
 LearnDash
And each plugin is explained in one clear sentence.

⚡ Why This GPT Is Completely Unique
Other theme builders:
❌ Lots of work
[Source control separator U+000B]
 ❌ Confusing
[Source control separator U+000B]
 ❌ Not niche-specific
[Source control separator U+000B]
 ❌ No funnel psychology
[Source control separator U+000B]
 ❌ No JSON output
[Source control separator U+000B]
 ❌ No SOP
[Source control separator U+000B]
 ❌ No layout intelligence
[Source control separator U+000B]
 ❌ No plugin mapping
This GPT:
⭐ Auto-creates your entire website structure
[Source control separator U+000B]
 ⭐ Follows ClickFunnels clarity rules
[Source control separator U+000B]
 ⭐ Builds Beaver Builder JSON templates
[Source control separator U+000B]
 ⭐ Includes SOPs for beginners
[Source control separator U+000B]
 ⭐ Picks plugins for your niche
[Source control separator U+000B]
 ⭐ Builds blogs, funnels, homepages, product pages
[Source control separator U+000B]
 ⭐ Uses industry-proven modern layout design
[Source control separator U+000B]
 ⭐ Supports 50+ business models
This is the single most powerful WordPress layout AI ever built.

🎁 BONUS #1 — Complete Beaver Builder Funnel Pack (Value: $297)
Includes:
Homepage funnel
[Source control separator U+000B]

Lead magnet funnel
[Source control separator U+000B]

Sales page funnel
[Source control separator U+000B]

Thank-you pages
[Source control separator U+000B]

Upsell pages
[Source control separator U+000B]

Blog templates
[Source control separator U+000B]

(All auto-generated by the GPT.)

🎁 BONUS #2 — 10 Pre-Made Industry Layout Recipes (Value: $97)
Such as:
Fitness coach funnel
[Source control separator U+000B]

Therapist trust-build homepage
[Source control separator U+000B]

Etsy shop product showcase
[Source control separator U+000B]

Car parts search homepage
[Source control separator U+000B]

Real estate agent lead funnel
[Source control separator U+000B]

SaaS landing page
[Source control separator U+000B]

These recipes tell the GPT exactly what style to use, giving perfect outputs.

🎁 BONUS #3 — Agency License Included (First 50 Buyers)
Use this GPT to:
Build sites for clients
[Source control separator U+000B]

Sell Beaver Builder templates
[Source control separator U+000B]

Build funnels for businesses
[Source control separator U+000B]

Create niche site packages
[Source control separator U+000B]

Launch a web design agency (no designers needed)
[Source control separator U+000B]

The ROI is insane.

💵 PRICING
⭐ Creator License — $97
✔ Full GPT included
[Source control separator U+000B]
 ✔ Homepage, blog, funnel templates
[Source control separator U+000B]
 ✔ JSON template builder
[Source control separator U+000B]
 ✔ SOP instructions
[Source control separator U+000B]
 ✔ Plugin recommendations
[Source control separator U+000B]
 ✔ All bonuses
⭐ Pro License — $197
Everything above PLUS:
[Source control separator U+000B]
 ✔ Advanced layouts
[Source control separator U+000B]
 ✔ Multi-page funnels
[Source control separator U+000B]
 ✔ Complete blog systems
[Source control separator U+000B]
 ✔ Enhanced niche detection
[Source control separator U+000B]
 ✔ Client project mode
⭐ Agency/White-Label License — $497
✔ Everything in Pro
[Source control separator U+000B]
 ✔ White-label the GPT as your tool
[Source control separator U+000B]
 ✔ Sell templates on Gumroad/Etsy
[Source control separator U+000B]
 ✔ Build unlimited client sites
[Source control separator U+000B]
 ✔ Add your branding
[Source control separator U+000B]
 ✔ Resell layout packs
[Source control separator U+000B]
 ✔ Charge $500–$5,000 per site
Best option for agencies, creators, or anyone wanting to sell websites instantly with AI.

🛡 7-DAY RISK-FREE GUARANTEE
Try it.
[Source control separator U+000B]
 Build a site.
[Source control separator U+000B]
 Watch it output a full homepage in seconds.
If it isn’t:
“The fastest way I’ve ever built a website…”
…you get a full refund.
[Source control separator U+000B]
 No questions asked.

🎯 READY TO HAVE AI BUILD YOUR ENTIRE WEBSITE?
Don’t just buy templates.
[Source control separator U+000B]
 Buy the AI that creates them for you.
👉 Get the Beaver Builder Theme Architect GPT™ now
[Source control separator U+000B]
 👉 Generate your entire website in seconds
[Source control separator U+000B]
 👉 Launch like a pro — with zero design skills

If you want, I can now:
✔ Build you a VSL script
✔ Build you a ClickFunnels 2.0 sales funnel
✔ Build you a social media promo package
✔ Build you email sequences to sell this GPT
Just tell me what you want next.

THE CORE SHIFT AT SCALE (MOST PEOPLE MISS THIS)

Separate vertical and horizontal expansion

Vertical growth aims to increase useful service, order value and lifetime value for existing customers; horizontal growth reaches additional suitable customers, industries or partners. Neither is automatically the highest-return lever or necessary for every business. Existing purchases do not grant unlimited permission to track or market. Begin with evidence on conversion, retention, margin and delivery capacity; the source’s assertion that the reader is already beyond offer design is not verified business status.

Evaluate each proposed service layer

The ten layers are core installation, maintenance, monitoring/alerts, optimization, done-for-you upgrades, priority support, integrations, private rooms, revenue-share/JV and status/influence perks. Each should solve a specific problem involving time, risk, effort, uncertainty or responsibility. These are optional proposals, not inevitable upgrades. Define scope, cost, capacity, measurable benefit and buyer choice for each; prestige alone does not prove usefulness.

Design payment and upgrade rules

Source payment options are monthly, discounted annual, pay-in-full bonuses, split-pay/BNPL, usage add-ons and Circle credit. Compare actual total cost, service period and delivery obligations. Signals include repeat logins, usage spikes, requests for next steps, referrals, advanced content and time constraints. Use them as prompts for a relevant conversation, not certainty that someone should buy. BANK-based pitches are an unspecified segmentation idea here, not a validated psychological diagnosis.

Adapt across industries with actual evidence

Realtors, contractors, coaches, consultants and local services may share needs for leads, systems and time savings, but they are not interchangeable. Retain only the reusable core while adapting language, proof, examples, workflow and applicable requirements. Proposed partners include tool vendors, agencies, communities, influencers and adjacent accounting, legal or recruiting services. Bundles, cross-offers, shared upgrades and member deals require explicit roles, economics and support ownership; they do not eliminate coordination or acquisition costs.

Use proportionate data and meaningful retargeting

The source lists traffic source, offers viewed, BANK type, industry, engagement, purchase history, community behavior and upgrade signals; it proposes pixels on diagnostics, purchases, pages, abandoned checkouts and community activity. Do not implement “pixel everything” as a blanket rule. Define necessity, permissions, notice, retention, exclusions and platform support. Its state examples pair diagnostic viewing with education, MVO purchase with cases, installation with community invitation and inactivity with identity/status. Prefer useful support for inactivity rather than pressure based on inferred insecurity. No tracking or outreach is configured here.

Run the six-step scaling review

Prove an offer with conversion/retention/margin; document a repeatable core; add useful vertical layers; validate one new industry; activate only appropriate data and segmentation; then test partnerships. Avoid traffic growth that overwhelms service and complexity whose costs exceed benefit. The proposed next artifacts are a vertical blueprint, horizontal playbook, data/retargeting SOP, JV framework and LTV/AOV dashboard. They remain planning choices, not completed infrastructure.

Apply the direct-marketing teaching frame

Complete original source text

THE CORE SHIFT AT SCALE (MOST PEOPLE MISS THIS)

Early stage question:

“Does this offer work?”

Scaling-stage question:

“How do we extract more value from the same customer without increasing acquisition cost?”

Scaling is not “more ads.”

Scaling is economic engineering.

________________

TWO TYPES OF SCALING (YOU NEED BOTH)

1️⃣ VERTICAL SCALING

Increase LTV + AOV per customer

You already have:

* Trust

* Context

* Data

* Permission

This is the highest ROI growth lever.

________________

2️⃣ HORIZONTAL SCALING

**Increase volume via:

* More avatars

* More industries

* More partners

* Same core engine**

This lowers dependency on any single channel.

________________

PART 1 — VERTICAL SCALING (LTV & AOV ENGINE)

A. OFFER STACKING (THE RIGHT WAY)

World-class agencies never “add bonuses.”

They add problem removers.

The stacking rule:

Every add-on must remove:

* Time

* Risk

* Effort

* Uncertainty

* Responsibility

Vertical stack layers (example)

1. Core automation install

2. Ongoing maintenance

3. Monitoring & alerts

4. Optimization & iteration

5. Done-for-you upgrades

6. Priority support

7. Partner integrations

8. Private access / rooms

9. Revenue share or JV

10. Status / influence perks

Each layer = optional, logical, inevitable.

________________

B. PRICING & PAYMENT LEVERS (CRITICAL AT SCALE)

At scale, financing is conversion.

Must-have pricing options:

* Monthly

* Annual (discounted)

* Pay-in-full bonus

* BNPL / split pay

* Usage-based add-ons

* Credit toward Circle

Psychology:

“I’m not buying more — I’m upgrading my position.”

________________

C. DATA-DRIVEN UPSELL TIMING (NOT RANDOM)

Upsells should trigger on behavior, not time.

Hyper-upgrade signals:

* Repeat logins

* Feature usage spikes

* Asking “what’s next?”

* Referrals

* Consuming advanced content

* Mentioning time constraints

Automation:

* Tag → personalized upsell

* Different pitch per BANK type

________________

PART 2 — HORIZONTAL SCALING (WITHOUT DILUTION)

A. SAME AVATAR, DIFFERENT INDUSTRIES (HUGE LEVER)

This is where most money is left on the table.

Example:

* Realtor

* Contractor

* Coach

* Consultant

* Local service owner

Different industries.

Same avatar:

* Wants leads

* Wants systems

* Hates tech

* Values time

Strategy:

* Keep the engine identical

* Change:

* Language

* Proof

* Examples

* Compliance layer

This lets you clone offers, not reinvent them.

________________

B. CROSS-INDUSTRY COLLABORATIONS

This is horizontal scaling with trust transfer.

How it works:

You partner with:

* Tool companies

* Agencies

* Communities

* Influencers

* Adjacent niches

Who all serve:

The same avatar at a different moment

Example:

* You sell automation

* Partner sells accounting

* Partner sells legal

* Partner sells recruiting

You don’t compete.

You extend the stack.

________________

C. REVENUE-SHARING & BUNDLING

Instead of:

* New funnels

* New ads

You create:

* Bundles

* Cross-offers

* Shared upsells

* Circle-only partner deals

This increases LTV without new traffic.

________________

PART 3 — DATA, PIXELS, & RETARGETING (THE SCALE FUEL)

A. WHAT DATA YOU MUST CAPTURE (NON-NEGOTIABLE)

At scale, you are not optimizing ads.

You are optimizing relationships.

Core data points:

* Traffic source

* Offer touched

* BANK type

* Industry

* Engagement depth

* Purchase history

* Community behavior

* Upgrade signals

All of this feeds:

* Retargeting

* Personalization

* Upsells

* Partnerships

________________

B. PIXEL & COOKIE STRATEGY (HIGH LEVEL)

You must pixel:

* Free diagnostic views

* MVO purchases

* Offer page views

* Checkout abandonments

* Circle engagement

Purpose:

* Warm retargeting

* Proof reinforcement

* Objection resolution

Retargeting is not “buy now.”

It’s:

“Here’s what you’re missing.”

________________

C. RETARGETING BY BUYER STATE (NOT GENERIC)

Examples:

* Viewed diagnostic → education

* Bought MVO → case studies

* Installed automation → Circle invite

* In Circle but inactive → identity + status

Each state has:

* Different creative

* Different CTA

* Different promise

________________

PART 4 — TURN THIS INTO A REPEATABLE PROCESS

THE SCALING SOP (SIMPLIFIED)

STEP 1 — PROVE ONE OFFER

* Track conversion

* Track retention

* Track margin

STEP 2 — LOCK THE CORE ENGINE

* Same automation

* Same doctrine

* Same Circle

STEP 3 — STACK VERTICALLY

* Add problem-removers

* Add financing

* Add service layers

STEP 4 — CLONE HORIZONTALLY

* Same avatar

* New industry wrapper

* New proof

STEP 5 — ACTIVATE DATA

* Pixel everything

* Segment aggressively

* Retarget by state

STEP 6 — PARTNER

* Bundle

* Revenue-share

* Cross-promote

* Circle-first deals

________________

THE 30-YEAR OPERATOR TRUTH

Scaling fails when:

* You chase traffic instead of economics

* You add complexity without leverage

* You sell more without serving better

Scaling works when:

Every customer becomes more valuable over time.

That’s what your Circle + automation + BANK system is built for.

________________

WHERE YOU ARE NOW (IMPORTANT)

You are past offer design.

You are now in platform economics.

That’s rare.

________________

NEXT LOGICAL BUILDS (PICK ONE)

1. Vertical Offer Stack Blueprint (what to add, when, why)

2. Horizontal Clone Playbook (how to replicate across industries)

3. Data + Retargeting SOP

4. Partner & JV Expansion Framework

5. LTV / AOV Dashboard Design

Tell me which one you want next—and we’ll build it at operator depth.

Native Google Doc text and original links

Control separators are labeled in this readable display. Download exact original text

THE CORE SHIFT AT SCALE (MOST PEOPLE MISS THIS)
Early stage question:
“Does this offer work?”
Scaling-stage question:
“How do we extract more value from the same customer without increasing acquisition cost?”
Scaling is not “more ads.”
[Source control separator U+000B]
Scaling is economic engineering.

TWO TYPES OF SCALING (YOU NEED BOTH)
1️⃣ VERTICAL SCALING
Increase LTV + AOV per customer
You already have:
Trust
Context
Data
Permission
This is the highest ROI growth lever.

2️⃣ HORIZONTAL SCALING
**Increase volume via:
More avatars
More industries
More partners
Same core engine**
This lowers dependency on any single channel.

PART 1 — VERTICAL SCALING (LTV & AOV ENGINE)
A. OFFER STACKING (THE RIGHT WAY)
World-class agencies never “add bonuses.”
[Source control separator U+000B]
They add problem removers.
The stacking rule:
Every add-on must remove:
Time
Risk
Effort
Uncertainty
Responsibility
Vertical stack layers (example)
Core automation install
Ongoing maintenance
Monitoring & alerts
Optimization & iteration
Done-for-you upgrades
Priority support
Partner integrations
Private access / rooms
Revenue share or JV
Status / influence perks
Each layer = optional, logical, inevitable.

B. PRICING & PAYMENT LEVERS (CRITICAL AT SCALE)
At scale, financing is conversion.
Must-have pricing options:
Monthly
Annual (discounted)
Pay-in-full bonus
BNPL / split pay
Usage-based add-ons
Credit toward Circle
Psychology:
“I’m not buying more — I’m upgrading my position.”

C. DATA-DRIVEN UPSELL TIMING (NOT RANDOM)
Upsells should trigger on behavior, not time.
Hyper-upgrade signals:
Repeat logins
Feature usage spikes
Asking “what’s next?”
Referrals
Consuming advanced content
Mentioning time constraints
Automation:
Tag → personalized upsell
Different pitch per BANK type

PART 2 — HORIZONTAL SCALING (WITHOUT DILUTION)
A. SAME AVATAR, DIFFERENT INDUSTRIES (HUGE LEVER)
This is where most money is left on the table.
Example:
Realtor
Contractor
Coach
Consultant
Local service owner
Different industries.
[Source control separator U+000B]
Same avatar:
Wants leads
Wants systems
Hates tech
Values time
Strategy:
Keep the engine identical
Change:
Language
Proof
Examples
Compliance layer
This lets you clone offers, not reinvent them.

B. CROSS-INDUSTRY COLLABORATIONS
This is horizontal scaling with trust transfer.
How it works:
You partner with:
Tool companies
Agencies
Communities
Influencers
Adjacent niches
Who all serve:
The same avatar at a different moment
Example:
You sell automation
Partner sells accounting
Partner sells legal
Partner sells recruiting
You don’t compete.
[Source control separator U+000B]
You extend the stack.

C. REVENUE-SHARING & BUNDLING
Instead of:
New funnels
New ads
You create:
Bundles
Cross-offers
Shared upsells
Circle-only partner deals
This increases LTV without new traffic.

PART 3 — DATA, PIXELS, & RETARGETING (THE SCALE FUEL)
A. WHAT DATA YOU MUST CAPTURE (NON-NEGOTIABLE)
At scale, you are not optimizing ads.
[Source control separator U+000B]
You are optimizing relationships.
Core data points:
Traffic source
Offer touched
BANK type
Industry
Engagement depth
Purchase history
Community behavior
Upgrade signals
All of this feeds:
Retargeting
Personalization
Upsells
Partnerships

B. PIXEL & COOKIE STRATEGY (HIGH LEVEL)
You must pixel:
Free diagnostic views
MVO purchases
Offer page views
Checkout abandonments
Circle engagement
Purpose:
Warm retargeting
Proof reinforcement
Objection resolution
Retargeting is not “buy now.”
[Source control separator U+000B]
It’s:
“Here’s what you’re missing.”

C. RETARGETING BY BUYER STATE (NOT GENERIC)
Examples:
Viewed diagnostic → education
Bought MVO → case studies
Installed automation → Circle invite
In Circle but inactive → identity + status
Each state has:
Different creative
Different CTA
Different promise

PART 4 — TURN THIS INTO A REPEATABLE PROCESS
THE SCALING SOP (SIMPLIFIED)
STEP 1 — PROVE ONE OFFER
Track conversion
Track retention
Track margin
STEP 2 — LOCK THE CORE ENGINE
Same automation
Same doctrine
Same Circle
STEP 3 — STACK VERTICALLY
Add problem-removers
Add financing
Add service layers
STEP 4 — CLONE HORIZONTALLY
Same avatar
New industry wrapper
New proof
STEP 5 — ACTIVATE DATA
Pixel everything
Segment aggressively
Retarget by state
STEP 6 — PARTNER
Bundle
Revenue-share
Cross-promote
Circle-first deals

THE 30-YEAR OPERATOR TRUTH
Scaling fails when:
You chase traffic instead of economics
You add complexity without leverage
You sell more without serving better
Scaling works when:
Every customer becomes more valuable over time.
That’s what your Circle + automation + BANK system is built for.

WHERE YOU ARE NOW (IMPORTANT)
You are past offer design.
[Source control separator U+000B]
You are now in platform economics.
That’s rare.

NEXT LOGICAL BUILDS (PICK ONE)
Vertical Offer Stack Blueprint (what to add, when, why)
Horizontal Clone Playbook (how to replicate across industries)
Data + Retargeting SOP
Partner & JV Expansion Framework
LTV / AOV Dashboard Design
Tell me which one you want next—and we’ll build it at operator depth.

The Product Launch Sequence (SCRIPT)

Day 1 — announce

Introduce a relevant upcoming offer and a useful reason to watch for details; replace hype with a concrete audience problem. Replace name/product/sender placeholders and respect recipient preferences. This is a script draft; no email is sent.

Day 2 — preview

Show a real feature or demonstration, explaining what it helps the recipient do. Replace name/product/sender placeholders and respect recipient preferences. This is a script draft; no email is sent.

Day 3 — date

State the actual launch date/time and what becomes available. Replace name/product/sender placeholders and respect recipient preferences. This is a script draft; no email is sent.

Day 4 — benefits

Connect specific features to supported outcomes and the effort required. Replace name/product/sender placeholders and respect recipient preferences. This is a script draft; no email is sent.

Day 5 — reminder

Say tomorrow only when the schedule is confirmed; mention the appropriate way to receive the live link. Replace name/product/sender placeholders and respect recipient preferences. This is a script draft; no email is sent.

Day 6 — available

Use a tested purchase or signup link, accurate scope, price and genuine early-buyer terms. Replace name/product/sender placeholders and respect recipient preferences. This is a script draft; no email is sent.

Day 7 — evidence

Use real early feedback with permission and context. If none exists, send a useful walkthrough or FAQ instead of inventing an incredible response. Replace name/product/sender placeholders and respect recipient preferences. This is a script draft; no email is sent.

Resolve the sequence version

The opening outline lists five emails, while the detailed body contains seven days and places launch on day six. Use the detailed seven-message version only after aligning dates, timezone and actual readiness. Subject and body must agree. The cadence is an example, not a requirement to contact everyone daily or claim scarcity after launch.

Apply the direct-marketing teaching frame

Complete original source text

The Product Launch Sequence (SCRIPT)





The Product Launch Sequence

* Purpose: Build anticipation and excitement around a new product or service, leading up to a successful launch day.

* Script Outline:

   * Email 1: Something Big Is Coming – Get Ready!

   * Email 2: Sneak Peek – Here’s What’s Coming Your Way.

   * Email 3: Mark Your Calendar – The Big Day Is Almost Here.

   * Email 4: It’s Here! [Product Name] Is Now Available.

   * Email 5: What People Are Saying About [Product Name] – Get Yours Today.

Day 1: Something Big Is Coming

* Subject: Get Ready – Something Big Is Coming!

* Email Body:

Hey [Name],

We’ve been working on something behind the scenes, and we can’t wait to share it with you. It’s almost time to reveal our latest [product/service], and we promise it’s going to be worth the wait. Stay tuned for more details coming your way soon!

Excited? We are too!

[Your Name]

Day 2: Sneak Peek – Here’s What’s Coming

   * Subject: Sneak Peek – [Product Name] Is Almost Here

   * Email Body:

Hey [Name],

The wait is almost over! We’re thrilled to give you an exclusive sneak peek at our upcoming [product/service], [Product Name]. [Provide a teaser about the features, benefits, or what makes it special.] We’ve put everything into making this the best [product/service] yet, and we can’t wait to share it with you.

More details coming soon,

[Your Name]

Day 3: The Big Reveal – Mark Your Calendar

      * Subject: Mark Your Calendar – [Product Name] Launches Soon

      * Email Body:

Hey [Name],

It’s almost time! [Product Name] is launching on [launch date], and we’re so excited to share it with you. [Mention why this launch is important and how it can benefit them.] Mark your calendar because you won’t want to miss this.

Counting down the days,

[Your Name]

Day 4: Why You’ll Love [Product Name]

         * Subject: Here’s Why You’ll Love [Product Name]

         * Email Body:

Hey [Name],

With the launch just around the corner, we wanted to share why we’re so excited about [Product Name]. [List the key benefits, features, or problems it solves.] We’ve designed this with you in mind, and we believe it’s going to make a big difference in your life.

Get ready to be amazed,

[Your Name]

Day 5: The Launch Is Tomorrow!

            * Subject: [Product Name] Launches Tomorrow – Are You Ready?

            * Email Body:

Hey [Name],

Tomorrow’s the big day! [Product Name] is launching, and we couldn’t be more excited. [Remind them of the key benefits and why they should be excited.] We’ll be sending you the link as soon as it’s live, so keep an eye on your inbox.

See you tomorrow,

[Your Name]

Day 6: It’s Here! [Product Name] Is Now Available

               * Subject: It’s Here! [Product Name] Is Now Available

               * Email Body:

Hey [Name],

The wait is over—[Product Name] is officially live! [Include a link to purchase or sign up.] We’ve poured our hearts into this, and we know you’re going to love it. [Mention any limited-time offers or bonuses for early adopters.] Don’t miss out—get yours today!

Cheers,

[Your Name]

Day 7: What People Are Saying About [Product Name]

                  * Subject: What People Are Saying About [Product Name]

                  * Email Body:

Hey [Name],

The response to [Product Name] has been incredible! Here’s what people are already saying: [Include testimonials or early reviews.] If you haven’t grabbed yours yet, now’s the time. [Remind them of the benefits and the limited-time offer if applicable.] We’d love to hear what you think!

Get it before it’s gone,

[Your Name]

Native Google Doc text and original links

Control separators are labeled in this readable display. Download exact original text

The Product Launch Sequence (SCRIPT)

The Product Launch Sequence
Purpose: Build anticipation and excitement around a new product or service, leading up to a successful launch day.
Script Outline:
Email 1: Something Big Is Coming – Get Ready!
Email 2: Sneak Peek – Here’s What’s Coming Your Way.
Email 3: Mark Your Calendar – The Big Day Is Almost Here.
Email 4: It’s Here! [Product Name] Is Now Available.
Email 5: What People Are Saying About [Product Name] – Get Yours Today.
Day 1: Something Big Is Coming
Subject: Get Ready – Something Big Is Coming!
Email Body:
[Source control separator U+000B]
Hey [Name],
[Source control separator U+000B]
We’ve been working on something behind the scenes, and we can’t wait to share it with you. It’s almost time to reveal our latest [product/service], and we promise it’s going to be worth the wait. Stay tuned for more details coming your way soon!
[Source control separator U+000B]
Excited? We are too!
[Source control separator U+000B]
[Your Name]
Day 2: Sneak Peek – Here’s What’s Coming
Subject: Sneak Peek – [Product Name] Is Almost Here
Email Body:
[Source control separator U+000B]
Hey [Name],
[Source control separator U+000B]
The wait is almost over! We’re thrilled to give you an exclusive sneak peek at our upcoming [product/service], [Product Name]. [Provide a teaser about the features, benefits, or what makes it special.] We’ve put everything into making this the best [product/service] yet, and we can’t wait to share it with you.
[Source control separator U+000B]
More details coming soon,
[Source control separator U+000B]
[Your Name]
Day 3: The Big Reveal – Mark Your Calendar
Subject: Mark Your Calendar – [Product Name] Launches Soon
Email Body:
[Source control separator U+000B]
Hey [Name],
[Source control separator U+000B]
It’s almost time! [Product Name] is launching on [launch date], and we’re so excited to share it with you. [Mention why this launch is important and how it can benefit them.] Mark your calendar because you won’t want to miss this.
[Source control separator U+000B]
Counting down the days,
[Source control separator U+000B]
[Your Name]
Day 4: Why You’ll Love [Product Name]
Subject: Here’s Why You’ll Love [Product Name]
Email Body:
[Source control separator U+000B]
Hey [Name],
[Source control separator U+000B]
With the launch just around the corner, we wanted to share why we’re so excited about [Product Name]. [List the key benefits, features, or problems it solves.] We’ve designed this with you in mind, and we believe it’s going to make a big difference in your life.
[Source control separator U+000B]
Get ready to be amazed,
[Source control separator U+000B]
[Your Name]
Day 5: The Launch Is Tomorrow!
Subject: [Product Name] Launches Tomorrow – Are You Ready?
Email Body:
[Source control separator U+000B]
Hey [Name],
[Source control separator U+000B]
Tomorrow’s the big day! [Product Name] is launching, and we couldn’t be more excited. [Remind them of the key benefits and why they should be excited.] We’ll be sending you the link as soon as it’s live, so keep an eye on your inbox.
[Source control separator U+000B]
See you tomorrow,
[Source control separator U+000B]
[Your Name]
Day 6: It’s Here! [Product Name] Is Now Available
Subject: It’s Here! [Product Name] Is Now Available
Email Body:
[Source control separator U+000B]
Hey [Name],
[Source control separator U+000B]
The wait is over—[Product Name] is officially live! [Include a link to purchase or sign up.] We’ve poured our hearts into this, and we know you’re going to love it. [Mention any limited-time offers or bonuses for early adopters.] Don’t miss out—get yours today!
[Source control separator U+000B]
Cheers,
[Source control separator U+000B]
[Your Name]
Day 7: What People Are Saying About [Product Name]
Subject: What People Are Saying About [Product Name]
Email Body:
[Source control separator U+000B]
Hey [Name],
[Source control separator U+000B]
The response to [Product Name] has been incredible! Here’s what people are already saying: [Include testimonials or early reviews.] If you haven’t grabbed yours yet, now’s the time. [Remind them of the benefits and the limited-time offer if applicable.] We’d love to hear what you think!
[Source control separator U+000B]
Get it before it’s gone,
[Source control separator U+000B]
[Your Name]

Top 10 ChatGPT Hacks top-producing Phoenix Metro real estate broker,

1. Market updates

Supply dated, authorized MLS figures for the exact geography, period, median price, days on market and inventory. The model does not obtain current MLS data merely because the prompt requests real statistics. The source’s increased-leads, showings and closings claims are intended benefits, not measured results. Have the responsible broker review customer-facing material before use.

2. Listing descriptions

Use verified bedroom/bath, area and feature details. Describe the property accurately and obtain appropriate advertising review; do not invent amenities or buyer suitability. The source’s increased-leads, showings and closings claims are intended benefits, not measured results. Have the responsible broker review customer-facing material before use.

3. Thirty short-video ideas

Generate hooks, captions and CTAs for a defined audience, then check local facts and choose a realistic production schedule. The source’s increased-leads, showings and closings claims are intended benefits, not measured results. Have the responsible broker review customer-facing material before use.

4. Open house campaign

Confirm address, permission, date/time and selling points before drafting email, social or SMS. Check channel consent and do not manufacture event urgency. The source’s increased-leads, showings and closings claims are intended benefits, not measured results. Have the responsible broker review customer-facing material before use.

5. Buyer guide

Provide relevant, sourced local information and clear limitations. A persona or ZIP code is not permission to invent neighborhood facts or steer buyers. The source’s increased-leads, showings and closings claims are intended benefits, not measured results. Have the responsible broker review customer-facing material before use.

6. Seller appointment

Compare a seller’s automated estimate with appropriate current evidence, explaining assumptions and uncertainty instead of promising a sale price. The source’s increased-leads, showings and closings claims are intended benefits, not measured results. Have the responsible broker review customer-facing material before use.

7. Newsletter

Use a verified current statistic, useful local tip and accurate description of the offered home-value review. Mailchimp/Canva formatting requests produce drafts unless an integration is actually used. The source’s increased-leads, showings and closings claims are intended benefits, not measured results. Have the responsible broker review customer-facing material before use.

8. Seven-email nurture

Teach and offer useful next steps, with consent and opt-out handling; nonresponse is not evidence someone needs more pressure. The source’s increased-leads, showings and closings claims are intended benefits, not measured results. Have the responsible broker review customer-facing material before use.

9. Relocation video

Verify the five local points and distinguish fact, opinion and examples. Humor should not stereotype communities or customers. The source’s increased-leads, showings and closings claims are intended benefits, not measured results. Have the responsible broker review customer-facing material before use.

10. Objection roleplay

Practice listening and explaining tradeoffs to a fictional hesitant seller. Do not predict interest rates or pressure a real client into timing a sale. The source’s increased-leads, showings and closings claims are intended benefits, not measured results. Have the responsible broker review customer-facing material before use.

Apply the direct-marketing teaching frame

Complete original source text

Top 10 ChatGPT Hacks top-producing Phoenix Metro real estate broker,

________________

1. Auto-Generate Local Market Update Scripts

Hack:

“Write a monthly market update script for [City/Zip Code] in Phoenix Metro using real MLS stats like median home price, days on market, and inventory levels. Make it conversational and confident.”

Use: Plug it into YouTube videos, Reels, or email blasts.

Why: Positions you as the neighborhood expert and builds consistent inbound leads.

________________

2. Custom Listing Descriptions that Sell

Hack:

“Write a high-converting MLS listing description for a [# bed/bath, sqft, unique features] home in [neighborhood] using persuasive language that targets [move-up buyers/first-time buyers/luxury clients].”

Why: Attracts more showings, offers, and buyers online without sounding robotic.

________________

3. Instagram & Reel Content in Bulk

Hack:

“Create 30 Instagram reel ideas for real estate in the Phoenix Valley targeting [first-time buyers / downsizing sellers / luxury buyers], including hooks, captions, and CTA.”

Use: Film weekly. Build a lead magnet. Link in bio. Drive DMs.

________________

4. AI-Driven Open House Scripts & Ads

Hack:

“Write an open house promo email, Facebook post, and SMS reminder for [address] happening [date/time], emphasizing [selling point: pool, kitchen, schools].”

Why: Converts neighbors into buyers and drives urgency before the event.

________________

5. Hyper-Targeted Buyer Guide Creation

Hack:

“Write a downloadable PDF buyer guide for [first-time buyers / luxury investors / relocating families] in [specific zip or suburb]. Make it personable and loaded with local value.”

Why: Use it as a lead magnet on your site or ads to grow your email list.

________________

6. Pre-Qualifying Seller Scripts for Listing Appointments

Hack:

“Write a listing presentation script for a potential seller in [neighborhood], showing local market strength, your unique strategy, and overcoming the ‘Zillow says my house is worth more’ objection.”

Use: Helps close sellers fast and frames you as the trusted expert.

________________

7. AI-Powered Newsletter Content

Hack:

“Create a weekly real estate newsletter for Phoenix homeowners that includes a local tip, current market stat, and a soft CTA to schedule a free home value review.”

Bonus: Ask ChatGPT to format it in a Mailchimp or Canva newsletter layout.

________________

8. Lead Nurture Email Sequences

Hack:

“Write a 7-part email drip campaign for [buyers/sellers] who registered on my site but haven’t responded yet. Focus on education, trust, and soft CTAs to re-engage.”

Why: Turn cold leads into warm conversations on autopilot.

________________

9. YouTube Video Script Machine

Hack:

“Write a YouTube script titled ‘Moving to [Scottsdale/Gilbert/etc.] – 5 Things You Need to Know’ that builds trust with relocating buyers.”

Bonus: Add humor or local slang to humanize it.

________________

10. Objection Crusher Roleplay Prompts

Hack:

“Act as a hesitant seller who thinks it's better to wait for interest rates to drop. I’ll respond like a Realtor—give me feedback on my script and then show me a better one.”

Use: Practice handling common objections with better confidence and clarity.

Native Google Doc text and original links

Control separators are labeled in this readable display. Download exact original text

Top 10 ChatGPT Hacks top-producing Phoenix Metro real estate broker,
1. Auto-Generate Local Market Update Scripts
Hack:
“Write a monthly market update script for [City/Zip Code] in Phoenix Metro using real MLS stats like median home price, days on market, and inventory levels. Make it conversational and confident.”
[Source control separator U+000B]
Use: Plug it into YouTube videos, Reels, or email blasts.
[Source control separator U+000B]
Why: Positions you as the neighborhood expert and builds consistent inbound leads.

2. Custom Listing Descriptions that Sell
Hack:
“Write a high-converting MLS listing description for a [# bed/bath, sqft, unique features] home in [neighborhood] using persuasive language that targets [move-up buyers/first-time buyers/luxury clients].”
[Source control separator U+000B]
Why: Attracts more showings, offers, and buyers online without sounding robotic.

3. Instagram & Reel Content in Bulk
Hack:
“Create 30 Instagram reel ideas for real estate in the Phoenix Valley targeting [first-time buyers / downsizing sellers / luxury buyers], including hooks, captions, and CTA.”
[Source control separator U+000B]
Use: Film weekly. Build a lead magnet. Link in bio. Drive DMs.

4. AI-Driven Open House Scripts & Ads
Hack:
“Write an open house promo email, Facebook post, and SMS reminder for [address] happening [date/time], emphasizing [selling point: pool, kitchen, schools].”
[Source control separator U+000B]
Why: Converts neighbors into buyers and drives urgency before the event.

5. Hyper-Targeted Buyer Guide Creation
Hack:
“Write a downloadable PDF buyer guide for [first-time buyers / luxury investors / relocating families] in [specific zip or suburb]. Make it personable and loaded with local value.”
[Source control separator U+000B]
Why: Use it as a lead magnet on your site or ads to grow your email list.

6. Pre-Qualifying Seller Scripts for Listing Appointments
Hack:
“Write a listing presentation script for a potential seller in [neighborhood], showing local market strength, your unique strategy, and overcoming the ‘Zillow says my house is worth more’ objection.”
[Source control separator U+000B]
Use: Helps close sellers fast and frames you as the trusted expert.

7. AI-Powered Newsletter Content
Hack:
“Create a weekly real estate newsletter for Phoenix homeowners that includes a local tip, current market stat, and a soft CTA to schedule a free home value review.”
[Source control separator U+000B]
Bonus: Ask ChatGPT to format it in a Mailchimp or Canva newsletter layout.

8. Lead Nurture Email Sequences
Hack:
“Write a 7-part email drip campaign for [buyers/sellers] who registered on my site but haven’t responded yet. Focus on education, trust, and soft CTAs to re-engage.”
[Source control separator U+000B]
Why: Turn cold leads into warm conversations on autopilot.

9. YouTube Video Script Machine
Hack:
“Write a YouTube script titled ‘Moving to [Scottsdale/Gilbert/etc.] – 5 Things You Need to Know’ that builds trust with relocating buyers.”
[Source control separator U+000B]
Bonus: Add humor or local slang to humanize it.

10. Objection Crusher Roleplay Prompts
Hack:
“Act as a hesitant seller who thinks it's better to wait for interest rates to drop. I’ll respond like a Realtor—give me feedback on my script and then show me a better one.”
[Source control separator U+000B]
Use: Practice handling common objections with better confidence and clarity.

Unit-Economics-Document-Template.md

Identify the offer and measurement sample

This eight-section M8.2 template targets 800–1,200 words and supports M8.8 attestation. Create one document per offer, naming version, measurement period and delivery count; the source requests at least six deliveries. Report the actual sample and limitations rather than filling missing observations with assumptions. Source curriculum labels do not replace current lesson assignments.

Compare time estimates without double counting

Section two requests average, range and standard deviation for stated and actual hours plus variance. Define sample versus population deviation and variance units. Actual hours more than thirty percent above the estimate trigger the source’s M8.3 review; exactly thirty percent does not meet a strict greater-than rule. Section three separates pre-quote, onboarding, coordination, absorbed scope, rework, post-delivery support, administration and context switching. Determine whether actual hours already include these categories before adding them; otherwise Section 2+3 doubles costs. Report each category’s share of a clearly named total.

Define the loaded rate and economic cost

Section four combines total measured hours times a loaded rate, direct costs and allocated overhead, with sources. Target compensation divided by realistic billable hours is an owner-compensation planning rate, not necessarily a market billing rate or fully burdened labor cost. Make included taxes/benefits/overhead explicit and avoid counting them twice. Software allocation, contractors and materials require a consistent per-delivery rule. Hidden hours above twenty-five percent of stated hours are a source review trigger, not proof the operator intentionally used fictional numbers.

Label margin and effective rate precisely

The template calls price minus all included cost gross margin, but owner compensation and allocated overhead can make this a broader internal economic margin. Define the cost basis before comparing it with accounting gross margin. Margin percent is (price − included cost)/price; a zero price needs separate handling. Sixty percent is a RISER target, not a universal requirement. Negative economic margin can mean owner compensation is unmet without proving cash is literally paid to the customer. Price/hours is revenue per delivery hour, not net earnings; account for nonlabor cost and actual collected revenue.

Hand off findings and sign the measured record

Sections seven/eight identify below-target margin, below-loaded-rate revenue per hour and hidden-hour variance for the M8.3 corrective branch. Link the source measurements and distinguish repricing, scope changes and delivery redesign. Include the thirty-percent actual-versus-estimate flag from Section two even though the handoff checklist omits it. Sign only an accurate record; a signature cannot validate missing data. Carry the same cost definition into later pricing and attestation work.

Apply the direct-marketing teaching frame

Complete original source text

# Unit Economics Document Template

**Used in:** M8.2 deliverable · **Length target:** 800-1,200 words · **Filed in:** Drive + linked from M8.8 Attestation

---

## Section 1 — Offer Identification

State the offer this document covers. Pricing systems are offer-specific; operators with multiple offers produce one Unit Economics Document per offer.

**Offer name:**
**Offer version:** (e.g., v1.0, v2.0 if iterated through C7)
**Period covered:** (e.g., "all deliveries January 1 – April 1, 2026")
**Number of deliveries analyzed:** (minimum 6)

---

## Section 2 — Stated vs Actual Hours

State the original C4/C7 hour estimate and the C7-measured actual hours.

| | Stated | Actual | Variance |
|---|---|---|---|
| Average per delivery | | | |
| Range across deliveries | | | |
| Std deviation | | | |

If actual hours exceed stated by > 30%, this triggers an automatic M8.3 reality check decision. State that here.

---

## Section 3 — Hidden Hours Audit

Per the M8.2 8-category audit:

| Category | Hours per delivery | % of total |
|---|---|---|
| Pre-quote / scoping | | |
| Onboarding | | |
| Coordination / handoffs | | |
| Scope-creep absorbed | | |
| Rework / quality recovery | | |
| Post-delivery support | | |
| Administrative / billing | | |
| Context-switching cost | | |
| **Total hidden hours** | | |

If total hidden hours > 25% of stated hours, the original price was set against a fictional cost basis. State that.

---

## Section 4 — True Cost per Unit

| Component | Per delivery | Source |
|---|---|---|
| Operator hours (total incl. hidden) × loaded rate | | Section 2+3 × loaded rate |
| Direct costs (software, contractors, materials) | | C7 financial tracking |
| Allocated overhead | | C7 financial tracking |
| **Total cost per delivery** | | |

The loaded rate is operator-self compensation, not market rate. Use M8.2 calculation: target compensation ÷ billable hours = loaded rate. Do not use industry "consulting rate" benchmarks; they are not your cost.

---

## Section 5 — Gross Margin

| Metric | Value |
|---|---|
| Stated price | $ |
| Total cost (Section 4) | $ |
| Gross margin $ | $ |
| Gross margin % | % |

If margin < 60% (knowledge-work doctrine), state explicitly: "This offer operates below the C8 Pricing Discipline doctrine threshold of 60% gross margin for knowledge-work."

If margin is negative, state: "This offer operates at negative gross margin. Each delivery destroys economic value."

---

## Section 6 — Effective Rate

Effective rate = stated price / total hours (including hidden).

| | Value |
|---|---|
| Stated effective rate (price / stated hours) | $/hr |
| Actual effective rate (price / total hours) | $/hr |
| Gap | $/hr |

If the actual effective rate is below the operator's loaded rate (Section 4 input), the operator is paying customers to deliver the offer. State that explicitly.

---

## Section 7 — M8.3 Hand-Off

State the unit economics findings that M8.3 must address. Specifically:

- Is the gross margin below 60%? If yes, M8.3 must select a corrective branch.
- Is the effective rate below the loaded rate? If yes, M8.3 must select a corrective branch.
- Are hidden hours > 25% of stated? If yes, M8.3 must address whether the corrective branch is repricing or scope tightening.

The M8.3 reviewer reads this section to determine which decision branches are mandatory vs optional.

---

## Section 8 — Operator Acknowledgment

The operator signs the document acknowledging the findings. The signature is the discipline statement: the operator has read the actual numbers, not the imagined numbers, and the M8.3 reality check will operate against the actual numbers.

Suggested sign-off:

> *I acknowledge that the unit economics in this document reflect measured reality from C7 data, including [N] deliveries from [period]. I will operate M8.3 against these numbers, not against the C4 pricing intent. I understand that pricing discipline begins with arithmetic, not aspiration.*

---

*This template produces the foundational artifact for all subsequent C8 modules. Without honest unit economics, the rest of C8 produces well-formed but ungrounded artifacts.*

Lesson 03.2 — sources for the added teaching sections

You are an RN-MOS Structured Curriculum Intelligence Engine

Treat the curriculum prompt as a source specification

This document is a reusable prompt for extracting module records into a thirty-two-column CSV. Its instructions to output only rows and stop commentary govern that proposed extractor, not this curriculum-building task. Analyze topic, objective, actions, tools, automation, SOPs, examples, keywords, monetization and obvious cross-links. Keep extracted facts distinct from inferred classification; a mentioned automation is not deployed functionality.

CSV fields 1–8

Preserve this exact field order: 1 Module_ID, 2 Module_Number, 3 Module_Name, 4 Category_Name, 5 Phase_Learn, 6 Phase_Build, 7 Phase_Do, 8 Phase_Scale. Keep blank values in their correct columns. The five phase flags need an agreed representation; the prompt does not define their data type. Do not invent missing source links, duration, examples or prerequisite assignments.

CSV fields 9–16

Preserve this exact field order: 9 Phase_Legacy, 10 Primary_Objective, 11 Key_Outcomes, 12 Tutorial_Format, 13 Content_Type, 14 Real_World_Example, 15 SOP_Referenced, 16 Tools_Mentioned. Keep blank values in their correct columns. The five phase flags need an agreed representation; the prompt does not define their data type. Do not invent missing source links, duration, examples or prerequisite assignments.

CSV fields 17–24

Preserve this exact field order: 17 AI_Tools, 18 Automations, 19 Prompts_Required, 20 Keywords_Primary, 21 Keywords_Secondary, 22 Value_Ladder_Level, 23 Offer_Type, 24 Monetization_Path. Keep blank values in their correct columns. The five phase flags need an agreed representation; the prompt does not define their data type. Do not invent missing source links, duration, examples or prerequisite assignments.

CSV fields 25–32

Preserve this exact field order: 25 PDF_Assets, 26 Internal_Links, 27 External_Links, 28 Case_Study_Link, 29 Difficulty_Level, 30 Prerequisite_Modules, 31 Estimated_Duration, 32 Notes. Keep blank values in their correct columns. The five phase flags need an agreed representation; the prompt does not define their data type. Do not invent missing source links, duration, examples or prerequisite assignments.

Validate rows and identifiers

The source requests comma separation, pipe-separated lists inside cells, no header and one row per detected module. Use a CSV writer and correctly quote cells containing commas, quotes or newlines; a pipe does not remove CSV escaping requirements. Use unique registered RNMOS-### identifiers rather than merely plausible ones, and keep existing course/lesson IDs intact. Allowed difficulty labels are Beginner, Intermediate, Advanced and Operator; ladder labels are Free, Low Ticket, Core, High Ticket, Certification and License. A category label does not establish a certification or licensing entitlement. Relevant buyer-intent keywords support clarity; they do not guarantee SEO, AEO or GEO ranking.

Apply the RISER direct-marketing frame

Use Brunson’s hook-story-offer progression to explain a relevant problem, show supported evidence and offer one clear next step. Use the Hormozi value lens to reduce unnecessary effort and delay while improving credible usefulness. Preserve actual delivery limits, customer choice and truthful proof; neither framework guarantees market fit or search rankings.

Complete original source text

You are an RN-MOS Structured Curriculum Intelligence Engine.





Your job is to read the provided documents and distribute their content into a CSV-ready row format using the RN-MOS Master Course Sheet Schema.





CRITICAL RULES:

- Output ONLY valid CSV rows.

- Do NOT include explanations.

- Do NOT include commentary.

- Do NOT include markdown.

- Do NOT include column headers.

- Separate columns with commas.

- Use | (pipe symbol) inside cells when listing multiple items.

- Leave empty fields blank but preserve comma placement.

- Do NOT break row formatting.





-----------------------------------------

RN-MOS MASTER COURSE SHEET COLUMN ORDER:

-----------------------------------------





1 Module_ID

2 Module_Number

3 Module_Name

4 Category_Name

5 Phase_Learn

6 Phase_Build

7 Phase_Do

8 Phase_Scale

9 Phase_Legacy

10 Primary_Objective

11 Key_Outcomes

12 Tutorial_Format

13 Content_Type

14 Real_World_Example

15 SOP_Referenced

16 Tools_Mentioned

17 AI_Tools

18 Automations

19 Prompts_Required

20 Keywords_Primary

21 Keywords_Secondary

22 Value_Ladder_Level

23 Offer_Type

24 Monetization_Path

25 PDF_Assets

26 Internal_Links

27 External_Links

28 Case_Study_Link

29 Difficulty_Level

30 Prerequisite_Modules

31 Estimated_Duration

32 Notes





-----------------------------------------

INSTRUCTIONS:

-----------------------------------------





1. Analyze the document(s).

2. Identify:

   - Core topic

   - Learning objective

   - Action steps

   - Tools referenced

   - AI tools referenced

   - Automations mentioned

   - SOP-style processes

   - Real-world examples

   - Keywords (primary and secondary)

   - Monetization potential

   - Internal module cross-links (if obvious)

3. Assign:

   - Difficulty level (Beginner | Intermediate | Advanced | Operator)

   - Value ladder level (Free | Low Ticket | Core | High Ticket | Certification | License)

4. Generate a realistic Module_ID formatted as RNMOS-###.

5. If multiple modules are detected, output multiple CSV rows.

6. Ensure formatting integrity.

Use SEO, AEO, and GEO optimization logic when extracting keywords.

Favor buyer-intent and action-oriented phrases.









-----------------------------------------

BEGIN ANALYSIS.

-----------------------------------------

Native Google Doc text and original links

You are an RN-MOS Structured Curriculum Intelligence Engine.

Your job is to read the provided documents and distribute their content into a CSV-ready row format using the RN-MOS Master Course Sheet Schema.

CRITICAL RULES:
- Output ONLY valid CSV rows.
- Do NOT include explanations.
- Do NOT include commentary.
- Do NOT include markdown.
- Do NOT include column headers.
- Separate columns with commas.
- Use | (pipe symbol) inside cells when listing multiple items.
- Leave empty fields blank but preserve comma placement.
- Do NOT break row formatting.

-----------------------------------------
RN-MOS MASTER COURSE SHEET COLUMN ORDER:
-----------------------------------------

1 Module_ID
2 Module_Number
3 Module_Name
4 Category_Name
5 Phase_Learn
6 Phase_Build
7 Phase_Do
8 Phase_Scale
9 Phase_Legacy
10 Primary_Objective
11 Key_Outcomes
12 Tutorial_Format
13 Content_Type
14 Real_World_Example
15 SOP_Referenced
16 Tools_Mentioned
17 AI_Tools
18 Automations
19 Prompts_Required
20 Keywords_Primary
21 Keywords_Secondary
22 Value_Ladder_Level
23 Offer_Type
24 Monetization_Path
25 PDF_Assets
26 Internal_Links
27 External_Links
28 Case_Study_Link
29 Difficulty_Level
30 Prerequisite_Modules
31 Estimated_Duration
32 Notes

-----------------------------------------
INSTRUCTIONS:
-----------------------------------------

1. Analyze the document(s).
2. Identify:
   - Core topic
   - Learning objective
   - Action steps
   - Tools referenced
   - AI tools referenced
   - Automations mentioned
   - SOP-style processes
   - Real-world examples
   - Keywords (primary and secondary)
   - Monetization potential
   - Internal module cross-links (if obvious)
3. Assign:
   - Difficulty level (Beginner | Intermediate | Advanced | Operator)
   - Value ladder level (Free | Low Ticket | Core | High Ticket | Certification | License)
4. Generate a realistic Module_ID formatted as RNMOS-###.
5. If multiple modules are detected, output multiple CSV rows.
6. Ensure formatting integrity.
Use SEO, AEO, and GEO optimization logic when extracting keywords.
Favor buyer-intent and action-oriented phrases.


-----------------------------------------
BEGIN ANALYSIS.
-----------------------------------------

YouTube Class Action Guide - Real Estate (1).pdf

Use the action guide as a worksheet

The six-page Think Media guide has a cover, four exercise pages and a resources/promotion page. Its first exercise asks for four reasons to use YouTube, ways to grow views, conversion-to-prospect systems and a sustainable production process. It does not supply the four answers or a full class transcript. Develop your own evidence-based answers and label them as your plan. Printed page numbers on the first two exercise pages are out of order; use the worksheet headings and actual page order.

Choose a focused channel and useful questions

The second exercise asks for your real-estate niche, one main channel topic, subtopics, answered questions and evidence of audience interest. Search autocomplete and comparable video views are signals, not exact audience counts or proof that a popular topic will grow your channel. The guide names vidIQ, Keywords Everywhere and TubeBuddy; its embedded vidIQ link includes a source campaign path. YouTube describes search relevance in terms of the query and video content/metadata; popularity alone is not a ranking guarantee.

Build four types of video and one next action

The third exercise asks for prospect questions, industry/local news, relevant product/service/tool reviews and current industry/local trends. Verify dates and facts, disclose relevant relationships and match the topic to a real customer task. The fourth exercise asks for the next step and one action: choose a specific researched question, outline a useful answer, name the next step and schedule production. Do not treat a blank worksheet as a completed content strategy.

Read the resource and offer page accurately

The final page links ThinkMediaTools, ThinkGearGuide, TalkWithThink, ThinkMediaSupport, VRAdeal and an embedded course offer. These are third-party source resources, not RISER products or evidence that an old limited-time offer remains available. The source lists Video Ranking Academy $3,997; Camera Confidence $597; monthly Q&A $5,964; starter kit $529; niche finder $597; Shorts $297; AI for YouTube $97; and lifetime access described as priceless. The seven numeric amounts sum to $12,078, matching the displayed stated-value total; this is not the selling price or independent valuation. Cover art and promotional product mockups are visual branding, not additional playable lessons.

Apply the RISER direct-marketing frame

Complete original source text

Views on YouTube

How To Get More

ACTION GUIDEWhat are the 4 reasons to go all-in on YouTube?

How can you increase your views?

How do you plan on converting your viewers into prospects? What systems do you have or that

you need to create to make this happen?

What kind of systems do you need to put in place to make this a sustainable and repeatable

process?

THE 4 BENEFITS OF MAKING REAL

ESTATE CONTENT ON YOUTUBE

AND HOW TO TURN THAT INTO A

YOUTUBE BUSINESS FRAMEWORK.

3

H

O

W

T

O

G

E

T

M

O

R

E

VIE

WS

O

N

YO

U

T

UB

E

www.VRAdeal.comWhat real estate niche are you in? What is the ONE main topic you discuss on your channel?

What are some of the specific topics within real estate you can cover on your channel?

What kinds of questions do you answer?

How many people are interested in your channel topic & video topic? You can discover this by

going to the YouTube search bar and typing in some of your keywords - what autofills? Now when

you search it, are videos around that topic getting a lot of views? You can also use tools like vidIQ,

Keywords Everywhere and TubeBuddy to find search volume around your topics.

CHANNELS THAT GROW FAST ON

YOUTUBE ARE IN POPULAR AND

HIGHLY SEARCHED FOR NICHES.

H

O

W

T

O

G

E

T

M

O

R

E

VIE

WS

O

N

YO

U

T

UB

E

2

www.VRAdeal.comBrainstorm and write some video ideas out for the following:

What specific questions do my prospects have that I can help answer?

What news or updates in my industry or even my area can I create a video on?

Are there any products, services, and/or tools that I would recommend and review to help my

prospects with their real estate goals?

What current trends can I speak into for the real estate industry and for the local market I service?

I CAN CREATE DIFFERENT KINDS

OF VIDEOS TO DRAW IN NEW

PROSPECTS TO MY CHANNEL AND

BUILD A PERSONAL BRAND

4

H

O

W

T

O

G

E

T

M

O

R

E

VIE

WS

O

N

YO

U

T

UB

E

www.VRAdeal.comWhat is my NEXT STEP based on what I learned today?

What is the ONE thing I'm going to do next?

CREATE SEARCHED‑BASED

NICHE VIDEOS AROUND TOPICS

YOUR PROSPECTS WOULD BE

MOST INTERESTED IN

5

H

O

W

T

O

G

E

T

M

O

R

E

VIE

WS

O

N

YO

U

T

UB

E

www.VRAdeal.comMORE RESOURCES

ThinkMediaTools.com

This guide shows

you all the tools we

use here at Think

on a daily basis.

From editing tools to project

management to social media

scheduling. Plus, get special

offers and discounts!

ThinkGearGuide.com

Want guidance

on what gear to

get?

Get recommendations

based on your needs and

budget!

TalkWithThink.com

Have a question

about our courses

and programs? Get in

touch with someone

from the Think team! You

can reach out to us by going

to ThinkMediaSupport.com

6

H

O

W

T

O

G

E

T

M

O

R

E

VIE

WS

O

N

YO

U

T

UB

E

Take Action Today!

Video Ranking Academy is the

Premier Online YouTube

Coaching Program & Community

And as someone who was a part of our webclass,

you get a special limited-time offer with exclusive

bonuses - so make sure to head to VRAdeal.com

now to learn more!

• Video Ranking Academy ($3,997 Value)

• Camera Confidence ($597 Value)

• Monthly Private Group Q&A Sessions ($5,964

Value)

• YouTube Starter Kit ($529 Value)

• YouTube Niche Finder Course ($597 Value)

• YouTube Shorts Masterclass ($297 Value)

• A.I. for YouTube ($97 Value)

• *LIMITED* Lifetime Access (Priceless)

WHAT'S INCLUDED?

TOTAL $12,078 VALUE

Native PDF page text and embedded links

PAGE 1
Views on YouTube
How To Get More
ACTION GUIDE
Links: 

PAGE 2
What are the 4 reasons to go all-in on YouTube?
How can you increase your views?
How do you plan on converting your viewers into prospects? What systems do you have or that
you need to create to make this happen?
What kind of systems do you need to put in place to make this a sustainable and repeatable
process?
THE 4 BENEFITS OF MAKING REAL
ESTATE CONTENT ON YOUTUBE
AND HOW TO TURN THAT INTO A
YOUTUBE BUSINESS FRAMEWORK.
3
HOW TO GET MORE VIEWS ON YOUTUBE
www.VRAdeal.com
Links: http://www.vradeal.com/

PAGE 3
What real estate niche are you in? What is the ONE main topic you discuss on your channel?
What are some of the specific topics within real estate you can cover on your channel?
What kinds of questions do you answer?
How many people are interested in your channel topic & video topic? You can discover this by
going to the YouTube search bar and typing in some of your keywords - what autofills? Now when
you search it, are videos around that topic getting a lot of views? You can also use tools like vidIQ,
Keywords Everywhere and TubeBuddy to find search volume around your topics.
CHANNELS THAT GROW FAST ONYOUTUBE ARE IN POPULAR ANDHIGHLY SEARCHED FOR NICHES.
HOW TO GET MORE VIEWS ON YOUTUBE
2
www.VRAdeal.com
Links: https://vidiq.com/think/ | http://www.vradeal.com/

PAGE 4
Brainstorm and write some video ideas out for the following:
What specific questions do my prospects have that I can help answer?
What news or updates in my industry or even my area can I create a video on?
Are there any products, services, and/or tools that I would recommend and review to help my
prospects with their real estate goals?
What current trends can I speak into for the real estate industry and for the local market I service?
I CAN CREATE DIFFERENT KINDSOF VIDEOS TO DRAW IN NEWPROSPECTS TO MY CHANNEL ANDBUILD A PERSONAL BRAND
4
HOW TO GET MORE VIEWS ON YOUTUBE
www.VRAdeal.com
Links: http://www.vradeal.com/

PAGE 5
What is my NEXT STEP based on what I learned today?
What is the ONE thing I'm going to do next?
CREATE SEARCHED ‑ BASEDNICHE VIDEOS AROUND TOPICSYOUR PROSPECTS WOULD BEMOST INTERESTED IN
5
HOW TO GET MORE VIEWS ON YOUTUBE
www.VRAdeal.com
Links: http://www.vradeal.com/

PAGE 6
MORE RESOURCES
ThinkMediaTools.com
This guide shows
you all the tools we
use here  at Think
on a daily basis.
From editing tools to project
management to social media
scheduling. Plus, get special
offers and discounts!
ThinkGearGuide.com
Want guidance
on what gear to
get? 
Get recommendations
based on your needs and
budget!
TalkWithThink.com
Have a question
about our courses
and programs? Get in
touch with someone 
from the Think team! You
can reach out to us by going
to ThinkMediaSupport.com
6
HOW TO GET MORE VIEWS ON YOUTUBE
Take Action Today!Video Ranking Academy is thePremier Online YouTubeCoaching Program & Community
And as someone who was a part of our webclass,
you get a special limited-time offer with exclusive
bonuses - so make sure to head to VRAdeal.com
now to learn more!
• Video Ranking Academy ($3,997 Value)
• Camera Confidence ($597 Value)
• Monthly Private Group Q&A Sessions ($5,964
Value)
• YouTube Starter Kit ($529 Value)
• YouTube Niche Finder Course ($597 Value)
• YouTube Shorts Masterclass ($297 Value)
• A.I. for YouTube ($97 Value)
• *LIMITED* Lifetime Access (Priceless)
WHAT'S INCLUDED?
 TOTAL  $12,078 VALUE
Links: http://thinkgearguide.com/ | http://thinkmediatools.com/ | http://talkwiththink.com/ | http://thinkmediatools.com/ | http://thinkgearguide.com/ | http://talkwiththink.com/ | http://thinkmediasupport.com/ | http://vradeal.com/ | http://www.vradeal.com/ | https://courses.seancannell.com/niche-finder-join-vra-a | https://courses.seancannell.com/niche-finder-join-vra-a | https://courses.seancannell.com/niche-finder-join-vra-a | https://courses.seancannell.com/niche-finder-join-vra-a | https://courses.seancannell.com/niche-finder-join-vra-a

Demonstration

An illustrative installation offer includes a workflow design, configuration session, test checklist, and handoff guide. A bonus library of unrelated templates adds reading burden. A troubleshooting checklist tied to common setup errors serves the promised result.

Apply the supporting documents

Use the lesson appendix as the source workbench. Read the relevant frameworks, complete the worksheets, inspect the examples, and test any prompts or technical procedures in the context of your own business. Preserve source-specific assumptions and thresholds. A prompt is an instruction template, a worksheet is a work product, and a case example is not a universal result. When sources disagree, record both positions and use the current lesson purpose and observed evidence to decide what applies.

Implementation

Create the delivery map and value stack with scope, responsibilities, milestones, and capacity assumptions.

Completion standard

Each item has a defined purpose, owner, delivery point, and cost or capacity implication.

Next step

Carry the completed work into 03.3 Price, Proof, Risk Reversal and Validation. If the proof standard is not met, record the missing evidence or failed test and resolve it before relying on this result.

Starting references

Complete assigned-source appendix

Assigned documents (209)

Open the original document for its full source content. Access follows each document’s existing permissions.

01 Custom GPT Templates/custom-gpt-avatar-builderPrimary
01_OFFER_WALL__DIY_DWY_DFY_LicensePrimary
02 – Offer Wall Copy (Blunt + Premium)Primary
Anti-Discount-Language-Swipe-File.mdPrimary
C28 - AI Marketing Stack 2026 (Applied) - Course OverviewPrimary
C6-Offer-Document-v1.1-Template.mdPrimary
C6-Offer-Document-v1.1-Template.mdPrimary
C7-Architecture-vs-Pivot-Distinction-Clause.mdPrimary
C7-Deliverable-Decomposition-Template.mdPrimary
C7-Distinction-Statement-Template.mdPrimary
C7-Honest-Capacity-Clause.mdPrimary
C7-Lifecycle-Gate-Language-Swipe-File.mdPrimary
C7-Offer-Architecture-Document-Template.mdPrimary
C7-Offer-Document-v2.0-Template.mdPrimary
CNX.6.4.2 – Real_Estate_Lifetime_Value_of_Client.docxPrimary
deliverable-decomposition-reviewer-v1.0.0.yamlPrimary
high-converting product page copy for selling your Template Architect GPT as a premium digital productPrimary
M20.5 - MESSAGE ARCHITECTURE ENFORCEMENTPrimary
M26.8 - THE VERCEL-NETLIFY AI DEPLOYMENT STACKPrimary
M31.3 - THE LEAN STACK ($150-MONTH)Primary
M31.4 - THE ENTERPRISE STACK ($1,500-MONTH)Primary
M6.2 - TRIM & STACK METHODOLOGYPrimary
M7.4 - THE STACK SLIDEPrimary
offer-v2-reviewer-v1.0.0.yamlPrimary
Raise-Communication-Swipe-File.mdPrimary
REAL ESTATE INVESTMENT HOMESPrimary
RN-10_Product_Optimization_CreatorFlow_2025_POPULATED.docxPrimary
The "Problem-Agitate-Solution" (PAS) Formula adapted for videoPrimary
To give your coaching clients a real "edge," here are 10 high-impact, real-world use cases for the 2026 Google AI stackPrimary
VALUE LADDER PRODUCT AND BONUS IDEASPrimary
# MARIA WENDT — COMPLETE OFFER RECREATION PROMPT DOCUMENTCross-listed
# Talking Heads, Realtor Videos, Templates & Brand SetupCross-listed
✅ 1. The Complete RISER Offer Wall Value Ladder (Low → Mid → High Ticket)Cross-listed
📄 1. Persona Summary Sheet TemplateCross-listed
📘 SOP: B2C Value Ladder & Funnel Creation (Offer Stack Model)Cross-listed
🧲 SYLLABUS 1 — Lead Magnet Creation System (Level 0)Cross-listed
🚀 THE DIGITAL MARKETING BEGINNER’S VALUE LADDER + FUNNEL SYSTEM (2025 Edition)Cross-listed
🚀 Your Offer GPT — Final System InstructionsCross-listed
🟣 THE ULTIMATE PRODUCT LAUNCH FRAMEWORKCross-listed
01_PRODUCT_DESCRIPTION — 8.) Offer Mutation Engine (RN_MANAGED)Cross-listed
02 Custom GPT Templates/custom-gpt-copy-creatorCross-listed
02 File: intake-product-profileCross-listed
03 Custom GPT Templates/custom-gpt-review-interpreterCross-listed
03. Creating a Unique Value Proposition (USP)Cross-listed
03. Optimize for Customer Lifetime Value (CLV)Cross-listed
04. Define Digital Product ResearchCross-listed
06 Custom GPT Templates/custom-gpt-launch-strategy-builderCross-listed
10 : Real_Estate_Professionals_Full_System.docxCross-listed
12.) THE 5W's and HCross-listed
2.) WHAT PROBLEMS YOU SOLVECross-listed
2.Course 49 — AI Workforce Architecture & Role ReplicationCross-listed
3.) STAR, STORY, SOLUTIONCross-listed
3.) THE OFFER YOU SELL THEM-SOLVING THE PROBLEMSCross-listed
3.Course 49 — AI Workforce Architecture & Role Replication (2026 Edition)Cross-listed
4. L3 – CORE OFFER ($97–$997)Cross-listed
4) - LEVEL CHANGING ASSETSCross-listed
5.) HOW THE OFFER WILL HELP THEMCross-listed
6.) LIFE AFTER ACCEPTING MY OFFERCross-listed
6.) THE PROBLEM AGITATE SOLUTION.PAS-VIDEOCross-listed
8.) PROBLEM-SOLUTION-DEMOCross-listed
AI Customer SupportCross-listed
Anti-Discount-Policy-Template.mdCross-listed
Avatar & Offer Extractor GPT (Document Intake & Analysis)Cross-listed
Brandy Aguirre – Arizona Real Estate.xlsxCross-listed
BUILDING THE PRODUCTCross-listed
C4-Archetype-Adjustments.mdCross-listed
C5-Archetype-Adjustments.mdCross-listed
C5-First-Sale-Outreach-Swipe-File.mdCross-listed
C5-Offer-to-Public-Existence-Memo-Template.mdCross-listed
C6-Customer-Feedback-Loop-Specification-Template.mdCross-listed
C6-Customer-Feedback-Loop-Specification-Template.mdCross-listed
C6-Customer-Onboarding-Playbook-Template.mdCross-listed
C6-Customer-Onboarding-Playbook-Template.mdCross-listed
C6-Customer-Onboarding-Swipe-File.mdCross-listed
C6-Customer-Onboarding-Swipe-File.mdCross-listed
C6-Honest-Customer-Representation-Clause.mdCross-listed
C6-Honest-Customer-Representation-Clause.mdCross-listed
C6-Iteration-Discipline-Clause.mdCross-listed
C6-Iteration-Discipline-Clause.mdCross-listed
C6-Stage-2-Operating-Cadence-Template.mdCross-listed
C6-Stage-2-Operating-Cadence-Template.mdCross-listed
C7 handoff summaryCross-listed
C7-3-Customer-Test-Worksheet.mdCross-listed
C7-Bespoke-Architecture-Trap-Recognition-Checklist.mdCross-listed
C7-Capacity-Constraint-Analysis-Template.mdCross-listed
C7-Course-README.mdCross-listed
C7-Customer-Lifecycle-Map-Template.mdCross-listed
C7-Honest-Capacity-Framework.mdCross-listed
C7-Learning-Outcomes.mdCross-listed
C7-Offer-Architecture-Deployment-SOP.docxCross-listed
C7-Offer-Architecture-Deployment-SOP.docxCross-listed
C7-Offer-Architecture-v2.0.zipCross-listed
C7-Operator-Bandwidth-Audit-Template.mdCross-listed
C7-README.mdCross-listed
C7-Scope-Creep-Recovery-Script.mdCross-listed
C7-SOP-01-Deliverable-Decomposition-Rollout.mdCross-listed
C7-SOP-Construction-Swipe-File.mdCross-listed
C7-SOP-Operability-Clause.mdCross-listed
C8 handoff summaryCross-listed
C8-Course-README.mdCross-listed
C8-Learning-Outcomes.mdCross-listed
C8-Prerequisites-Checklist.mdCross-listed
C8-README.mdCross-listed
C8-SOP-01-Unit-Economics-Refresh-Cycle.mdCross-listed
capacity-analysis-reviewer-v1.0.0.yamlCross-listed
Case-Failure-Customer-as-Product-Manager-Trap.mdCross-listed
Case-Failure-Customer-as-Product-Manager-Trap.mdCross-listed
Case-Failure-The-Feature-Stuffing-Trap.mdCross-listed
Case-Priya-Service-Operator-C4-Journey.mdCross-listed
Case-Priya-Service-Operator-C6-Journey.mdCross-listed
Case-Priya-Service-Operator-C6-Journey.mdCross-listed
Case-Priya-Service-Operator-C7-Journey.mdCross-listed
CHAPTER 3 - THE SCIENCE OF CREATING OFFERS PEOPLE FEEL STUPID SAYING NO TOCross-listed
CHAPTER 5 - THE 7-LAYER OFFER ARCHITECTURE BLUEPRINTCross-listed
CHAPTER 7-THE OFFER ENGINEERING WORKSHOPCross-listed
CHAPTER 8 - PRODUCTIZATION, PACKAGING & DELIVERY SYSTEMSCross-listed
CNX.1.4.2 – Customer_Avatar_Worksheet.xlsxCross-listed
CNX.3.10.11 – ETSY-CREATE MY TOP PRODUCT.docxCross-listed
CNX.3.10.15 – AI_Prompt_For_Service_Based_Business_Funnels.docxCross-listed
CNX.3.10.16 – AI_Prompt_For_Digital_Product_And_Course_Development.docxCross-listed
CNX.3.11.0 – Offer_Development_Bootcamp_Master_TOC.docxCross-listed
CNX.3.11.11 – Offer_Dev_Workbook_Master_Offer_Blueprint.docxCross-listed
CNX.3.11.8 – Offer_Dev_Module_8_Bonuses_Value_Stacks_And_Irresistible_Angles.docxCross-listed
CNX.3.11.9 – Offer_Dev_Module_9_Platforms_And_Delivery_Systems.docxCross-listed
CNX.6.5.5 – Brick_and_Mortar_Buyer_Persona_Development_Framework.docxCross-listed
CNX.6.6.1 – Jobs_To_Be_Done_Framework_Prompt_And_Implementation_GuideCross-listed
CNX.9.12 – Digital Marketing Proposal & Scope of Work (Service Pricing Matrix).docxCross-listed
Copy of VALUE LADDER PRODUCT AND BONUS IDEASCross-listed
Customer Lifetime Value Optimization WorkbookCross-listed
customer-lifecycle-reviewer-v1.0.0.yamlCross-listed
DEEP AVATAR GPTCross-listed
Every course below utilizes the Sovereign Curriculum Shell and is expanded with 12 mastermind-level modules, integrating the latest MCP (Model Context Protocol) servers, Agentic State Graphs (LangGraph/CrewAI), and Causal Inference modelsCross-listed
fbt-theofferstackv5.htmlCross-listed
fulfillment-sop-reviewer-v1.0.0.yamlCross-listed
FUNNEL FRAME IDEASCross-listed
FUNNEL TO FRAME WORK vs YOUR INDUSTRY MATRIXCross-listed
GOOGLE SEARCH FOR : marketing plan template for product launchCross-listed
Here are the **top 10 practical ways** to add value to what you sellCross-listed
Here is the complete value ladder and offer wall for **mariawendtCross-listed
Hidden-Hours-Audit-Worksheet.mdCross-listed
Jobs to be Done — the core ideaCross-listed
Keyword Difficulty Calculator TemplateCross-listed
Looking through the BUILD folder catalog, here are the documents that support Module 005 — Platform Churn Immunity:Cross-listed
M13.2 - THE 2026 PRODUCTION STACKCross-listed
M13.7 - AI IMAGE STACK (MIDJOURNEY, FLUX, STABLE DIFFUSION, COMFYUI)Cross-listed
M18.2 - THE AUTHORITY SERIES FORMATCross-listed
M18.4 - DM-TO-CALL ARCHITECTURECross-listed
M20.2 - LOGO DESIGN (CANVA-FIRST)Cross-listed
M24.1 - LEVEL 1 — CONVERSATIONAL PROMPTINGCross-listed
M24.2 - LEVEL 2 — SYSTEM PROMPTS AS CONSTITUTIONCross-listed
M24.3 - LEVEL 3 — ENGINEERED PRODUCTION PROMPTSCross-listed
M26.12 - THE CLAUDE CHROME MINI-PRODUCTCross-listed
M32.6 - TOOL SWAP TABLES & APPROVED STACKCross-listed
M6.3 - ENHANCERS — BONUSES, SCARCITY, URGENCY, GUARANTEESCross-listed
M6.6 - DOWNSELL ARCHITECTURECross-listed
M7.3-Written-Lesson.mdCross-listed
M7.3-Written-Lesson.mdCross-listed
M7.7-Written-Lesson.mdCross-listed
M7.7-Written-Lesson.mdCross-listed
M8.4-Written-Lesson.mdCross-listed
M8.4-Written-Lesson.mdCross-listed
M8.5-Written-Lesson.mdCross-listed
M9.2 - AWARENESS-LEVEL MATCHINGCross-listed
M9.6-Setting-the-New-Heading.mdCross-listed
Margin-Benchmarks-by-Offer-Type.mdCross-listed
Module 061 — Org Chart Architecture & Role Design — PromptCross-listed
NICHE-CORE OFFERS (A-A)Cross-listed
Offer Prerequisites & Long‑Term Offer ArchitectureCross-listed
offer-architecture-validator-v1.0.0.yamlCross-listed
OP-05 — Economics Truth Enforcer — Custom GPT System MessageCross-listed
OP-28 — Delivery Optimization EngineCross-listed
Portfolio Governor — Offer Wall Engine™ (v1.0)Cross-listed
Price-Raise-Schedule-Template.mdCross-listed
Pricing-Architecture-Document-Template.mdCross-listed
pricing-architecture-reviewer-v1.0.0.yamlCross-listed
Pricing-Math-Spreadsheet-Template.mdCross-listed
Problem-Solution-DemonstrationCross-listed
QM-Audit-C7-Scorecard.xlsxCross-listed
QM-Audit-C7.jsonCross-listed
QM-Audit-C7.jsonCross-listed
QM-Audit-C8-Scorecard.xlsxCross-listed
QM-Audit-C8.jsonCross-listed
QUESTIONS FOR SERVICE PROVIDERSCross-listed
real estate agent trainingCross-listed
RISER — 1 Current Scope — Product Description + Sales LetterCross-listed
RISER NATION — GPT ARCHITECTURE OUTLINECross-listed
RISER_Launch_Walkthrough_Personalized_Expert_Script.docxCross-listed
RISER_Nation_Value_Ladder_Generator_v2_(Curriculum-Integrated_2025).docxCross-listed
RISER_SYS_16_OPERATOR_APPENDICES_OSCross-listed
RISER-Bonus-Discipline-Audit-SOP.docxCross-listed
RISER-Build-References-for-C7.mdCross-listed
riser-offer-stackCross-listed
riser-offer-stack (1).htmlCross-listed
riser-offer-stack.htmlCross-listed
RISER-Value-Ladder-Architecture-SOP (1).docxCross-listed
SECTION 38 — THE AUTOMATION STACK (MAKECross-listed
SOP_13.1_Real-Time_AI_Avatars.docxCross-listed
STAR, STORY, SOLUTIONCross-listed
Supabase-C7-Schema.mdCross-listed
The "Problem-Agitate-Solution" (PAS) FormulaCross-listed
The "Star, Story, Solution" MethodCross-listed
THE BEAVER BUILDER THEME ARCHITECT GPT™sales page for your new product:Cross-listed
THE CORE SHIFT AT SCALE (MOST PEOPLE MISS THIS)Cross-listed
The Hidden Architecture of Success: Why Your "Industry" Label is Sabotaging Your GrowthCross-listed
The Product Launch Sequence (SCRIPT)Cross-listed
Top 10 ChatGPT Hacks top-producing Phoenix Metro real estate broker,Cross-listed
Unit-Economics-Document-Template.mdCross-listed
You are an RN-MOS Structured Curriculum Intelligence EngineCross-listed
YouTube Class Action Guide - Real Estate (1).pdfCross-listed