@mindrian_os/install 1.13.0-beta.11

package/pipelines/analogy/02-abstract.md

@@ -0,0 +1,87 @@
+---
+stage: 2
+methodology: reason
+chain: analogy
+input_from: decompose
+output_to: search
+room_section: problem-definition
+---
+
+# Stage 2: Abstract (Domain-Independent Encoding)
+
+## Input Extraction
+
+Extract from Stage 1 artifact (scan `room/problem-definition/` for most recent artifact with `pipeline: analogy` and `pipeline_stage: 1` in frontmatter):
+
+- **SAPPhIRE triples** -- the function-behavior-structure decomposition per room section
+- **Core contradiction** -- the improving-vs-worsening tension
+- **Function-behavior-structure** -- the domain-specific encoding to be abstracted
+
+Present to the user: "From the decomposition, I'm abstracting: [function] as the core function, with [contradiction] as the key tension to resolve."
+
+## Stage Instructions
+
+The goal is to strip ALL domain-specific language and produce a purely functional description that could apply to any field. This is what enables cross-domain search -- you cannot find analogies in biology if you keep using business terminology.
+
+### Step 1: Functional Verb Replacement
+
+Replace every domain-specific term with a standardized functional verb. Read `references/methodology/sapphire-encoding.md` for the functional verb vocabulary.
+
+Standard functional verbs: deliver, protect, transform, connect, filter, amplify, regulate, separate, convert, store, distribute, stabilize, absorb, channel, detect, signal, adapt, repair, recycle, generate.
+
+Examples:
+- "Customer acquisition funnel" becomes "filter population by fit criteria, convert interest to commitment"
+- "Tumor drug resistance" becomes "adaptive barrier blocks delivery system"
+- "Supply chain optimization" becomes "minimize transfer distance while maintaining flow capacity"
+- "Competitive moat" becomes "structural barrier that increases with usage"
+
+Larry should challenge domain-locked thinking aggressively: "You keep saying 'market penetration' -- but functionally, what is penetration? It's overcoming a barrier to reach a target. Where else do systems overcome barriers to reach targets? Everywhere -- cell membranes, firewalls, military logistics, root systems in soil."
+
+### Step 2: TRIZ Parameter Mapping
+
+Read `references/methodology/triz-principles.md` for the 39 TRIZ parameters and 40 inventive principles.
+
+Map the core contradiction to TRIZ parameter space:
+1. Identify which of the 39 parameters the venture is trying to IMPROVE
+2. Identify which of the 39 parameters WORSENS as a result
+3. Look up the TRIZ Contradiction Matrix intersection for suggested inventive principles
+
+Read `references/methodology/triz-matrix.json` for the contradiction matrix data.
+
+Format:
+```
+TRIZ Contradiction:
+  Improving: Parameter [N] - [name]
+  Worsening: Parameter [M] - [name]
+  Suggested Principles: [P1], [P2], [P3], [P4]
+  Principle descriptions: [from triz-principles.md]
+```
+
+### Step 3: Functional Keywords for Search
+
+Produce 5-10 domain-independent keywords that capture the venture's core functions. These become the search queries for Stage 3.
+
+Format: `[verb] + [abstract object]`
+Examples: "filter population", "overcome adaptive barrier", "amplify weak signal", "distribute through network", "regulate bidirectional flow"
+
+When the methodology produces its artifact, ensure pipeline provenance is added to frontmatter:
+
+```yaml
+pipeline: analogy
+pipeline_stage: 2
+abstract_function: "[domain-independent function description]"
+triz_improving: "[parameter number and name]"
+triz_worsening: "[parameter number and name]"
+triz_principles: [list of suggested principle numbers]
+functional_keywords: [list of 5-10 search keywords]
+```
+
+## Output Contract
+
+The following sections from the artifact feed into Stage 3 (search):
+
+- **Abstract function description** -- becomes the primary search query for cross-domain analogy retrieval
+- **TRIZ parameter mapping** -- guides search toward domains that resolved the same contradiction type
+- **Functional keywords** -- become specific search terms for AskNature, patents, and academic databases
+
+Stage 3 will extract these by scanning `room/problem-definition/` for the most recent artifact with `pipeline: analogy` and `pipeline_stage: 2` in frontmatter.

