thinking-thought-experiment

What this skill does

# Thought Experiments

## Overview

Thought experiments use imagination to test ideas when direct experimentation is impractical, impossible, or premature. Einstein's elevator, Schrödinger's cat, and the trolley problem have advanced physics and philosophy. In engineering, thought experiments help evaluate designs, explore edge cases, and stress-test decisions before implementation.

**Core Principle:** Structured imagination is a tool. When you can't test in reality, test in your mind with discipline.

## The Core Reframe

When you can't run the real experiment — the failure is too rare, the scale too large, the decision too one-way — you can still run it in your head with discipline: fix the conditions, then trace the consequence chain one step at a time until something breaks. The value is in the *step-by-step trace*, not in the verdict you jumped to.

## When to Use

- Tracing a failure mode you can't easily trigger (primary DB down at peak, region outage)
- Reasoning about behavior at a scale you can't currently reach (10x/100x traffic)
- Evaluating a one-way architectural decision before committing
- Exploring edge cases that are expensive or impossible to reproduce

Decision flow:

```
Need to understand how something behaves?
  → Can you cheaply test or measure it? → yes → DO THAT (stop here)
  → Is the real test too rare/large/irreversible? → yes → THOUGHT EXPERIMENT
```

## When NOT to Use

- **If you can cheaply test or measure it, test it.** A thought experiment is a substitute for empiricism, not a replacement — a load test, a feature flag, a query against real data, or a quick spike beats imagined consequences every time. Reach for this skill only when the real experiment is genuinely out of reach.
- **For adversarial "how would an attacker break this" analysis, use thinking-red-team** — it has the structured attack-surface and findings format. Don't reinvent it here.

## Trigger Card

When you need to trace how a system would behave at a scale you can't cheaply test:

1. **Define the scenario precisely** — what changed? What's different from normal operation? Set initial conditions.
2. **Walk the consequence chain step by step** — given these conditions, what does the system do next? Then what? Then what? Be mechanistic, not hand-wavy.
3. **Derive what you'd need to check** — what observation would confirm or refute this chain? If you can test one link cheaply, test it.

If you can cheaply test or measure the real thing (load test, feature flag, query against real data), do that instead — a thought experiment is a substitute for empiricism, not a replacement. For adversarial "how would an attacker break this" analysis, use `thinking-red-team`.

## Types of Thought Experiments

### 1. The Hypothetical Scenario

Imagine a specific situation and trace consequences:

```
"What if we had 100x current traffic tomorrow?"
"What if our primary database failed right now?"
"What if a competitor copied our core feature?"
```

### 2. The Extreme Case

Push a parameter to its limit:

```
"What happens with 0 users? 1 billion users?"
"What if latency was 0? What if it was 10 seconds?"
"What if this team was 1 person? 100 people?"
```

### 3. The Counterfactual

Imagine the opposite of reality:

```
"What if we hadn't chosen microservices?"
"What if we didn't have this dependency?"
"What if our main customer segment didn't exist?"
```

### 4. The Role Reversal

Think from a different perspective:

```
"What would a malicious actor do with this system?"
"How would a new hire experience this codebase?"
"What would a competitor do with our technology?"
```

### 5. The Time Shift

Move forward or backward in time:

```
"How will this look in 5 years?"
"If we had known this a year ago, what would we have done?"
"What will we wish we had built today?"
```

## The Thought Experiment Process

### Step 1: Define the Experiment

State clearly what you're testing:

```markdown
## Thought Experiment: Database Failure Resilience

Question: How would our system behave if the primary database
         became unavailable for 30 minutes during peak traffic?

Variables:
- Database state: Unavailable
- Duration: 30 minutes
- Traffic: Peak (3x normal)
- Preparation time: None (unexpected)
```

### Step 2: Set the Initial Conditions

Describe the starting state precisely:

```markdown
## Initial Conditions

System state:
- 10,000 active users
- 500 RPS to database
- No circuit breaker currently
- 10-second connection timeout
- No read replica failover configured

User behavior:
- Users will retry failed requests
- ~50% will leave after 2 failures
```

### Step 3: Trace the Consequences

Walk through what happens step by step:

```markdown
## Consequence Chain

T+0s: Database becomes unavailable
T+0-10s: Requests queue waiting for connection
T+10s: Connection timeouts start
T+10-30s: App servers accumulate waiting requests
T+30s: Thread pools exhausted
T+30s-2m: Cascading timeouts to upstream services
T+2m: Load balancer health checks fail
T+2m: Alerts fire (too late - damage done)
T+2-30m: Service completely unavailable
T+30m: Database returns, but app servers need restart
T+35m: Service gradually recovers
T+1h: Backlog of failed requests processed
```

### Step 4: Identify Insights

What did you learn?

```markdown
## Insights

1. Circuit breaker would limit cascade (need to implement)
2. Thread pool exhaustion is the failure mode (need limits)
3. Alerts fire too late (need proactive monitoring)
4. Recovery is slow (need automated recovery)
5. User experience is terrible (need graceful degradation)
```

### Step 5: Derive Actions

What should you do based on this experiment?

```markdown
## Actions

| Insight | Action | Priority |
|---------|--------|----------|
| No circuit breaker | Implement circuit breaker | High |
| Thread pool exhaustion | Add connection limits | High |
| Late alerts | Add DB latency monitoring | Medium |
| Slow recovery | Automate failover | Medium |
| Poor UX | Implement degraded mode | Medium |
```

## Thought Experiment Patterns

### The Failure Mode Analysis

```markdown
## Thought Experiment: What if [component] fails?

For each critical component:
- API Gateway fails: [Trace consequences]
- Auth service fails: [Trace consequences]
- Cache layer fails: [Trace consequences]
- Message queue fails: [Trace consequences]

Template for each:
1. What fails immediately?
2. What fails within 1 minute?
3. What's the blast radius?
4. How would we know?
5. How would we recover?
```

### The Adversarial Analysis

> For real security work, prefer **thinking-red-team** (structured attack surface + reproducible-attack-path findings). Use the sketch below only as a quick lens, not a substitute.

```markdown
## Thought Experiment: Attacker Perspective

"I am a malicious actor with [access level]. How would I cause maximum damage?"

Scenario 1: External attacker with no access
- What public endpoints are vulnerable?
- What would a DDoS look like?
- What data could I infer from public behavior?

Scenario 2: Compromised user account
- What can I access beyond my own data?
- Can I escalate privileges?
- What's the blast radius of one compromised account?

Scenario 3: Malicious insider
- What would a rogue employee do?
- What access is over-provisioned?
- What audit trails would catch this?
```

### The Scale Experiment

```markdown
## Thought Experiment: 10x Scale

Current: 10,000 users, 100 RPS
Imagined: 100,000 users, 1,000 RPS

What breaks?
- [ ] Database connections (pool exhaustion at ~300)
- [ ] Single-threaded workers (CPU bound at ~500 RPS)
- [ ] Memory per request (OOM at ~800 RPS)
- [ ] Network bandwidth (saturated at ~1500 RPS)

What doesn't break?
- [x] Stateless API servers (horizontally scalable)
- [x] CDN-served assets (already edge-cached)
- [x] Read-heavy queries (can add replicas)

First constraint to address: Database connection pooling
```

### The Timeline Experiment

```markdown
## Thought Experiment: 3 Years From Now

It's 2027. Our syste