System Archetype Diagnosis¶
Essence¶
System Archetype Diagnosis turns recurring system trouble into a structural diagnosis. Instead of asking only who made a mistake or which local fix was insufficient, it asks what feedback pattern keeps regenerating the behavior. The archetype is useful when a problem repeats across time, departments, policies, markets, or communities and the visible symptoms do not explain why ordinary fixes fail.
The key move is not simply naming a famous pattern. The key move is to map the loops, compare the map to known archetype templates, test whether the match actually fits, and then use the diagnosis to choose intervention families.
Compression statement¶
When a complex problem repeats despite local fixes, map the feedback loops, compare the structure to known system archetypes, validate the fit, and use the diagnosis to identify leverage points and intervention families.
Canonical formula: recurring symptoms + causal loop map + fit evidence + counterexample check -> archetype match -> leverage-point-informed intervention choice
When to Use This Archetype¶
Use this archetype when a system repeatedly returns to the same kind of problem after local correction. Typical clues include short-term fixes followed by relapse, growth that stalls against a constraint, escalation between actors, shared-resource degradation, or repeated surprise that the same problem appears in new places.
It is especially appropriate when the team needs a shared explanation before choosing an intervention. A diagnosis such as limits to growth, shifting the burden, fixes that fail, escalation, or tragedy of the commons can make hidden feedback visible, but the label must be earned by evidence.
Structural Problem¶
The structural problem is that actors experience events, while the system behaves through loops. People see a backlog, a conflict, a shortage, or a failure. They respond to that symptom. Their response changes incentives, capacity, trust, delay, resource availability, or expectations. Those changes then feed back into the original symptom, sometimes after enough delay that the connection is missed.
Without archetype diagnosis, each recurrence is treated as new. The organization keeps solving the apparent problem while preserving the structure that regenerates it.
Intervention Logic¶
The intervention begins by collecting the recurring symptoms and the time horizon over which they repeat. Then it maps causal relations, feedback loops, delays, constraints, incentives, and actors. The map is compared against candidate system archetypes, and the diagnosis remains provisional until pattern-fit evidence is stronger than the alternatives.
After the pattern is named, the work shifts to intervention choice. A limits-to-growth diagnosis suggests looking for the binding constraint. A shifting-the-burden diagnosis suggests reducing dependency on symptomatic relief while strengthening the fundamental solution. A fixes-that-fail diagnosis suggests examining delayed side effects of the fix itself. The diagnosis is only useful if it changes where and how the system is acted upon.
Key Components¶
System Archetype Diagnosis converts recurring trouble into a structural explanation through a sequence that begins with evidence and ends with action, with explicit guardrails against premature labeling. The Symptom Pattern gathers the repeated observable signs — overload, relapse, oscillation, escalation, stalled growth, unintended consequences — that suggest a deeper feedback structure rather than a one-time failure. The Causal Loop Map bridges those events to structure by showing how variables influence one another and where effects return to shape their own causes, distinguishing reinforcing loops, balancing loops, delays, constraints, and incentives. The Feedback Loop Boundary decides what belongs inside the diagnostic frame; if it is too narrow the analysis collapses into local blame, and if it is too broad the model becomes too vague to act on. These three components establish the empirical base before any pattern name is invoked.
The middle three components turn the mapped structure into a tested diagnosis rather than a slogan. The Archetype Match compares the local structure to known templates — limits to growth, shifting the burden, fixes that fail, escalation, tragedy of the commons — and records both what fits and what does not. The Pattern-Fit Evidence explains why the selected archetype is credible, drawing on loop relations, time patterns, delayed effects, repeated responses, stakeholder observations, and anomalous cases. The Counterexample Check is the main internal guardrail against overmatching: it asks what evidence would make the proposed archetype wrong, compares alternative archetypes, and looks for missing variables or boundary errors that could overturn the diagnosis.
The final three components ensure the diagnosis becomes intervention rather than interpretation. The Leverage Point identifies where action could change the feedback pattern — a rule, delay, incentive, information flow, capacity constraint, ownership boundary, or resource allocation — because a named archetype without leverage is only commentary. The Intervention Playbook connects the diagnosed pattern to response families, narrowing the field of plausible actions without replacing local design. The Monitoring Signal checks whether the diagnosed pattern is actually changing after intervention; if the expected feedback response does not appear, the diagnosis itself should be revised rather than the action redoubled.
| Component | Description |
|---|---|
| Symptom Pattern ↗ | A symptom pattern gathers the repeated observable signs that suggest a deeper structure. It may include recurring overload, relapse, oscillation, escalation, stalled growth, or unintended consequences. The symptom pattern is evidence, not the diagnosis itself. |
| Causal Loop Map ↗ | A causal loop map shows how variables influence one another and where effects return to shape their own causes. It is the bridge between local events and structural explanation. A weak map merely lists events; a useful map reveals reinforcing loops, balancing loops, delays, constraints, and incentives. |
| Feedback Loop Boundary ↗ | The feedback loop boundary defines what belongs inside the diagnostic frame. If the boundary is too narrow, the diagnosis becomes blame of local actors. If it is too broad, the model becomes too vague to act on. Boundary choice determines which variables can explain recurrence. |
| Archetype Match ↗ | The archetype match compares the mapped structure to known system archetypes. It names the closest structural pattern only after the map, symptoms, delays, and outcomes fit. A match should also record what does not fit. |
| Pattern-Fit Evidence ↗ | Pattern-fit evidence explains why the selected archetype is credible. It can include loop relations, time patterns, delayed effects, repeated responses, stakeholder observations, and anomalous cases. This component prevents diagnosis from becoming slogan use. |
| Counterexample Check ↗ | The counterexample check asks what evidence would make the proposed archetype wrong. It compares alternative archetypes and looks for missing variables or boundary errors. This is the main internal guardrail against overmatching. |
| Leverage Point ↗ | A leverage point identifies where intervention could change the feedback pattern. It might be a rule, delay, incentive, information flow, capacity constraint, ownership boundary, or resource allocation. Diagnosis without leverage points is only interpretation. |
| Intervention Playbook ↗ | An intervention playbook connects the diagnosed pattern to response families. It does not replace local design; it narrows the field of plausible actions. The playbook remains a component here because the separate playbook candidate is still second-wave and merge-sensitive. |
| Monitoring Signal ↗ | A monitoring signal checks whether the diagnosed pattern is actually changing after intervention. If the expected feedback response does not appear, the diagnosis should be revised. |
Common Mechanisms¶
| Mechanism | Description |
|---|---|
| Causal Loop Diagram ↗ | A causal loop diagram is a mechanism for making feedback visible. It implements the archetype by giving people a shared representation they can inspect and challenge. The diagram is not the archetype; it is one way to support diagnosis. |
| System Archetype Template ↗ | A system archetype template provides a recurring pattern with typical symptoms, loops, and intervention hints. It helps compare a local map against known structures. The template should remain a guide, not a forced answer. |
| Pattern Diagnosis Workshop ↗ | A workshop gathers stakeholders to map symptoms, compare interpretations, and agree on a provisional diagnosis. It is useful when no single actor sees the whole loop. |
| Named Archetype Diagnoses ↗ | Limits-to-growth, shifting-the-burden, fixes-that-fail, tragedy-of-the-commons, escalation, and success-to-the-successful diagnoses are mechanism families under the parent pattern. They implement System Archetype Diagnosis by focusing attention on a particular feedback structure. |
| Leverage Point Matrix ↗ | A leverage point matrix translates the diagnosis into possible intervention sites. It helps teams avoid stopping at the label and asks which loop, delay, rule, incentive, or constraint should be changed. |
| Archetype Fit Checklist ↗ | A fit checklist prompts reviewers to test evidence, alternatives, boundary choices, and overmatching risk before using the diagnosis to guide action. |
Parameter / Tuning Dimensions¶
Important tuning dimensions include the diagnostic boundary, the time horizon, the granularity of variables, the required confidence threshold for naming an archetype, the number of alternative diagnoses preserved, and the level of evidence required before intervention.
Another major tuning dimension is action proximity. Some uses only create shared understanding. Stronger uses select interventions, redesign incentives, or change governance. The stronger the action, the more validation the diagnosis needs.
Invariants to Preserve¶
The diagnosis must preserve structural fit, causal traceability, stakeholder contestability, and intervention relevance. A named archetype should remain linked to observed behavior and loop evidence. Alternative explanations should not disappear just because one label is memorable.
The most important invariant is that the archetype name is not the solution. It is a map from recurring behavior to likely leverage points.
Target Outcomes¶
A successful diagnosis gives stakeholders a shared structural explanation of recurrence. It reduces blame-only narratives, exposes why symptom fixes fail, points toward leverage points, and makes intervention monitoring more meaningful.
The broader outcome is transferable learning. Once a team recognizes a recurring feedback trap in one domain, it can detect similar structures elsewhere without assuming the local details are identical.
Tradeoffs¶
The archetype trades speed of recognition against risk of overmatching. A familiar archetype can rapidly orient action, but it can also become a premature label. It trades abstraction against context: abstraction reveals transferable structure, while context preserves the local facts that make intervention safe.
It also trades shared language against premature consensus. A name helps people coordinate, but the same name can close debate too early if alternatives and counterexamples are not preserved.
Failure Modes¶
A common failure mode is archetype overmatching: a team chooses a familiar pattern because it sounds right. Another failure mode is diagnostic labeling without intervention, where the team names the trap but never identifies leverage points. A third is boundary blindness, where the map excludes the actors, delays, or incentives that actually explain recurrence.
Other risks include linearized loop maps, blame relabeling, stale archetype libraries, and recipe-following from intervention playbooks. Each risk can be reduced by requiring fit evidence, counterexample checks, stakeholder review, and post-intervention monitoring.
Neighbor Distinctions¶
System Archetype Diagnosis is distinct from Archetype Pattern Indexing. Indexing creates or retrieves a pattern library; diagnosis applies a pattern to a current recurring situation.
It is distinct from Reusable Pattern Application. Pattern application uses a known solution pattern; diagnosis first determines which feedback structure is creating the problem.
It is distinct from Archetype Overmatching Guardrail. The guardrail prevents false matching; diagnosis produces a tested match. This draft includes counterexample checks, but the parent function is still diagnosis.
It is distinct from Feedback Loop Redirection and Leverage Point Intervention. Those are downstream actions that may follow once the diagnosis identifies which structure to change.
Variants and Near Names¶
Important variants include Limits to Growth Diagnosis, Shifting the Burden Diagnosis, Fixes That Fail Diagnosis, Tragedy of the Commons Diagnosis, and Archetype-Based Intervention Playbook. The named archetypes are kept as variants or mechanisms because the batch roadmap explicitly warns not to draft individual system-dynamics diagrams as standalone archetypes.
Near names include Feedback Pattern Diagnosis, System Dynamics Archetype Diagnosis, Archetype Mapping, and Recurring Feedback Trap Diagnosis. These names should point back to this parent unless a future reconciliation pass finds a distinct intervention structure.
Cross-Domain Examples¶
In city transportation, repeated congestion relief through new road capacity can fail if added capacity induces more demand. In a service organization, emergency escalation can relieve visible backlog while delaying the capacity-building needed to prevent future backlog. In environmental governance, individually rational extraction can degrade a shared resource. In team coordination, defensive approval checks can reinforce distrust and slow work.
The common structure is not the domain. The common structure is a recurring feedback pattern that local fixes fail to change.
Non-Examples¶
A one-time installation error is not System Archetype Diagnosis unless it recurs through a feedback structure. A catalog of archetypes is not this archetype; that is pattern indexing. A causal diagram that documents a linear process is not this archetype. A consultant applying the same archetype label to every case without evidence is an overmatching failure, not a valid use.