octavehq/ads-resonance

Octave Ads Resonance Loop — Performance → Library Intelligence

Turn ad performance data into GTM intelligence: pull performance from whichever source is available, map winners and losers back to the source cards that produced them, recommend library updates, brief the sales team on what language the market responds to, and write falsifiable prediction cards so the loop builds a verifiable track record over time.

Companion skill: /octave:ads builds the campaigns this loop analyzes. Campaigns generated there persist source cards to ~/.octave/source_cards/ (the data contract is defined in /octave:ads Step 2G and source-cards.template.json), which unlocks this loop's strongest analysis path. The loop also works on campaigns created outside /octave:ads via reverse-inference.

MCP Server: Library updates (Step 3) require the Octave MCP server. Look for available MCP tools that match the Octave tool names (e.g., update_entity, update_motion_playbook). The MCP server prefix varies by workspace. If multiple Octave-like MCP servers are available and you're unsure which to use, ask the user which workspace to target.

---

Step 1: Detect Performance Data Source

Performance data can come from four places, in order of preference:

1. MCP (live Google Ads / Meta / LinkedIn API via an installed MCP server) — real-time, but most likely to fail at runtime
2. BigQuery Data Transfer Service (~24h delayed managed pipeline) — the recommended default for read-only resonance analysis, no developer token approval required
3. Direct API (curl/Python against the Google Ads API, no MCP) — when the user has an approved developer token but no MCP installed
4. Manual (paste CSV / screenshot / verbal) — last resort

Read performance-data-sources.md for setup instructions, all SQL and API queries, table layouts, and the troubleshooting table. That doc is the source of truth for everything in this step — the SKILL describes the procedure; the reference owns the queries.

Critical principle: never tell the user "I can pull your data" without running a smoke test first. A path that looks available (the MCP tool exists, the dataset exists, the dev token is set) can still fail at query time. Probe first, then commit.

Walk through the four paths in order. For each one, first detect, then smoke-test. The first path that passes its smoke test wins — use it. If all four fail, fall through to manual.

Detection patterns

| Path | What to look for | |------|------------------| | 1 — MCP | MCP tools matching google_ads, googleads, adwords, google_campaigns, meta_ads, facebook_ads, linkedin_ads | | 2 — BigQuery | A BigQuery MCP tool (bigquery, bq, mcp__bigquery*), OR the bq CLI on PATH and authenticated, OR a known dataset like google_ads containing ads_Campaign_* / ads_CampaignBasicStats_* tables | | 3 — Direct API | The user mentions they have an approved developer token + a refresh token, but no MCP. Or earlier in the conversation they shared API credentials | | 4 — Manual | Always available |

Path 1 — MCP smoke test

If a Google Ads MCP tool is detected, before promising data:

→ {google_ads_mcp}__list_accessible_customers()

If that succeeds, pick one accessible customer ID and run the simplest possible query:

→ {google_ads_mcp}__search(
    customer_id: "{id}",
    query: "SELECT customer.id, customer.descriptive_name FROM customer"
  )

Interpret the result:

• Success → Path 1 is good. Use it for all subsequent queries.
• CUSTOMER_NOT_FOUND + "missing authentication credential" → wrong login-customer-id. Tell the user the exact fix (set GOOGLE_ADS_LOGIN_CUSTOMER_ID to the MCC, not a sub-account) and fall through to Path 2.
• DEVELOPER_TOKEN_NOT_APPROVED "only approved for use with test accounts" → the developer token is in Test tier and cannot query production accounts. Tell the user they need to apply for Basic Access in API Center (~3 days) and fall through to Path 2.
• invalid_scope or 403 → the credentials are missing the adwords scope. Reference the Python refresh-token snippet in the data sources doc and fall through to Path 2.
• 404 on a versioned path → API version sunset. Check the current version (see the data sources doc) and fall through to Path 2.

For all four failure modes, the message to the user should be one sentence: what failed, what the fix is, and "I'll try BigQuery next."

Path 2 — BigQuery smoke test

If a BigQuery MCP tool is available, list datasets and look for google_ads (or any dataset containing tables prefixed ads_Campaign_). If bq CLI is available, run:

bq ls --project_id=<project>
bq ls <project>:google_ads