package/pipelines/analogy/03-search.md

@@ -0,0 +1,135 @@
+---
+stage: 3
+methodology: research
+chain: analogy
+input_from: abstract
+output_to: transfer
+room_section: competitive-analysis
+---
+
+# Stage 3: Search (Dual-Mode Analogy Retrieval)
+
+## Input Extraction
+
+Extract from Stage 2 artifact (scan `room/problem-definition/` for most recent artifact with `pipeline: analogy` and `pipeline_stage: 2` in frontmatter):
+
+- **Abstract function description** -- the domain-independent encoding of the venture's core problem
+- **TRIZ parameter mapping** -- improving/worsening parameters and suggested inventive principles
+- **Functional keywords** -- 5-10 domain-independent search terms
+
+Present to the user: "Searching for analogies to: [abstract function]. Looking for systems that [functional description] across [internal/external/both] sources."
+
+## Stage Instructions
+
+This stage runs DUAL-MODE search: internal (room graph + Brain) and external (web research). The mode depends on user preference or pipeline configuration:
+
+- **Internal only** (`--brain`): KuzuDB + Brain queries, no web search
+- **External only** (`--external`): Tavily web research, no Brain queries
+- **Both** (default): All sources in parallel
+
+### Internal Search (Tier 0 / Tier 1 / Tier 2)
+
+#### Tier 0: LLM Reasoning (always available)
+
+Use the abstract function description and functional keywords to generate candidate analogies from training knowledge. For each candidate, provide:
+- Source domain
+- How the analogy maps structurally
+- Analogy distance classification (near / far / cross-domain)
+
+Generate 3-5 candidates from diverse domains (biology, engineering, military, sports, economics, ecology, etc.).
+
+#### Tier 1: KuzuDB Local Graph (if room/.lazygraph/ exists)
+
+Query existing HSI_CONNECTION edges for structural_transfer matches:
+
+```
+Scan HSI_CONNECTION edges where innovation_type = 'structural_transfer'
+Sort by hsi_score DESC
+Return top 5 with source/target artifacts and structural descriptions
+```
+
+Also query CONTRADICTS edges that share the same TRIZ parameter pattern as the venture's contradiction.
+
+#### Tier 2: Brain MCP (if connected)
+
+Read `references/brain/query-patterns.md` for `brain_cross_domain` and `brain_search_semantic` patterns.
+
+1. **brain_cross_domain**: Find bridging frameworks between the venture's domain and other domains
+2. **brain_search_semantic**: Vector search using the abstract function description as query text
+3. **brain_analogy_search**: Find frameworks from DIFFERENT domains that address the SAME problem type
+
+```cypher
+MATCH (f1:Framework)-[:ADDRESSES_PROBLEM_TYPE]->(pt:ProblemType)
+WHERE f1.category = $source_category
+WITH pt, collect(f1) AS source_frameworks
+MATCH (f2:Framework)-[:ADDRESSES_PROBLEM_TYPE]->(pt)
+WHERE NOT f2.category = $source_category
+AND NOT f2 IN source_frameworks
+OPTIONAL MATCH (f2)-[:CO_OCCURS]->(bridge:Framework)
+WHERE bridge IN source_frameworks
+RETURN f2.name, f2.category, f2.description, pt.name, bridge.name
+ORDER BY bridge IS NOT NULL DESC
+LIMIT 15
+```
+
+### External Search (via Tavily MCP)
+
+If external mode is active, dispatch parallel research queries:
+
+1. **Biomimicry search**: Search AskNature.org with functional keywords
+   - Query: "how does nature [abstract function keyword]?"
+   - Example: "how does nature filter population by fit criteria?"
+
+2. **Patent search**: Search Google Patents or Lens.org with TRIZ principles
+   - Query: "[TRIZ principle name] AND [functional keyword]"
+   - Example: "segmentation AND adaptive barrier delivery"
+
+3. **Academic search**: Search Google Scholar or Semantic Scholar
+   - Query: "[abstract function] cross-domain analogy"
+   - Example: "overcome adaptive barrier delivery system structural isomorphism"
+
+Each external result must include:
+- Source URL and title
+- Source domain classification
+- How it maps to the venture's abstract function
+- Analogy distance score (near/far/cross-domain)
+- Structural fitness estimate (0-1)
+
+### Ranking and Classification
+
+Combine all results (internal + external) and rank by:
+
+| Factor | Weight | Description |
+|--------|--------|-------------|
+| Structural fitness | 40% | How well the relational structure maps to the venture |
+| Analogy distance | 30% | Far/cross-domain analogies score higher (more novel) |
+| Evidence quality | 20% | Concrete examples beat abstract similarities |
+| Source reliability | 10% | Brain graph > academic > patent > web |
+
+Classify each analogy by distance:
+- **Near** (same industry): structural_fitness 0.30-0.45, low surprise
+- **Far** (adjacent domain): structural_fitness 0.45-0.65, medium surprise
+- **Cross-domain** (completely different field): structural_fitness > 0.65, high surprise
+
+When the methodology produces its artifact, ensure pipeline provenance is added to frontmatter:
+
+```yaml
+pipeline: analogy
+pipeline_stage: 3
+search_mode: "[internal|external|both]"
+analogies_found: [count]
+top_analogy: "[source domain]: [brief description]"
+analogy_distances: { near: N, far: N, cross_domain: N }
+discovery_methods: [list of methods that found results]
+```
+
+## Output Contract
+
+The following sections from the artifact feed into Stage 4 (transfer):
+
+- **Top 3-5 ranked analogies** -- each with source domain, structural mapping, distance classification
+- **Structural fitness scores** -- quantified mapping quality for each analogy
+- **Discovery provenance** -- how each analogy was found (LLM/KuzuDB/Brain/external)
+- **TRIZ principle alignment** -- which inventive principles each analogy embodies
+
+Stage 4 will extract these by scanning `room/competitive-analysis/` for the most recent artifact with `pipeline: analogy` and `pipeline_stage: 3` in frontmatter.

