Tracing Knowledge Lineages

# Tracing Knowledge Lineages

## Overview

Ideas have history. Understanding why we arrived at current approaches - and what was tried before - prevents repeating failures and rediscovers abandoned solutions.

**Core principle:** Before judging current approaches or proposing "new" ones, trace their lineage.

## When to Trace Lineages

**Trace before:**
- Proposing to replace existing approach (understand why it exists first)
- Dismissing "old" patterns (they might have been abandoned for wrong reasons)
- Implementing "new" ideas (they might be revivals worth reconsidering)
- Declaring something "best practice" (understand its evolution)

**Red flags triggering lineage tracing:**
- "This seems overcomplicated" (was it simpler before? why did it grow?)
- "Why don't we just..." (someone probably tried, what happened?)
- "This is the modern way" (what did the old way teach us?)
- "We should switch to X" (what drove us away from X originally?)

## Tracing Techniques

### Technique 1: Decision Archaeology

Search for when/why current approach was chosen:

1. **Check decision records** (common locations: `docs/decisions/`, `docs/adr/`, `.decisions/`, architecture decision records)
2. **Search conversations** (skills/collaboration/remembering-conversations)
3. **Git archaeology** (`git log --all --full-history -- path/to/file`)
4. **Ask the person who wrote it** (if available)

**Document:**
```markdown
## Lineage: [Current Approach]

**When adopted:** [Date/commit]
**Why adopted:** [Original problem it solved]
**What it replaced:** [Previous approach]
**Why replaced:** [What was wrong with old approach]
**Context that drove change:** [External factors, new requirements]
```

### Technique 2: Failed Attempt Analysis

When someone says "we tried X and it didn't work":

**Don't assume:** X is fundamentally flawed
**Instead trace:**
1. **What was the context?** (constraints that no longer apply)
2. **What specifically failed?** (the whole approach or one aspect?)
3. **Why did it fail then?** (technology limits, team constraints, time pressure)
4. **Has context changed?** (new tools, different requirements, more experience)

**Document:**
```markdown
## Failed Attempt: [Approach]

**When attempted:** [Timeframe]
**Why attempted:** [Original motivation]
**What failed:** [Specific failure mode]
**Why it failed:** [Root cause, not symptoms]
**Context at time:** [Constraints that existed then]
**Context now:** [What's different today]
**Worth reconsidering?:** [Yes/No + reasoning]
```

### Technique 3: Revival Detection

When evaluating "new" approaches:

1. **Search for historical precedents** (was this tried before under different name?)
2. **Identify what's genuinely new** (vs. what's rebranded)
3. **Understand why it died** (if it's a revival)
4. **Check if resurrection conditions exist** (has context changed enough?)

**Common revival patterns:**
- Microservices ← Service-Oriented Architecture ← Distributed Objects
- GraphQL ← SOAP ← RPC
- Serverless ← CGI scripts ← Cloud functions
- NoSQL ← Flat files ← Document stores

**Ask:** "What did we learn from the previous incarnation?"

### Technique 4: Paradigm Shift Mapping

When major architectural changes occurred:

**Map the transition:**
```markdown
## Paradigm Shift: From [Old] to [New]

**Pre-shift thinking:** [How we thought about problem]
**Catalyst:** [What triggered the shift]
**Post-shift thinking:** [How we think now]
**What was gained:** [New capabilities]
**What was lost:** [Old capabilities sacrificed]
**Lessons preserved:** [What we kept from old paradigm]
**Lessons forgotten:** [What we might need to relearn]
```

## Search Strategies

**Where to look for lineage:**

1.