If you find tables matching ads_CampaignBasicStats_<MCC>, run the two-stage smoke test defined in performance-data-sources.md § "Smoke test". The first stage proves data exists and is fresh. The second stage proves the data is meaningful — that it'll actually drive useful resonance analysis, not just produce empty tables.

• Stage 1 — freshness probe: row count plus earliest/most-recent _DATA_DATE over the last 30 days.
• Stage 2 — meaningful-data probe: the ad-group-level CPC/CTR query. This is the most actionable single query at small spend and immediately exposes whether the data has signal worth analyzing.
• Stage 2b — mandatory sanity cross-check: immediately after Stage 2, run the raw-stats-only query and verify per-ad-group totals match the Stage 2 values exactly. If any row differs, stop the loop and report a dim-join inflation bug — do not proceed with analysis. Inflated totals will silently corrupt every downstream conclusion (CPC comparisons, prediction cards, library recommendations).

CRITICAL — dim-table snapshot trap. ads_AdGroup_<MCC> and ads_Campaign_<MCC> are daily-snapshotted dimension tables. Joining them without a latest-snapshot dedup CTE cartesian-explodes your totals. Every query that reads dim metadata must use the ag_latest / c_latest CTE pattern from the data sources doc — see § "Gotcha #4: Daily-snapshotted dim tables" for the full writeup. Never JOIN the dim tables directly.

Interpret the result:

• Stage 1 returns rows > 0 and most_recent within the last 2 days → freshness OK, continue to Stage 2.
• Stage 2 returns ≥ 2 ad groups with clicks > 5 → Path 2 is good. Use the BigQuery queries from the data sources doc for all subsequent fetches. Note in your report what the data window covers and how many ad groups have meaningful volume.
• Stage 2 returns 0 or 1 rows with meaningful volume → the data is fresh but too thin for cross-ad-group comparisons. Tell the user explicitly: "I have data, but only N days / N ad groups have enough clicks to draw real conclusions. I can run the loop in smoke test mode (verifies the pipes work, conclusions are unreliable) or partial mode (only report findings I can stand behind). Which?"
• Stage 1 returns rows == 0 or most_recent is more than 2 days old → the transfer exists but has stalled or hasn't backfilled yet. Tell the user and offer to either trigger a backfill (bq mk --transfer_run ...) or fall through to Path 3 / Path 4.
• Permission denied on either query → the calling identity (user or service account) lacks roles/bigquery.dataViewer on the dataset. Tell the user the exact fix and fall through.
• No matching dataset/tables → Path 2 isn't set up yet. Offer to walk the user through setup interactively (this is the first-run path). The full setup steps are documented in performance-data-sources.md § "Path 2: BigQuery Data Transfer Service". Read that section and execute it step by step with the user — enable the APIs, create the dataset, create the transfer in the BigQuery console (this requires the user to click through the OAuth grant), trigger a backfill, then re-run the smoke test once data starts landing. Setup is ~10 minutes of clicks plus ~17 hours for the full 30-day backfill (most-recent days land first, so analysis can begin within ~30 min). Do not skip to Path 3 or Path 4 unless the user explicitly declines the setup.

Path 3 — Direct API smoke test

If the user has shared API credentials earlier in the conversation (developer token + refresh token + client id/secret), or has an Application Default Credentials file for the Ads API, you can hit the API directly with curl or Python. Same smoke test as Path 1: mint an access token from the refresh token, hit listAccessibleCustomers, then run a customer query against an accessible ID.

Same failure modes as Path 1 (login-customer-id, dev token tier, scope, API version) — see the data sources doc for the curl invocations.

Path 4 — Manual

If all programmatic paths fail (or the user explicitly requests manual), ask:

AskUserQuestion({
  questions: [{
    question: "How would you like to provide ad performance data?",
    header: "Performance Data",
    options: [
      {
        label: "Paste a CSV or table",
        description: "Paste performance data from your ad platform (needs: variant/headline, impressions, clicks, conversions)"
      },
      {
        label: "Paste a screenshot",
        description: "Share a screenshot of your ad platform dashboard — I'll extract the metrics"
      },
      {
        label: "Summarize verbally",
        description: "Tell me which variants won and lost, with approximate numbers"
      },
      {
        label: "Skip — I'll come back later",
        description: "Run the resonance loop when you have performance data"
      }
    ],
    multiSelect: false
  }]
})

What to fetch (any path)

