layered-reasoning

What this skill does

# Layered Reasoning

---

## Common Patterns

### Pattern 1: 30K → 3K → 300 ft Decomposition (Top-Down)

**When**: Starting from vision/principles, deriving concrete actions

**Structure**:
- **30,000 ft (Strategic)**: Why? Core principles, invariants, constraints (e.g., "Customer privacy is non-negotiable")
- **3,000 ft (Tactical)**: What? Approaches, architectures, policies (e.g., "Zero-trust security model, end-to-end encryption")
- **300 ft (Operational)**: How? Specific actions, procedures, code (e.g., "Implement AES-256 encryption for data at rest")

**Example**: Product strategy
- **30K**: "Become the most trusted platform" (principle)
- **3K**: "Achieve SOC 2 compliance, publish security reports, 24/7 support" (tactics)
- **300 ft**: "Implement MFA, conduct quarterly audits, hire 5 support engineers" (actions)

**Process**: (1) Define strategic layer invariants, (2) Derive tactical options that satisfy invariants, (3) Select tactics, (4) Design operational procedures implementing tactics, (5) Validate operational layer doesn't violate strategic constraints

### Pattern 2: Bottom-Up Aggregation

**When**: Starting from observations/data, building up to principles

**Structure**:
- **300 ft**: Specific observations, measurements, incidents (e.g., "User A clicked 5 times, User B abandoned")
- **3,000 ft**: Patterns, trends, categories (e.g., "40% abandon at checkout, slow load times correlate with abandonment")
- **30,000 ft**: Principles, theories, root causes (e.g., "Performance impacts conversion; every 100ms costs 1% conversion")

**Example**: Engineering postmortem
- **300 ft**: "Service crashed at 3:42 PM, memory usage spiked to 32GB, 500 errors returned"
- **3K**: "Memory leak in caching layer, triggered by specific API call pattern under load"
- **30K**: "Our caching strategy lacks eviction policy; need TTL-based expiration for all caches"

**Process**: (1) Collect operational data, (2) Identify patterns and group, (3) Formulate hypotheses at tactical layer, (4) Validate with more data, (5) Distill strategic principles

### Pattern 3: Layer Translation (Cross-Layer Communication)

**When**: Explaining same concept to different audiences (CEO, manager, engineer)

**Technique**: Translate preserving core meaning while adjusting abstraction

**Example**: Explaining tech debt
- **CEO (30K)**: "We built quickly early on. Now growth slows 20% annually unless we invest $2M to modernize."
- **Manager (3K)**: "Monolithic architecture prevents independent team velocity. Migrate to microservices over 6 months."
- **Engineer (300 ft)**: "Extract user service from monolith. Create API layer, implement service mesh, migrate traffic."

**Process**: (1) Identify audience's layer, (2) Extract core message, (3) Translate using concepts/metrics relevant to that layer, (4) Maintain causal links across layers

### Pattern 4: Constraint Propagation (Top-Down)

**When**: High-level constraints must guide low-level decisions

**Mechanism**: Strategic constraints flow down, narrowing options at each layer

**Example**: Healthcare app design
- **30K constraint**: "HIPAA compliance is non-negotiable" (strategic)
- **3K derivation**: "All PHI must be encrypted, audit logs required, access control mandatory" (tactical)
- **300 ft implementation**: "Use AWS KMS for encryption, CloudTrail for audits, IAM for access" (operational)

**Guardrail**: Lower layers cannot violate upper constraints (e.g., operational decision to skip encryption violates strategic constraint)

### Pattern 5: Emergent Property Recognition (Bottom-Up)

**When**: Lower-layer interactions create unexpected upper-layer behavior

**Example**: Team structure
- **300 ft**: "Each team owns microservice, deploys independently, uses Slack for coordination"
- **3K emergence**: "Conway's Law: architecture mirrors communication structure; slow cross-team features"
- **30K insight**: "Org structure determines system architecture; realign teams to product lines, not services"

**Process**: (1) Observe operational behavior, (2) Identify emerging patterns at tactical layer, (3) Recognize strategic implications, (4) Adjust strategy if needed

### Pattern 6: Consistency Checking Across Layers

**When**: Validating that all layers align (no contradictions)

**Check types**:
- **Upward consistency**: Do operations implement tactics? Do tactics achieve strategy?
- **Downward consistency**: Can strategy be executed with these tactics? Can tactics be implemented operationally?
- **Lateral consistency**: Do parallel tactical choices contradict? Do operational procedures conflict?

**Example inconsistency**: Strategy says "Move fast," tactics say "Extensive approval process," operations say "3-week release cycle" → Contradiction

**Fix**: Align layers. Either (1) change strategy ("Move carefully"), (2) change tactics ("Lightweight approvals"), or (3) change operations ("Daily releases")

---

## Workflow

Use this structured approach when applying layered reasoning:

```
□ Step 1: Identify relevant layers and abstraction levels
□ Step 2: Define strategic layer (principles, invariants, constraints)
□ Step 3: Derive tactical layer (approaches that satisfy strategy)
□ Step 4: Design operational layer (concrete actions implementing tactics)
□ Step 5: Validate consistency across all layers
□ Step 6: Translate between layers for different audiences
□ Step 7: Iterate based on feedback from any layer
□ Step 8: Document reasoning at each layer
```

**Step 1: Identify relevant layers and abstraction levels** ([details](#1-identify-relevant-layers-and-abstraction-levels))
Determine how many layers needed (typically 3-5). Map layers to domains: business (vision/strategy/execution), technical (architecture/design/code), organizational (mission/goals/tasks).

**Step 2: Define strategic layer** ([details](#2-define-strategic-layer))
Establish high-level principles, invariants, and constraints that must hold. These are non-negotiable and guide all lower layers.

**Step 3: Derive tactical layer** ([details](#3-derive-tactical-layer))
Generate approaches/policies/architectures that satisfy strategic constraints. Multiple tactical options may exist; choose based on tradeoffs.

**Step 4: Design operational layer** ([details](#4-design-operational-layer))
Create specific procedures, implementations, or actions that realize tactical choices. This is where execution happens.

**Step 5: Validate consistency across all layers** ([details](#5-validate-consistency-across-all-layers))
Check upward (do ops implement tactics?), downward (can strategy be executed?), and lateral (do parallel choices conflict?) consistency.

**Step 6: Translate between layers for different audiences** ([details](#6-translate-between-layers-for-different-audiences))
Communicate at appropriate abstraction level for each stakeholder. CEO needs strategic view, engineers need operational detail.

**Step 7: Iterate based on feedback from any layer** ([details](#7-iterate-based-on-feedback-from-any-layer))
If operational constraints make tactics infeasible, adjust tactics or strategy. If strategic shift occurs, propagate changes downward.

**Step 8: Document reasoning at each layer** ([details](#8-document-reasoning-at-each-layer))
Write explicit rationale at each layer explaining how it relates to layers above/below. Makes assumptions visible and aids future iteration.

---

## Guardrails

### 1. Maintain Consistency Across Layers

**Danger**: Strategic goals contradict operational reality, or implementation violates principles

**Guardrail**: Regularly check upward, downward, and lateral consistency. Propagate changes bidirectionally (strategy changes → update tactics/ops; operational constraints → update tactics/strategy).

**Red flag**: "Our strategy is X but we actually do Y" signals layer mismatch

### 2. Don't Skip Layers When Communicating

**Danger**: Jumping from 30K to 300 ft confuses audiences, loses context

**Guardrail**: Move through layers sequentially. If