@polderlabs/bizar 10.7.2 → 10.10.0

package/.claude/skills/thinking-bounded-rationality/SKILL.md

@@ -1,406 +0,0 @@
----
-name: thinking-bounded-rationality
-description: Use when a search or investigation could run indefinitely and you need a stopping rule. Set an explicit "good enough" threshold and stop at the first option that clears it.
----
-
-# Bounded Rationality and Satisficing
-
-## Overview
-
-Herbert Simon's Bounded Rationality recognizes that any agent operating under finite resources cannot exhaustively optimize: the search space is too large, information is incomplete, and acting has a cost. Rather than pursuing the optimal solution, Simon proposed "satisficing"—a portmanteau of satisfy + suffice—choosing the first solution good enough to meet an explicit threshold, then stopping.
-
-For an autonomous coding agent the binding constraint is a **budget**: tool calls, search/read operations, context window, and wall-clock time per turn. A grep that could keep matching, a file tree you could keep traversing, a doc set you could keep reading — each has steeply diminishing returns. Satisficing converts "search until certain" (which never terminates) into "search until the threshold is met, then act."
-
-**Core Principle:** Define "good enough" *before* you search, and stop at the first option that clears the bar. Optimizing is correct only when the gap between good and best is worth more than the budget it costs to close it.
-
-## When to Use
-
-- An investigation or search has no natural endpoint (greps, file reads, doc crawls, candidate solutions) and could consume the whole budget.
-- Multiple options would all clear the requirement and you're tempted to keep comparing.
-- You're gathering more context than the decision actually needs.
-- A reversible, low-stakes choice is consuming optimization-level effort.
-- You need to commit and ship before the turn/budget runs out.
-
-Decision flow:
-
-```
-Search/investigation that could run indefinitely? → yes → Is closing the gap to "best" worth the budget? → no → SATISFICE (threshold + stop)
-                                                                                                          ↘ yes → Optimize (and cap the budget)
-                                                  ↘ no → just answer
-```
-
-## When NOT to Use
-
-- **Irreversible or high-stakes choices** (data deletion, security boundaries, schema/migration decisions, public commitments) — the gap between good and best is worth the budget; optimize and verify.
-- **Correctness gates** — tests, security checks, and "did the fix actually work?" are not satisficeable; you need the right answer, not a sufficient-looking one.
-- **The answer is cheaply knowable** — if one more grep or a single file read would settle it definitively, just do it; don't satisfice your way past a pam fact.
-- **The threshold can't be stated** — if you can't articulate what "good enough" means, you can't satisfice responsibly; clarify the requirement first.
-
-## Trigger Card
-
-When a search or investigation could run indefinitely and you need to ship:
-
-1. **Set an explicit aspiration level** — what does "good enough" look like? Define a concrete, measurable threshold.
-2. **Search sequentially** — evaluate options one at a time in the order you encounter them. Do not enumerate exhaustively.
-3. **Stop at the first option that clears the threshold.** Commit and move on.
-
-If the threshold can't be articulated or the cost of a wrong choice is catastrophic, don't satisfice — run the full procedure. For a single cheaply-knowable fact, just look it up.
-
-## The Three Constraints
-
-### 1. Information Bounds
-
-**What you can know is limited**
-
-- Complete information rarely exists
-- Gathering more information has costs
-- Information has diminishing returns
-- Future states are inherently uncertain
-
-```
-Example: Choosing a technology stack
-Reality: You can't test every option in production
-         You can't predict 5-year industry shifts
-         You can't know your future team composition
-Satisfice: Pick a well-supported option that meets current needs
-```
-
-### 2. Processing Bounds (the budget)
-
-**What you can compute and attend to is limited**
-
-- Each turn has a finite budget of tool calls, reads, and context-window tokens
-- Adding more options/criteria to a comparison degrades signal, not improves it — past ~3-5 criteria, marginal context rarely flips the decision
-- Long, sprawling investigations crowd out the context needed to act on what you found
-- More search reduces uncertainty with sharply diminishing returns
-
-```
-Example: Choosing among architecture options
-Reality: Reading every doc and modeling every interaction effect
-         burns the budget before you produce an answer
-Satisfice: Fix the 3-5 criteria that actually decide it, evaluate
-           against those, and stop at the first option that clears them
-```
-
-### 3. Action-Cost Bounds
-
-**Deciding and re-deciding both cost budget and time**
-
-- Every additional search/read consumes budget that can't be spent elsewhere
-- The user is waiting; an answer now usually beats a marginally better answer later
-- Re-opening a settled, reversible decision is rarely worth the cost
-- Perfect is the enemy of shipped
-
-```
-Example: Picking a library for a reversible internal task
-Reality: You could compare ten options across a dozen dimensions
-         Reversibility means a wrong-but-adequate pick is cheap to swap
-Satisfice: Pick the first well-supported option that meets the requirement, move on
-```
-
-## Satisficing vs. Optimizing
-
-### When to Satisfice
-
-| Signal | Why Satisfice |
-|--------|---------------|
-| Reversible decision | Can adjust later with more information |
-| Time pressure | Cost of delay exceeds value of more analysis |
-| Diminishing returns | 80% solution found, 100% would take 10x effort |
-| High uncertainty | More analysis won't reduce uncertainty meaningfully |
-| Many acceptable options | Several solutions meet requirements adequately |
-| Low stakes | Consequences of suboptimal choice are minor |
-
-### When to Optimize
-
-| Signal | Why Optimize |
-|--------|--------------|
-| Irreversible decision | Mistakes are permanent or very costly to undo |
-| High stakes | Wrong choice has severe consequences |
-| Clear criteria | You know exactly what "best" means |
-| Bounded search space | All options can actually be evaluated |
-| Available time | Deadline allows for thorough analysis |
-| Clear value of optimal | Difference between good and best is significant |
-
-## The Satisficing Process
-
-### Step 1: Define Aspiration Level
-
-Set the minimum acceptable threshold for each criterion:
-
-```
-Example: Hiring a senior engineer
-Optimizing: Find the absolute best candidate
-Satisficing: Find a candidate who:
-- Has 5+ years relevant experience ✓
-- Can pass technical interview ✓
-- Salary expectations fit budget ✓
-- Available to start within 4 weeks ✓
-- Culture fit (team confirms) ✓
-
-First candidate who meets all criteria → Hire
-```
-
-### Step 2: Search Sequentially
-
-Evaluate options one at a time against aspiration level:
-
-```
-Option A: Meets 4/5 criteria → Continue search
-Option B: Meets 3/5 criteria → Continue search  
-Option C: Meets 5/5 criteria → STOP, choose this one
-```
-
-Key insight: You don't compare options against each other, you compare each option against your threshold.
-
-### Step 3: Adjust Aspiration If Needed
-
-If search is too long or too short, recalibrate:
-
-```
-Too many options qualify → Raise aspiration level
-Nothing qualifies after reasonable search → Lower aspiration level
-```
-
-### Step 4: Commit and Move On
-
-Once threshold is met:
-
-- Stop searching
-- Accept the decision
-- Resist second-guessing
-- Redirect energy to execution
-
-## Application Patterns
-
-### For Technical Design
-
-```
-Scenario: Choose a message queue for new service
-
-Satisficing approach:
-1. Define requirements (aspiration level):
-   - At-least-once delivery ✓
-   - Handles 10k msg/sec ✓
-   - Team familiarity or fast learning curve ✓
-   - Managed option available ✓
-   - Within cost budget ✓
-
-2. Evaluate sequentially:
-   - RabbitMQ: Meets all → STOP, use RabbitMQ
-
-3. Don't continue researching Kafka, SQS, etc.
-   unless RabbitMQ fails threshold
-```
-
-### For Code Review
-
-```
-Scenario: Reviewing a PR under time pressure
-
-Satisficing approach:
-1. Define "good enough" criteria:
-   - No security vulnerabilities ✓
-   - Tests pass ✓
-   - No obvious performance issues ✓
-   - Code is readable ✓
-   - Follows project conventions ✓
-
-2. Stop when criteria met
-   Don't perfect every line if shipping matters
-```
-
-### For Research/Investigation
-
-```
-Scenario: Debugging production issue
-
-Satisficing approach:
-1. Define stopping criteria:
-   - Root cause identified ✓
-   - Fix verified in staging ✓
-   - Rollback plan exists ✓
-
-2. Stop investigating once you can fix
-   Don't exhaustively trace every code path
-   if you have a working solution
-```
-
-### For Feature Scope
-
-```
-Scenario: MVP feature set decisions
-
-Satisficing approach:
-1. Define "enough to learn":
-   - Core user job addressed ✓
-   - Measurable success metric exists ✓
-   - Usable enough for feedback ✓
-   - Can ship within sprint ✓
-
-2. First scope that meets criteria → Ship it
-   Don't polish what you might throw away
-```
-
-## Setting Appropriate Aspiration Levels
-
-### Too High → Analysis Paralysis
-
-Symptoms:
-
-- Nothing ever meets the bar
-- Endless research and comparison
-- Decisions perpetually delayed
-- Perfect becomes enemy of good
-
-Fix: Ask "What's the minimum that would be acceptable?"
-
-### Too Low → Poor Outcomes
-
-Symptoms:
-
-- Frequent rework required
-- Quality issues in production
-- Technical debt accumulation
-- Stakeholder dissatisfaction
-
-Fix: Ask "What past decisions do I regret? What threshold would have prevented them?"
-
-### Calibration Heuristics
-
-```
-Reversibility Check:
-- Easily reversible → Lower aspiration OK
-- Hard to reverse → Raise aspiration
-
-Consequence Check:
-- Minor consequences → Lower aspiration OK
-- Major consequences → Raise aspiration
-
-Time Check:
-- Tight deadline → Accept lower aspiration
-- Ample time → Can afford higher aspiration
-```
-
-## Common Traps
-
-### Trap 1: Satisficing Feels Like Settling
-
-**Reality:** Satisficing is rational under constraints, not lazy.
-
-```
-Optimizing with infinite time = mathematically correct
-Optimizing with real constraints = often irrational
-Satisficing = adapted to actual world
-```
-
-### Trap 2: Post-Decision Regret
-
-**Reality:** Finding a better option later doesn't mean the decision was wrong.
-
-```
-You chose Option B (met threshold)
-Later discovered Option D was "better"
-This is expected—you stopped searching at B
-Regret is only valid if B didn't meet your threshold
-```
-
-### Trap 3: Creeping Aspiration
-
-**Reality:** Moving goalposts prevent closure.
-
-```
-Original: "Need 100ms response time"
-After meeting it: "Actually, 50ms would be better"
-After that: "Hmm, 25ms would be ideal..."
-
-Fix: Lock aspiration level before search begins
-```
-
-### Trap 4: Satisficing the Wrong Things
-
-**Reality:** Some decisions warrant optimization.
-
-```
-Wrong to satisfice:
-- Security critical systems
-- Legal compliance
-- Safety-critical code
-- Irreversible architectural choices
-
-Right to satisfice:
-- Internal tooling
-- Reversible experiments
-- Style preferences
-- Low-stakes choices
-```
-
-## Integration with Other Thinking Models
-
-### With First Principles
-
-```
-Use First Principles to determine:
-- What constraints are real vs assumed?
-- What is the fundamental requirement?
-Then satisfice against those fundamentals
-```
-
-### With Inversion
-
-```
-Use Inversion to set aspiration level:
-- "What would make this solution unacceptable?"
-- Avoid those failure modes
-- Any option avoiding them satisfices
-```
-
-### With Circle of Competence
-
-```
-Outside your circle:
-- You can't evaluate "optimal" anyway
-- Satisficing is your only realistic option
-- Set thresholds based on expert input
-
-Inside your circle:
-- You can choose when to optimize vs satisfice
-- Trust your calibrated aspiration levels
-```
-
-### With Pre-Mortem
-
-```
-Run pre-mortem to validate aspiration level:
-- "If this satisficed solution fails, why?"
-- Adjust thresholds to prevent likely failures
-- Don't over-engineer against unlikely failures
-```
-
-## Verification Checklist
-
-- [ ] Identified whether this decision warrants optimizing or satisficing
-- [ ] Set clear aspiration level before searching
-- [ ] Defined explicit stopping criteria
-- [ ] Evaluated options against threshold, not against each other
-- [ ] Stopped when threshold was met (or adjusted threshold rationally)
-- [ ] Committed to decision without continued comparison shopping
-- [ ] Documented reasoning for future reference
-
-## Key Questions
-
-- "What's the minimum acceptable solution here?"
-- "What would 'good enough' look like for this decision?"
-- "Is more research likely to change my decision?"
-- "What's the cost of continued analysis vs acting now?"
-- "Can I reverse this decision if I learn more later?"
-- "Am I searching for best, or searching to avoid deciding?"
-- "What threshold would I set for someone else in my position?"
-
-## Simon's Insight
-
-"A wealth of information creates a poverty of attention."
-
-In a world of infinite information and finite attention, satisficing isn't settling—it's adapting to reality. The goal isn't to make perfect decisions, but to make good decisions efficiently, preserving cognitive resources for the problems that truly require optimization.
-
-The satisficer who ships beats the optimizer who's still researching.