package/pipelines/analogy/04-transfer.md

@@ -0,0 +1,101 @@
+---
+stage: 4
+methodology: structure-argument
+chain: analogy
+input_from: search
+output_to: validate
+room_section: solution-design
+---
+
+# Stage 4: Transfer (Correspondence Table Generation)
+
+## Input Extraction
+
+Extract from Stage 3 artifact (scan `room/competitive-analysis/` for most recent artifact with `pipeline: analogy` and `pipeline_stage: 3` in frontmatter):
+
+- **Top 3-5 ranked analogies** -- source domain, structural mapping, distance classification
+- **Structural fitness scores** -- quantified mapping quality
+- **TRIZ principle alignment** -- inventive principles each analogy embodies
+
+Also re-read Stage 1 artifact (scan `room/problem-definition/` for `pipeline: analogy` and `pipeline_stage: 1`) for:
+- **SAPPhIRE triples** -- the original function-behavior-structure of the venture
+- **Core contradiction** -- what the transferred solution must resolve
+
+Present to the user: "I found [N] analogies. The strongest is from [source domain] with [structural fitness] structural fitness. Building correspondence tables for the top [3] candidates."
+
+## Stage Instructions
+
+Run `/mos:structure-argument` to build a Minto Pyramid for each transferred solution. The governing thought for each is: "The solution from [source domain] can be adapted to [venture domain] because [structural isomorphism]."
+
+### Step 1: Correspondence Table Construction
+
+For each of the top 3 analogies, build an explicit correspondence table:
+
+```markdown
+## Correspondence Table: [Source Domain] -> [Venture Domain]
+
+| Source Element | Source Function | Venture Equivalent | Transfer Feasibility |
+|---------------|----------------|-------------------|---------------------|
+| [element A1] | [what it does in source] | [proposed venture equivalent] | High/Medium/Low |
+| [element A2] | [what it does in source] | [proposed venture equivalent] | High/Medium/Low |
+| [element A3] | [what it does in source] | [proposed venture equivalent] | High/Medium/Low |
+
+**Structural Isomorphism:** [description of which relations are preserved]
+**What Transfers:** [specific solution principle that applies]
+**What Does NOT Transfer:** [domain-specific elements that break the mapping]
+**Transfer Distance:** [near/far/cross-domain]
+```
+
+### Step 2: Concrete Design Proposals
+
+For each correspondence table, generate a concrete design proposal:
+
+1. **The Adaptation**: How the source domain solution would work in the venture's context
+2. **Implementation Steps**: 3-5 specific actions to apply the transferred principle
+3. **Required Modifications**: What changes to the venture's current approach are needed
+4. **New Capabilities Needed**: What the venture would need to build or acquire
+5. **Expected Impact**: How this resolves the core contradiction identified in Stage 1
+
+### Step 3: Transfer Feasibility Scoring
+
+Rate each transfer on two axes:
+
+| Axis | Score Range | Measures |
+|------|-----------|----------|
+| **Structural fit** | 0.0-1.0 | How many relations from the source survive in the venture mapping |
+| **Implementation distance** | 0.0-1.0 | How far the venture needs to move from its current state (lower = easier) |
+
+**Combined score** = structural_fit * (1 - implementation_distance * 0.5)
+
+This penalizes high-distance implementations but not as heavily as low structural fit.
+
+### Step 4: KuzuDB Edge Creation
+
+If room/.lazygraph/ exists, the following edges should be created after Stage 4:
+
+- **ANALOGOUS_TO** edges between venture artifacts and source domain concepts
+  - Properties: analogy_distance, structural_fitness, source_domain, transfer_map (JSON), discovery_method, pipeline_stage: 4
+- **RESOLVES_VIA** edges linking existing CONTRADICTS edges to the proposed resolution
+  - Properties: resolution_type: "analogy", analogy_source, confidence, triz_principle
+
+When the methodology produces its artifact, ensure pipeline provenance is added to frontmatter:
+
+```yaml
+pipeline: analogy
+pipeline_stage: 4
+transfers_generated: [count]
+top_transfer: "[source domain] -> [venture domain]: [brief description]"
+combined_scores: [list of combined feasibility scores]
+edges_created: { analogous_to: N, resolves_via: N }
+```
+
+## Output Contract
+
+The following sections from the artifact feed into Stage 5 (validate):
+
+- **Correspondence tables** -- the explicit element-to-element mappings for each analogy
+- **Design proposals** -- concrete adaptations to stress-test
+- **Transfer feasibility scores** -- structural fit and implementation distance ratings
+- **What does NOT transfer** -- known mapping failures for Devil's Advocate to probe
+
+Stage 5 will extract these by scanning `room/solution-design/` for the most recent artifact with `pipeline: analogy` and `pipeline_stage: 4` in frontmatter.

