Category Split/Merge Review¶
Decision procedure — instantiates Schema Update Protocol
Adjudicates a single overloaded-or-redundant category question — split, merge, or keep — and enacts the chosen change on that node alone.
A Category Split/Merge Review is a bounded decision procedure aimed at one node: this category is either doing too much (candidate to split) or two categories are doing the same thing (candidates to merge), and the review decides which — split, merge, redefine the boundary, or leave it alone. Its defining feature is narrowness. It does not re-lay a hierarchy, restructure relations, or migrate a corpus; it takes a specific split/merge question that some evidence has raised and renders a verdict, then enacts that verdict on the affected node. The discipline it adds is a threshold: a category should only split if the sub-distinctions are used differently downstream, and two should only merge if nobody actually acts on the difference. Absent that test, every review drifts toward splitting (more categories always look more "accurate") and the schema fragments.
Example¶
An online marketplace's catalog team faces a swollen Home & Kitchen category that now holds 90,000 listings and returns hopeless search results. A Category Split/Merge Review convenes on exactly this question. They pull the evidence: buyers refine within Home & Kitchen using filters the schema does not carry (cookware vs. small appliances vs. storage), and sellers already stuff those distinctions into free-text titles. The review tests the split against its threshold — would separate subcategories change what buyers filter on and what the recommender surfaces? Yes, clearly. So they decide to split Home & Kitchen into three children and enact it: they define each child's boundary, write the inclusion rule, and — crucially — open an edge-case registry for the listings that genuinely straddle two children (a kettle that is also cookware) so those do not silently force a fourth split next quarter. They also examine, and reject, a proposed merge of Garden into Outdoor, because sellers price and ship those differently. The review touches three nodes and stops; the rest of the catalog is untouched.
How it works¶
The review is a comparison of two competing structures under one test, not an open redesign:
- Frame one question. Name the exact node(s) in play and whether the motion is split, merge, or redefine — never "improve the category system."
- Apply the use-difference threshold. Split only if the finer distinctions drive different downstream action (routing, search, pricing, reporting); merge only if the existing distinction drives none.
- Enact on the node, minimally. Write the new boundary rule for each resulting category and reassign only the directly affected items.
- Park the straddlers. Items that fit neither child cleanly go into an edge-case registry rather than spawning new categories on the spot.
Tuning parameters¶
- Split threshold height — how much downstream use-difference is required to justify a split; raise it to resist fragmentation, lower it to chase accuracy.
- Merge tolerance — how rarely a distinction must be used before two categories collapse into one; loose tolerance simplifies but can erase a rare-but-real difference.
- Blast radius cap — how many nodes a single review may touch; a hard cap of one-to-three keeps it a review rather than a restructure.
- Registry-vs-category rule — the standing policy for when a straddling pattern is logged as an edge case versus promoted to its own category.
When it helps, and when it misleads¶
Its strength is focus: by deciding one node against an explicit threshold, it produces defensible, reversible changes and resists the schema's natural drift toward ever-finer buckets. The tension it manages is the old one between lumpers and splitters — those who prefer few broad categories and those who prefer many narrow ones — and the use-difference threshold is what keeps that temperament from deciding the schema.[n1]
Its failure mode is over-fragmentation: every review that lacks a real threshold splits, because a new subcategory always feels like added precision, and after a year the catalog has 300 leaf categories no user can navigate. The classic misuse is treating a pile of straddling edge cases as proof that more splitting is needed, when it is usually proof the boundary is drawn on the wrong axis entirely. The guarding discipline is to require that a proposed split name the specific downstream consumer whose behavior changes, and to route ambiguous straddlers into the edge-case registry to accumulate — if the same straddle recurs a hundred times, that is the signal, and it often argues for a merge or a re-cut, not another split.
How it implements the components¶
revision_decision— the review is the decision: it renders the split / merge / redefine / keep verdict for the node in question, with the threshold test as its justification.category_revision— it enacts the verdict, writing the new boundary rules and reassigning the directly affected items on the chosen node(s).edge_case_registry— straddling items are logged rather than force-fit, preserving emerging distinctions without prematurely minting categories.
This review decides and enacts one node's change but does not build the crosswalk that carries the whole corpus across — that migration_rule work is Knowledge-Base Retagging's. Its nearest twin is Taxonomy Revision, which also performs category revision; the difference is that Taxonomy Revision re-lays an entire subsumption hierarchy while this adjudicates a single split-or-merge question, and it leaves the continuity_constraint and current_schema_snapshot work to that page.
Related¶
- Instantiates: Schema Update Protocol — the review is the bounded decision-and-enactment step for one category question.
- Consumes: Classification Audit supplies the violating cases and misfit rate that raise the split/merge question in the first place.
- Sibling mechanisms: Classification Audit · Coding-Frame Revision · Glossary Update · Knowledge-Base Retagging · Ontology Refactoring · Schema Change Review Board · Schema Migration Workflow · Taxonomy Revision
Editorial Notes¶
Form Classification¶
Form family: Decision, Gate & Allocation
Rationale: Adjudicates a single overloaded-or-redundant category question — split, merge, or keep — and enacts the chosen change on that node alone, making its operative form a case-specific gate, selection, routing, prioritization, or disposition decision.
Independent corroboration: The frozen evidence defines Category Split/Merge Review as 'Adjudicates a single overloaded-or-redundant category question — split, merge, or keep — and enacts the chosen change on that node alone', so its operative form is Decision, Gate & Allocation.
Nearest alternative: Assessment, Review & Assurance — The review culminates in a binding split, merge, or keep allocation decision, rather than stopping at an evaluative finding.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Library & Information Science
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Taxonomy and vocabulary governance established bounded decisions to split, merge, redefine, or retain a category.
Related originating lineages:
- Biology & Ecology — Taxonomic lumping and splitting contribute evidence-based adjudication of whether one named class hides distinct kinds.
- Computer Science & Software Engineering — Schema and type refactoring contribute bounded split/merge migrations with explicit edge-case handling.
Review resolution: Library and information science is the agreed primary lineage because taxonomy and controlled-vocabulary governance adjudicate whether a category should be split, merged, or retained. Biological taxonomy and computer-science schema refactoring are independently formative parallels, supporting a convergent multi-domain record.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] "Lumpers and splitters" names the recurring temperamental divide between people who prefer a few broad categories and people who prefer many fine ones — a phrase long used in biological taxonomy and later borrowed widely. A split/merge review works precisely because it replaces temperament with a use-difference test. ↩