package/.claude/skills/thinking-circle-of-competence/SKILL.md

@@ -1,216 +0,0 @@
----
-name: thinking-circle-of-competence
-description: Use when you're unsure whether you actually know the answer. If you lack the evidence or context to answer reliably, abstain, ask, or fetch it — don't confabulate a confident reply.
----
-
-# Circle of Competence
-
-## Overview
-The Circle of Competence, articulated by Warren Buffett and Charlie Munger, is about knowing precisely where reliable knowledge ends. For an autonomous agent the operative version is **abstention**: the failure mode isn't being wrong about a hard problem — it's producing a fluent, confident answer when the grounding for it isn't there. The most damaging output a model can give is a plausible fabrication: an invented API, a hallucinated file path, a made-up statistic, a guessed config value, delivered with the same tone as a verified fact.
-
-**Core Principle:** Knowing what you can't reliably answer is more valuable than the answer. When the evidence or context to answer correctly is missing, the right move is to abstain, ask, or go fetch it — not to confabulate. "I don't know, let me check" beats a confident guess.
-
-## When to Use
-- A question demands a specific fact you're not certain of (an exact API signature, a config value, a version behavior, a number)
-- You're about to assert something about *this* codebase/system without having read it
-- The request is in an unfamiliar domain and your answer would be reconstructed from vague pattern rather than grounded knowledge
-- You notice you're filling a gap with the most plausible-sounding value rather than a checked one
-- A confident answer would be expensive to be wrong about
-
-Decision flow:
-```
-About to give a specific/high-stakes answer?
-  → Is it grounded in something I've read/run/can cite? → yes → answer
-                                                        ↘ no → CAN I cheaply fetch/check it? → yes → FETCH, then answer
-                                                                                              ↘ no → ABSTAIN or ASK; flag the uncertainty
-```
-
-## When NOT to Use
-- **The answer is grounded and verifiable** — you've read the file, run the command, or it's stable common knowledge. Don't perform false humility on things you actually know; needless hedging is its own failure.
-- **The cost of being wrong is trivial and reversible** — a pam reversible attempt with a caveat can beat stalling, as long as you flag it as unverified.
-- **You can just look it up right now** — then the move is *fetch*, not abstain. Abstention is the fallback when grounding is genuinely unavailable, not an excuse to skip a cheap check.
-- **Brainstorming / clearly-hypothetical framing** — when the user has signalled they want options or speculation, labeled informed guesses are appropriate.
-
-## The Three Zones (by grounding, not by ego)
-
-### Zone 1: Grounded — answer
-**The answer is anchored in something checkable**
-
-- You read it in the actual code/file/doc this session, or ran it
-- It's stable, common knowledge unlikely to be version- or context-specific
-- You could cite *where* the answer comes from
-
-```
-Examples (grounded):
-- "This function returns null on miss" — after reading the function
-- HTTP 404 means not found — stable, universal
-- "The config sets timeout to 30s" — after opening the config
-→ Answer directly.
-```
-
-### Zone 2: Partial — verify before asserting
-**Plausible but reconstructed, not confirmed**
-
-- You have the general shape but not the specific
-- It's version-, environment-, or repo-specific and you haven't checked this one
-- You'd be inferring from a pattern, which is usually right but sometimes wrong
-
-```
-Examples (partial):
-- "The library probably has a `retry` option" — likely, unchecked
-- "This API usually returns ISO timestamps" — depends on the version here
-→ Fetch/read to confirm, OR answer with an explicit "I believe X, verify with Y."
-```
-
-### Zone 3: Ungrounded — abstain or ask
-**A confident answer here would be a fabrication**
-
-- You'd be inventing a specific value (signature, path, number, flag)
-- The domain is unfamiliar and the answer reconstructed from vague pattern
-- You can't point to any source for it
-
-```
-Examples (ungrounded):
-- Exact signature of an API you haven't seen in this codebase
-- A precise statistic with no source
-- "What does our internal service X do?" with no access to it
-→ Say so, ask, or fetch — do NOT confabulate.
-```
-
-## Telling the Zones Apart
-
-The honest test before a specific or high-stakes claim:
-
-| Question | Grounded | Partial | Ungrounded |
-|----------|---------|---------|-----------|
-| Can I point to where this answer comes from? | ✓ | sort of | ✗ |
-| Have I read/run the relevant thing this session? | ✓ | | ✗ |
-| Is it version-/repo-/config-specific and unconfirmed? | | ✓ | ✓ |
-| Am I filling a gap with the *most plausible-sounding* value? | | ✓ | ✓ |
-
-Watch for the confabulation tells:
-- An exact name, number, or path arrives with no memory of *where* it came from
-- The answer is suspiciously convenient and complete for something you never looked at
-- You're hedging the framing ("typically", "should be") around a claim the user will treat as fact
-- "I'm capable in general, so I can answer this specific" — capability is not grounding
-
-## What to Do in Each Zone
-
-### Grounded: answer directly
-```
-✓ Give the answer
-✓ Cite the source if it helps the user trust it
-✓ Don't hedge a verified fact into mush
-```
-
-### Partial: confirm, then answer
-```
-→ Cheap to check? FETCH first — read the file, run the command, grep the symbol
-→ Can't check right now? Answer with the uncertainty marked:
-  "I believe X — confirm against Y before relying on it."
-→ Never round a "probably" up to a flat assertion
-```
-
-### Ungrounded: abstain, ask, or fetch — never confabulate
-```
-Option A: Fetch
-- Get the grounding (read the code, search the docs, call the tool), then answer
-
-Option B: Ask
-- "I don't have access to X — can you share it / point me to it?"
-- A precise question beats a confident guess
-
-Option C: Abstain explicitly
-- "I don't know this reliably and can't verify it here."
-- State what *would* let you answer
-```
-
-## Common Traps
-
-### Trap 1: Competence creep
-Being grounded in one area doesn't transfer to the adjacent one:
-```
-Read service A's code → grounded on service A
-Does NOT mean grounded on service B, the infra, or the client
-Check the thing you're actually being asked about.
-```
-
-### Trap 2: Stale or version-specific recall
-General knowledge of a tool ≠ knowledge of *this* version/config:
-```
-"I know how this library usually works" — but the repo pins an old major version
-with a different API. Recall is partial here; verify against the installed version.
-```
-
-### Trap 3: Fluency misread as grounding
-A smooth, complete answer *feels* authoritative regardless of whether it's checked:
-```
-The trap: the more confidently a specific value comes out, the less it gets questioned
-The fix: before a specific claim, ask "where did this come from?" — if there's no source, it's ungrounded
-```
-
-### Trap 4: Capability-implies-knowledge
-Being a strong general reasoner does not mean you know this specific fact:
-```
-"I can reason about anything" → still can't know an unread file's contents,
-a private API's signature, or a number with no source. Capability is not grounding.
-```
-
-## Application Examples
-
-### Reporting an API or library detail
-```
-Question: "What are the arguments to this client's `query` method?"
-
-Self-assessment:
-- Have I read this client's source in the repo? No → Partial/Ungrounded
-- Am I about to reconstruct a plausible signature? Yes → confabulation risk
-
-Action: grep/read the actual definition, THEN answer. If unavailable,
-        say "I haven't seen this client's source — let me read it" rather than inventing args.
-```
-
-### Answering about this specific system
-```
-Question: "What does our internal billing service do on a failed charge?"
-
-Self-assessment:
-- Do I have access to that service's code/docs? No → Ungrounded
-- Can I infer a "typical" behavior? Yes, but it'd be a guess about a specific system
-
-Action: Abstain or ask: "I don't have that service's code here — can you point me to it,
-        or should I search the repo?" Do not describe behavior you haven't seen.
-```
-
-### Adopting an unfamiliar technology
-```
-Question: "Should we use GraphQL here?"
-
-Self-assessment:
-- Do I have grounded knowledge of GraphQL's general tradeoffs? Yes → can speak to them
-- Do I know THIS system's query patterns and constraints? Only what I've read → check
-
-Action: Give the well-grounded general tradeoffs; for the fit to *this* system,
-        verify the actual access patterns before recommending.
-```
-
-## Verification Checklist
-- [ ] Identified which zone the answer falls in (grounded / partial / ungrounded)
-- [ ] For specific claims: can point to where the answer comes from
-- [ ] If partial/ungrounded and cheap to check: fetched/read before asserting
-- [ ] If ungrounded and uncheckable: abstained or asked, did not confabulate
-- [ ] Marked any unverified claim as unverified, not as fact
-- [ ] Did not hedge a genuinely-grounded answer into needless mush
-
-## Key Questions
-- "Where does this specific answer come from — can I cite it?"
-- "Have I actually read/run the thing I'm about to describe?"
-- "Am I filling this gap with a checked value or the most plausible-sounding one?"
-- "Could I cheaply fetch the grounding instead of guessing?"
-- "If I'm wrong here, how would anyone find out — and how costly is it?"
-- "Is this version-/repo-/config-specific in a way I haven't confirmed?"
-
-## Buffett's Reminder
-"What counts is not how much they know, but rather how realistically they define what they don't know."
-
-The advantage isn't a bigger circle — it's refusing to answer outside it as if you were inside it. For an agent, the highest-value words are often "I don't know that reliably; let me check" — because a confident fabrication costs far more than an honest gap.