Whichever path wins, fetch these per-variant metrics so the resonance map (Step 2) has what it needs:

• Impressions
• Clicks / CTR
• Conversions / conversion rate
• Cost per click (CPC) / cost per conversion (CPA)
• Ad creative content (RSA headlines and descriptions for matching back to source cards)
• Quality Score (Google) or Relevance Score (Meta/LinkedIn) if available

Match fetched data back to the variants the campaign was generated with (see /octave:ads Step 3) by headline text (most reliable across paths), then by ad set name, then by campaign ID if the user stored it during export.

Step 2: Map Performance Back to Source Cards

This is the core of the resonance loop. Before generating the map, decide which analytical mode the data supports — the wrong mode produces confident-sounding noise. Then decide whether the campaign was generated by /octave:ads (source cards exist) or is legacy/external (source cards must be reverse-inferred).

2.1: Pick the analytical mode based on volume

Different volumes stabilize different metrics. Volume — not spend — is what determines statistical confidence. $100/day on $50 CPC enterprise keywords is 2 clicks; $100/day on $0.50 CPC long-tail keywords is 200 clicks. Same dollar amount, totally different reliability. Use the volume thresholds below as the primitives. Spend amounts are listed only as rough orientation.

Read this table and pick the most conservative mode that fits the unit being compared.

| Mode | Volume threshold (the actual gate) | Rough spend orientation | What's stable | What's still noise | |---|---|---|---|---| | Smoke-test | <500 impressions OR <20 clicks total in the window across all units | < $100/day | Almost nothing | Conversions, CTR, CPC at any level | | Ad-group | ≥2 ad groups each with 500+ impressions and 20+ clicks in the window | $100–$500/day | Ad-group-level CTR and CPC | Conversion rate at any level, ad-level metrics, CPA | | Ad | Per-ad: 1,000+ impressions and 30+ clicks for the ad in question | $500–$2,000/day | Ad-level CTR (only for ads meeting the threshold) | Conversion rate, CPA, ad-level CPC for low-volume ads | | Full resonance | All ad-mode thresholds met + 30+ total conversions in the window | > $2,000/day | All of the above + ad-level conversion rate | Headline-level attribution (Google does not expose this) |

The gates are AND, not OR. An ad with 5,000 impressions and 4 clicks doesn't qualify for ad mode (clicks too low). An ad group with 50,000 impressions but only 10 conversions doesn't qualify for full resonance (conversions too low).

Default thresholds can be overridden at runtime if the user explicitly says they know their data. Accept arguments like:

• --min-impressions 200 (lowers the per-unit impression floor)
• --min-clicks 10
• --min-conversions 10
• --mode ad-group / --mode ad / --mode full-resonance (force a specific mode regardless of volume)

When the user passes an override, state in the report what was overridden and to what value, so the user can interpret the confidence accordingly. Do not silently use looser thresholds than the data supports.

Hard rules — apply regardless of mode:

1. Never claim a "winning" or "losing" variant from N < 30 conversions unless the user has explicitly overridden --min-conversions. State the conversion data, but frame any conclusion as "early signal, needs more volume to validate." A single conversion is correlation, not causation.
2. Always report the data window, total impressions/clicks/conversions, and selected mode at the top of the resonance map. This calibrates the reader for how much weight to give the conclusions.
3. CPC gaps between ad groups are usually the biggest finding at small spend. A 3x+ CPC delta between two ad groups in the same account targeting the same persona is a "rework or kill" signal even with no conversion data, because it reveals a Quality Score / keyword-creative match problem that no amount of creative iteration will fix.
4. If the smoke test (Step 1, Stage 2) returned only 1 ad group with meaningful volume, you cannot run a real resonance loop. Report what you have, label it explicitly as "single-ad-group early signal," and offer to re-run when more data is available.
5. Units below the threshold for the chosen mode get N/A confidence and are excluded from winners/losers tables. They can appear in an "FYI — insufficient volume" section, but never in the actionable findings.

Pick the mode now and state it explicitly at the top of the resonance map output so the user knows the confidence floor before reading the findings.

2.2: Decide whether source cards exist

Two paths into this step:

Path A — Campaign was generated by /octave:ads (source cards exist):

