Clear, Complicated, Complex, Chaotic: Using Cynefin to Decide How to Build
The most expensive architecture mistake I see isn't a bad technology choice. It's applying the wrong kind of process to a system — running a rigid, best-practice rollout on something genuinely unpredictable, or running loose experimentation on something that just needed a known, boring answer. Dave Snowden's Cynefin framework is the fastest tool I know for catching that mismatch before it costs you a quarter.
Cynefin sorts a system (or a decision, or a problem) into one of four domains based on the relationship between cause and effect — not by how hard it feels, but by whether cause and effect are knowable in advance at all.
(Snowden's original diagram arranges the domains differently — Complex sits opposite Clear, not beside it, because the point is that ordered systems can fall off a cliff into chaos with no warning. I've laid mine out as a simple grid for readability; don't lose that cliff-edge relationship when you use this in practice.)
Clear — best practice, known patterns
Cause and effect are obvious to anyone. You sense the situation, categorize it, and respond with the established best practice — there's genuinely one right answer and arguing about it wastes time. CRUD APIs, standard auth flows, a well-understood ETL job: sense → categorize → respond.
The failure mode here isn't technical, it's organizational: over-engineering a Clear problem because it's attached to an exciting project. If you're writing an ADR to justify a design for something this well-trodden, that's usually a sign the ADR is theater, not decision-making.
Complicated — expert analysis, good practice
Cause and effect are knowable, but not obvious — you need expertise or analysis to find the right answer, and there may be several good ones rather than one best one. Most distributed-systems design lives here: choosing a data-partitioning strategy, designing a multi-region failover topology, picking a consistency model for a given workload. sense → analyze → respond.
This is where most solution architects spend their careers, and it's the domain classic architecture practice — ADRs, trade-off matrices, expert review — was built for. The failure mode is treating Complicated as Complex: endlessly prototyping something an expert could have solved analytically in an afternoon.
Complex — probe, sense, respond
Cause and effect are only obvious in hindsight. You can't analyze your way to the right answer because the system's behavior emerges from the interaction of its parts — the only way to learn is to run safe-to-fail experiments and see what actually happens. probe → sense → respond.
This is where most LLM-based and agentic systems actually live, whether teams admit it or not. Retrieval quality, prompt behavior, multi-agent interaction, emergent failure modes under real user traffic — none of that is derivable from first principles the way a Complicated system's behavior is. It's why the evaluation harnesses I keep coming back to on this blog aren't a nice-to-have for AI systems; they're the probe half of the only response strategy that actually fits this domain. Treating a Complex AI system like a Complicated one — designing it exhaustively up front and expecting the design to hold — is the single most common architecture mistake I see in this space right now.
Chaotic — act, sense, respond
No discernible relationship between cause and effect at all, at least not on a timescale that helps you. There's no time to probe or analyze — you act first, to establish some kind of order, then sense what changed, then respond. act → sense → respond.
An active production incident is Chaotic almost by definition, and it's why incident response runbooks look nothing like architecture design docs — they're written for a domain where "do something reasonable right now" beats "find the optimal answer." The mistake here runs in both directions: treating a Chaotic incident like a Complicated problem (convening an analysis meeting while the system is down), or treating everyday Complex work like a permanent Chaotic emergency (an org that's always firefighting hasn't actually got a chaos problem — it's usually a Complex problem nobody built a probe-sense-respond process for).
Disorder — the domain nobody names correctly
The unlabeled space in the middle is where you are when you don't yet know which of the other four domains you're in. Most bad architecture decisions happen here, disguised as one of the other four: people default to whichever domain matches their favorite tool, then reason backward. Architects reach for Complicated-style analysis on Complex problems because analysis is the tool they're best at. Ask "what domain is this actually in" as an explicit first step, separate from "what should we do about it" — Cynefin's entire value is in refusing to let those collapse into the same question.
Why this belongs on an architecture blog
None of this replaces the frameworks I usually write about here — reference architectures, evaluation harnesses, LLMOps discipline. It's the layer above them: Cynefin is how you decide which of those tools actually applies to the system in front of you, before you've sunk a quarter into the wrong one.