Skip to content

Pattern Fit Checklist

Diagnostic checklist — instantiates Archetype Overmatching Guardrail

Lists the structural features a named archetype requires and checks the case against them one by one, so a match must clear a fixed bar rather than a feeling of familiarity.

Pattern Fit Checklist pins a proposed match to a fixed, archetype-specific list of the necessary structural features the pattern demands, then walks the case feature by feature — present, absent, or unknown. Its defining move is that the required features are committed before the case is examined, and any missing necessary feature is disqualifying no matter how many others match. It is a binary gate, not a score: passing means "not disqualified," not "confirmed." That single property is what stops a lazy "this is just like X" from carrying a decision on the strength of one salient resemblance.

Example

A platform team proposes breaking the monolith apart: "this is clearly a microservices situation." Before funding it, an architect opens the microservices-fit checklist — the necessary features the pattern actually requires: components that need independent deployment, distinct scaling profiles, service boundaries that line up with team boundaries, tolerance for network latency and partial failure between components, and data that can be partitioned without cross-service transactions. Going down the list, three of the six required features come back absent: the teams share one release train and the data is heavily relational with cross-cutting transactions. The checklist does not weigh or total anything — it simply shows the necessary features are not present, so the "microservices" label fails its gate. The conversation moves to a modular monolith instead, and it does so on a pre-committed bar rather than on who argued hardest.

How it works

The required features are fixed in advance as necessary conditions for the named archetype. Each is marked present / absent / unknown against the case, and a single missing necessary feature disqualifies the match outright — the list is a conjunction, not a tally. This is what separates it from counting resemblances: ten superficial matches do not rescue a case that lacks one load-bearing structural feature.

Tuning parameters

  • Feature strictness (necessary vs. nice-to-have) — which items are hard gates and which are merely favourable. More hard gates cut false matches but reject more borderline-genuine cases.
  • Granularity — a few coarse items or many fine ones. Finer lists catch subtle mismatches but cost time and can nitpick a real fit to death.
  • Unknown handling — treat "unknown" as fail, as pass, or as "must investigate." The conservative default surfaces evidence gaps instead of hiding them.
  • Scope — one checklist for a single candidate, versus one per competing pattern; when several archetypes contend, that comparison belongs to a sibling.

When it helps, and when it misleads

It is strongest when the archetype has crisp, agreed necessary features and the risk is a reflexive match — a checklist converts expert judgement into a reliable floor that a tired or hurried reviewer still clears.[1] It misleads when the pattern's real features are fuzzy or context-dependent, where a rigid list either rubber-stamps or over-rejects; and it is easily run backwards — writing (or quietly editing) the checklist to fit the case you already favour. The disciplines that guard against this are to fix the checklist before seeing the case, and to keep the necessary features few and independently defensible.

How it implements the components

  • proposed_archetype — the checklist is built around one named candidate; using it is stating the claim on the table, "this case is an instance of X, whose required features are these."
  • structural_fit_check — the item-by-item present/absent pass over the archetype's necessary features is the structural fit test itself, run as a hard gate.

It does NOT grade partial fit or weight features — that's Pattern Fit Scoring Rubric; it does not weigh the case against rival archetypes — that's Differential Pattern Review; and it does not attach a confidence label to the decision — that's Decision Confidence Label.

  • Instantiates: Archetype Overmatching Guardrail — the checklist is the fastest gate the guardrail offers: does the case even have the pattern's required features?
  • Sibling mechanisms: Pattern Fit Scoring Rubric · Differential Pattern Review · Case Comparison Matrix · Anti-Pattern Review · Counterexample Search Session · Precedent Distinction Memo · Red-Team Pattern Match Review · Review Queue · Decision Confidence Label

Editorial Notes

Form Classification

Form family: Assessment, Review & Assurance

Rationale: Pattern Fit Checklist operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it lists the structural features a named archetype requires and checks the case against them one by one, so a match must clear a fixed bar rather than a feeling of familiarity.

Independent corroboration: The frozen evidence defines Pattern Fit Checklist as 'Lists the structural features a named archetype requires and checks the case against them one by one, so a match must clear a fixed bar rather than a feeling of familiarity', 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: Multi-domain

Rationale: The checklist operationalizes diagnosis against named system-archetype features.

Related originating lineages:

  • Education & Pedagogy — Criterion-referenced checklists supplied the explicit feature-by-feature assessment form.
  • Organizational & Management Science — Organizational and management science materially shaped Pattern Fit Checklist through coordination, organizational learning, performance, and change practice.
  • Psychology — Pattern Fit Checklist is rooted in psychology and behavioral science: A fixed feature checklist counters recognition bias and unstructured expert matching.

Review resolution: Light authoritative-source research resolves the primary-origin disagreement in favor of systems thinking and cybernetics. MIT: The System Archetypes directly documents the defining practice or theory described in the selected origin rationale. Other listed domains are retained only where the blind reviews identify material co-development or translation; broader adoption remains separate as domain_reach=multi_domain.

Attribution caveat: The guardrail is an encyclopedia-specific operationalization rather than a canonical named systems method.

Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.

Review outcome: Researched adjudication after independent review; high confidence.

Sources consulted:

Notes

The checklist encodes necessary, not sufficient, conditions: clearing every item means the case is not disqualified, not that the match is proven. Confirmation — and the question of whether some other archetype fits even better — is the job of the scoring, comparison, and differential siblings that consume this gate's result.

References

[1] The idea that a fixed checklist turns expert judgement into a dependable floor under time pressure and fatigue is the thesis of Atul Gawande's The Checklist Manifesto (2009); here the "floor" is a match that must clear pre-committed structural requirements. registry