package/.claude/skills/thinking-cynefin/SKILL.md

@@ -1,70 +0,0 @@
----
-name: thinking-cynefin
-description: Use when unsure how to approach a problem—plan, analyze, experiment, or stabilize first. Classify it by cause-effect (clear/complicated/complex/chaotic) and match the approach to the domain.
----
-
-# Cynefin Framework
-
-## Overview
-
-Cynefin (Dave Snowden) classifies a problem by the relationship between cause and effect, then prescribes the matching approach. Using the wrong approach for the domain is the failure mode: detailed planning is useless in chaos, and experimentation is reckless when a best practice already exists.
-
-**Core Principle:** The nature of the problem determines the approach. Classify first, then act.
-
-## The Classifier
-
-| Cause–effect is… | Domain | Approach | Do this |
-|------------------|--------|----------|---------|
-| Obvious to anyone | **Clear** | Sense → Categorize → Respond | Apply the known best practice / runbook; don't over-engineer |
-| Knowable with expertise/analysis | **Complicated** | Sense → Analyze → Respond | Investigate, profile, design; multiple valid solutions exist |
-| Only visible in retrospect (emergent) | **Complex** | Probe → Sense → Respond | Run small safe-to-fail probes, amplify what works |
-| Not perceivable; turbulent | **Chaotic** | Act → Sense → Respond | Act now to stabilize (rollback/failover), understand later |
-| Unsure which domain | **Disorder** | Decompose | Split into parts and classify each part |
-
-```
-Can you see clear cause→effect?
-  obvious to everyone        → CLEAR
-  knowable with analysis     → COMPLICATED
-  only clear in hindsight    → COMPLEX
-  totally turbulent, no time → CHAOTIC
-  can't tell                 → DISORDER (decompose)
-```
-
-## When to Use
-
-- You're unsure whether to plan, analyze, experiment, or just act
-- An approach isn't working and you suspect it's mismatched to the problem
-- Triaging an incident (is this stabilize-first chaos, or analyzable?)
-
-## When NOT to Use
-
-- The domain is already obvious and the approach is uncontested → skip the ceremony and just do it.
-- You've already classified and now need to execute → switch to the domain's actual method (debugging, a hypothesis differential, experiment design); Cynefin only routes, it doesn't solve.
-- The question is "what is the cause," not "how should I approach this" → classification won't find the bug.
-
-## The Common Mismatches (the whole point)
-
-- **Complex treated as Complicated:** extensive planning, but outcomes keep surprising you. You can't analyze your way through emergence—probe instead.
-- **Complicated treated as Clear:** "just do it like Company X" without understanding why. Context matters; analyze the specific case.
-- **Chaotic treated as Complex:** running experiments during an active outage. Chaos needs immediate stability, not learning.
-- **Clear treated as Complicated:** over-engineering a trivial problem. Apply the best practice and move on.
-
-## Confidence Check
-
-Before committing, test the classification:
-- Clear? Do best practices reliably work here? If not → probably Complicated.
-- Complicated? Can analysis predict the outcome? If not → probably Complex.
-- Complex? Can you run a safe-to-fail probe? If it's too turbulent to probe → Chaotic.
-- Re-check as the situation evolves; domains shift (chaos stabilizes into complex/complicated).
-
-## Key Questions
-
-- "What's the relationship between cause and effect here?"
-- "Can experts reliably predict the outcome, or is it only clear in hindsight?"
-- "Is this actually complex, or am I avoiding the analysis?"
-- "Is this actually complicated, or am I over-planning a simple thing?"
-- "Has the situation moved to a different domain since I last looked?"
-
-## Snowden's Wisdom
-
-"Complex systems are dispositional, not causal—you can't predict what will happen, only influence what might." The failure is rarely the methodology itself; it's applying the wrong methodology to the wrong domain.