package/pipelines/analogy/05-validate.md

@@ -0,0 +1,106 @@
+---
+stage: 5
+methodology: challenge-assumptions
+chain: analogy
+input_from: transfer
+output_to: null
+room_section: competitive-analysis
+---
+
+# Stage 5: Validate (Structural Mapping Stress-Test)
+
+## Input Extraction
+
+Extract from Stage 4 artifact (scan `room/solution-design/` for most recent artifact with `pipeline: analogy` and `pipeline_stage: 4` in frontmatter):
+
+- **Correspondence tables** -- element-to-element mappings for each analogy
+- **Design proposals** -- concrete adaptations to stress-test
+- **Transfer feasibility scores** -- structural fit and implementation distance
+- **What does NOT transfer** -- known mapping failures to probe
+
+Also re-read Stage 2 artifact (scan `room/problem-definition/` for `pipeline: analogy` and `pipeline_stage: 2`) for:
+- **TRIZ contradiction mapping** -- does the transfer introduce NEW contradictions?
+- **Abstract function description** -- does the transfer preserve the core function?
+
+Present to the user: "I have [N] transferred solutions. Now the Devil's Advocate will stress-test each structural mapping to find where they break."
+
+## Stage Instructions
+
+Run `/mos:challenge-assumptions` with the correspondence tables and design proposals as the claims under examination.
+
+### Challenge Framework
+
+For each transferred analogy, the Devil's Advocate must probe:
+
+#### 1. Structural Integrity Challenges
+
+- **Mapping completeness**: "You mapped [source element] to [venture element], but what about [unmapped source element]? The source system needs ALL of these to work -- can you function without it?"
+- **Relation preservation**: "In the source domain, [element A] directly causes [element B]. In your venture, that causal link doesn't exist. The analogy breaks here."
+- **Scale mismatch**: "This works in [source domain] because the system operates at [scale]. Your venture operates at [different scale]. Does the principle survive the scale change?"
+
+#### 2. New Contradiction Detection
+
+For each design proposal, check whether the transferred solution introduces NEW contradictions:
+- "By adopting [source approach], you improve [X] but now you worsen [Y]. This is a new TRIZ contradiction: Parameter [N] vs Parameter [M]."
+- If new contradictions found, look up TRIZ matrix for resolution principles
+- A transfer that resolves one contradiction but creates two new ones is a net negative
+
+#### 3. Domain Assumption Challenges
+
+- "The source domain assumes [condition]. Does that condition hold in your venture?"
+- "This solution evolved in [source ecosystem]. Your ecosystem has [different property]. Will it survive the transplant?"
+- "The analogy distance is [cross-domain]. At this distance, what domain-specific mechanisms are you implicitly importing?"
+
+#### 4. Implementation Feasibility Challenges
+
+- "The implementation distance is [score]. What are the 3 biggest obstacles to getting from here to there?"
+- "This requires [capability] that your team/venture currently lacks. How do you acquire it?"
+- "The source took [timeframe] to develop this. What makes you think you can transfer it in [venture timeframe]?"
+
+### Classification
+
+After stress-testing, classify each transferred analogy:
+
+| Status | Meaning | Action |
+|--------|---------|--------|
+| **SURVIVED** | Structural mapping held under interrogation, no critical failures | Recommend for implementation |
+| **WOUNDED** | Partial structural mapping, some relations broke but core principle transfers | Refine mapping, address broken relations |
+| **KILLED** | Fundamental structural mismatch discovered, analogy is superficial | Document why it failed for learning |
+
+### Survival Map
+
+Produce a survival map showing:
+```
+Analogy 1: [Source Domain] -> [Status]
+  Survived: [which structural mappings held]
+  Failed: [which mappings broke and why]
+  New contradictions: [any introduced by the transfer]
+  Refined proposal: [if WOUNDED, what changes would save it]
+
+Analogy 2: [Source Domain] -> [Status]
+  ...
+```
+
+When the methodology produces its artifact, ensure pipeline provenance is added to frontmatter:
+
+```yaml
+pipeline: analogy
+pipeline_stage: 5
+analogies_tested: [count]
+survived: [count]
+wounded: [count]
+killed: [count]
+new_contradictions_found: [count]
+recommended_transfer: "[best surviving analogy source domain]"
+```
+
+## Output Contract
+
+Final stage -- no downstream pipeline stage. The artifact serves as:
+
+- **Decision support** for which analogies to pursue in the venture
+- **Risk documentation** showing where structural mappings are weakest
+- **Learning record** for why certain cross-domain transfers fail (improves future searches)
+- **Input to /mos:act** for subsequent framework selection based on validated analogies
+
+If a transfer SURVIVED with high structural fitness (> 0.7), Larry should proactively suggest: "This analogy is strong enough to drive your next design iteration. Want me to run `/mos:act` to apply the transferred principle, or `/mos:build-thesis` to incorporate it into your investment argument?"

