Dialectical Reasoning

Synthesize opposing views into higher-order resolution. The logic of productive disagreement.

Type Signature

Dialectical : Thesis → Antithesis → Synthesis

Where:
  Thesis     : Position × Evidence × Stakeholder → ArgumentA
  Antithesis : ArgumentA → CounterPosition × Evidence × Stakeholder → ArgumentB
  Synthesis  : (ArgumentA, ArgumentB) → IntegratedPosition × Tradeoffs

When to Use

Use dialectical when:

• Stakeholders hold opposing valid positions
• Trade-offs need explicit analysis
• Strategic tension requires resolution
• Multiple perspectives each have merit
• "On one hand... on the other" situations

Don't use when:

• Cause-effect chain needed → Use Causal
• Explaining observation → Use Abductive
• Evaluating past decisions → Use Counterfactual

Core Principles

Charitable Interpretation

Each position must be represented at its strongest:

• Steel-man, don't straw-man
• Assume good faith and valid reasoning
• Identify the kernel of truth in each view

Genuine Synthesis

Synthesis is NOT:

• Compromise (splitting the difference)
• Victory (one side wins)
• Avoidance (postpone decision)

Synthesis IS:

• Integration at higher level of abstraction
• Resolution that addresses underlying concerns
• New position that transcends original framing

Three-Stage Process

Stage 1: Thesis

Purpose: Articulate first position at maximum strength.

Components:

yaml
thesis:
  position: 
    statement: "Core claim being made"
    underlying_concern: "What this position is really about"
    
  stakeholder:
    who: "Person/team holding this view"
    role: "Their organizational function"
    incentives: "What they optimize for"
    
  evidence:
    supporting:
      - claim: "Evidence point"
        source: "Where this comes from"
        strength: 0.0-1.0
    empirical: [DataPoint]
    logical: [Argument]
    
  implications:
    if_adopted: "What happens if we go this way"
    risks: [Risk]
    benefits: [Benefit]

Example:

yaml
thesis:
  position:
    statement: "We should prioritize enterprise features over SMB growth"
    underlying_concern: "Revenue concentration and deal size efficiency"
    
  stakeholder:
    who: "Sales leadership"
    role: "Revenue generation"
    incentives: "ARR, deal size, quota attainment"
    
  evidence:
    supporting:
      - claim: "Enterprise deals average $400K vs SMB $5K"
        source: "Q3 sales data"
        strength: 0.95
      - claim: "Sales cost per $ revenue 5x lower for enterprise"
        source: "CAC analysis"
        strength: 0.85
    empirical:
      - "3 enterprise deals = entire SMB revenue"
      - "Enterprise churn 3% vs SMB 8%"
      
  implications:
    if_adopted: "Focus engineering on enterprise features, reduce SMB investment"
    risks: 
      - "Lose SMB market to competitors"
      - "Revenue concentration risk"
    benefits:
      - "Higher margins"
      - "Larger average deal"

Stage 2: Antithesis

Purpose: Articulate counter-position at maximum strength.

Process:

1. Identify what thesis misses or undervalues
2. Find stakeholder with opposing view
3. Build strongest case for alternative
4. Identify where thesis assumptions break

Components:

yaml
antithesis:
  position:
    statement: "Counter claim"
    underlying_concern: "What this position is really about"
    
  stakeholder:
    who: "Person/team holding this view"
    role: "Their organizational function"
    incentives: "What they optimize for"
    
  critique_of_thesis:
    - assumption_challenged: "Thesis assumes X"
      counter_evidence: "But actually Y"
    - risk_identified: "Thesis ignores Z"
      
  evidence:
    supporting: [EvidencePoint]
    empirical: [DataPoint]
    logical: [Argument]
    
  implications:
    if_adopted: "What happens if we go this way"
    risks: [Risk]
    benefits: [Benefit]

Example:

yaml
antithesis:
  position:
    statement: "SMB volume creates the foundation for sustainable growth"
    underlying_concern: "Market presence, product iteration, and risk distribution"
    
  stakeholder:
    who: "Product leadership"
    role: "Product-market fit and growth"
    incentives: "Usage, retention, feature validation"
    
  critique_of_thesis:
    - assumption_challenged: "Enterprise features drive growth"
      counter_evidence: "SMB usage generates product insights 10x faster"
    - assumption_challenged: "Revenue concentration is acceptable"
      counter_evidence: "Losing 1 enterprise deal = losing 80 SMB accounts"
    - risk_identified: "Enterprise sales cycle is 9 months"
      
  evidence:
    supporting:
      - claim: "SMB accounts generate 80% of feature requests"
        source: "Product feedback analysis"
        strength: 0.90
      - claim: "SMB provides faster iteration cycles"
        source: "Release metrics"
        strength: 0.85
    empirical:
      - "SMB churn prediction accuracy 95% vs enterprise 60%"
      - "Product improvements from SMB feedback shipped in 2 weeks"
      
  implications:
    if_adopted: "Maintain SMB investment, use as product lab"
    risks:
      - "Slower revenue growth short-term"
      - "Lower margin overall"
    benefits:
      - "Diversified revenue base"
      - "Faster product iteration"
      - "Lower concentration risk"

Stage 3: Synthesis

Purpose: Integrate positions at higher level, resolving underlying tensions.

Synthesis Approaches:

| Approach | When to Use | Example | |----------|-------------|---------| | Integration | Both positions address valid concerns | "Enterprise revenue + SMB as product lab" | | Sequencing | Temporal resolution possible | "SMB first for PMF, then enterprise scale" | | Segmentation | Different contexts warrant different approaches | "SMB for product X, Enterprise for product Y" | | Reframing | Original dichotomy was false | "The real question isn't SMB vs Enterprise, it's time-to-value" | | Transcendence | Higher goal subsumes both | "Optimize for sustainable unit economics regardless of segment" |

Synthesis Components:

yaml
synthesis:
  integrated_position:
    statement: "What we will actually do"
    framing: "How this resolves the tension"
    
  how_thesis_is_addressed:
    concern_validated: "What's true about thesis"
    how_incorporated: "How we address that concern"
    
  how_antithesis_is_addressed:
    concern_validated: "What's true about antithesis"
    how_incorporated: "How we address that concern"
    
  trade_offs_acknowledged:
    - trade_off: "What we're giving up"
      mitigation: "How we reduce impact"
      accepted_by: "Stakeholder who accepts this"
      
  resolution_type: integration | sequencing | segmentation | reframing | transcendence
  
  implementation:
    actions: [Action]
    metrics: [Metric]  # How we know it's working
    review_date: date  # When we reassess

Example:

yaml
synthesis:
  integrated_position:
    statement: "SMB as rapid learning engine, enterprise as revenue engine, 
                with explicit feature graduation path"
    framing: "Not SMB vs Enterprise, but learning velocity vs revenue efficiency 
              with a bridge between them"
              
  how_thesis_is_addressed:
    concern_validated: "Enterprise deals are more efficient per dollar"
    how_incorporated: "Maintain enterprise sales motion, prioritize enterprise 
                       features that have been validated through SMB"
                       
  how_antithesis_is_addressed:
    concern_validated: "SMB generates faster product learning"
    how_incorporated: "Protect SMB investment as product lab, use SMB metrics 
                       to prioritize enterprise features"
                       
  trade_offs_acknowledged:
    - trade_off: "Some enterprise-only features will ship slower"
      mitigation: "Identify 'must have' enterprise features, fast-track those"
      accepted_by: "Sales leadership (with fast-track list)"
      
    - trade_off: "Some SMB features won't graduate to enterprise"
      mitigation: "Clear graduation criteria defined upfront"
      accepted_by: "Product leadership (with criteria agreement)"
      
  resolution_type: integration
  
  implementation:
    actions:
      - "Define feature graduation criteria (Product + Sales)"
      - "Create SMB → Enterprise feature pipeline"
      - "Allocate 60% engineering to graduated features, 40% to SMB lab"
    metrics:
      - "SMB feature graduation rate (target: 3/month)"
      - "Enterprise close rate on graduated features (target: +20%)"
      - "Combined revenue growth (target: 30% QoQ)"
    review_date: "End of Q2"

