@mindrian_os/cli 1.13.0-beta.10 → 1.13.0-beta.44

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

@@ -1,44 +0,0 @@
----
-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

@@ -1,50 +0,0 @@
----
-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

@@ -1,54 +0,0 @@
----
-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

@@ -1,37 +0,0 @@
----
-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.

package/pipelines/thesis/01-structure-argument.md

@@ -1,45 +0,0 @@
----
-stage: 1
-methodology: structure-argument
-chain: thesis
-input_from: null
-output_to: challenge-assumptions
-room_section: problem-definition
----
-
-# Stage 1: Structure Argument (Minto Pyramid)
-
-## Input Extraction
-
-First stage -- uses user's thesis, argument, or claim directly. No prior pipeline artifact needed.
-
-If the user provided a thesis statement when starting the pipeline, use that as the starting point. If not, the structure-argument methodology will elicit one through conversation.
-
-## Stage Instructions
-
-Run `/mos:structure-argument` with the user's thesis or claim.
-
-Focus the session on producing:
-- **Core argument** (Minto answer-first statement)
-- **Supporting arguments** (the pillars holding up the core argument)
-- **Evidence for each pillar** (what data or reasoning supports each supporting argument)
-- **Evidence gaps** (where the argument lacks support)
-
-Larry should push for structural clarity -- each level of the pyramid must genuinely support the level above it. Weak pillars get flagged, not ignored.
-
-When the methodology produces its artifact, ensure pipeline provenance is added to frontmatter:
-
-```yaml
-pipeline: thesis
-pipeline_stage: 1
-```
-
-## Output Contract
-
-The following sections from the artifact feed into Stage 2 (challenge-assumptions):
-
-- **Core argument** (Minto answer-first) -- becomes the target for Devil's Advocate interrogation
-- **Supporting arguments** -- become specific assumptions to challenge (each pillar is an assumption)
-- **Evidence gaps** -- become areas for deeper interrogation (where the argument is weakest)
-
-Stage 2 will extract these by scanning `room/problem-definition/` for the most recent artifact with `pipeline: thesis` and `pipeline_stage: 1` in frontmatter.

package/pipelines/thesis/02-challenge-assumptions.md

@@ -1,48 +0,0 @@
----
-stage: 2
-methodology: challenge-assumptions
-chain: thesis
-input_from: structure-argument
-output_to: build-thesis
-room_section: competitive-analysis
----
-
-# Stage 2: Challenge Assumptions (Devil's Advocate)
-
-## Input Extraction
-
-Extract from Stage 1 artifact (scan `room/problem-definition/` for most recent artifact with `pipeline: thesis` and `pipeline_stage: 1` in frontmatter):
-
-- **Core argument** -- the top-level claim that everything else supports
-- **Supporting arguments** -- each pillar becomes an assumption to challenge
-- **Evidence gaps** -- areas where the argument is weakest, deserving deepest interrogation
-
-Present to the user: "From your Minto Pyramid, I'm bringing forward: [core argument] as the claim under examination, with [N] supporting assumptions to stress-test and [evidence gaps] as the weakest points."
-
-## Stage Instructions
-
-Run `/mos:challenge-assumptions` with the extracted core argument and supporting claims.
-
-The Devil's Advocate session should be shaped by the Thesis context:
-- Each supporting argument from Stage 1 is treated as an assumption to challenge
-- Evidence gaps from Stage 1 get the hardest interrogation -- these are where the thesis is most vulnerable
-- For each assumption: attempt to disprove it, find counter-evidence, identify conditions under which it fails
-- Classify each assumption after stress-testing: SURVIVED (strong evidence), WOUNDED (partial evidence), KILLED (disproven or unfounded)
-
-When the methodology produces its artifact, ensure pipeline provenance is added to frontmatter:
-
-```yaml
-pipeline: thesis
-pipeline_stage: 2
-pipeline_input: "Core Argument: '[extracted from stage 1]'"
-```
-
-## Output Contract
-
-The following sections from the artifact feed into Stage 3 (build-thesis):
-
-- **Surviving assumptions** -- become thesis pillars (these held up under interrogation)
-- **Killed assumptions** -- become risks to address (acknowledged weaknesses in the thesis)
-- **New questions raised** -- become areas for thesis qualification (what the thesis needs to acknowledge)
-
-Stage 3 will extract these by scanning `room/competitive-analysis/` for the most recent artifact with `pipeline: thesis` and `pipeline_stage: 2` in frontmatter.

package/pipelines/thesis/03-build-thesis.md