package/pipelines/analogy/CHAIN.md

@@ -0,0 +1,56 @@
+---
+name: analogy
+display_name: Design-by-Analogy Pipeline
+description: From venture problem to cross-domain analogies -- decompose, abstract, search, transfer, validate
+stages: 5
+estimated_time: 90-180min
+venture_stages: [Discovery, Design, Investment]
+problem_types: [ill-defined-complex, well-defined-complex, well-defined-complicated]
+---
+
+# Design-by-Analogy Pipeline
+
+## When to Use
+
+User has a venture problem, contradiction, or design challenge that could benefit from solutions discovered in other domains. The pipeline formalizes cross-domain analogy discovery -- finding structural isomorphisms between the venture's problem and solutions from biology, engineering, other industries, or academic research.
+
+Typical starting points:
+- "I'm stuck on a design problem and need fresh approaches"
+- "What can we learn from how other industries solved this?"
+- "We have a contradiction -- improving X worsens Y"
+- "Find me analogies from nature or other fields"
+
+## Stage Sequence
+
+1. **decompose** -- Extract SAPPhIRE function-behavior-structure triples from room artifacts
+2. **abstract** -- Strip domain language, map to TRIZ parameter space, produce functional keywords
+3. **search** -- Dual-mode retrieval: internal (KuzuDB + Brain) and external (Tavily for AskNature, patents, academic)
+4. **transfer** -- Build correspondence tables mapping source domain solutions to venture domain
+5. **validate** -- Stress-test structural mappings via Devil's Advocate challenge
+
+## What It Produces
+
+After all 5 stages, the Room will have:
+- **problem-definition:** SAPPhIRE decomposition with function-behavior-structure triples (Stage 1)
+- **problem-definition:** Domain-independent abstract encoding with TRIZ contradiction mapping (Stage 2)
+- **competitive-analysis:** Ranked cross-domain analogies with source domains and structural fitness scores (Stage 3)
+- **solution-design:** Correspondence tables with concrete design proposals transferred from analogous domains (Stage 4)
+- **competitive-analysis:** Validated analogy survival map with stress-test results and refined proposals (Stage 5)
+
+## Chain Provenance
+
+Each artifact includes `pipeline: analogy` and `pipeline_stage: N` in frontmatter, creating an inspectable provenance chain. This allows Larry to detect existing pipeline progress and offer resumption.
+
+## Relationship to Existing Infrastructure
+
+This pipeline FORMALIZES what HSI already discovers implicitly:
+- HSI `structural_transfer` = Stage 2 (ABSTRACT) + Stage 4 (TRANSFER)
+- HSI `semantic_implementation` = Stage 4 (TRANSFER) applied
+- KuzuDB `CONTRADICTS` edges = Stage 1 (DECOMPOSE) contradiction detection
+- Brain `brain_cross_domain` = Stage 3 (SEARCH) internal mode
+
+The pipeline adds: SAPPhIRE encoding, TRIZ parameter mapping, external research orchestration, explicit correspondence tables, and Devil's Advocate validation of structural mappings.
+
+## Quick Access
+
+For on-demand analogy discovery without the full pipeline, use `/mos:find-analogies` which runs a compressed version of Stages 1-3.

