Taxonomy Without a Decision Procedure (Pattern Catalog vs. Pattern Language)

A recurring critique of named-category taxonomies (design-pattern catalogs, skill taxonomies, business-model catalogs) that supply a name plus one-line intent plus example per category but no criteria — forces, trade-offs, applicability conditions — for choosing among overlapping options; contrasted with a true "pattern language" (Alexander/GoF) that resolves forces into a choice.

Also known as: pattern catalog, pattern language, selection criteria, when to pick which, decision procedure, connective tissue (GoF/Alexander), forces and trade-offs

Documents (1)

• Service Models in the Public Sector — Supporting Information Kuno Schedler and Ali Asker Guenduez (Yearbook of Swiss Administrative Sciences) · 2024-12-31 Reader 🖥️
  Forty-five named patterns for organizing and delivering public services — most adapted from Gassmann et al.'s private-sector Business Model Navigator, some invented specifically for government — are each already in documented use by real governments worldwide, demonstrating that public-sector service delivery can be systematically redesigned using a catalogable set of reusable organizing templates rather than treated as a series of one-off administrative choices.

Propositions touching this concept (1)

By publication month, oldest first (extraction month when no publication date is known).

2026-07

• explicitA proposed new standing rule should be tested by asking whether a reasonably competent orchestrator would make the right decision once it knew the one missing fact; if yes, the rule should just state that fact, and a fix that instead specifies a decision procedure (approvals, checkpoints, mandatory steps) is usually a sign of encoding process where a small clarification would have sufficed.
  The Orchestrator's Tax · p11

Open gaps (10)

• incompleteNo decision procedure. Twenty patterns, zero guidance on when to pick which. Each pattern carries only a 'Used for: [domains]' tag (naming application areas, not selection criteria, forces, or trade-offs). This is a pattern CATALOG, not a pattern LANGUAGE -- it has none of the GoF/Alexander connective tissue (Intent, Applicability, Consequences, forces that resolve into a choice). For a reader whose bar is 'a taxonomy without when-to-use-which is half a pattern language', this is the central omission.
  20 Loop Design Patterns Every AI Engineer Should Know — read next: Read against a real pattern-structure: Anthropic's harness paper (extract-anthropic-harness-design-long-running-application-development#p8) ties evaluator use to a concrete condition -- worth its cost only when the task sits beyond what the model does reliably solo -- exactly the selection criterion this thread lacks. Also extract-ai-workflow-patterns-real-unit-of-adoption-2026 (guidance on which workflows to automate first / how patterns chain).
• incompleteNo context is given on team size, function (e.g. engineering vs. sales), growth stage, or remote/hybrid setup; the specific cadences and durations (30 min weekly, 45-60 min monthly 1:1s, quarterly 2-3hr sessions) are presented as universal defaults with no acknowledgment that they'd need adaptation for, say, a large distributed engineering org.
  Amy Gibson's Post — read next: Compare against context-sensitive team-design frameworks (e.g. your own pattern language on cross-disciplinary team spaces) that make cadence and structure conditional on team size, distribution, and work type rather than fixed.
