version: "1.0.1" name: layered-reasoning description: Structures thinking across multiple abstraction levels (30,000 ft strategic, 3,000 ft tactical, 300 ft operational) while maintaining consistency between layers. Guides through top-down decomposition, bottom-up aggregation, cross-layer translation, and constraint propagation. Use when reasoning across multiple abstraction levels, designing systems with hierarchical layers, explaining concepts at different depths, maintaining consistency between principles and implementation, or when users mention 30,000-foot view, layered thinking, abstraction levels, top-down design, or strategy-to-execution alignment.

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) 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) 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) Generate approaches/policies/architectures that satisfy strategic constraints. Multiple tactical options may exist; choose based on tradeoffs.

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

Step 5: Validate consistency across all layers (details) 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) 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) 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) 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 explaining to executive, start 30K → 3K (stop there unless asked). If explaining to engineer, provide 30K context first, then dive to 300 ft.

Test: Can listener answer "why does this matter?" (links to upper layer) and "how do we do this?" (links to lower layer)

3. Each Layer Should Be Independently Useful

Danger: Layers that only make sense when combined, not standalone

Guardrail: Strategic layer should guide decisions even without seeing operations. Tactical layer should be understandable without code. Operational layer should be executable without re-deriving strategy.

Principle: Good layers can be consumed independently by different audiences

4. Limit Layers to 3-5 Levels

Danger: Too many layers create overhead; too few lose nuance

Guardrail: For most domains, 3 layers sufficient (strategy/tactics/operations or architecture/design/code). Complex domains may need 4-5 but rarely more.

Rule of thumb: Can you name each layer clearly? If not, you have too many.

5. Upper Layers Constrain, Lower Layers Implement

Danger: Treating layers as independent rather than hierarchical

Guardrail: Strategic layer sets constraints ("must be HIPAA compliant"). Tactical layer chooses approaches within constraints ("encryption + audit logs"). Operational layer implements ("AES-256 + CloudTrail"). Cannot violate upward.

Anti-pattern: Operational decision ("skip encryption for speed") violating strategic constraint ("HIPAA compliance")

6. Propagate Changes Bidirectionally

Danger: Strategic shift without updating tactics/ops, or operational constraint discovered but strategy unchanged

Guardrail: Top-down: Strategy changes → re-evaluate tactics → adjust operations. Bottom-up: Operational constraint → re-evaluate tactics → potentially adjust strategy.

Example: Strategy shift to "privacy-first" → Update tactics (end-to-end encryption) → Update ops (implement encryption). Or: Operational constraint (performance) → Tactical adjustment (different approach) → Strategic clarification ("privacy-first within performance constraints")

7. Make Assumptions Explicit at Each Layer

Danger: Implicit assumptions lead to inconsistency when assumptions violated

Guardrail: Document assumptions at each layer. Strategic: "Assuming competitive market." Tactical: "Assuming cloud infrastructure." Operational: "Assuming Python 3.9+."

Benefit: When assumptions change, know which layers need updating

8. Recognize Emergent Properties

Danger: Focusing only on designed properties, missing unintended consequences

Guardrail: Regularly observe bottom layer, look for emerging patterns at middle layer, consider strategic implications. Emergent properties can invalidate strategic assumptions.

Example: Microservices (operational) → Coordination overhead (tactical emergence) → Slower feature delivery (strategic failure if goal was speed)

Quick Reference

Layer Mapping by Domain

Consistency Check Questions

Translation Hints by Audience

Resources

Navigation to Resources

• **Templates**: Layered reasoning document template, consistency check template, cross-layer communication template
• **Methodology**: Layer design principles, consistency validation techniques, emergence detection, bidirectional propagation
• **Rubric**: Evaluation criteria for layered reasoning quality (10 criteria)

Related Skills

• abstraction-concrete-examples: For moving between abstract and concrete (related but less structured than layers)
• decomposition-reconstruction: For breaking down complex systems (complements layered approach)
• communication-storytelling: For translating between audiences at different layers
• adr-architecture: For documenting architectural decisions across layers
• alignment-values-north-star: For strategic layer definition (values → strategy)

Examples in Context

Example 1: SaaS Product Strategy

30K (Strategic): "Become the easiest CRM for small businesses" (positioning)

3K (Tactical): "Simple UI, 5-minute setup, mobile-first, $20/user pricing, self-serve onboarding"

300 ft (Operational): "React app, OAuth for auth, Stripe for billing, onboarding flow: signup → import contacts → send first email"

Consistency check: Does $20 pricing support "easiest" (yes, low barrier)? Does 5-minute setup work with current implementation (measure in practice)? Does mobile-first align with React architecture (yes)?

Example 2: Technical Architecture

30K: "Highly available system with <1% downtime, supports 10× traffic growth"

3K: "Multi-region deployment, auto-scaling, circuit breakers, blue-green deployments"

300 ft: "AWS multi-AZ, ECS Fargate with target tracking, Istio circuit breakers, CodeDeploy blue-green"

Emergence: Observed: cross-region latency 200ms → Tactical adjustment: regional data replication → Strategic clarification: "High availability within regions, eventual consistency across regions"

Example 3: Organizational Change

30K: "Build customer-centric culture where customer feedback drives decisions"

3K: "Monthly customer advisory board, NPS surveys after each interaction, customer support KPIs in exec dashboards"

300 ft: "Schedule CAB meetings first Monday monthly, automated NPS via Delighted after ticket close, Looker dashboard with CS CSAT by rep"

Consistency: Does monthly CAB support "customer-centric" (or too infrequent)? Do support KPIs incentivize right behavior (check for gaming)? Does automation reduce personal touch (potential conflict)?