Quality Gates

| Gate | Requirement | Failure Action | |------|-------------|----------------| | Thesis strength | Steel-manned, evidence-backed | Strengthen before proceeding | | Antithesis genuine | Not straw-man, different stakeholder | Find genuine opposition | | Synthesis integrative | Not compromise or victory | Reframe until true synthesis | | Trade-offs explicit | All parties acknowledge costs | Surface hidden disagreements | | Actionable | Concrete next steps | Add implementation detail |

Stakeholder Agreement Protocol

Synthesis isn't complete until affected stakeholders acknowledge:

1. Their concern was understood (thesis/antithesis accurately represented)
2. The synthesis addresses their core interest (not just their stated position)
3. They accept the trade-offs (explicitly, not assumed)

yaml
stakeholder_acknowledgment:
  thesis_stakeholder:
    name: "Sales leadership"
    concern_understood: true
    synthesis_addresses_concern: true
    accepts_trade_offs: true
    conditions: "Fast-track list for critical enterprise features"
    
  antithesis_stakeholder:
    name: "Product leadership"
    concern_understood: true
    synthesis_addresses_concern: true
    accepts_trade_offs: true
    conditions: "Clear graduation criteria before implementation"

Common Failure Modes

| Failure | Symptom | Fix | |---------|---------|-----| | False dichotomy | Positions aren't truly opposed | Reframe the actual tension | | Straw-man | Weak representation of one side | Involve actual stakeholder | | Mushy middle | Synthesis is just "do both" | Force resource allocation | | Unacknowledged loss | Trade-offs hidden | Surface what's being given up | | No implementation | Synthesis is abstract | Add concrete actions |

Output Contract

yaml
dialectical_output:
  thesis:
    position: string
    stakeholder: string
    evidence: [EvidencePoint]
    strength: float  # 0.0-1.0
    
  antithesis:
    position: string
    stakeholder: string
    evidence: [EvidencePoint]
    strength: float
    
  synthesis:
    position: string
    resolution_type: string
    confidence: float
    
  integration:
    thesis_addressed: string
    antithesis_addressed: string
    
  trade_offs:
    - trade_off: string
      mitigation: string
      accepted_by: string
      
  stakeholder_agreement:
    - stakeholder: string
      agrees: bool
      conditions: optional<string>
      
  implementation:
    actions: [string]
    metrics: [string]
    review_date: date
    
  next:
    suggested_mode: ReasoningMode  # Usually causal
    canvas_updates: [string]
    
  trace:
    duration_ms: int
    rounds_of_refinement: int

Example Execution

Context: "Engineering wants to rebuild core platform (6 months). Sales wants new features for Q2 deals."

Stage 1 - Thesis (Engineering):

Position: "Technical debt is blocking velocity. Rebuild now or pay 10x later."
Evidence: 
  - Deploy time increased 300% YoY
  - 40% of sprint spent on workarounds
  - 3 critical bugs from architecture issues
Underlying concern: Sustainable development velocity

Stage 2 - Antithesis (Sales):

Position: "We have $2M in pipeline dependent on Q2 features. Delay = lose deals."
Evidence:
  - 5 enterprise deals waiting on specific features
  - Competitor launching similar features in March
  - Q2 quota at risk without new capabilities
Underlying concern: Revenue target attainment

Stage 3 - Synthesis:

Integrated position: "Strangler fig pattern - rebuild incrementally while 
                      delivering high-priority features"

How thesis addressed: Platform rebuild happens, but in modules alongside features
How antithesis addressed: Q2 features delivered, no delay

Trade-offs:
  - Rebuild takes 9 months instead of 6 (Engineering accepts)
  - Only top 3 features in Q2, not all 5 (Sales accepts with prioritization input)
  
Resolution type: Integration via sequencing

Implementation:
  - Week 1: Joint prioritization session (top 3 features + first rebuild module)
  - Q2: Deliver features on new modules where possible
  - Q3-Q4: Complete rebuild with feature delivery continuing