Initial commit
This commit is contained in:
Zhongwei Li
311
skills/layered-reasoning/resources/template.md
Normal file
311
skills/layered-reasoning/resources/template.md
Normal file
@@ -0,0 +1,311 @@
|
||||
# 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):
|
||||
```python
|
||||
# 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 |
|
||||
Reference in New Issue
Block a user