parallel-investigation

Parallel Investigation

Coordinate parallel investigation threads to explore multiple hypotheses simultaneously. Most effective for production incidents, performance regressions, or integration failures where the root cause is unclear.

Core Principle

When uncertain, explore multiple paths in parallel. Converge when evidence points to an answer.

Parallel investigation reduces time-to-solution by eliminating serial bottlenecks.

Investigation Structure

Phase 1: Problem Decomposition

Break the problem into independent investigation threads:

Problem: API responses are slow

Investigation Threads:
├── Thread A: Database performance
│   └── Check slow queries, indexes, connection pool
├── Thread B: Application code
│   └── Profile endpoint handlers, check for N+1
├── Thread C: Infrastructure
│   └── Check CPU, memory, network latency
└── Thread D: External services
    └── Check third-party API response times

Each thread should be independent (no blocking dependencies), focused (clear scope), and time-boxed.

Phase 2: Thread Assignment

Assign threads with clear ownership:

## Thread A: Database Performance
**Investigator:** [Name/Agent A]
**Duration:** 30 minutes
**Scope:**
- Query execution times
- Index utilization
- Connection pool metrics
**Report Format:** Summary + evidence

Phase 3: Parallel Execution

Each thread follows this pattern:

1. Gather evidence specific to thread scope
2. Document findings as you go
3. Identify if thread is a lead or dead end
4. Prepare summary for sync point

Thread Log Template:

## Thread: [Name]
**Start:** [Time]

### Findings
- [Timestamp] [Finding]

### Evidence
- [Log/Metric/Screenshot]

### Preliminary Conclusion
[What this thread suggests about the problem]

Phase 4: Sync Points

Regular convergence to share findings:

Sync Point Agenda:
1. Each thread report (2 min each)
2. Discussion & correlation (5 min)
3. Decision: Continue, Pivot, or Converge (3 min)