Campaigns generated by /octave:ads automatically persist source cards to ~/.octave/source_cards/<workspace_slug>/<campaign_slug>.json, with final headlines populated after creative generation. The file contains the campaign metadata, the full source cards, and a headlines_by_variant mapping from each variant to the actual headlines that were generated. The schema is defined in source-cards.template.json.

To use Path A in the resonance loop:

1. Scan ~/.octave/source_cards/ for subdirectories. Each subdirectory is a workspace slug.
2. Inside each, look at every campaign file. Read the headlines_by_variant field.
3. Match each headline string against the headlines observed in BigQuery (via the per-ad query in performance-data-sources.md). Match by exact headline text — this is reliable because Google preserves headline strings verbatim.
4. When a match is found, you can trace forward from the BigQuery row → the headline → the variant type → the source card → the derivation chain → the original prospect language or proof point. This is the strong direction of inference.

If no source card files exist (the campaigns running in BigQuery weren't generated by /octave:ads — e.g., they were created in the Google Ads UI directly), fall through to Path B (reverse-inference).

Path B — Legacy or externally created campaign (no source cards): For everything currently running in production that wasn't generated by /octave:ads, the resonance loop has to reverse-infer the variant type and source card from the headlines themselves. This is a much weaker form of analysis — you're looking at the output and guessing what the brief was. Be honest about this in the report: a winning headline tells you what worked, but without the original brief you can only speculate about which underlying angle made it work.

The reverse-inference process for legacy campaigns:

1. Cluster headlines by inferred variant type. Read the headline pool of each ad and tag it with the closest matching variant type (pain-focused, outcome-focused, social-proof, competitive, question-based, data-driven, status-quo, authority, brand-only — see variant-methodologies.md). Most legacy ads will be brand-only or generic-benefit; that's a finding in itself.
2. Look at headline structure and pinning. A pinned HEADLINE_1 tells you what the ad creator believed was the lead message. A pool of 15 headlines with no pinning tells you Google was given full optimization latitude. A pool of 5 brand headlines tells you the creator never tested angles at all.
3. Trace winners backward to speculative source cards. If "Still Prepping Audits By Hand?" wins, the implicit Pain Language Audit might be: emotional core = visceral frustration with manual compliance work; specific dysfunction = audit preparation as an unautomated weeks-long process; data tier = INFERRED (no underlying field finding cited). Mark these reverse-inferred cards clearly so the user knows they're hypotheses, not derivations.
4. The library-update recommendations are weaker in Path B. You're recommending changes to personas/Motion ICP narratives based on what appears to resonate from external creative — not from creative whose grounding you can verify. Lower the confidence tier on every recommendation by one level (HIGH → MEDIUM, MEDIUM → LOW).
5. Recommend that the next campaign go through /octave:ads so the next loop iteration can use Path A. The strongest version of the resonance loop requires that the campaign and the analysis share a vocabulary.

2.3: Build the resonance map

For each variant with performance data (Path A) or each ad group (Path B at small spend), produce the map. The template adapts to the mode picked in 2.1 — at small spend, there are no per-variant winners to list; the unit of comparison is ad groups.

Standard template (ad mode or full resonance mode):

## Resonance Map

**Data window**: {start} – {end} ({N} days) | **Spend**: ${X} | **Total impressions**: {N} | **Total conversions**: {N}
**Mode**: {smoke-test | ad-group | ad | full resonance}
**Path**: {A — source cards exist | B — reverse-inferred from headlines}

### Winners (top performing variants)

| Variant | Type | Ad Set | CTR | Conv Rate | Source Card | Derivation Chain | Confidence |
|---------|------|--------|-----|-----------|-------------|-----------------|------------|
| "Still Prepping Audits By Hand?" | Pain-focused | VP Eng × FinServ | 3.2% | 1.8% | Pain Language Audit | Finding F-123 (call w/ Acme, 2 weeks ago) → emotional core: "fear of failed audits" → headline | HIGH |

**What this tells us**: The pain of manual audit prep resonates more strongly than the cost-of-inaction framing for VP Engineering personas. The winning language traces to a specific finding from a real sales call — this isn't just ad performance, it's market validation of a pain point.

### Underperformers (below-average variants)

| Variant | Type | Ad Set | CTR | Conv Rate | Source Card | Hypothesis for Underperformance | Confidence |
|---------|------|--------|-----|-----------|-------------|-------------------------------|------------|
| "Every Hire Starts From Zero" | Status quo | VP Eng × FinServ | 0.4% | 0.1% | Compounding Cost Model | The compounding narrative may be too abstract for search intent — buyers searching for solutions want immediate pain acknowledgment, not long-term projections | MEDIUM |

Small-spend template (ad-group mode):

When the data only supports ad-group comparisons, lead with the CPC gap finding instead of variant-level analysis:

## Resonance Map

**Data window**: {start} – {end} ({N} days) | **Spend**: ${X} | **Total conversions**: {N}
**Mode**: ad-group (spend too low for ad-level conclusions)
**Path**: {A | B}

### Ad Group Comparison

| Ad Group | Campaign | Impr | Clicks | CTR | Conv | Cost | CPC | Confidence |
|---|---|---|---|---|---|---|---|---|
| VP Eng × Enterprise FinServ | Compliance Automation Q1 | 1,000 | 60 | 6.00% | 1 | $180 | $3.00 | HIGH |
| Director Compliance × Mid-Market | Compliance Automation Q1 | 400 | 15 | 3.75% | 0 | $225 | $15.00 | HIGH |

**Key finding**: The Director Compliance ad group costs ~5x more per click than the VP Eng ad group and converts at 0% vs ~1.5% over the window. This is a Quality Score / keyword-creative match gap, not a creative gap alone — even rewriting the ads will not close a CPC delta this large without keyword changes.

**Actionable**: Pause or rework the Director Compliance ad group. Move budget to VP Eng. Expected effect: ~5x more clicks per dollar at the same total spend.

### Per-ad observations (FYI only — too noisy to act on)

[List ads with their headlines and metrics, but explicitly do NOT rank them or label winners/losers. The ad-group finding is the actionable one.]

Confidence tiers for the resonance map:

• HIGH: 14+ days of data, 1,000+ impressions on the unit being compared, the metric in question is one the spend tier supports as stable
• MEDIUM: 7–14 days, 500+ impressions, OR the metric is borderline for the spend tier
• LOW: < 7 days, < 500 impressions, OR the metric is one the spend tier explicitly does not support
• N/A: Unit has < 100 impressions or < 5 clicks — Google has not given it a fair test, do not include in winners/losers tables

Step 3: Generate Library Update Recommendations

Based on the resonance map, generate specific, actionable recommendations for the Octave library:

## Library Update Recommendations

### Persona Updates
| Persona | Field | Current | Recommended Update | Evidence |
|---------|-------|---------|-------------------|----------|
| VP Engineering | Primary pain point | "Tool sprawl across compliance stack" | "Manual audit preparation that doesn't scale" | Pain-focused variant at 3.2% CTR vs status-quo at 0.4% — manual process pain resonates 8x stronger than tool sprawl framing |

### Playbook Updates
| Playbook | Update | Evidence |
|----------|--------|----------|
| Enterprise FinServ | Add discovery opener: "How are you handling audit prep today?" | Derived from winning headline "Still Prepping Audits By Hand?" — 3.2% CTR proves this question self-selects the right buyer |

### Value Prop Updates
| Value Prop | Update | Evidence |
|------------|--------|----------|
| Compliance Automation | Reframe from "reduce risk" to "eliminate manual audit prep" | Pain-focused (manual process) outperformed authority (risk reduction) by 4x in CTR |

For each recommendation, ask the user whether to apply it:

AskUserQuestion({
  questions: [{
    question: "Apply these library updates?",
    header: "Library Updates",
    options: [
      { label: "Apply all", description: "Update personas and Motion Playbook narratives based on ad performance evidence" },
      { label: "Let me pick", description: "Review each recommendation individually" },
      { label: "Save as findings only", description: "Don't update the library yet — save these as findings for later review" },
      { label: "Skip", description: "Review only, no changes" }
    ],
    multiSelect: false
  }]
})

If they choose to apply updates, use the appropriate MCP tools. For Motion Playbook narrative edits (Strategic narrative, Benefits and impacts, Pains and consequences sections inside a Motion ICP cell), use update_motion_playbook:

→ {octave_mcp}__update_entity(oId: "{persona_oId}", instructions: "{update}")
→ {octave_mcp}__update_motion_playbook(motionPlaybookOId: "{motion_playbook_oId}", instructions: "{update}")

Step 4: Feed Winning Language to Sales

Generate a Sales Intelligence Brief — a summary designed for sales teams showing what language the market is responding to:

## Sales Intelligence Brief — From Ad Performance

### Winning Messages (use these in conversations)
| Message | Where It Won | Suggested Sales Use |
|---------|-------------|-------------------|
| "Still prepping audits by hand?" | Google Search, 3.2% CTR, VP Eng | Discovery opener — ask this in the first 2 minutes |
| "Audit prep: 3 weeks → 2 days" | Google Search, 2.8% CTR, VP Eng | Proof point framing — lead with this specific transformation |

### Messages That Didn't Land (avoid or reframe)
| Message | Where It Failed | Why | Alternative |
|---------|----------------|-----|------------|
| "Every hire starts from zero" | Google Search, 0.4% CTR | Too abstract for search intent | Reframe to concrete: "New hires spend 6 weeks learning your compliance process" |

### Persona Insight
{Persona}: The ad data confirms this buyer responds to **immediate, tangible process pain** over **strategic risk framing**. Lead with "how are you doing X today?" not "what happens if X breaks?"

Step 5: Generate Next Campaign Recommendations

Based on what worked, recommend the next campaign iteration:

## Next Campaign Recommendations

### Double Down
- **Pain-focused variants won across all ad sets** → Next campaign: allocate 60% of budget to pain-focused variants, test 3 pain sub-angles (manual process, time waste, audit failure risk)
- **VP Engineering was the top-converting persona** → Consider increasing bid/budget for this ad set

### Test Next
- **Question-based variant showed high CTR but low conversion** → The question stops the scroll but the landing page may not match. Test a dedicated landing page that mirrors the question framing.
- **No data on Meta/LinkedIn yet** → Repurpose the top 3 Google winners as Meta ads to test cross-platform resonance

### Retire
- **Status quo / cost of inaction variants underperformed everywhere** → Retire this variant type for this persona. The Compounding Cost Model may apply better to executive personas (CFO/CEO) who think in longer time horizons.

Offer to build the next iteration with /octave:ads so its source cards feed the next loop run (Path A).

Step 6: Predictions & Calibration

This step turns the resonance loop from a one-shot analyzer into an iterative scientific instrument with a verifiable track record. Read prediction-cards.md for the full schema, prediction types, persistence model, self-tuning rules, and the empirical lessons from prior backtests. That doc is the source of truth for everything in this step.

The principle: at the end of every loop run, write down explicit, falsifiable predictions about what specific metrics will do over a specific window. The next time the loop runs, evaluate the previous predictions against actual data and report a track record. Over time, calibration accumulates and the loop tunes its own confidence based on its own history of being right and wrong.

6.1: Read previous predictions FIRST (before generating new findings)

At the start of every loop run, before producing any new resonance map:

Determine the MCC ID and today's date (the loop needs both to find the right file and evaluate predictions):

• The MCC ID is the numeric suffix on the BigQuery table names. Run bq ls <project>:<dataset> and look for tables matching ads_Campaign_<digits>. The digits are the MCC ID. If multiple MCCs are present, ask the user which to analyze.
• Today's date in UTC: run date -u +%Y-%m-%d via the Bash tool, OR use the currentDate value from the system context if available.

Then read previous predictions:

1. Read ~/.octave/predictions/<MCC_ID>.json. If the file doesn't exist, this is the first run for this account — skip to 6.3 (no previous predictions to evaluate). On first run, copy prediction-cards.template.json to the destination path as the starter file.
2. Find all cards with status: PENDING whose evaluation_window end date is on or before today.
3. For each such card, read its evaluation_sql field — the loop generates SQL queries at prediction-creation time and stores them in the card so re-evaluation is deterministic. Substitute the placeholders (<project>, <dataset>, <MCC>, <window_start>, <window_end>) with the actual values, then run via bq query.
4. Apply the card's confirms / refutes / inconclusive conditions to the query result. Update the card with one of: CONFIRMED, REFUTED, INCONCLUSIVE_FAVORABLE, INCONCLUSIVE_UNFAVORABLE, or leave as PENDING with a partial_evaluation block if the window data isn't fully landed yet (the BQ data only goes through yesterday — anything past that is PENDING).
5. Apply the refresh-window rule: if the prediction's evaluation_window end date is within the last refresh_lag_days (typically 7), set tentative: true on the card regardless of which resolution status you assigned. Both CONFIRMED and REFUTED can flip inside the refresh window — late-reported data can push rate metrics in either direction (CTR can drop if impressions grow faster than clicks; conversion rate can rise if late conversions come in; CPC can change as total cost adjusts). Only set tentative: false once the evaluation window has aged past window_end + refresh_lag_days. Tentative cards are re-evaluated on every subsequent run until they finalize. See prediction-cards.md § "Common pitfalls" #7 for the full rule and the empirical backtest evidence behind it.
6. Write evaluated_at, evaluated_against, and evaluation_notes for each updated card.
7. Execute the card's action_if_<status> instructions — most often this means promoting/demoting source cards in the library, NOT changing campaigns autonomously.

6.2: Show the user the "Previous Predictions Evaluated" panel

Before showing the new resonance map, show the user a summary of what the last run's predictions said and how they resolved:

## Previous Predictions Evaluated

| ID | Type | Claim | Status | Notes |
|---|---|---|---|---|
| P-2026-04-03-004 | cpc-efficiency-gap | CPC gap holds at >= 3x | ✅ CONFIRMED | Held at ~5x via a new ad group that didn't exist at prediction time |
| P-2026-04-03-002 | regression-to-mean | Pilot ad group conv rate regresses to 0-3% | 🟡 INCONCLUSIVE_FAVORABLE | Volume gate failed (8 clicks); directional signal supports the prediction |
| P-2026-04-03-001 | regression-to-mean | Pilot ad group CTR regresses to 4-6% | 🟡 INCONCLUSIVE_UNFAVORABLE | Volume gate failed; CTR moved away from prediction |
| P-2026-04-03-003 | exposure-projection | Director Compliance reaches 30 clicks in 7 days | ⏳ PENDING | 4 of 7 days available; on track to refute |

**Track record so far**: 1 confirmed / 0 refuted / 2 inconclusive (1 favorable, 1 unfavorable) / 1 pending
**Strongest type**: cpc-efficiency-gap (1/1 confirmed)

This panel is the user-facing magic. It builds trust by being honest about what the loop got right and wrong last time.

6.3: Generate new prediction cards

After producing the new resonance map (Steps 2–5), generate 3–6 new prediction cards covering the strongest claims in the current run. Read prediction-cards.md for the full taxonomy of prediction types and the rules for each.

Hard rules for prediction generation:

1. Every prediction must be a SQL query that returns a boolean. Vague claims ("the pain framing will keep winning") are not predictions.
2. Every prediction must specify CONFIRMS, REFUTES, and INCONCLUSIVE conditions as precise queries the next loop run can execute without additional human input.
3. Prefer structural predictions over unit-specific predictions (the structural-over-unit rule). The first backtest empirically validated this: structural predictions generalized to brand new units, unit-specific predictions failed when the named unit lost volume between windows. See prediction-cards.md § "The structural-over-unit rule" for examples.
4. Always generate one field-stability prediction per run. It's a meta-prediction about whether the cast of ad groups will change, and it's the first signal the loop has about whether to weight structural vs unit-specific claims more heavily on the next run.
5. Don't generate regression-to-mean predictions for units below the volume gate. Compute (current run rate clicks/day) * 7 >= volume_gate. If false, generate an exposure-projection instead — those can be confirmed even at low volume.
6. Read the calibration block before generating new predictions, and apply the self-tuning rules deterministically. Don't eyeball the hit rate — apply the exact rules in prediction-cards.md § "Self-tuning over time", in order. Those rules are deterministic so two future sessions reading the same calibration block will make the same tuning decisions. Always note in the loop output what tuning was applied (e.g., "cpc-efficiency-gap promoted from MEDIUM to HIGH based on 12/14 hit rate").

For each new card, fill in every field of the schema (see prediction-cards.md § "The prediction card schema"). Required fields: id, generated_at, generated_by, mode, is_structural, claim, type, evaluation_window, evidence_at_prediction, confirms (natural language), refutes (natural language), inconclusive (natural language), evaluation_sql (the parameterized SQL query that produces the data needed to apply the confirm/refute/inconclusive conditions — uses placeholders <project>, <dataset>, <MCC>, <window_start>, <window_end>), confidence, rationale, action_if_confirmed, action_if_refuted, action_if_inconclusive, status: PENDING.

The evaluation_sql field is what makes the loop deterministic across runs. Without it, the next session has to interpret the natural-language confirms field and reconstruct a query — different sessions may write different queries. Always emit the SQL at generation time so re-evaluation is mechanical, not interpretive. See prediction-cards.template.json for example schemas with evaluation_sql filled in.

6.4: Update the calibration block and write the file

After all evaluation and generation is complete, recompute the calibration block at the bottom of the JSON file:

• total_predictions, evaluated, pending, confirmed, refuted, inconclusive_favorable, inconclusive_unfavorable
• directional_hit_rate: (confirmed + inconclusive_favorable) / (resolved predictions)
• by_type: per-prediction-type breakdown with hit rates
• lessons: append any new lessons learned from this run (especially if a previously confirmed type just got refuted, or vice versa)

Write the file back to ~/.octave/predictions/<MCC_ID>.json. Include a brief mention in the loop's user-facing output: "Updated prediction track record at ~/.octave/predictions/<MCC_ID>.json — N new predictions generated, evaluate by [date]."

6.5: Show upcoming evaluation dates

Tell the user when the next meaningful prediction resolution will occur:

## Upcoming Prediction Evaluation Dates

| Earliest evaluation | Predictions resolving |
|---|---|
| 2026-04-13 | P-2026-04-07-001 (CPC gap), P-2026-04-07-002 (CPC tier distribution), P-2026-04-07-003 (VP Eng ad group reaches 100 clicks) |
| 2026-04-13 | P-2026-04-07-004 (conversions reach 5), P-2026-04-07-005 (field stability) |

Re-run `/octave:ads-resonance` on or after 2026-04-13 to see how these resolved.

This gives the user a reason to come back. It's also a hint for setting up a recurring run (see "Cadence and scheduling" in prediction-cards.md).

6.6: Offer HTML output

After the chat-markdown resonance map, library updates, sales brief, next-campaign recommendations, and prediction cards have been generated, offer to also produce self-contained HTML reports for longitudinal consumption:

AskUserQuestion({
  questions: [{
    question: "Generate HTML reports alongside the chat output?",
    header: "HTML reports",
    options: [
      { label: "Both reports", description: "Resonance report (this run's findings) + Prediction dashboard (full calibration track record)" },
      { label: "Resonance report only", description: "Self-contained HTML of this run's findings, saved to ~/Desktop/" },
      { label: "Prediction dashboard only", description: "Self-contained HTML showing all active and resolved predictions with calibration stats, saved to ~/Desktop/" },
      { label: "Skip", description: "Chat output is enough" }
    ],
    multiSelect: false
  }]
})

• Resonance report: follow resonance-report-template.md. Save to ~/Desktop/resonance-report-<workspace-slug>-<YYYY-MM-DD>.html.
• Prediction dashboard: follow prediction-dashboard-template.md. Save to ~/Desktop/prediction-dashboard-<workspace-slug>-<YYYY-MM-DD>.html. Reads from ~/.octave/predictions/<MCC_ID>.json.

Both reports are self-contained single HTML files with inline CSS and inline SVG charts — no external JS, no external images, only Google Fonts via CDN. They work offline after first load, print cleanly, and can be shared as a single file attachment.

Tell the user the path(s) after generating and suggest opening with open <path> (macOS) or double-click.

6.7: Failure modes

If the loop cannot read or write the predictions file (permissions, disk full, etc.):

• Continue with the rest of the resonance loop normally
• Tell the user clearly: "Unable to read/write prediction cards at ~/.octave/predictions/<MCC_ID>.json. Calibration tracking is disabled for this run."
• Do NOT try to recreate the file from scratch (might destroy history)
• Do NOT proceed silently without telling the user the calibration system is broken

If the schema version of an existing file is NEWER than what the current loop knows about (current: v0.2):

• Refuse to write (would lose information from a future schema)
• Read PENDING predictions if possible, evaluate them, but do not append new predictions
• Tell the user the loop and the file are out of sync

Related Skills

• /octave:ads - Build the ad campaigns this loop analyzes (persists the source cards that unlock Path A)
• /octave:library - Review and refine the personas, Motion Playbooks, and value props the loop recommends updating
• /octave:insights - Field intelligence from calls and emails (the conversational counterpart to ad resonance)