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:

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:

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:

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:

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:

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:

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)

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

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