/growth-factors-mining

name: growth-factors-mining
description: Builds a per-run LIGHT growth-vector database for the Diffmode growth-tactics pipeline by mining public growth case studies fresh, every run, and distilling each into atomic "growth factors" (transferable mechanisms). Clean-room — NEVER reads the proprietary tactics_DB. Outputs growth-factors.json (~20-40 vectors spread across the 6-category scheme — not every category is populated; `conv-` is routinely empty on a demand-gen run) in the schema the synthesis chain + lite-constraints consume. Use as the per-run substitute for the proprietary 576-vector database when generating free growth-tactic ideas.
metadata:
  version: "1.0.0"

Growth-Factors Mining (per-run LIGHT vector DB)

You build a small, fresh growth-mechanism database from **public case studies**, distilled using the "mechanism over tactic" method. This is the free pipeline's substitute for the proprietary 576-vector database: a deliberately weaker, clean-room asset that gives the synthesis chain real vectors to combine without shipping any proprietary IP.

⚠️ Clean-room rule (moat-critical — non-negotiable)

You MUST build this **only** from freshly researched public sources. You MUST NOT read, open, glob, or grep anything under `tactics_DB/` (the proprietary vector DB, its intelligence layer, and anti-vector tracking — and any script that reads them). No content here may be traceable to that database. The value you ship is the **method**; the DB it produces is intentionally lighter than the paid one. If any input path points into `tactics_DB/`, refuse it and note it in your summary.

Inputs & Output

The invoker provides (do not hardcode absolute paths):

• **INPUT — founder context** (required): `WS/01-diagnostics/founder-input.md`. Read FIRST

— use the product's business model, industry, stage, channels, and audience to **bias your case-study search** toward relevant growth stories (a bootstrapped B2B SaaS should mine indie SaaS / community-led / content / PLG case studies, not enterprise ad-spend stories).

• **INPUT — competitive context** (optional but recommended):

`WS/02-enrichment/competitors-analysis.md` and `WS/02-enrichment/acquisition-tactics.md` — to seed searches around the channels/tactics live in this founder's space and the adjacent industries worth borrowing from.

• **WEB RESEARCH** (required capability): your web-research backend — search plus page

retrieval. This is the ONLY source of vectors.

• **OUTPUT**: write `WS/03-think-tanks/demand-generation/growth-factors.json`.

Caching & bounded research (cost control — surface this tradeoff)

This stage is deliberately "fresh per run," which is slower / pricier / less deterministic than a static asset. Mitigate:

• **Cache:** if `growth-factors.json` already exists at the output path AND the brief does

NOT set `remine: true`, do NOT re-research. Read the existing file, validate it against the schema + counts below, and return `{status:"ok", ...,"summary":"reused cached growth-factors.json (N vectors)"}`. Re-mine only when the orchestrator brief sets `remine: true` (a Start-fresh relaunch) or the file is missing/invalid.

• **Resume-partial (socket-death recovery — do NOT re-pay for deep research):** if the brief

includes **`resume_partial: true`** (the orchestrator sets this only when re-spawning after a mid-mine death) AND a partial `growth-factors.json` exists that PARSES but is short of target (e.g. < 20 vectors, or otherwise incomplete), **read it, KEEP every already-distilled vector verbatim, and mine ONLY the remainder** needed to reach the target count + category spread. Continue each prefix's sequential numbering from where the partial file left off; do NOT re-run the deep-research passes that produced the vectors already on disk — that duplication (≈8 deep research calls) is exactly what this flag exists to avoid. `resume_partial` is **never combined with `remine: true`** (which forces a full fresh re-mine); if both somehow appear, `remine` wins and you re-research from scratch.

• **Bound breadth + cap deep research (the run's biggest cost lever):** review **12-20

public case studies** using **at most ~1-2 deep-research passes** (iterate search + page retrieval, or a single deep multi-source call if your backend has one) — seed them from the founder context for the initial case-study landscape, then gather the remaining case studies + their specific metrics with cheaper plain-search calls. Do NOT open-ended crawl. This stage's deep-research calls were the single biggest cost driver in the field (~85% of a run's research spend; a socket-death respawn used to *duplicate* them), so keep them scarce — search-first. Stop when you have enough distinct mechanisms to hit the target count.

Method — adapt the proven extraction methodology

Apply the proven "mechanism over tactic" extraction method (inlined below). For each case study:

1. **Mechanism, not tactic.** Capture WHY it worked at a first-principles level ("high-concept analogy bypasses explanation friction"), NOT what they did ("posted on LinkedIn"). One case study yields 1-3 atomic vectors. 2. **Transferability test.** Would this work in a *completely different* industry? Give 2-3 cross-industry `examples` proving it transfers. Drop "Low transferability" / very context-specific findings. 3. **Dedup.** Before adding a vector, check it isn't the same mechanism as one already in your list with different words. Merge duplicates; keep the cleaner statement. 4. **No generic advice.** Reject "be consistent", "post regularly", "talk to customers" — those aren't vectors. 5. **Demand-gen lean.** Prefer `lever-` / `resource-` / `struct-` (acquisition/distribution mechanisms). `psych-` and `pos-` are allowed when the mechanism drives *acquisition* (reciprocity → partnership access, exclusivity → community growth, authority signaling → outreach acceptance). `conv-` only