Sfumato Decision Making

---
name: sfumato-decision-making
description: 'Make progress on decisions when information is incomplete or ambiguous. Apply Leonardo da Vinci''s sfumato principle: "a willingness to embrace ambiguity, paradox, and uncertainty" rather than forci...'
license: MIT
metadata:
  version: 1.0.4955
  author: sethmblack
repository: https://github.com/sethmblack/paks-skills
keywords:
- sfumato-decision-making
- writing
---

# Sfumato Decision-Making

Make progress on decisions when information is incomplete or ambiguous. Apply Leonardo da Vinci's sfumato principle: "a willingness to embrace ambiguity, paradox, and uncertainty" rather than forcing false certainty.

---

## When to Use

- Decision is needed but information is incomplete
- User says "I need to decide but don't have enough information"
- Premature certainty is blocking productive discussion
- Stakeholders are forcing binary choices on gradient problems
- Request for help with "unclear situations" or "ambiguous decisions"
- Analysis paralysis due to uncertainty

---

## Inputs

| Input | Required | Description |
|-------|----------|-------------|
| decision | Yes | The decision to be made |
| available_info | Yes | What is currently known |
| unknowns | No | Explicit uncertainties (will be identified if not provided) |
| timeline | No | When the decision must be made |
| reversibility | No | Whether/how the decision can be undone |

---

## The Four-Step Framework

### Step 1: Map the Uncertainty Landscape

Like Leonardo's sfumato technique that acknowledged edges are gradients not lines, map where certainty fades into uncertainty:

**Certainty Categories:**
| Category | Definition | Example |
|----------|------------|---------|
| **Known** | Verified through direct observation or reliable data | "Database handles 10K queries/sec" |
| **Believed** | Assumed but not verified; could be wrong | "Users prefer feature X" |
| **Unknown-Known** | Recognized gaps that could be filled | "We don't know competitor pricing" |
| **Unknown-Unknown** | Gaps we haven't recognized | (By definition, can't list; acknowledge they exist) |

**For each key factor in the decision:**
- What category does it fall into?
- How confident are you in the categorization itself?
- What would change the categorization?

**Leonardo's insight:** "That painter who has no doubts will achieve little." Productive doubt is a feature, not a bug.

### Step 2: Identify Reversible vs. Irreversible Elements

Not all aspects of a decision have equal stakes:

| Element Type | Characteristics | Approach |
|--------------|-----------------|----------|
| **Reversible** | Can be undone, low cost to change, experiments possible | Decide faster, learn from action |
| **Partially Reversible** | Can be undone with effort/cost | Decide with caution, plan reversal path |
| **Irreversible** | Cannot be undone, or cost is prohibitive | Require higher confidence before deciding |

**Map each component of the decision:**
```
Decision component: [What]
Reversibility: [Reversible / Partially / Irreversible]
Reversal cost: [Time/money/reputation if reversed]
Confidence required: [Low / Medium / High]
Current confidence: [Low / Medium / High]
```

### Step 3: Design a Staged Decision Approach

Rather than one binary decision, construct a staged approach:

**Stage 1: Reversible Actions**
- What can you do now that commits you to nothing permanent?
- What experiments can you run to reduce uncertainty?
- What information can you gather while appearing to progress?

**Stage 2: Partial Commitment**
- What partially reversible decisions would unlock information?
- What is the minimum commitment that creates optionality?
- What gates or checkpoints would trigger reassessment?

**Stage 3: Full Commitment (if reached)**
- Under what conditions would you commit irreversibly?
- What would need to be true?
- What alternative paths remain even after commitment?

**Leonardo's insight:** Leonardo spent decades iterating on flying machine designs. Each iteration was a partial commitment that taught something, not a binary success/failure.

### Step 4: Set Monitoring Triggers

Establish explicit triggers for revisiting the decision:

| Trigger Type | Description | Example |
|--------------|-------------|---------|
| **Time-based** | Revisit after elapsed time | "Re-evaluate in 2 weeks" |
| **Information-based** | Revisit when new data arrives | "If user research completes, reconsider" |
| **Threshold-based** | Revisit if metrics cross boundaries | "If adoption <10%, pivot" |
| **Event-based** | Revisit if circumstances change | "If competitor launches, reassess" |

**For each trigger:**
- What would we observe?
- What would it mean for the decision?
- Who is responsible for monitoring?
- What is the response protocol?

---

## Workflow

### Step 1: Gather and Review Inputs

Collect all relevant information:
- Review the provided data and context
- Identify key parameters and constraints
- Clarify any ambiguities or missing information
- Establish success criteria

### Step 2: Analyze the Situation

Perform systematic analysis:
- Identify patterns and relationships
- Evaluate against established frameworks
- Consider multiple perspectives
- Document key findings

### Step 3: Generate Recommendations

Create actionable outputs:
- Synthesize insights from analysis
- Prioritize recommendations by impact
- Ensure recommendations are specific and measurable
- Consider implementation feasibility

## Output Format