package/pipelines/discovery/01-explore-domains.md

@@ -0,0 +1,44 @@
+---
+stage: 1
+methodology: explore-domains
+chain: discovery
+input_from: null
+output_to: think-hats
+room_section: problem-definition
+---
+
+# Stage 1: Domain Explorer
+
+## Input Extraction
+
+First stage -- uses user's topic/problem description directly. No prior pipeline artifact needed.
+
+If the user provided a topic when starting the pipeline, use that as the starting point. If not, the explore-domains methodology will elicit one through conversation.
+
+## Stage Instructions
+
+Run `/mos:explore-domains` with the user's topic.
+
+Focus the session on producing:
+- **Domain Statement** (1 clear sentence defining the territory)
+- **Top 3 intersectional collisions** ranked by surprise level
+- **IKA scores** (Interest, Knowledge, Access) with evidence for each score
+
+Larry should push for specificity in the Domain Statement -- this becomes the core input for Stage 2. Vague domains produce vague downstream analysis.
+
+When the methodology produces its artifact, ensure pipeline provenance is added to frontmatter:
+
+```yaml
+pipeline: discovery
+pipeline_stage: 1
+```
+
+## Output Contract
+
+The following sections from the artifact feed into Stage 2 (think-hats):
+
+- **Domain Statement** -- becomes the topic for Six Thinking Hats exploration
+- **Top collision territory** -- becomes the specific challenge to examine from 6 perspectives
+- **IKA weak spots** -- become specific areas for Black Hat (risk) analysis
+
+Stage 2 will extract these by scanning `room/problem-definition/` for the most recent artifact with `pipeline: discovery` and `pipeline_stage: 1` in frontmatter.

