Skip to content

Canonical Classification

Create stable membership classes so entities can be compared, governed, routed, interpreted, or processed consistently.

The Diagnostic Story

Symptom: The same kind of case keeps arriving, and every time it does, someone has to re-argue what it is before anything can happen. Reports contradict each other because two teams counted different things under the same label. Items get rerouted, refiled, or reclassified downstream — not because the facts changed, but because no one ever agreed on what category the facts belong to. High-stakes decisions produce unexplained disparities that nobody can audit because the categories were never stable.

Pivot: Name the categories explicitly — not just with labels, but with membership criteria: what makes something belong here and not there, how edge cases are handled, and what handling follows from each class assignment. The classification scheme becomes a shared contract rather than a local custom.

Resolution: The same case receives the same treatment whoever handles it and whenever it arrives. Comparisons across periods, teams, or sites become meaningful because the classes are now consistent. Disputes shift from what is this to is the scheme right — a governable and auditable question instead of a recurring improvisation.

Reach for this when you hear…

[clinical coding] “Every coder is picking a different code for the same presentation — we don't have a training problem, we have a criteria problem.”

[data platform] “Finance says active users are 200k and product says 340k and they're both pulling from the same database — that's a definition problem, not a number problem.”

[regulatory compliance] “If a case falls in a gray zone, we get a different answer depending on which reviewer picks it up — we need written criteria before we touch another one.”

When This Archetype Applies

Partial catalog groundingSome structural conditions are represented by existing abstractions, but no sufficient condition set is fully represented.

Entities are treated inconsistently because there is no stable classification scheme, no explicit membership rule, or no agreed connection between class assignment and downstream handling.

What this problem means

The structural problem is inconsistent treatment caused by unstable membership. The system has entities, cases, records, people, events, problems, or artifacts that need to be grouped, but the grouping rules are unclear. Different actors use different names, classify the same case differently, or attach different consequences to the same label.

This produces repeated debates, misrouting, incomparable data, hidden unfairness, and ad hoc exceptions. The deeper tension is that stable categories help systems act at scale, while real cases are messy and any boundary can oversimplify important differences.

Show the applicability expression

Applicability expression4 distinct conditions

Inconsistent entity categoriesandIncomparable local categoriesandDisputed boundary casesandUndefined membership criteria
Algebraic1234

groundedpartly groundedopen

4 conditions, all required.

4Required in every casenumbered 1–4

These hold no matter which pattern applies.

1

Inconsistent entity categories · grounded

Different actors assign the same entity to different categories.

2

Incomparable local categories · grounded

Reports, records, or metrics are incomparable because categories are locally defined or unstable.

3

Disputed boundary cases · grounded · any one of 2

Boundary cases repeatedly produce disputes, exceptions, or manual reassignment.

4

Undefined membership criteria · 2 cases · 0 matched

Category names exist without explicit membership criteria or downstream consequences.

Other requirements and context (1)

Why these sit outside the expression

Application gateit governs whether applying the archetype is appropriate or material, rather than defining the structural problem itself.

  • Application gateA repeated decision depends on what kind of case, person, item, record, problem, or event is being handled.

3 of 4 conditions grounded · 1 open.

Read the methodologyDownload the trigger-logic data

Mechanisms / Implementations

  • Controlled Vocabulary: Governs a shared term list under an authority so each sign form maps to one authorized sense, with variant and legacy terms crosswalked to the preferred form.
  • Customer Segmentation Model: Partitions the demand side into explicit, bounded segments and reads how much complete value each one actually needs, so entry is a chosen slice rather than an undifferentiated claim on the whole market.
  • Data Schema: Fixes the shared structure, field names, types, and units of exchanged data so information passes between systems without custom per-pair mapping.
  • Diagnostic Category System: Sorts observed cases into named condition or fault types to steer interpretation, tagging each assignment with an explicit confidence and keeping ambiguous cases provisionally open for reclassification.
  • Eligibility Class System: Sorts applicants into qualification classes by testing evidence against stated criteria, with a contestable appeal path and explicit rules for what happens when a case's facts or the criteria themselves change.
  • Filing Code System: Assigns each record a stable code drawn from a governed code map and held in one authoritative register, so items can be filed, found, and reported consistently across offices and years.
  • Severity or Triage Scale: Ranks cases into ordered urgency or severity levels so that everything in a level gets the same response intensity, with the level thresholds audited against how cases actually turn out.
  • Taxonomy

Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.

Built directly on (3)

Also references 4 related abstractions

Variants

Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.

Eligibility Classification · domain variant · recognized

Classify entities into eligibility groups so a service, benefit, role, permission, or process can be applied consistently.

Diagnostic Classification · domain variant · recognized

Classify observations into diagnostic categories so interpretation and next action become consistent.

Severity or Risk Classification · risk or failure variant · recognized

Classify cases by severity, criticality, or risk band so handling intensity and oversight become consistent.

Hierarchical Classification · subtype · recognized

Organize canonical classes into nested levels so broad classes and specific sub-classes remain connected.

Membership Boundary Refinement · subtype · merge review

Refine existing membership criteria when category boundaries create harmful inclusion, exclusion, ambiguity, or edge-case failure.

Editorial Notes

Problem Classification

Classification: Representation, Classification & Model MisfitCategory Boundary, Segmentation & Cluster Fit

Problem kernel: entities lack stable and explicit membership rules

Rationale: Inconsistent classification follows because class boundaries and their connection to downstream treatment are not defined.

Independent corroboration: The earliest necessary condition in the frozen evidence is: Entities are treated inconsistently because there is no stable classification scheme, no explicit membership rule, or no agreed connection between class assignment and downstream handling. That is a category boundary segmentation and cluster fit problem because Discrete classes, cutpoints, prototypes, or discovered clusters impose unstable or misleading membership on heterogeneous and continuous cases.

Review outcome: Independent reviewer agreement; high confidence.