```markdown
## Sfumato Decision Analysis

### Decision Under Consideration
[Clear statement of what must be decided]

### Uncertainty Map
| Factor | Category | Confidence | Would Change If |
|--------|----------|------------|-----------------|
| [Factor] | Known/Believed/Unknown | High/Med/Low | [Condition] |

### Key Unknowns
1. [Unknown]: [Why it matters] - [How to resolve]

### Reversibility Assessment
| Decision Element | Reversibility | Reversal Cost | Required Confidence |
|------------------|---------------|---------------|---------------------|
| [Element] | Reversible/Partial/Irreversible | [Cost] | Low/Med/High |

### Staged Decision Approach

**Stage 1: Low-Commitment Actions (Do Now)**
- [ ] [Action that gathers information without commitment]
- [ ] [Experiment that reduces uncertainty]

**Stage 2: Partial Commitment (Conditions: [when])**
- [ ] [Decision that creates optionality]
- [ ] [Minimum viable commitment]

**Stage 3: Full Commitment (Conditions: [when])**
- [ ] [Final commitment] - requires: [conditions]

### Monitoring Triggers
| Trigger | Threshold | Response |
|---------|-----------|----------|
| [Type] | [Condition] | [Action] |

### Current Recommendation
[What to do right now given current information]

### What Would Change This
[Conditions that would alter the recommendation]
```

---

## Constraints

- Do not force false certainty where genuine ambiguity exists
- Do not use ambiguity as an excuse for inaction when action is possible
- Do not treat all uncertainty as equal; some matters more than others
- Acknowledge when the timeline prevents proper staged decision-making
- Be explicit about the costs of both action and inaction

---

## Outputs

**Primary Output:** A structured analysis document that identifies and articulates patterns, insights, and actionable recommendations based on the input data.

**Format:**
```markdown
## Analysis: [Topic]

### Key Findings
- [Finding 1]
- [Finding 2]
- [Finding 3]

### Recommendations
1. [Action 1]
2. [Action 2]
3. [Action 3]
```

**Example output:** See the Example section below for a complete demonstration.

## Example

**Input:**
```
decision: Should we migrate from PostgreSQL to a distributed database?
available_info: Current DB handles load but we're at 70% capacity; projected growth unclear
unknowns: Future traffic patterns, actual migration complexity, team learning curve
timeline: No hard deadline, but CTO wants a direction in 4 weeks
```

**Output:**

## Sfumato Decision Analysis

### Decision Under Consideration
Whether to migrate the primary data store from PostgreSQL to a distributed database (e.g., CockroachDB, YugabyteDB, or similar).

### Uncertainty Map
| Factor | Category | Confidence | Would Change If |
|--------|----------|------------|-----------------|
| Current capacity (70%) | Known | High | We instrumented wrong |
| Growth projections | Believed | Low | Actual growth data for 6 months |
| PostgreSQL scaling limits | Believed | Medium | Load testing to failure |
| Migration complexity | Unknown-Known | Low | Proof-of-concept migration |
| Team distributed DB skill | Known | High | Direct assessment |
| Production incident risk | Unknown-Known | Low | Similar company case studies |

### Key Unknowns
1. **Growth trajectory**: Matters because determines when we hit limits - Resolve via: better forecasting model, traffic modeling
2. **Migration complexity**: Matters because determines true cost - Resolve via: prototype migration of one service
3. **Failure modes under load**: Matters because determines risk - Resolve via: load testing PostgreSQL to find real limits

### Reversibility Assessment
| Decision Element | Reversibility | Reversal Cost | Required Confidence |
|------------------|---------------|---------------|---------------------|
| Research distributed DBs | Reversible | ~0 | Low |
| Prototype migration | Reversible | ~2 engineer-weeks | Low |
| Migrate one non-critical service | Partially Reversible | ~1 month, complexity | Medium |
| Migrate primary data store | Irreversible (practically) | 6+ months, high risk | High |

### Staged Decision Approach

**Stage 1: Low-Commitment Actions (Do Now)**
- [ ] Load test PostgreSQL to actual breaking point (not projections)
- [ ] Build traffic forecasting model with confidence intervals
- [ ] Evaluate 2-3 distributed DB options on paper (features, cost, team fit)
- [ ] Interview 2 companies who completed similar migrations

**Stage 2: Partial Commitment (Conditions: PostgreSQL limits confirmed within 12 months)**
- [ ] Prototype migration of analytics service (low-risk, representative)
- [ ] Measure actual performance, complexity, team learning curve
- [ ] Calculate true cost based on prototype, not estimates

**Stage 3: Full Commitment (Conditions: Prototype successful AND growth confirmed AND team confident)**
- [ ] Full migration plan with rollback strategy
- [ ] Requires: Successful prototype + 90% confidence in growth projections + executive buy-in on timeline

### Monitoring Triggers
| Trigger | Threshold | Response |
|---------|-----------|----------|
| Capacity | >85% sustained | Accelerate Stage 2 |
| Growth data | 3 months actual | Update projections, reassess |
| Prototype complete | Any outcome | Decision point for Stage 3 |
| PostgreSQL major release | New scaling features | Reassess entire premise |

### Current Recommendation
Do not decide the full migration question now. Instead, enter Stage 1 immediately: load test PostgreSQL to find real limits, build better growth models, and gather external case studies. Report findings in 3 weeks. The decision will be clearer with this information, and the cost of these actions is low.

### What Would Change This
- If capacity hits 85%+ before Stage 1 completes: Accelerate to parallel prototype
- If PostgreSQL 17 offers significant horizontal scaling: Reassess entire migration thesis
- If team expresses strong preference for or against: Factor into complexity assessment

---

## Integration

This skill is part of the **Leonardo da Vinci** expert persona. Use it when decisions must be made under uncertainty without forcing premature closure.

Leonardo's sfumato painting technique acknowledged that edges in reality are gradients, not hard lines. His notebooks show decades of iteration on problems (flying machines, anatomy, optics) where definitive answers emerged slowly through patient investigation. This skill applies that same comfort with productive ambiguity to decision-making.