From systems-analysis
Use when designing, evaluating, or diagnosing control and regulation systems — especially when asking "why can't we control this?", "why does this regulator fail?", "is our defense sufficient?", or when facing a system too large to regulate by brute force. Triggers on regulation failure, alert fatigue, oscillating controllers, defense ceilings, scaling limits, "we keep adding rules/alerts but it's not working", whack-a-mole against adaptive adversaries, reactive controls hitting a ceiling.
How this skill is triggered — by the user, by Claude, or both
Slash command
/systems-analysis:requisite-varietyThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Three principles for regulation and control. Sources: Ashby (1956), Conant & Ashby (1970).
Three principles for regulation and control. Sources: Ashby (1956), Conant & Ashby (1970).
Not every regulation question needs a full variety audit. If D, R, and E are obvious and the variety gap (or absence of one) is clear in a sentence — state it and move on. Ashby's Law holds whether you spend five seconds or five minutes applying it. Scale the analysis to the cost of the regulation failing.
| Principle | Statement | Diagnostic question |
|---|---|---|
| Requisite Variety | Only variety can absorb variety. A regulator needs at least as much response variety as the disturbance variety it faces. | Does R have enough distinct responses to match D's distinct disturbances? |
| Good Regulator | Every good regulator must be a model of the system it regulates. Variety without structure is brute force. | Does the regulator contain a model of the system — or is it pattern-matching without representation? |
| Constraints | When the system is too large for brute-force regulation, discovering structure (constraints) in the disturbances is the regulator's only path. | Can you find constraints that reduce D's effective variety below R's capacity? |
Apply in order: first check variety (capacity), then check model (structure), then look for constraints (tractability). At each step, note what you're least confident about — that's where the analysis is weakest and where you should warn the human.
A feedback regulator is inherently imperfect: the more successfully it holds E constant, the more it blocks the channel carrying its own information. Error-controlled regulators (thermostats, auto-scalers, reactive defenses) can reduce variety but never eliminate it. For tighter regulation, shift to anticipatory: get information about D before it reaches E.
A good regulator blocks the flow of variety from D to E. Test: can you tell from E what disturbances occurred? If yes, regulation is failing.
Prefer executable verification. If you can count D's states, enumerate R's responses, or measure E's variance, do that rather than reasoning about it. A computed variety gap is more convincing than an argued one.
A team has 200+ custom WAF rules but keeps getting breached. The SOC wants more rules.
Name the parts: D = adversary's attack variety (open, adaptive). R = WAF rule set (fixed between updates). T = web application. E = application integrity. η = no unauthorized access.
Requisite Variety: D is adversarially adaptive — it expands in response to R. R grows only through manual rule authorship after breaches. R can never catch D. This is a structural losing position, not a resourcing problem.
Good Regulator: The WAF's model of the adversary is "attacks look like past attacks." A capable adversary's next move is specifically designed to not look like past attacks. The model is wrong.
Constraints: The WAF constrains at the syntactic level (payload patterns). Attacks operate at the semantic level (what the application does). Syntactic constraints on a semantic adversary are leaky by construction. R needs to operate at the same level as D — behavioral analysis, runtime application self-protection.
| Thought | Reality |
|---|---|
| "More rules" | Adaptive D outruns enumerated R. Find constraints. |
| "Covers everything" | Coverage ≠ model. What does R model? |
| "Tune until stable" | Error-controlled R is inherently imperfect. May need anticipatory. |
| "Too complex to model" | Then too complex to regulate. Find constraints first. |
| "More data helps" | Only if R can act on it. Variety bounds what R can do. |
| "We need more rules" | Do rules can keep up? If D is adaptive, enumeration loses. |
npx claudepluginhub jackwillis/claude-plugins --plugin systems-analysisUses feedback loop analysis to diagnose why a system grows uncontrollably, oscillates, or resists change. Identifies dominant loops and delays.
Routes to the appropriate systems thinking tool based on your situation. Use for diagnosing system behaviors, feedback loops, and leverage points.
Maps feedback loops, identifies system archetypes, and ranks interventions by Meadows' leverage hierarchy for complex problems with interconnected components.