@@ -1,54 +0,0 @@
----
-stage: 3
-methodology: build-thesis
-chain: thesis
-input_from: challenge-assumptions
-output_to: null
-room_section: financial-model
----
-
-# Stage 3: Build Investment Thesis
-
-## Input Extraction
-
-Extract from Stage 2 artifact (scan `room/competitive-analysis/` for most recent artifact with `pipeline: thesis` and `pipeline_stage: 2` in frontmatter):
-
-- **Surviving assumptions** -- use as thesis pillars (these withstood Devil's Advocate scrutiny)
-- **Killed assumptions** -- use as acknowledged risks (honest about what did not survive)
-- **New questions raised** -- use as thesis qualifications (conditions and limitations)
-
-Present to the user: "From your Devil's Advocate session, I'm bringing forward: [N] surviving assumptions as thesis pillars, [N] killed assumptions as risks to address, and [N] new questions as areas for qualification."
-
-## Stage Instructions
-
-Run `/mos:build-thesis` with the extracted surviving assumptions and risk areas.
-
-The thesis-building session should be shaped by the pipeline context:
-- Thesis pillars come directly from stress-tested surviving assumptions -- these carry weight because they were challenged
-- Risk section incorporates killed assumptions honestly -- investors respect candor about weaknesses
-- Qualifications section addresses the new questions raised during challenge
-- The thesis narrative should reference the interrogation: "We stress-tested N assumptions. M survived..."
-
-When the methodology produces its artifact, ensure pipeline provenance is added to frontmatter:
-
-```yaml
-pipeline: thesis
-pipeline_stage: 3
-pipeline_input: "Surviving Assumptions: '[extracted from stage 2]'"
-```
-
-## Output Contract
-
-Final stage -- no output_to. This completes the Thesis Pipeline.
-
-### What the Full Thesis Pipeline Produced
-
-Across all 3 stages, the Room now contains:
-
-| Room Section | Artifact | From Stage |
-|-------------|----------|------------|
-| problem-definition | Minto Pyramid -- structured argument with pillars and evidence | Stage 1 |
-| competitive-analysis | Devil's Advocate -- assumption survival map, killed claims, new questions | Stage 2 |
-| financial-model | Investment Thesis -- stress-tested thesis with pillars, risks, qualifications | Stage 3 |
-
-The provenance chain (`pipeline: thesis`, `pipeline_stage: 1/2/3`) connects all three artifacts, showing how a raw argument became a stress-tested investment thesis through structured interrogation.

package/pipelines/thesis/CHAIN.md

@@ -1,37 +0,0 @@
----
-name: thesis
-display_name: Thesis Pipeline
-description: From structured argument to stress-tested investment thesis
-stages: 3
-estimated_time: 60-120min
-venture_stages: [Design, Investment]
-problem_types: [well-defined-complex, well-defined-complicated, ill-defined-complex]
----
-
-# Thesis Pipeline
-
-## When to Use
-
-User has a venture thesis or argument that needs rigorous stress-testing before presenting to stakeholders or investors. Best for later-stage ventures where the idea is clear but the argument needs structural integrity and evidence.
-
-Typical starting points:
-- "I need to build my investment thesis"
-- "I have an argument but I'm not sure it holds up"
-- "I need to present my venture to investors and want it bulletproof"
-
-## Stage Sequence
-
-1. **structure-argument** -- Build the Minto Pyramid, top-down argument structure
-2. **challenge-assumptions** -- Devil's Advocate stress-tests every supporting claim
-3. **build-thesis** -- Synthesize surviving arguments into a complete investment thesis
-
-## What It Produces
-
-After all 3 stages, the Room will have:
-- **problem-definition:** Minto Pyramid artifact with structured argument hierarchy
-- **competitive-analysis:** Devil's Advocate artifact with assumption survival map
-- **financial-model:** Investment Thesis artifact with thesis pillars, risks, qualifications
-
-## Chain Provenance
-
-Each artifact includes `pipeline: thesis` and `pipeline_stage: N` in frontmatter, creating an inspectable provenance chain. This allows Larry to detect existing pipeline progress and offer resumption.

package/references/brain/causal-directives.md

@@ -1,91 +0,0 @@
----
-title: Brain Causal Reasoning Directives
-description: >
-  Tells Larry HOW to reason causally when analyzing room artifacts.
-  Brain DIRECTS causal reasoning. KuzuDB STORES causal claims.
-  Brain is READ-ONLY from the causal layer -- no user data written to Brain.
-tier: 0
-version: 1.7.0
-used_by:
-  - commands/causal.md
-  - skills/larry-personality/SKILL.md
-  - scripts/compute-causal.py
----
-
-# Causal Reasoning Directives
-
-Brain directs Larry's causal reasoning. These are the RULES for how Larry identifies, structures, and communicates causal claims. All causal data is stored in local KuzuDB -- never written to Brain.
-
-## The Three Gaps Larry Must Close
-
-From Duraisamy (2025) "Active Inference AI Systems for Scientific Discovery":
-
-### Gap 1: Abstraction Gap
-**Problem:** Larry sees text tokens. Users need mechanistic understanding.
-**Directive:** For every causal claim, Larry MUST identify the MECHANISM -- not just "A causes B" but HOW A produces B through a specific physical, economic, or strategic process.
-
-**Example:**
-- BAD: "Ceramic AM enables new markets"
-- GOOD: "Gradient architecture eliminates CTE mismatch at metal-ceramic interfaces (mechanism: graded transition absorbs differential thermal expansion), which prevents thermal shock fracture in etch chamber liners (failure mode), enabling higher plasma temperatures (performance)"
-
-### Gap 2: Reasoning Gap
-**Problem:** Pattern completion is not causal inference.
-**Directive:** Larry MUST distinguish correlation from causation. Use the dual-process approach:
-1. THINKING mode: Generate causal hypotheses (divergent)
-2. REASONING mode: Test each hypothesis for causal coherence (convergent)
-
-**Causal Coherence Tests:**
-- Does a physical/economic mechanism exist?
-- Does the direction make sense? (A causes B, not B causes A)
-- Are there confounders? (C causes both A and B, creating false A->B)
-- Is this correlation masquerading as causation?
-
-### Gap 3: Reality Gap
-**Problem:** Internal models diverge from external reality.
-**Directive:** Every causal claim MUST include a falsifiable prediction -- something testable that would DISPROVE the claim if the test fails.
-
-**Example:**
-- Claim: "Qualification timeline is the real moat, not material properties"
-- Prediction: "If true, we should see customers willing to pay 30%+ premium for pre-qualified suppliers, even with comparable material specs. Interview 5 procurement leads -- if <3 confirm, the claim is wrong."
-
-## Causal Claim Structure
-
-Every causal claim Larry generates or validates must have these 7 fields:
-
-| Field | Required | Description |
-|-------|----------|-------------|
-| cause | YES | What produces the effect |
-| effect | YES | What happens as a result |
-| mechanism | YES | HOW the cause produces the effect |
-| confidence | YES | 0-1 scale based on evidence strength |
-| evidence | YES | Which room artifacts support this claim |
-| falsifiable_prediction | YES | What would disprove this claim |
-| domain | YES | materials, business, competitive, financial, team, legal, general |
-
-**Confidence Calibration:**
-- 0.7+: observed (multiple artifacts + external validation + mechanism confirmed)
-- 0.5-0.69: asserted (clear mechanism + some artifact support, untested prediction)
-- 0.3-0.49: inferred (plausible mechanism, single artifact, no external validation)
-- 0.0-0.29: speculative (interesting hypothesis, no supporting evidence)
-
-## Causal Analysis by Problem Type
-
-### Un-Defined Problems
-**Directive:** Don't assert causation yet. Map POSSIBLE causal pathways. Use "might cause" language.
-
-### Ill-Defined Problems
-**Directive:** Identify competing causal explanations. Present contradictions explicitly. Use contradiction detection.
-
-### Well-Defined Problems
-**Directive:** Trace complete causal chains. Validate mechanisms. Generate falsifiable predictions.
-
-### Wicked Problems
-**Directive:** Map causal loops (feedback). Surface where intervention has leverage. Accept that causation is circular.
-
-## Integration with Pipeline
-
-Larry should reference these directives when:
-1. Running /mos:causal extract -- enforce Three Gaps on every claim
-2. Running /mos:causal trace -- narrate chains with mechanisms
-3. Running /mos:causal predict -- generate predictions grounded in Gap 3
-4. During regular conversation -- when assumptions stack up, suggest causal analysis

package/references/brain/causal-enrichment.cypher

@@ -1,165 +0,0 @@
-// Brain Causal Framework Enrichment
-// Phase 52: BRAIN-01 through BRAIN-06
-// Execute via mcp__neo4j-brain__write_neo4j_cypher
-//
-// IMPORTANT: Before running any write statements, run the discovery queries
-// in the "Discovery" section to verify exact node names. Replace placeholder
-// names below with exact names from discovery results.
-//
-// Generated: 2026-04-05
-// Requirements: BRAIN-01, BRAIN-02, BRAIN-03, BRAIN-04, BRAIN-05, BRAIN-06
-
-// ============================================================================
-// SECTION 0: DISCOVERY (run FIRST via mcp__neo4j-brain__read_neo4j_cypher)
-// ============================================================================
-
-// Query A: Get all Framework node names (verify exact spelling)
-// MATCH (f:Framework) RETURN f.name AS name LIMIT 50
-
-// Query B: Get all Concept node names
-// MATCH (c:Concept) RETURN c.name AS name LIMIT 50
-
-// Query C: Check VentureStage nodes
-// MATCH (v:VentureStage) RETURN v.name AS name LIMIT 20
-
-// Query D: Check existing edge types on Framework nodes
-// MATCH (f:Framework)-[r]->() RETURN DISTINCT type(r) AS rel_type LIMIT 30
-
-// Query E: Check if Falsifiability or Hypothesis Tree exist
-// MATCH (f:Framework) WHERE f.name CONTAINS 'Falsif' OR f.name CONTAINS 'Hypothesis' RETURN f.name LIMIT 10
-
-// ============================================================================
-// SECTION 1: BRAIN-03 -- Create Theory of Change Framework node
-// ============================================================================
-
-MERGE (f:Framework {name: 'Theory of Change'})
-ON CREATE SET f.description = 'Forward causal reasoning: articulate the causal pathway from activities to outcomes. Maps assumptions about how change happens.',
-              f.category = 'causal',
-              f.created = datetime()
-
-// ============================================================================
-// SECTION 2: BRAIN-04 -- Create Causal Reasoning parent Concept node
-// ============================================================================
-
-MERGE (c:Concept {name: 'Causal Reasoning'})
-ON CREATE SET c.description = 'Parent concept connecting causal analysis frameworks: root cause analysis, systems thinking, causal loop diagrams, scenario analysis, and theory of change.',
-              c.created = datetime()
-
-// Link each causal framework to the Causal Reasoning concept
-// NOTE: Use exact names from Query A. Names below are best-guess from Brain schema.
-
-MATCH (f:Framework {name: 'Root Cause Analysis'}), (c:Concept {name: 'Causal Reasoning'})
-MERGE (f)-[:RELATED_TO]->(c)
-
-MATCH (f:Framework {name: 'Systems Thinking'}), (c:Concept {name: 'Causal Reasoning'})
-MERGE (f)-[:RELATED_TO]->(c)
-
-MATCH (f:Framework {name: 'Causal Loop Diagrams'}), (c:Concept {name: 'Causal Reasoning'})
-MERGE (f)-[:RELATED_TO]->(c)
-
-MATCH (f:Framework {name: 'Scenario Analysis Framework'}), (c:Concept {name: 'Causal Reasoning'})
-MERGE (f)-[:RELATED_TO]->(c)
-
-MATCH (f:Framework {name: 'Theory of Change'}), (c:Concept {name: 'Causal Reasoning'})
-MERGE (f)-[:RELATED_TO]->(c)
-
-// ============================================================================
-// SECTION 3: BRAIN-01 -- Wire FEEDS_INTO chains
-// ============================================================================
-
-// Chain: Root Cause Analysis -> Systems Thinking -> Causal Loop Diagrams -> Scenario Analysis
-MATCH (a:Framework {name: 'Root Cause Analysis'}), (b:Framework {name: 'Systems Thinking'})
-MERGE (a)-[:FEEDS_INTO]->(b)
-
-MATCH (a:Framework {name: 'Systems Thinking'}), (b:Framework {name: 'Causal Loop Diagrams'})
-MERGE (a)-[:FEEDS_INTO]->(b)
-
-MATCH (a:Framework {name: 'Causal Loop Diagrams'}), (b:Framework {name: 'Scenario Analysis Framework'})
-MERGE (a)-[:FEEDS_INTO]->(b)
-
-// Branch: Systems Thinking -> Reverse Salient Analysis
-MATCH (a:Framework {name: 'Systems Thinking'}), (b:Framework {name: 'Reverse Salient Analysis'})
-MERGE (a)-[:FEEDS_INTO]->(b)
-
-// ============================================================================
-// SECTION 4: BRAIN-02 -- CO_OCCURS edges (bidirectional)
-// ============================================================================
-
-// Root Cause Analysis <-> Six Thinking Hats
-MATCH (a:Framework {name: 'Root Cause Analysis'}), (b:Framework {name: 'Six Thinking Hats'})
-MERGE (a)-[:CO_OCCURS]->(b)
-MERGE (b)-[:CO_OCCURS]->(a)
-
-// Systems Thinking <-> Reverse Salient Analysis
-MATCH (a:Framework {name: 'Systems Thinking'}), (b:Framework {name: 'Reverse Salient Analysis'})
-MERGE (a)-[:CO_OCCURS]->(b)
-MERGE (b)-[:CO_OCCURS]->(a)
-
-// Cynefin <-> Root Cause Analysis
-MATCH (a:Framework {name: 'Cynefin Framework'}), (b:Framework {name: 'Root Cause Analysis'})
-MERGE (a)-[:CO_OCCURS]->(b)
-MERGE (b)-[:CO_OCCURS]->(a)
-
-// ============================================================================
-// SECTION 5: BRAIN-05 -- TYPICAL_AT venture stage mappings
-// ============================================================================
-
-// Create VentureStage nodes if they do not exist (verify with Query C first)
-MERGE (s:VentureStage {name: 'Pre-Opportunity'})
-MERGE (s2:VentureStage {name: 'Opportunity Identified'})
-MERGE (s3:VentureStage {name: 'Problem Validation'})
-
-// Map causal frameworks to venture stages
-MATCH (f:Framework {name: 'Root Cause Analysis'}), (s:VentureStage {name: 'Opportunity Identified'})
-MERGE (f)-[:TYPICAL_AT]->(s)
-
-MATCH (f:Framework {name: 'Systems Thinking'}), (s:VentureStage {name: 'Pre-Opportunity'})
-MERGE (f)-[:TYPICAL_AT]->(s)
-
-MATCH (f:Framework {name: 'Reverse Salient Analysis'}), (s:VentureStage {name: 'Pre-Opportunity'})
-MERGE (f)-[:TYPICAL_AT]->(s)
-
-MATCH (f:Framework {name: 'Theory of Change'}), (s:VentureStage {name: 'Problem Validation'})
-MERGE (f)-[:TYPICAL_AT]->(s)
-
-// ============================================================================
-// SECTION 6: BRAIN-06 -- Link Falsifiability and Hypothesis Tree
-// ============================================================================
-
-// NOTE: Use exact names from Query E. Names below are best-guess.
-
-// Link to Causal Reasoning concept
-// NOTE: Falsifiability is a Concept, Logic Trees is a Concept (not Framework labels)
-MATCH (f:Concept {name: 'Falsifiability'}), (c:Concept {name: 'Causal Reasoning'})
-MERGE (f)-[:RELATED_TO]->(c)
-
-MATCH (f:Concept {name: 'Logic Trees (Issue, Hypothesis, Decision)'}), (c:Concept {name: 'Causal Reasoning'})
-MERGE (f)-[:RELATED_TO]->(c)
-
-// FEEDS_INTO from Theory of Change to Logic Trees
-MATCH (a:Framework {name: 'Theory of Change'}), (b:Concept {name: 'Logic Trees (Issue, Hypothesis, Decision)'})
-MERGE (a)-[:FEEDS_INTO]->(b)
-
-// FEEDS_INTO from Logic Trees to Falsifiability
-MATCH (a:Concept {name: 'Logic Trees (Issue, Hypothesis, Decision)'}), (b:Concept {name: 'Falsifiability'})
-MERGE (a)-[:FEEDS_INTO]->(b)
-
-// ============================================================================
-// VERIFICATION QUERIES (run via mcp__neo4j-brain__read_neo4j_cypher)
-// ============================================================================
-
-// Verify BRAIN-01: FEEDS_INTO chain
-// MATCH (a:Framework)-[:FEEDS_INTO]->(b:Framework)
-// WHERE a.name CONTAINS 'Root Cause' OR a.name CONTAINS 'Systems' OR a.name CONTAINS 'Causal Loop'
-// RETURN a.name AS from_fw, b.name AS to_fw
-// LIMIT 10
-
-// Verify BRAIN-04: Causal Reasoning concept connections
-// MATCH (f:Framework)-[:RELATED_TO]->(c:Concept {name: 'Causal Reasoning'})
-// RETURN f.name AS framework
-// LIMIT 10
-
-// Verify BRAIN-05: TYPICAL_AT edges
-// MATCH (f:Framework)-[:TYPICAL_AT]->(s:VentureStage)
-// RETURN f.name AS framework, s.name AS stage
-// LIMIT 10