package/pipelines/discovery/02-think-hats.md

@@ -0,0 +1,50 @@
+---
+stage: 2
+methodology: think-hats
+chain: discovery
+input_from: explore-domains
+output_to: analyze-needs
+room_section: solution-design
+---
+
+# Stage 2: Six Thinking Hats
+
+## Input Extraction
+
+Extract from Stage 1 artifact (scan `room/problem-definition/` for most recent artifact with `pipeline: discovery` and `pipeline_stage: 1` in frontmatter):
+
+- **Domain Statement** -- use as the topic for Six Hats exploration
+- **Top collision territory** -- use as the specific challenge to examine from 6 perspectives
+- **IKA weak spots** -- feed into Black Hat (risk) analysis as known vulnerability areas
+
+Present to the user: "From your Domain Explorer work, I'm bringing forward: [Domain Statement] with the collision territory [top collision] and your IKA weak spots [areas] for risk analysis."
+
+## Stage Instructions
+
+Run `/mos:think-hats` with the extracted domain as the topic.
+
+The Six Hats session should be shaped by the Discovery context:
+- **White Hat** (facts): What data exists about this collision territory?
+- **Red Hat** (gut): How does this domain territory feel? What excites or worries you?
+- **Black Hat** (risks): Focus especially on IKA weak spots from Stage 1 -- where are the real dangers?
+- **Yellow Hat** (benefits): What opportunities does this collision create?
+- **Green Hat** (alternatives): What other approaches exist in this territory?
+- **Blue Hat** (synthesis): Pull together the multi-perspective view into a coherent assessment
+
+When the methodology produces its artifact, ensure pipeline provenance is added to frontmatter:
+
+```yaml
+pipeline: discovery
+pipeline_stage: 2
+pipeline_input: "Domain Statement: '[extracted from stage 1]'"
+```
+
+## Output Contract
+
+The following sections from the artifact feed into Stage 3 (analyze-needs):
+
+- **Blue Hat synthesis** -- becomes the problem framing for Jobs to Be Done analysis
+- **Yellow/Black Hat tension** -- becomes the customer segment hypothesis (who benefits vs who is at risk)
+- **Red Hat gut reactions** -- become validation priorities (what needs evidence vs what is assumed)
+
+Stage 3 will extract these by scanning `room/solution-design/` for the most recent artifact with `pipeline: discovery` and `pipeline_stage: 2` in frontmatter.

package/pipelines/discovery/03-analyze-needs.md

