Companion to the Paper. The Paper makes the argument; the Playbook is the working toolkit — the diagnostic protocol, the mechanism library, audit and design templates, the automation layer, and a model-ready prompt. It assumes the vocabulary defined in the Paper: the four conditions (Relevance Gap, Desire Gap, Trust Gap, Ability Gate), the two principles (Data Proximity and Commitment Load), and the design rules (minimum necessary intervention; every step earns its place).
1. How to use this playbook
The Playbook turns the framework into repeatable work. There are two entry points.
Auditing a flow that leaks — start with the diagnostic protocol (Section 2) and the per-step audit template (Section 4). You have analytics telling you where users stop; the protocol tells you how to form a hypothesis about why.
Designing a new flow — start with the design template (Section 5). You are building the sequence of commitments before there is data, so the work is to anticipate the blocker at each step and decide what the step must do to earn it.
The mechanism library (Section 3) is the lookup you reach for after diagnosis, never before. The automation layer (Section 6) and the model-ready prompt (Section 7) let an AI model run the protocol alongside you.
One rule sits above all the tools: diagnose the commitment problem before reaching for a mechanism. Most failed optimization is a correct mechanism applied to the wrong blocker.
2. The diagnostic protocol
Use this to audit an existing product. Six steps.
Step 1 — Map every commitment event. List every moment the user is asked to give something: attention, click, scroll, answer, data, email, phone, account creation, confirmation, payment, activation, message, upload, invite, renewal, upgrade, repeat purchase. For each, ask: what commitment is being requested here?
Step 2 — Estimate commitment load. For each commitment, ask how heavy the ask feels: how much time, effort, money; how sensitive the data; how reversible the action; what the user risks; what uncertainty remains. The heavier the ask, the more relevance, desire, trust, and ability must precede it. If the load exceeds what any single intervention can realistically cover, flag the step for decomposition — can this one heavy ask be split into a sequence of lighter ones?
Step 3 — Identify available data. What do we know about this user at this moment — from targeting, behavior, user input, and previous steps? Is the current experience using it to make the next commitment more relevant, and is it doing so responsibly? Apply the boundary: would this use of data make the user feel understood or exposed? Unused data sitting at a high-friction step is one of the most common high-leverage opportunities.
Step 4 — Diagnose the dominant blocker, in order. Work the conditions in sequence — relevance → desire → trust → ability — and treat the earliest unmet one as the real blocker. Behavioral signals:
- Early exit, low click-through despite fit → Relevance Gap
- Exploration without progression, repeat visits without action → Desire Gap
- Abandonment near data capture or payment; reading FAQ, refund, privacy pages → Trust Gap
- Form drop-off, failed payments, validation errors, rage clicks → Ability Gate
Two disambiguations matter. When the signal points to desire, separate true desire from resistance: is the user not wanting the outcome, or wanting it but stalling on price, switching cost, or “later”? What they read or do before bouncing usually tells you — pricing and comparison behavior points to price; FAQ and refund behavior points to trust. And remember the diagnosis is a structured hypothesis, not proof; in sensitive categories trust can fail before desire forms, overriding the default order.
Step 5 — Match mechanism to blocker. Do not use a desire mechanism when the problem is trust, more proof when the problem is ability, more explanation when the problem is desire, or more personalization when the problem is intrusiveness. The earliest-unmet rule from Step 4 is what stops you intervening on a condition that was never the blocker.
Step 6 — Define the experiment. Each intervention becomes a testable claim with a primary metric, a guardrail metric, and a named baseline. Examples: if the blocker is relevance, a sharper problem reframe should beat generic benefit copy on progression; if the blocker is ability, friction removal should beat more persuasion on completion. State what you are beating — unstructured A/B testing, or the team’s prior experiment hit-rate — and the downstream guardrail (refunds, churn, retention, complaints) that protects against a false win. The framework does not replace experimentation; it improves the quality of the hypothesis.
3. The mechanism library
Mechanisms are tools for moving users through commitments. They are not interchangeable. Match the mechanism to the diagnosed blocker.
3.1 Relevance mechanisms — used when the user does not recognize why this matters to them. Problem reframing, audience specificity, contrast framing, category education, hidden-cost visibility, segmentation-specific entry copy, “if you are X” framing, current-state vs possible-state contrast. Goal: make the user recognize themselves.
3.2 Desire mechanisms — used when the user understands relevance but does not want the next action enough. Curiosity gap, variable reward, result preview, progress indicator, emotional contrast, loss framing, outcome concretization, partial reveal, “one step away” framing, peak commitment timing. Goal: make the user want to continue now. First confirm it is desire and not resistance — none of these fixes a price objection or status-quo inertia.
3.3 Trust mechanisms — used when the user wants the outcome but does not believe or feel safe enough. Specificity, transparent data exchange, mechanism explanation, similarity-based social proof, authority, reciprocity, privacy explanation, refund or risk reversal, case evidence, user control, trust-building micro-rewards before the ask. Goal: make the user feel safe and confident enough to proceed.
3.4 Ability mechanisms — used when the user has intent but the action is too hard, unclear, or inconvenient. Friction removal, fewer fields, clearer CTA, better defaults, progress visibility, saved progress, one-tap actions, easier payment, error prevention, recovery paths, removing unnecessary screens. Goal: make the action easy enough to complete now.
3.5 Structural moves — when the ask is simply too heavy. Some asks will not clear the threshold no matter which mechanism above you apply, because the load is inherently high. These are structural, not per-blocker. Commitment decomposition — split one heavy ask into a sequence of lighter ones. Staged data collection — collect the minimum now, defer the rest to a step where it is justified by value already received. Peak-timing deferral — move the heavy ask to the moment desire, trust, and ability are all sufficient, rather than where the business wants it. Goal: change the shape of the sequence so the heavy commitment becomes reachable.
4. Audit template
For each step in an existing flow, answer the following.
Step identity
- What is the step? What action is required? What is the desired next commitment?
- How many users reach this step? How many complete it?
User state
- What does the user know here? What do they want? What might they doubt? What might feel difficult? What emotional state are they likely in?
Commitment load
- How heavy is the ask? What does the user give: attention, data, effort, money, trust, identity, time, or risk?
- Is it reversible? Is the data sensitive? Is the price or opportunity cost meaningful? Is there professional, social, or emotional risk?
- If the load is high: can this ask be decomposed into lighter steps?
Data proximity
- What do we know about this user at this moment, and from where (targeting, behavior, input, prior steps)?
- Is the current message using it? Could the next step become more specific?
- Would that specificity feel helpful or intrusive?
Blocker diagnosis
- Working in order — is the earliest unmet condition relevance, desire, trust, or ability?
- If desire: is it true desire, or resistance (price, inertia, “later”)?
- What behavioral evidence supports the diagnosis?
Loop quality
- What loop is currently open? Is it specific and closeable? What action closes it?
- What micro-reward is delivered, and is it real? Does it make the next commitment more likely?
Intervention
- Which mechanism matches the blocker? What copy, UI, offer, proof, timing, or flow change should be tested?
- What is the hypothesis? What is the primary metric? What downstream metric guards against a false win?
5. Design template
Use this when building a new growth flow.
Product and user
- What are we selling? What is the user’s starting problem? What are they already aware of, already desiring, already distrustful of? What alternatives — including doing nothing — do they have?
Commercial architecture
- What is the primary conversion event? Is the system linear or cyclical?
- If cyclical: which actions must recur, and what is the expected decay rate of each loop — how will we refresh the mechanic before it flattens?
- Where should payment happen? What must the user experience before payment?
Step architecture — for every step:
- What commitment are we asking for, and how heavy is it?
- Which condition must be resolved (relevance, desire, trust, ability)?
- What data do we have, and what data do we need?
- What intervention makes the next step feel justified? What value closes the current loop?
- What trust work is needed before the ask? What friction can be removed?
- If the ask is heavy: should it be decomposed, and where does it belong relative to peak commitment timing?
Testing architecture — for every major intervention:
- What is the hypothesis? Which blocker does it target, with which mechanism?
- What is the expected behavior change, the primary success metric, and the guardrail metric?
- What baseline are we beating? What do we learn if it wins, and if it loses?
6. The automation layer
The framework is well suited to AI-assisted growth work because it turns vague optimization into structured diagnosis and generation. An AI model can help with funnel mapping, screenshot and flow analysis, step-by-step diagnosis, blocker classification, commitment-load estimation, data-proximity analysis, hook and copy generation, micro-reward design, paywall-timing hypotheses, A/B variant creation, guardrail-metric suggestions, experiment critique, and lifecycle, onboarding, and CRM rewriting.
The operating constraint is the same as for a human: the model should not simply make copy more persuasive. It should diagnose the commitment problem first. The prompt in Section 7 enforces that order.
A practical model run answers, in sequence: What product is this? What step are we optimizing? What commitment is being requested? What do we know about the user? How heavy is the commitment? Where is the drop-off? Which condition is the earliest unmet one? Is an apparent desire problem actually price or inertia? Is the ask heavy enough to require decomposition? What is the minimum necessary intervention? What variants should we test, against what baseline and guardrail?
7. Model-ready skill prompt
Use the following as the starting prompt for applying Commitment Flow Architecture with an AI model. It is the working spec for the skill.
You are a growth strategist using Commitment Flow Architecture. Analyze the provided funnel step, screen, copy, flow, or screenshot. Do not simply make the copy more persuasive — diagnose the commitment problem first.
For each step:
- Identify the user commitment being requested.
- Estimate its commitment load: attention, effort, data sensitivity, money, emotional risk, reversibility, uncertainty. If the load is high, note whether the ask should be decomposed into a sequence of lighter commitments.
- Identify the data available about the user at this moment, and whether the experience uses it responsibly — helpful, not intrusive.
- Diagnose the dominant blocker by working the conditions in order — Relevance Gap, Desire Gap, Trust Gap, Ability Gate — and treating the earliest unmet one as the real blocker. If the apparent blocker is desire, separate true desire from resistance (price, switching cost, “later”).
- State the behavioral evidence for the diagnosis, and flag that it is a hypothesis. Note any sensitive-category reason the default order might not hold.
- Select the minimum necessary intervention — sometimes a mechanism, sometimes removing a step, sometimes resequencing the ask.
- Suggest 3 to 5 variants that match the diagnosed blocker.
- Define the experiment hypothesis.
- Recommend the primary metric, a guardrail metric, and the baseline the test must beat (unstructured A/B, or the team’s prior hit-rate).
- Flag ethical or trust risks: over-personalization, fake loops, sensitive data, cyclical or compulsion-loop dynamics, and short-term conversion wins that may damage retention.
- If useful, map the step to a product type — self-insight, dating / social discovery, conversational AI, AI output tool, fitness / wellness, B2B SaaS, or another relevant category.
This Playbook is the operational companion to the Paper. The product-type walkthroughs (self-insight, dating / social discovery, conversational AI, AI output tool, fitness / wellness, B2B SaaS) can be added here as application templates once the Paper is locked.