@ztffn/presentation-generator-plugin 1.0.0

package/skills/presentation-generator/narrative/content-signals.md

@@ -0,0 +1,178 @@
+# Content Extraction Signals
+
+Guidance for extracting presentation-worthy content from source documents.
+Defines what to prioritize, what to skip, and the canonical content brief schema.
+
+## What Makes Content Presentation-Worthy
+
+### Prioritize
+
+- **Quantified claims**: Numbers with context ("40% cost reduction in field trial, Oslo 2024")
+- **Named problems with an owner**: A specific person, team, or organization experiencing a defined pain
+- **Before/after contrasts**: Measurable change from current state to proposed state
+- **Proof points with specificity**: Named pilots, real customers, dated results, third-party validation
+- **Objections already present in the source**: Questions, concerns, or risks the documents acknowledge
+- **Explicit calls to action**: Any sentence stating what should happen next
+- **Competitive differentiation**: Direct comparisons or unique capabilities not available elsewhere
+
+### De-prioritize
+
+- Implementation details (API specs, config files, deployment steps) unless the audience is technical and this is the point
+- Legal boilerplate, disclaimers, terms and conditions
+- Process descriptions (how meetings are scheduled, how tickets flow)
+- Generic benefit statements that could apply to any product ("saves time", "easy to use")
+- Historical background that does not serve the current argument
+- Anything true but not audience-moving
+
+## Audience Sensitivity
+
+Adjust extraction depth based on `audience` and `goal`:
+
+| Audience Type | Emphasize | De-emphasize |
+|---|---|---|
+| Technical | Mechanism details in `dataPoints`, architecture in `proofPoints` | High-level value claims they already understand |
+| Commercial / Executive | Outcome framing in `valueProps`, ROI in `dataPoints` | Implementation details, technical jargon |
+| Mixed | Layer both — headline outcome first, mechanism in parenthetical | Neither extreme |
+
+| Goal | Content Lens |
+|---|---|
+| `pitch` | Focus on differentiation, proof, and urgency |
+| `demo` | Focus on capability evidence and wow moments |
+| `update` | Focus on progress against prior commitments, blockers, next steps |
+| `internal` | Focus on decisions needed, trade-offs, and open questions |
+| `exploratory` | Focus on landscape, options, and criteria for choice |
+
+## Content Brief Schema
+
+The content agent must return a JSON object conforming to this schema. Every field must be populated with specific, concrete entries.
+
+```json
+{
+  "product": {
+    "name": "string — product or project name",
+    "description": "string — one sentence describing what it does"
+  },
+  "audience": {
+    "who": "string — specific role or group (e.g. 'VP of Engineering at industrial customers')",
+    "background": "string — what they already know",
+    "cares_about": "string — their primary decision criteria"
+  },
+  "goal": "pitch | demo | update | internal | exploratory",
+  "keyMessages": [
+    "Declarative sentence making a specific claim — not a topic label"
+  ],
+  "valueProps": [
+    "Why this matters to THIS audience specifically — not generic benefits"
+  ],
+  "dataPoints": [
+    {
+      "label": "string — what the number represents",
+      "value": "string — the specific number or metric",
+      "source": "string — where this data comes from (e.g. 'field trial, Oslo 2024')"
+    }
+  ],
+  "proofPoints": [
+    "Named evidence: case study, pilot result, customer quote, third-party reference"
+  ],
+  "objections": [
+    "Specific concern the audience may raise, drawn from source material"
+  ],
+  "callToAction": "Single actionable sentence — what should happen after this presentation",
+  "context": "Relationships, timing, sensitivities, or competitive dynamics relevant to this meeting"
+}
+```
+
+### Strong vs. Weak Examples
+
+| Field | Weak | Strong |
+|---|---|---|
+| `keyMessages` | "Calora is an energy system" | "Calora reduces industrial heat costs by 40% with no infrastructure replacement" |
+| `valueProps` | "Saves money" | "Eliminates the capital expenditure barrier that blocked your Stavanger plant upgrade" |
+| `dataPoints` | `{ "label": "savings", "value": "significant" }` | `{ "label": "Heat cost reduction", "value": "40%", "source": "Field trial, Oslo 2024" }` |
+| `proofPoints` | "We have pilot results" | "Norsk Hydro pilot (Q3 2024): 38% cost reduction, 99.7% uptime over 6 months" |
+| `objections` | "People worry about risk" | "Integration with existing BMS requires 2-week commissioning window — addressed via phased rollout" |
+| `callToAction` | "Let's continue the conversation" | "Agree to a structured 3-month pilot at the Stavanger facility starting Q2" |
+
+### Validation Rules
+
+Before returning the brief, verify:
+
+1. `keyMessages` contains 3-5 entries, each a declarative sentence (subject + verb + specific claim)
+2. `dataPoints` contains at least one entry with a specific number in `value`
+3. `callToAction` is a single sentence with an action verb and a concrete outcome
+4. No field contains layout, design, or slide-type references
+
+## Worked Example — Brief from Source Documents
+
+The following shows a complete extraction from two hypothetical source documents. Study the signal identification process and the handling of gaps.
+
+### Source documents provided
+
+**Document 1: Product one-pager (excerpt)**
+> Tempo is a workforce scheduling platform for distributed service businesses. Companies using Tempo reduce scheduling time by 73% and cut last-minute shift coverage failures by 58%. Our largest customer, Hargrove Services (3,200 employees), eliminated their scheduling coordinator role entirely after rollout. Tempo integrates with ADP and Workday in under a day. Pricing starts at $12/employee/month.
+
+**Document 2: Customer quote (excerpt)**
+> "Our ops managers used to spend Sunday nights building next week's schedule. Now they approve it in 15 minutes on their phones. The biggest surprise was how many conflicts we'd been creating without realizing it — Tempo surfaces those automatically." — VP Operations, regional healthcare staffing firm (150 locations)
+
+---
+
+### Signal identification
+
+**Strong signals extracted:**
+- Quantified outcomes with source: 73% scheduling time reduction, 58% shift failure reduction — from one-pager
+- Named customer with scale: Hargrove Services, 3,200 employees, eliminated a role — specific proof point
+- Before/after contrast from a real user: "Sunday nights" → "15 minutes on phone" — visceral, citable
+- Objection pre-empted in source: integration with ADP/Workday in under a day — answers the likely adoption concern
+- Surprise detail worth surfacing: automatic conflict detection — creates differentiation without claiming it
+
+**Gaps (not in source material):**
+- Audience for this specific meeting: not specified
+- Goal (pitch / demo / update): not specified
+- Competitive differentiation: not mentioned
+- Call to action: not specified
+- `valueProps` require knowing the audience before they can be stated
+
+---
+
+### Resulting brief
+
+```json
+{
+  "product": {
+    "name": "Tempo",
+    "description": "Workforce scheduling platform that reduces scheduling time and eliminates shift coverage failures for distributed service businesses"
+  },
+  "audience": {
+    "who": "NOT FOUND IN SOURCE — ask user",
+    "background": "Likely an operational leader managing a distributed hourly workforce",
+    "cares_about": "NOT FOUND IN SOURCE — ask user"
+  },
+  "goal": "NOT FOUND IN SOURCE — ask user (pitch / demo / update?)",
+  "keyMessages": [
+    "Tempo reduces workforce scheduling time by 73% and cuts shift failures by 58%",
+    "Hargrove Services (3,200 employees) eliminated their scheduling coordinator role entirely after rollout",
+    "Integration with ADP and Workday takes less than one day",
+    "Tempo automatically surfaces conflicts that manual scheduling creates invisibly"
+  ],
+  "valueProps": [
+    "NOT FOUND IN SOURCE — populate once audience role and priorities are known"
+  ],
+  "dataPoints": [
+    { "label": "Scheduling time reduction", "value": "73%", "source": "Product one-pager" },
+    { "label": "Shift coverage failure reduction", "value": "58%", "source": "Product one-pager" },
+    { "label": "Integration setup time", "value": "Under 1 day", "source": "Product one-pager" },
+    { "label": "Schedule approval time (customer quote)", "value": "15 minutes", "source": "VP Operations, regional healthcare staffing firm" }
+  ],
+  "proofPoints": [
+    "Hargrove Services (3,200 employees): eliminated scheduling coordinator role after rollout",
+    "Regional healthcare staffing firm (150 locations): ops managers reduced Sunday schedule prep from hours to 15-minute phone approval"
+  ],
+  "objections": [
+    "NOT FOUND IN SOURCE — ask user. Likely: change management for ops managers; integration with existing HR stack"
+  ],
+  "callToAction": "NOT FOUND IN SOURCE — ask user",
+  "context": "NOT FOUND IN SOURCE — ask user"
+}
+```
+
+**What to do with the gaps:** Three critical fields are missing (goal, audience, CTA). The orchestrator must ask the user for these before passing the brief to the narrative agent. A brief without a stated goal cannot produce a purposeful framework selection. A brief without an audience cannot produce audience-specific value props. Ask one targeted question that covers the most urgent gap first.