@@ -0,0 +1,54 @@
+---
+stage: 3
+methodology: analyze-needs
+chain: discovery
+input_from: think-hats
+output_to: null
+room_section: market-analysis
+---
+
+# Stage 3: Jobs to Be Done
+
+## Input Extraction
+
+Extract from Stage 2 artifact (scan `room/solution-design/` for most recent artifact with `pipeline: discovery` and `pipeline_stage: 2` in frontmatter):
+
+- **Blue Hat synthesis** -- use as the problem framing for JTBD analysis
+- **Yellow/Black Hat tension** -- use as the customer segment hypothesis (who benefits most, who faces highest risk)
+- **Red Hat gut reactions** -- use as validation priorities (what the user feels strongly about but lacks evidence for)
+
+Present to the user: "From your Six Hats analysis, I'm bringing forward: [Blue Hat synthesis] as the problem frame, with [customer segment hypothesis] as our target customer and [validation priorities] as areas where we need evidence."
+
+## Stage Instructions
+
+Run `/mos:analyze-needs` with the extracted customer segment and problem framing.
+
+The JTBD session should be shaped by the Discovery context:
+- Customer segment comes from Yellow/Black Hat tension (who has the most to gain and the most to lose)
+- Problem framing comes from Blue Hat synthesis (the structured view of the territory)
+- Push for specific jobs, not abstract needs -- what progress is the customer trying to make?
+- Validation priorities from Red Hat become the "gut check" areas where JTBD evidence either confirms or challenges intuition
+
+When the methodology produces its artifact, ensure pipeline provenance is added to frontmatter:
+
+```yaml
+pipeline: discovery
+pipeline_stage: 3
+pipeline_input: "Blue Hat Synthesis: '[extracted from stage 2]'"
+```
+
+## Output Contract
+
+Final stage -- no output_to. This completes the Discovery Pipeline.
+
+### What the Full Discovery Pipeline Produced
+
+Across all 3 stages, the Room now contains:
+
+| Room Section | Artifact | From Stage |
+|-------------|----------|------------|
+| problem-definition | Domain Explorer -- territory map, collisions, IKA scores | Stage 1 |
+| solution-design | Six Hats -- multi-perspective analysis, risk/benefit tensions | Stage 2 |
+| market-analysis | JTBD -- customer jobs, hiring criteria, competitive alternatives | Stage 3 |
+
+The provenance chain (`pipeline: discovery`, `pipeline_stage: 1/2/3`) connects all three artifacts, showing how domain territory became customer needs through structured multi-lens analysis.

package/pipelines/discovery/CHAIN.md

@@ -0,0 +1,37 @@
+---
+name: discovery
+display_name: Discovery Pipeline
+description: From domain territory to customer needs -- explore, challenge, validate
+stages: 3
+estimated_time: 45-90min
+venture_stages: [Pre-Opportunity, Discovery]
+problem_types: [undefined-complex, undefined-complicated, ill-defined-complex]
+---
+
+# Discovery Pipeline
+
+## When to Use
+
+User has a vague idea or domain interest and needs to move from "I think this is interesting" to "here's who has the problem and what they need." Best for early-stage ventures where the territory is still undefined -- the user knows something is there but hasn't mapped it yet.
+
+Typical starting points:
+- "I'm interested in X but don't know where to start"
+- "I see an opportunity in this space but can't articulate it"
+- "I have domain expertise but no venture thesis yet"
+
+## Stage Sequence
+
+1. **explore-domains** -- Map the territory, find intersections, score IKA
+2. **think-hats** -- Examine the top domain from 6 perspectives
+3. **analyze-needs** -- Identify specific jobs-to-be-done for the customer segment
+
+## What It Produces
+
+After all 3 stages, the Room will have:
+- **problem-definition:** Domain Explorer artifact with territory map, intersectional collisions, IKA scores
+- **solution-design:** Six Hats analysis with perspective tensions, risk assessment, gut reactions
+- **market-analysis:** JTBD artifact with customer job priorities, hiring criteria, competitive alternatives
+
+## Chain Provenance
+
+Each artifact includes `pipeline: discovery` and `pipeline_stage: N` in frontmatter, creating an inspectable provenance chain. This allows Larry to detect existing pipeline progress and offer resumption.