The Fundamental Split
Before diving into the four domains, you need to understand the axis they sit on. Cynefin divides the world into two halves: Ordered systems and Unordered systems. This distinction is the foundation everything else builds on.
Ordered systems have a stable, knowable relationship between cause and effect. If you push a button, the same thing happens every time. A load balancer with a round-robin algorithm distributes requests predictably. A cron job that runs pg_dump at 02:00 UTC produces a backup at 02:00 UTC. You can take these systems apart, study the pieces, put them back together, and they still work the same way. They are decomposable — understanding the parts gives you understanding of the whole.
Unordered systems do not have a stable cause-and-effect relationship that you can determine in advance. The behavior of the system emerges from the interactions of its components, and those interactions change based on context, timing, and history. A distributed system under load is unordered: the same request can succeed or fail depending on which pod handles it, what the current retry storm looks like, and whether a garbage collection pause happens at the wrong millisecond. A team's morale is unordered: the same management action (say, introducing on-call rotations) might energize one team and demoralize another. You cannot understand these systems by studying their parts in isolation because the interesting behavior lives in the relationships between parts.
This distinction matters operationally because it determines your fundamental approach:
| Aspect | Ordered | Unordered |
|---|---|---|
| Cause and effect | Knowable in advance | Only visible in hindsight (or not at all) |
| Approach | Analyze, then act | Experiment, then observe |
| Documentation | Runbooks, SOPs | Heuristics, observability dashboards |
| Expertise | Domain specialists | Cross-functional collaboration |
| Repeatability | High — same input, same output | Low — context-dependent |
Key Point: Most production systems are a mix of ordered and unordered components. Your Kubernetes control plane is ordered (the API server processes requests deterministically). Your microservices mesh under real user traffic is unordered (emergent behavior from thousands of concurrent interactions). Senior engineers develop the instinct to identify which part of the system they are dealing with and switch strategies accordingly. Treating an unordered component as ordered — by writing a runbook that assumes deterministic behavior — is a common source of failed incident responses.