Partition Refinement/Coarsening Review¶
Review — instantiates Exhaustive Disjoint Partition Design
Periodically re-decides block granularity — splitting blocks that hide distinct cases and merging blocks too thin to matter — while keeping the partition mutually exclusive and exhaustive.
Partition Refinement/Coarsening Review is the scheduled ritual where stewards operate the granularity dial and only that dial. It asks a single question — "are these the right-sized blocks for how they're used?" — and answers it with two moves: refine (split a block that hides materially different cases into sub-blocks) or coarsen (merge blocks too small or too alike to be worth separating), re-checking disjointness and exhaustiveness after every move. It is the only sibling that changes the number and size of blocks; it doesn't write membership rules, doesn't detect violations, and doesn't route individual units. Its output is a new partition version, not merely an opinion — which is why it hands off to the crosswalk and change notice downstream.
Example¶
A customer-support team's ticket taxonomy has drifted out of usefulness in two opposite directions at once. "Billing" is a single giant block quietly holding refunds, invoicing errors, and plan changes — three problems with three different owners and wildly different fix times — so reporting on "Billing" tells no one anything actionable; the review refines it into three sub-blocks. Meanwhile a dozen legacy categories each carry under a percent of tickets and mostly fragment the dashboards; the review coarsens several into one. After each move the team re-confirms that no ticket now falls under two blocks and that every ticket still lands somewhere. Reporting regains signal, and the scheme stays MECE.
How it works¶
- Review size against use. On a cadence (or on a trigger — a block gone dominant, a swollen residual), compare the block-size distribution to how the blocks are actually consumed.
- Split or merge. Refine a heterogeneous block by adding a distinction; coarsen redundant blocks by dropping one. Each move is immediately re-tested for overlap and gaps.
- Touch the construction basis deliberately. A split usually extends the partition's construction basis with a new attribute; a merge retires one. New dimensions add resolving power but are where fresh overlap sneaks in.
- Emit a version, not a verdict. The approved change becomes a new partition version routed to the crosswalk and the change notice.
Tuning parameters¶
- Split trigger — how dominant or internally varied a block must get before it's split. A low bar keeps blocks meaningful but multiplies them.
- Merge trigger — the minimum share below which blocks become merge candidates. A high bar keeps the scheme compact but buries rare cases inside larger ones.
- Depth limit — how many levels of refinement are allowed. Deeper captures nuance but strains the membership rules and the stewards who maintain them.
- Basis discipline — whether a split must reuse the existing construction basis or may introduce a new dimension. New dimensions add power at the price of overlap risk.
- Cadence — a fixed periodic review vs event-driven. Event-driven reacts faster but can churn the scheme (and its downstream consumers) more often.
When it helps, and when it misleads¶
Its strength is keeping resolution matched to use, so blocks stay informative: it catches both the "one enormous block" and the "death by a thousand tiny blocks" failure, which no detection tool will flag because both are perfectly valid MECE partitions. The taxonomy tension between lumpers and splitters names exactly the dial it turns, and naming it is half of turning it well.[n1]
Its hazard is that every refinement or coarsening is a breaking change for downstream consumers, so an over-eager review churns dashboards, joins, and trend lines faster than anyone can adapt — and a careless split on a new dimension can silently reintroduce overlap. The classic misuse is granularity by politics: minting a block for one loud stakeholder rather than for a use that needs it. The discipline is to tie each move to a concrete downstream use, re-run the disjointness and coverage checks after every change, and route the result through the crosswalk and change notice instead of quietly editing the scheme.
How it implements the components¶
block_granularity_model— the review sets this directly: how many blocks there are and how fine each cut is.partition_construction_basis— splits extend the basis with a new distinguishing attribute; merges retire one, so the review owns changes to the basis over time.block_stewardship_and_review_cadence— it is the stewards' recurring review, the governance beat on which granularity is reconsidered.
It does not write the membership predicates for the new sub-blocks (block_membership_criteria) — that's Block Membership Decision Table — and it does not announce the resulting change to consumers (downstream_block_use_contract); that's Partition Change Notice.
Related¶
- Instantiates: Exhaustive Disjoint Partition Design — it keeps the block structure fit for use as the world it describes changes.
- Consumes: Overlap Detection Join and Coverage Gap Audit to re-verify MECE after each split or merge.
- Sibling mechanisms: Partition Change Notice and Partition Crosswalk Table (consume the version it produces) · Residual Bucket Governance Policy · MECE Partition Template · Equivalence-Class Partition Derivation
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: The periodic review evaluates block granularity, overlap, gaps, and actual use to determine whether the partition remains fit.
Nearest alternative: Decision, Gate & Allocation — Splits and merges may follow, but they are dispositions produced by assessment of the existing partition.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Library & Information Science
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Revising classification granularity while preserving exhaustive, nonoverlapping organization is a core classification-science concern.
Related originating lineages:
- Biology & Ecology — Biological taxonomy independently developed the recurrent lumper-versus-splitter problem.
- Data Science & Analytics — Partition Refinement/Coarsening Review also draws materially on data science and analytics' computational practice of modeling, monitoring, validation, and pattern extraction, which shaped this mechanism rather than merely adopting it as an application.
- Mathematics — Partition Refinement/Coarsening Review is most directly rooted in mathematics' axiomatic study of abstract structure, relations, and formal operations. The lineage fits its defining practice: Periodically re-decides block granularity — splitting blocks that hide distinct cases and merging blocks too thin to matter — while keeping the partition mutually exclusive and exhaustive.
- Philosophy — Ontology materially supplies criteria for when distinctions mark real kinds rather than convenient partitions.
Review resolution: Authoritative-source research resolves the primary-origin disagreement in favor of library information science. SKOS Simple Knowledge Organization System Reference — W3C documents the formative practice or theory represented here. The retained alternate domains identify material co-development or translation, while current applicability is recorded separately as domain_reach=multi_domain; origin_mode=convergent describes the historical relationship among lineages.
Attribution caveat: Granularity review is shared by classification science, taxonomy, and ontology; information science best fits the maintained operational scheme.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; medium confidence.
Sources consulted:
Notes¶
A swollen residual is one of this review's most reliable refine signals: when the Residual Bucket Governance Policy flags a recurring pattern in "Other," this review is where that promotion request is adjudicated and turned into a real block. Keeping the promotion decision here — rather than in the residual policy itself — is what stops the catch-all from quietly minting blocks without a MECE re-check.
[n1] "Lumpers and splitters" is the long-standing taxonomic contrast between those who prefer fewer, broader categories and those who prefer many fine ones. Neither is right in general; the correct granularity is the one the downstream use requires, which is exactly why the choice is revisited on a cadence rather than fixed once. ↩