• unstated assumptionThe author assumes that the inability to externalize institutional knowledge and design context is a fundamental limitation of AI, not merely a tooling limitation. This conflates current AI capabilities with inherent constraints. Future models with persistent memory, codebase-scale context, and temporal reasoning could potentially bridge this gap.
  Eight years of wanting, three months of building with AI — read next: Read work on long-context models, AI memory architectures, and research on whether design taste can be formalized or learned (e.g., Christopher Alexander's pattern language as a possible bridge).
• incompleteThe 'hidden cost of yes' claim names the phenomenon but gives no method for actually estimating that hidden cost before committing, i.e., no decision procedure — only the observation that the cost exists.
  Brain Food: Two Types of Talent — read next: Greg McKeown's 'Essentialism' (notably advertised in the same email) and Cal Newport's writing on deep work and attention scarcity both supply the operational frameworks this aphorism gestures at but doesn't provide.
• incompletePair rotations are treated as the mechanism for collective ownership, but the article admits opinions diverge on frequency and concedes costs (context switch, lost tacit knowledge). It does not give a decision procedure, so 'pair + rotate' as a substitute for PR-mediated cross-team review remains under-specified.
  On Pair Programming — read next: Mob programming literature (Llewellyn Falco, Woody Zuill); engineering org studies on knowledge silo formation.
• incompleteThe 45 service models are presented as a flat, unordered catalog — each with only a name, a one-sentence 'operating principle', and two examples — with no criteria (forces, trade-offs, applicability conditions, or a decision procedure) for choosing among models when several plausibly apply to the same problem (e.g. is a city building shared infrastructure better served by 'Orchestrator', 'Fractional Ownership', or 'Government as a Platform'?). This is a pattern CATALOG rather than a pattern LANGUAGE in the Alexander/Gang-of-Four sense — it lacks the connective tissue (Intent, Applicability, Consequences, forces resolved into a choice) that would make it genuinely actionable rather than merely descriptive.
  Service Models in the Public Sector — Supporting Information — read next: This is the same 'taxonomy without a decision procedure' gap already flagged twice elsewhere in this corpus — in a 20-pattern AI agentic-loop catalog (extract-20-loop-design-patterns#g1) and in a 9-category agent-skills taxonomy (extract-claude-code-how-we-use-skills#g2) — suggesting it is a structural failure mode of catalog-style research generally, not specific to this domain. The main Schedler & Guenduez paper (not included in this SI) reportedly identifies five governmental roles — Activator, Yield Shaper, Funder, Guardian of Public Goods, Performance Designer — which might supply exactly this selection logic and would be the natural next read.
• incompleteNone of the 90 examples documents a failed, reversed, or politically contested adoption of a service model — every case is presented as an apparent success. The catalog is silent on when these private-sector-derived mechanisms produce legitimacy costs, equity problems, or accountability gaps specific to government (e.g. an 'Auction' or 'Pay what you want' logic applied to a core public good could conflict with universal-access norms), so a practitioner reading this SI alone has no way to anticipate failure modes before choosing a model.
  Service Models in the Public Sector — Supporting Information — read next: New Public Management critique literature on the marketization of public services and quasi-market legitimacy costs (e.g. work building on Christopher Hood's NPM analysis), or empirical follow-up studies tracking which of these 45 models were later abandoned or reversed.
• uninformedThe SI never explicitly distinguishes which of the 45 public-sector models are direct imports from the 55-item private-sector Business Model Navigator (reproduced verbatim in Table A) versus which are genuinely public-sector-native categories with no private-sector counterpart (e.g. 'Contracting Out', 'Sanctions', 'Registrar', 'Regulator', 'Guarantees', 'Seed Money', 'Voucher', 'Waiver', 'Concession', 'Permits', 'Taxpayers' money'). Roughly a third of the 45 look novel to this study rather than adapted, but the document leaves readers to infer the split themselves rather than stating it.
  Service Models in the Public Sector — Supporting Information — read next: The main paper's methodology section likely makes this provenance explicit — worth reading directly (Schedler & Guenduez, 'Service Models in the Public Sector,' Yearbook of Swiss Administrative Sciences, 2024) rather than inferring it from the SI's raw list.
• incompleteAll 39 codebases come exclusively from CodeScene's own customer base, and the paper cannot disclose selection criteria or codebase identities for confidentiality reasons. Companies that already pay for a code-quality tool are plausibly a non-random, quality-aware sample, which the paper notes as an external-validity threat but does not attempt to bound.
  Code Red: The Business Impact of Code Quality -- A Quantitative Study of 39 Proprietary Production Codebases — read next: Look for an independent replication using a non-CodeScene-customer dataset or a different code-health/quality metric to check whether the 15x/124%/9x figures hold outside CodeScene's own customer base.
• incompleteThe article's own central provocative question — 'how much data is too much data' — is posed rhetorically and never answered; no threshold, framework, or decision procedure is offered for organizations trying to operationalize 'minimization' in practice.
  What Happens After Every Company Becomes a Data Company? — read next: Data-minimization-by-design frameworks (e.g. NIST privacy engineering, GDPR Art. 5 guidance) that attempt to convert the principle into an auditable practice.