Growth Factors Mining

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 for the rare acquisition-adjacent conversion mechanism. This is a demand-gen pipeline.

Categories & ID format (NOT secret — reused so synthesis runs unchanged)

The 6 categories and the {prefix}-NNN-slug ID format are public conventions. Reuse them so the ported synthesis prompts consume your output unchanged. Numbering is local to this run — number sequentially per prefix starting at 001 based on the order you mine them. Any resemblance to proprietary IDs is incidental; you derive these independently.