gh-lyndonkl-claude/skills/layered-reasoning/resources/template.md

Layered Reasoning Templates

Quick-start templates for structuring multi-level reasoning, checking consistency across layers, and translating between abstraction levels.

---

Template 1: 3-Layer Reasoning Document

When to use: Designing systems, planning strategy, explaining concepts at multiple depths

Layered Reasoning Template

Topic/System: [Name of what you're analyzing]

Purpose: [Why this layering matters]

Date: [Date]

---

Layer 1: Strategic (30,000 ft) — WHY

Core Principles/Invariants:

1. [Principle 1, e.g., "Customer privacy is non-negotiable"]
2. [Principle 2, e.g., "System must scale to 10× current load"]
3. [Principle 3, e.g., "Developer productivity is paramount"]

Strategic Constraints:

• [Constraint 1, e.g., "Must comply with GDPR"]
• [Constraint 2, e.g., "Cannot exceed $X budget"]
• [Constraint 3, e.g., "Launch within 6 months"]

Assumptions:

• [Assumption 1, e.g., "Market remains competitive"]
• [Assumption 2, e.g., "Cloud infrastructure available"]

Success Criteria (Strategic):

• [Metric 1, e.g., "Market leader in trust ratings"]
• [Metric 2, e.g., "Support 100M users"]

---

Layer 2: Tactical (3,000 ft) — WHAT

Approaches/Architectures (that satisfy strategic layer):

Approach 1: [Name, e.g., "Microservices Architecture"]

• Satisfies: [Which strategic principles, e.g., "Scales to 10×, enables team independence"]
• Tactics:
  • [Tactic 1, e.g., "Service mesh for inter-service communication"]
  • [Tactic 2, e.g., "Event-driven architecture for async operations"]
  • [Tactic 3, e.g., "API gateway for external requests"]
• Tradeoffs: [What's sacrificed, e.g., "Increased operational complexity"]

Approach 2: [Name, e.g., "Zero-Trust Security Model"]

• Satisfies: [Which strategic principles, e.g., "Customer privacy, GDPR compliance"]
• Tactics:
  • [Tactic 1, e.g., "End-to-end encryption for all data"]
  • [Tactic 2, e.g., "Identity-based access control"]
  • [Tactic 3, e.g., "Continuous verification, no implicit trust"]
• Tradeoffs: [What's sacrificed, e.g., "Slight performance overhead"]

Success Criteria (Tactical):

• [Metric 1, e.g., "99.9% uptime"]
• [Metric 2, e.g., "API response time <100ms p95"]

---

Layer 3: Operational (300 ft) — HOW

Implementation Details (that realize tactical layer):

Implementation 1: [Tactic being implemented, e.g., "Service Mesh"]

• Technology: [Specific tools, e.g., "Istio on Kubernetes"]
• Procedures:
  • [Step 1, e.g., "Deploy sidecar proxies to each pod"]
  • [Step 2, e.g., "Configure mutual TLS between services"]
  • [Step 3, e.g., "Set up traffic routing rules"]
• Timeline: [When, e.g., "Sprint 1-2"]
• Owner: [Who, e.g., "Platform team"]

Implementation 2: [Tactic being implemented, e.g., "End-to-End Encryption"]

• Technology: [Specific tools, e.g., "AWS KMS for key management, AES-256 encryption"]
• Procedures:
  • [Step 1, e.g., "Generate master key in KMS"]
  • [Step 2, e.g., "Encrypt data at rest using KMS data keys"]
  • [Step 3, e.g., "Use TLS 1.3 for data in transit"]
• Timeline: [When, e.g., "Sprint 3"]
• Owner: [Who, e.g., "Security team"]

Success Criteria (Operational):

• [Metric 1, e.g., "100% services behind Istio"]
• [Metric 2, e.g., "All PHI encrypted, verified in audit"]

---

Consistency Validation

Upward Consistency (Do operations implement tactics? Do tactics achieve strategy?):

• ☐ [Check 1]: Does Istio implementation enable microservices architecture? → [Yes/No + Evidence]
• ☐ [Check 2]: Does microservices architecture support 10× scale? → [Yes/No + Evidence]
• ☐ [Check 3]: Does encryption implementation satisfy privacy principle? → [Yes/No + Evidence]

Downward Consistency (Can strategy be executed with tactics? Can tactics be implemented?):

• ☐ [Check 1]: Can we achieve GDPR compliance with chosen tactics? → [Yes/No + Gaps]
• ☐ [Check 2]: Can we implement Istio within budget/timeline? → [Yes/No + Constraints]

Lateral Consistency (Do parallel choices contradict?):

• ☐ [Check 1]: Does encryption overhead conflict with <100ms latency goal? → [Yes/No + Mitigation]
• ☐ [Check 2]: Do microservices complexity conflict with 6-month timeline? → [Yes/No + Adjustment]

Emergent Properties Observed:

• [Emergence 1, e.g., "Microservices increased cross-team coordination overhead → slowed feature delivery"]
• [Implication, e.g., "Adjust strategy: 'Scale' includes team coordination, not just technical scale"]

---

Change Propagation Plan

If Strategic Layer Changes:

• [Change scenario, e.g., "New regulation requires data residency"] →
• [Tactical impact, e.g., "Need multi-region deployment with geo-replication"] →
• [Operational impact, e.g., "Deploy regional clusters, implement data sovereignty"]

If Operational Constraint Discovered:

• [Constraint, e.g., "Istio adds 50ms latency, exceeds <100ms goal"] →
• [Tactical adjustment, e.g., "Switch to Linkerd (lighter sidecar) or optimize routes"] →
• [Strategic clarification, e.g., "Refine: <100ms for critical paths, <200ms for others"]

---

Template 2: Cross-Layer Communication Plan

When to use: Presenting to stakeholders at different levels (board, management, engineers)

Communication Template

Core Message: [Single sentence summarizing what you're communicating]

---

For Executive Audience (30K ft - Strategic)

Slide 1: WHY (Problem/Opportunity)

• Context: [Strategic context, e.g., "Market shifting to privacy-first products"]
• Impact: [Business impact, e.g., "Losing 20% customers to competitors on trust"]
• Outcome: [Desired end state, e.g., "Become market leader in data privacy"]

Slide 2: WHAT (Approach)

• Strategy: [High-level approach, e.g., "Zero-trust architecture, end-to-end encryption, transparent security"]
• Investment: [Resources required, e.g., "$2M, 6 months, 10 engineers"]
• Risk: [Key risks, e.g., "Performance impact, timeline risk if encryption complex"]

Slide 3: OUTCOMES (Success Metrics)

• Revenue impact: [e.g., "$5M ARR from enterprise customers requiring compliance"]
• Market position: [e.g., "SOC 2 Type II + GDPR certified within 6 months"]
• Risk mitigation: [e.g., "Avoid $XM penalty for non-compliance"]

Language: Business outcomes, revenue, market share, strategic risk. Avoid technical details.

---

For Management Audience (3K ft - Tactical)

Roadmap Overview:

• Q1: [Tactical milestone, e.g., "Implement encryption at rest + TLS 1.3"]
• Q2: [Tactical milestone, e.g., "Deploy zero-trust access controls + audit logging"]
• Q3: [Tactical milestone, e.g., "SOC 2 audit + penetration testing"]

Team & Resources:

• Security Team (5 engineers): Encryption, access control, audit systems
• Platform Team (3 engineers): Infrastructure, key management, monitoring
• Product Team (2 engineers): User-facing privacy controls

Dependencies & Risks:

• Dependency 1: [e.g., "Requires AWS KMS setup (1 week)"]
• Risk 1: [e.g., "Encryption may slow API response; plan optimization sprint"]

Success Metrics:

• [Metric 1, e.g., "100% data encrypted by end Q1"]
• [Metric 2, e.g., "Pass SOC 2 audit Q3"]

Language: Roadmaps, team velocity, dependencies, milestones. Some technical detail but focus on execution.

---

For Engineering Audience (300 ft - Operational)

Technical Design:

• Architecture: [e.g., "Client → API Gateway (TLS 1.3) → Service Mesh (mTLS) → Encrypted DB"]
• Components:
  • [Component 1, e.g., "AWS KMS for key management"]
  • [Component 2, e.g., "AES-256-GCM for data at rest"]
  • [Component 3, e.g., "Istio sidecar proxies for service-to-service encryption"]

Implementation Steps:

1. [Step 1, e.g., "Set up AWS KMS, create customer master key"]
2. [Step 2, e.g., "Implement encryption layer in data access library"]
3. [Step 3, e.g., "Deploy Istio with mTLS strict mode"]
4. [Step 4, e.g., "Migrate existing data: encrypt in background job"]
5. [Step 5, e.g., "Update monitoring: track encryption overhead"]

Code Example (if relevant):

# Encrypt data before storing
def store_user_data(user_id, data):
    encrypted_data = kms.encrypt(data, key_id='customer-master-key')
    db.insert(user_id, encrypted_data)

Testing Plan:

• [Test 1, e.g., "Unit tests for encryption/decryption"]
• [Test 2, e.g., "Integration tests for end-to-end encrypted flow"]
• [Test 3, e.g., "Performance tests: measure latency impact"]

Language: Code, architecture diagrams, APIs, specific technologies, testing. Detailed and technical.

---

Template 3: Consistency Check Matrix

When to use: Validating alignment across layers before finalizing decisions

Consistency Check Template

System/Decision: [What you're validating]

---

Layer Pair	Consistency Question	Status	Evidence/Gaps	Action Required
Ops → Tactical	Do operational procedures implement tactical approaches?	☐ Pass ☐ Fail	[e.g., "Istio implements service mesh as planned"]	[e.g., "None" or "Fix X"]
Tactical → Strategic	Do tactical approaches achieve strategic principles?	☐ Pass ☐ Fail	[e.g., "Zero-trust satisfies privacy principle"]	[e.g., "None" or "Adjust Y"]
Strategic → Tactical	Can strategic goals be achieved with chosen tactics?	☐ Pass ☐ Fail	[e.g., "Tactics support GDPR compliance"]	[e.g., "None" or "Add Z tactic"]
Tactical → Ops	Can tactical approaches be implemented operationally?	☐ Pass ☐ Fail	[e.g., "Team has Istio expertise"]	[e.g., "Hire or train"]
Ops A ↔ Ops B	Do parallel operational choices conflict?	☐ Pass ☐ Fail	[e.g., "Encryption + caching compatible"]	[e.g., "Optimize cache encryption"]
Tactical A ↔ Tactical B	Do parallel tactical approaches contradict?	☐ Pass ☐ Fail	[e.g., "Microservices + monorepo: no conflict"]	[e.g., "None" or "Choose one"]

---

Overall Consistency: ☐ Aligned (all pass) ☐ Minor Issues (1-2 fails, fixable) ☐ Major Issues (3+ fails, rethink)

Summary of Gaps:

1. [Gap 1, e.g., "Encryption overhead conflicts with latency SLA → Need optimization"]
2. [Gap 2, e.g., "No plan for key rotation → Add operational procedure"]

Remediation Plan:

1. [Action 1, e.g., "Benchmark encryption overhead, optimize hot paths"]
2. [Action 2, e.g., "Define 90-day key rotation policy, automate in KMS"]

---

Template 4: Layer Transition Analysis

When to use: When changing strategies, discovering operational constraints, or refactoring systems

Transition Template

Transition Type: ☐ Top-Down (Strategy changed) ☐ Bottom-Up (Operational constraint discovered)

---

If Top-Down (Strategy Change)

Strategic Change: [What changed at strategic layer, e.g., "New regulation requires data residency in EU"]

Tactical Implications:

• Current Tactics: [e.g., "Single US region deployment"]
• Required Tactics: [e.g., "Multi-region deployment with EU data sovereignty"]
• New Tactics: [e.g., "Deploy EU cluster, implement regional routing, data replication"]

Operational Implications:

• Current Operations: [e.g., "Single AWS us-east-1 region"]
• Required Operations: [e.g., "AWS eu-west-1 cluster, regional databases, GDPR-compliant data handling"]
• Migration Plan: [Timeline and steps, e.g., "Q1: Deploy EU infra, Q2: Migrate EU customers"]

Cost/Impact:

• Resources: [e.g., "$500K infrastructure, 3 engineers for 3 months"]
• Risk: [e.g., "Data sync latency, potential data loss during migration"]

---

If Bottom-Up (Operational Constraint)

Operational Constraint: [What was discovered, e.g., "Istio sidecar adds 50ms latency, exceeds 100ms SLA"]

Tactical Re-Evaluation:

• Current Tactic: [e.g., "Istio service mesh for microservices"]
• Options:
  1. Option A: [e.g., "Switch to Linkerd (lighter, ~10ms overhead)"]
  2. Option B: [e.g., "Optimize Istio config, remove unnecessary features"]
  3. Option C: [e.g., "Selective mesh: only for services needing mTLS"]
• Recommendation: [Which option and why]

Strategic Clarification (if needed):

• Original Strategy: [e.g., "<100ms latency for all APIs"]
• Refined Strategy: [e.g., "<100ms for critical paths (user-facing), <200ms for internal APIs"]
• Rationale: [e.g., "Security (mTLS) worth 50ms for internal, but optimize user-facing"]

Decision: ☐ Keep Strategy, Adjust Tactics ☐ Refine Strategy, Keep Tactics ☐ Both Change

---

Quick Reference: When to Use Each Template

Template	Use Case	Output
3-Layer Reasoning Document	Designing systems, planning strategy	Structured doc with strategic/tactical/operational layers + consistency checks
Cross-Layer Communication	Presenting to different stakeholders	Tailored messaging for exec/management/engineers
Consistency Check Matrix	Validating alignment before finalizing	Gap analysis with remediation plan
Layer Transition Analysis	Strategy changes or operational constraints	Impact analysis + migration/adjustment plan