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.”

Mechanisms / Implementations

  • Controlled Vocabulary
  • Customer Segmentation Model
  • 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
  • Eligibility Class System
  • Filing Code System
  • Severity or Triage Scale
  • 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.