package/skills/presentation-generator/narrative/frameworks.md

@@ -0,0 +1,234 @@
+# Narrative Frameworks
+
+Proven story structures for presentations. Select the right framework based on
+the content brief's `goal` and `audience` fields. These are narrative-only —
+no slide types, layouts, colors, or JSON format.
+
+## Framework Catalog
+
+### 1. Problem-Solution-Value (PSV)
+
+The workhorse pitch structure. Establish pain, present the fix, prove it works.
+
+**Flow:** Problem → Solution → Evidence → Value → Call to Action
+
+**Best for:** `pitch`, `demo` where the audience has the problem
+**Audience:** Commercial, executive, or mixed
+
+**Spine pattern:**
+- Open with the problem the audience recognizes
+- Present the solution as a direct answer
+- Show evidence (data, pilots, demos)
+- Quantify the value to this specific audience
+- Close with a concrete next step
+
+### 2. Before-After-Bridge (BAB)
+
+Contrast the current state with the desired future, then show how to get there.
+
+**Flow:** Current Reality → Desired Future → The Bridge (your solution)
+
+**Best for:** `pitch` to audiences who may not realize they have a problem
+**Audience:** Executive, board, investors
+
+**Spine pattern:**
+- Paint the current state vividly — costs, friction, missed opportunities
+- Show what the world looks like after adoption
+- Reveal the bridge: what makes the transformation possible
+- Evidence that the bridge works
+- Ask for commitment
+
+### 3. Five-Whys Drill-Down
+
+Start with a surface observation, drill into root causes layer by layer. Each "why" becomes a drill-down branch.
+
+**Flow:** Observation → Why #1 → Why #2 → ... → Root Cause → Solution
+
+**Best for:** `internal`, `exploratory` where understanding the problem matters more than selling
+**Audience:** Technical, analytical
+
+**Spine pattern:**
+- State the observation on the spine
+- Each drill-down layer peels back one level of causation
+- The final layer reveals the root cause
+- Solution addresses the root, not the symptom
+
+### 4. Hero's Journey (Product Adaptation)
+
+The audience is the hero. Their world has changed. They face a challenge. Your product is the guide that helps them succeed.
+
+**Flow:** Status Quo → Disruption → Challenge → Guide (you) → Transformation → New Normal
+
+**Best for:** `pitch` to audiences going through change (market shifts, regulatory pressure, digital transformation)
+**Audience:** Executive, strategic
+
+**Spine pattern:**
+- Acknowledge their current world
+- Name the disruption they face
+- Frame the challenge it creates
+- Position your offering as the guide, not the hero
+- Show the transformation (with proof)
+- Define the new normal they can achieve
+
+### 5. Minto Pyramid (Conclusion First)
+
+Lead with the answer. Support with grouped evidence. Drill down for detail.
+
+**Flow:** Conclusion → Supporting Argument 1 → Supporting Argument 2 → Supporting Argument 3
+
+**Best for:** `update`, `internal` where the audience is time-constrained and wants the bottom line first
+**Audience:** Executive, senior stakeholders
+
+**Spine pattern:**
+- Open with the recommendation or conclusion
+- Each spine node is a major supporting argument
+- Drill-downs contain the evidence for each argument
+- Close with implications and next steps
+
+## The Earned Secret — Making "Why Now" Inevitable
+
+Before selecting a framework, identify the non-obvious insight that makes this presentation's moment different from three years ago. Mike Maples Jr: "Share the thing you know that's not obvious — the earned secret."
+
+The earned secret is not a product feature. It is a shift in the world that makes your argument newly urgent:
+
+- A regulatory change that makes the old approach non-compliant
+- A cost inflection that makes the status quo unaffordable
+- A technological shift that makes the solution newly feasible
+- A competitive move that closes existing options
+
+Where the earned secret appears in each framework:
+
+| Framework | Where it goes |
+|---|---|
+| PSV | The *cause* of the problem — why it's worse now than before |
+| BAB | Why the Bridge is possible *now* when it wasn't before |
+| Hero's Journey | IS the disruption the audience faces |
+| Minto Pyramid | The urgency behind the recommendation — why this decision can't wait |
+| Five-Whys | Often emerges at the root cause level |
+
+A presentation without an earned secret is a description. One with it is an argument.
+
+## Selection Guide
+
+| Goal | Primary Framework | Alternative |
+|---|---|---|
+| `pitch` | Problem-Solution-Value | Before-After-Bridge (if problem isn't obvious) |
+| `demo` | Problem-Solution-Value | Hero's Journey (if showing transformation) |
+| `update` | Minto Pyramid | Problem-Solution-Value (if proposing change) |
+| `internal` | Minto Pyramid | Five-Whys (if diagnosing an issue) |
+| `exploratory` | Five-Whys | Minto Pyramid (if presenting findings) |
+
+## Combining Frameworks
+
+Frameworks define the spine structure. Drill-downs can use a different pattern:
+
+- PSV spine with Five-Whys drill-downs under the Problem node (why does this problem exist?)
+- Minto spine with PSV drill-downs under each argument (what problem does this evidence address?)
+- Hero's Journey spine with data-heavy drill-downs under Transformation (prove the outcome)
+
+## Spine Length Guidelines
+
+| Presentation Duration | Spine Nodes | Drill-Downs Per Node |
+|---|---|---|
+| 5-10 minutes | 4-5 | 0-1 |
+| 15-20 minutes | 5-6 | 1-2 |
+| 30+ minutes | 6-7 | 2-3 |
+
+The spine is the minimum viable presentation. Drill-downs are optional depth the presenter can use or skip based on time and audience interest.
+
+## Worked Examples
+
+The following show how each framework maps to a concrete spine given a specific brief. Headlines are in strong claim form. These are method demonstrations — apply the same logic to any domain.
+
+### PSV — Industrial Inspection Software (pitch to VP Operations, 15 min)
+
+**Brief signals:** `goal=pitch`, audience has the problem but hasn't quantified it, 5 key messages, 2 named case studies.
+
+**Why PSV:** The audience lives with unplanned downtime daily. PSV makes the cost visible before introducing the solution as the obvious answer.
+
+**Spine:**
+1. "Manual inspection cycles cost your plants 14% of annual uptime"
+2. "Sensor-based continuous monitoring closes the gap between visits"
+3. "Customers cut unplanned downtime by 60% within 90 days"
+4. "2× ROI in year one from avoided emergency maintenance"
+5. "Start a no-cost 30-day pilot on your most critical line"
+
+**Drill-downs:**
+- Under node 2: "How this integrates with your existing SCADA setup" — skeptics ask this before any commitment
+- Under node 3: "NovoChem: 6 plants, 18 months of results" — makes the headline claim concrete for proof-seekers
+
+---
+
+### BAB — Employee Wellbeing Platform (pitch to CHRO, 20 min)
+
+**Brief signals:** `goal=pitch`, audience doesn't yet frame burnout as a productivity problem — the pain is real but unnamed.
+
+**Why BAB:** Before-After-Bridge is for audiences who don't yet see their situation as a problem. Show the gap first; the product is the bridge.
+
+**Spine:**
+1. "Today: Burnout is invisible until someone quits or goes on leave"
+2. "Future: Managers see team energy signals before problems escalate"
+3. "The Bridge: Continuous passive sensing replaces the annual engagement survey"
+4. "Companies on this model cut voluntary attrition by 35% in 12 months"
+5. "Run a 60-day pilot before your next engagement cycle"
+
+**Drill-downs:**
+- Under node 1: "What exit interviews systematically fail to capture" — makes current-state pain concrete
+- Under node 3: "Privacy and consent: how anonymous aggregation works" — this objection surfaces before any procurement decision
+
+---
+
+### Five-Whys — Deployment Frequency (internal, VP Engineering + CTO)
+
+**Brief signals:** `goal=internal`, `audience=technical/analytical`, team needs to diagnose root cause before leadership will fund a fix.
+
+**Why Five-Whys:** The goal is understanding, not selling. Each "why" is a spine node that peels back one causal layer. The solution only makes sense once the root cause is visible.
+
+**Spine:**
+1. "We deploy 4× less frequently than our industry benchmark"
+2. "Every release requires 3 manual sign-offs — confidence is structurally zero"
+3. "No automated rollback makes every deploy high-stakes by definition"
+4. "Root cause: payment module test gaps create risk no one is willing to own"
+5. "6 weeks of coverage work removes the manual gates and unblocks CI/CD"
+
+**Drill-downs:**
+- Under node 4: "Coverage gap by module — which tests are missing and why" — technical audience needs this to believe the diagnosis
+- Under node 4: "How comparable squads measure release confidence" — external validation for skeptics
+
+---
+
+### Hero's Journey — Clinical Workflow Platform (pitch to hospital executive, 30 min)
+
+**Brief signals:** `goal=pitch`, audience is actively navigating a staffing disruption they did not choose, 30-minute slot.
+
+**Why Hero's Journey:** Hospital administrators are not looking for software — they are managing a crisis. Cast them as the protagonist navigating a changed world. The product is the guide, not the hero.
+
+**Spine:**
+1. "Your staffing model was built for 2019. The workforce has permanently changed."
+2. "Understaffed units are absorbing 40% more administrative load per nurse"
+3. "Remove the administrative load so nurses do nursing, not paperwork"
+4. "Summit Health cut per-shift admin time by 2.3 hours — nurses noticed immediately"
+5. "18 health systems are already running the new model — join the next cohort"
+
+**Drill-downs:**
+- Under node 3: "What the rollout looks like for floor staff" — executive thinking about change management asks this first
+- Under node 4: "Summit Health: full methodology and 12-month results" — evidence for the skeptical CFO in the room
+
+---
+
+### Minto Pyramid — Roadmap Scope Change (update to CEO + CFO)
+
+**Brief signals:** `goal=update`, `audience=executive`, audience is time-constrained and wants the bottom line, not the backstory.
+
+**Why Minto:** Exec audiences want the recommendation first. Supporting arguments justify it; drill-downs provide evidence if challenged. Never make them wait for the conclusion.
+
+**Spine:**
+1. "Recommendation: defer the mobile launch by one quarter"
+2. "API instability makes mobile reliability impossible to guarantee right now"
+3. "Enterprise accounts — our fastest-growing segment — don't need mobile yet"
+4. "Deferral frees 3 engineers to close the security audit gap before Q3"
+5. "Decision needed by Friday to re-staff before sprint planning"
+
+**Drill-downs:**
+- Under node 2: "API failure log from the last 60 days" — data behind the stability claim
+- Under node 3: "Mobile traffic by segment: enterprise vs. SMB breakdown" — proves the audience claim with usage data

package/skills/presentation-generator/narrative/graph-topology.md

@@ -0,0 +1,185 @@
+# Graph Topology for Presentations
+
+How narrative structure maps to graph navigation.
+No JSON schema, edge handles, or layout details — structure only.
+
+## Navigation Model
+
+The presentation graph uses two axes:
+
+- **Horizontal (left/right):** The main story spine. Right advances the narrative, left goes back.
+- **Vertical (down/up):** Drill-down depth. Down enters optional detail, up returns to the parent.
+
+This maps directly to a folder tree where depth equals drill-down depth.
+
+## Topology Recipes
+
+### 1. Linear (Pure Spine)
+
+No drill-downs. Every slide is on the main horizontal path.
+
+```
+[Cover] → [Problem] → [Solution] → [Evidence] → [CTA]
+```
+
+**When to use:**
+- Tight time constraints (5-10 minutes)
+- Well-known audience where you won't get deep questions
+- Status updates where every point matters equally
+- Simple narratives with no optional depth
+
+### 2. Spine with Deep Dives
+
+Main path has 4-7 spine nodes. Each can have 1-3 optional drill-down children below it.
+
+```
+[Cover] → [Problem] → [Solution] → [Value] → [CTA]
+              ↓            ↓           ↓
+           [Detail]    [How It]    [Case
+            [Why]       Works]     Study]
+```
+
+**When to use:**
+- Standard pitch or demo (15-30 minutes)
+- Mixed-knowledge audience where some want depth
+- Exploratory meetings where follow-up questions are expected
+- Any presentation where the presenter wants flexibility
+
+**Drill-down rules:**
+- A spine node's drill-downs expand on that node's message only
+- Drill-downs should be independently meaningful — the audience shouldn't need to visit them to understand the spine
+- Order drill-down siblings left to right if there is a natural sequence; otherwise order by likely interest
+
+### 3. Hub (Spoke Model)
+
+One central node with branches radiating outward. Good for feature tours or option comparisons.
+
+```
+           [Feature A]
+              ↑
+[Feature D] ← [Hub] → [Feature B]
+              ↓
+           [Feature C]
+```
+
+**When to use:**
+- Feature tour where order doesn't matter
+- Option comparison (the hub states the question, spokes are the options)
+- Portfolio overview (hub is the company, spokes are product lines)
+
+**Hub rules:**
+- The hub slide must be self-contained — it's the orientation point
+- Each spoke should be navigable independently
+- Returning to the hub from any spoke should always work
+
+## Tree Visualization Format
+
+Before the user approves the structure, the orchestrator renders the outline as a folder tree:
+
+```
+Cover: [headline]
+Problem: [headline]
+  └─ Detail: [headline]
+  └─ Root Cause: [headline]
+Solution: [headline]
+  └─ How It Works: [headline]
+  └─ Technical Deep Dive: [headline]
+Value: [headline]
+  └─ Case Study: [headline]
+Call to Action: [headline]
+```
+
+**Reading the tree:**
+- Top-level items are spine nodes (horizontal navigation)
+- Indented items with `└─` are drill-down children (vertical navigation)
+- Siblings at the same indent level are horizontal peers within their branch
+- The tree reads top-to-bottom as left-to-right on the spine
+
+## Structural Guidelines
+
+### Spine Length
+
+- Minimum: 4 nodes (cover, 2 content, close)
+- Maximum: 7 nodes (beyond this, the main story is too long)
+- Ideal: 5-6 nodes for a standard pitch
+
+### Drill-Down Depth
+
+- Maximum 2 levels deep (parent → child → grandchild)
+- Most presentations need only 1 level of drill-down
+- If you need 3+ levels, the structure is too deep — refactor to a longer spine
+
+### First and Last Slides
+
+- First slide (cover): Sets context. Who we are, what this is about. Centered, branded.
+- Last slide (close): Single call to action or summary. Centered, branded.
+- Both are on the spine. Neither has drill-downs.
+
+### Branching Points
+
+A spine node with drill-downs is a branching point. The presenter can:
+1. Press right to skip the branch entirely
+2. Press down to explore, then up to return, then right to continue
+
+The narrative must work either way — the spine alone is the minimum viable presentation.
+
+## Topology Decision Walkthrough
+
+The following shows how a content brief maps to a concrete topology decision. Apply the same reasoning to any brief.
+
+### Input: brief attributes
+
+- **Goal:** `pitch`
+- **Audience:** Commercial (VP Operations at enterprise manufacturing companies)
+- **Duration estimate:** 20 minutes
+- **Key messages:** 5 (problem cost, root cause, solution mechanism, proof, value)
+- **Objections in brief:** 3 (integration complexity, change management, ROI timeline)
+- **Proof points:** 2 (named case studies with data)
+- **Call to action:** Agree to a structured 90-day pilot
+
+---
+
+### Decision logic
+
+**Step 1 — Choose topology class.**
+`goal=pitch`, 20-minute slot → Spine with Deep Dives. Linear is too thin for a commercial pitch with 3 objections. Hub doesn't fit because the narrative has a directional arc.
+
+**Step 2 — Set spine length.**
+5 key messages × ~2.5 minutes each = roughly 13 minutes on the spine, leaving time for drill-down visits if the audience is skeptical. 5-node spine is correct.
+
+**Step 3 — Verify the spine alone tells a complete story.**
+Problem → Root Cause → Solution → Proof → CTA — the logic holds without any drill-downs. An audience that asks no questions can get the full story on the spine. ✓
+
+**Step 4 — Place the objections.**
+3 objections identified → none go on the spine (they break momentum). Each becomes a drill-down under the node whose claim would trigger that objection:
+- Integration complexity → drill-down under Solution node
+- Change management → drill-down under Solution node (sibling to integration)
+- ROI timeline → drill-down under Proof node (show the payback math alongside the case study)
+
+**Step 5 — Place the proof points.**
+Summarized proof stays on the spine (headline number + claim). Full case study detail moves to a drill-down under Proof. This way proof-seekers get what they need; time-constrained audiences can skip it.
+
+---
+
+### Resulting structure
+
+```
+Cover: [presentation title]
+Problem: [quantified cost of the problem]
+  └─ Root Cause: [why the problem persists]
+Solution: [mechanism that addresses the root cause]
+  └─ Integration: [how it connects to existing infrastructure]
+  └─ Change Management: [what changes for the people using it]
+Proof: [headline result from a named customer]
+  └─ Case Study: [full methodology and 12-month results]
+  └─ ROI Model: [payback timeline for the audience's context]
+Call to Action: [the specific next step]
+```
+
+**Reading this structure:**
+- 8 total nodes (5 spine + 3 drill-down)
+- All objections are handled via drill-downs — the presenter visits them based on audience signals, not on a fixed script
+- The spine alone completes the story; drill-downs add confidence without cluttering the main arc
+- Cover and CTA have no drill-downs by design — they are orientation and closing points
+
+**What this tells the narrative agent:** Write 5 spine slides as complete, standalone arguments. Write 3 drill-down slides that answer the specific objection or expand the specific proof claim of their parent — not general elaboration.