Archetype Fit Checklist¶
Validation checklist — instantiates System Archetype Diagnosis
Tests a proposed system-archetype match against its evidence and its strongest rival before the label is allowed to guide action.
Archetype Fit Checklist does the opposite work from a diagnosis: it does not propose a pattern, it tries to break one. Given a proposed archetype match — from a named diagnosis or a workshop — the checklist treats it as a hypothesis to be falsified and asks two hard questions. First, is the pattern-fit evidence actually present: do the specific loops, timings, delays, and stakeholder observations the archetype predicts really appear in this case? Second, what is the strongest rival archetype, and what evidence distinguishes it from the proposed one? The label passes only if it beats its best competitor on the evidence. The distinguishing idea is that this mechanism is a guardrail, not a producer — its entire value is refusing to let a memorable, plausible-sounding pattern guide action until it has survived a genuine attempt to disprove it.
Example¶
A cloud-platform team has recurring cost overruns, and someone proposes the tidy explanation: it is a Tragedy of the Commons — every product team over-provisions the shared infrastructure because the bill is centralized. It sounds right, and the room is ready to build a chargeback scheme. The Archetype Fit Checklist runs before that. It demands the fit evidence: is spend actually driven by many teams each over-drawing a rival, shared pool? Pulling the numbers, the reviewer finds that ninety percent of the overrun comes from a single data-processing service whose cost scales with a workload that is itself growing — most teams' usage is flat. Then it forces the strongest rival: this looks far more like Limits to Growth, one engine hitting a pricing tier, than a commons. The evidence favors the rival, so the checklist withholds the "commons" label and sends the team back to re-diagnose — sparing them a chargeback scheme that would have solved a problem they did not have.
How it works¶
- Treat the proposed match as falsifiable. Take the candidate archetype as a claim to be tested, not a conclusion to be dressed up.
- Demand the predicted evidence. List what the archetype specifically predicts — particular loops, delays, timing, and observations — and check each against the case.
- Name and pit the strongest rival. Identify the most credible alternative archetype and ask what evidence would separate it from the proposed one; require a genuine rival, not a straw one.
- Pass, hold, or fail. Endorse the label only if it beats its best competitor on evidence; otherwise return it for re-diagnosis or more data.
Tuning parameters¶
- Evidence bar — how much fit evidence is required to pass. A high bar blocks overmatching but risks paralysis; a low one waves plausible labels through.
- Rivals considered — how many alternative archetypes are pitted against the proposal. More rivals catch more false matches but cost time.
- Boundary scrutiny — how hard the checklist probes whether the frame was drawn to make the pattern fit. Loose scrutiny lets boundary-gerrymandering pass.
- Pass / hold / fail thresholds — where the lines sit between endorsing, sending back for evidence, and rejecting. Their placement sets the whole guardrail's strictness.
When it helps, and when it misleads¶
Its strength is that it is the primary defense against archetype overmatching — the failure where a team adopts a familiar pattern because it sounds right and stops looking.[1] By forcing an explicit rival and demanding predicted evidence, it converts an appealing story into a tested claim, and its "hold" verdict legitimizes the honest answer of "not yet."
Its failure mode is that a checklist can be gamed: a determined advocate rationalizes each item to "pass" and pits the proposal against a deliberately weak rival. Set the other way — the bar impossibly high, every rival fatal — it becomes analysis paralysis that never lets any diagnosis proceed. The classic misuse is reading a passed checklist as proof the diagnosis is correct, when all it certifies is "not yet falsified, and better than the best rival tried." The guarding discipline is to require a genuine strongest rival and real predicted evidence, and to treat a pass as a license to act provisionally, not a guarantee.
How it implements the components¶
pattern_fit_evidence— assembles and audits the concrete evidence that the proposed archetype predicts — loops, timings, delayed effects, stakeholder observations — as the basis for endorsement.counterexample_check— names the strongest rival archetype and the evidence that would falsify the proposal, the internal guardrail against overmatching.
It never proposes the match it evaluates — archetype_match is produced by the named diagnoses and System Archetype Template; the checklist only tries to break a match already on the table. It also does not gather the raw symptom_pattern or draw the causal_loop_map (those are the named diagnoses' and Pattern Diagnosis Workshop's), nor turn an endorsed diagnosis into ranked interventions (leverage_point, intervention_playbook — Leverage Point Matrix).
Related¶
- Instantiates: System Archetype Diagnosis — supplies the falsification gate that keeps a match honest before it guides action.
- Consumes: a proposed
archetype_matchfrom a named diagnosis such as Shifting the Burden Diagnosis or Tragedy of the Commons Diagnosis. - Sibling mechanisms: Escalation Archetype Mapping · Fixes That Fail Diagnosis · Limits to Growth Diagnosis · Shifting the Burden Diagnosis · Tragedy of the Commons Diagnosis · System Archetype Template · Pattern Diagnosis Workshop · Leverage Point Matrix · Causal Loop Diagram
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Tests a proposed system-archetype match against its evidence and its strongest rival before the label is allowed to guide action, making its operative form a bounded evaluation of existing evidence or work that produces a finding or disposition.
Independent corroboration: The frozen evidence defines Archetype Fit Checklist as 'Tests a proposed system-archetype match against its evidence and its strongest rival before the label is allowed to guide action', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Systems Thinking & Cybernetics
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Universal
Rationale: System-dynamics archetype practice supplies loop- and delay-based diagnosis whose fit must be tested against observed structure.
Related originating lineages:
- Engineering & Design — Validation checklists require discriminating evidence before action.
- Organizational & Management Science — Diagnostic checklists operationalize the review.
- Philosophy — Falsification and rival-hypothesis comparison supply the evidential guardrail.
- Psychology — The law of the instrument explains overmatching to familiar patterns.
Review resolution: Systems thinking supplies the archetype-diagnosis object. Engineering validation, organizational-learning practice, philosophical falsification, and psychological debiasing each materially shape the strongest-rival gate. Its application can span domains even though its origins remain this bounded set.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
References¶
[1] The law of the instrument, expressed by Abraham Maslow in The Psychology of Science (1966) — "if the only tool you have is a hammer, it is tempting to treat everything as if it were a nail" — names the bias behind archetype overmatching: a familiar pattern in hand makes every new situation look like an instance of it. The checklist's explicit-rival requirement is the corrective. registry ↩