Hierarchical Aggregation Levels

Overview

Complex classification systems serve users with different granularity needs. A single flat list forces everyone to work at the same level of detail, too fine for some purposes, too coarse for others.

The solution is a hierarchical structure with defined aggregation levels, where each level serves a distinct purpose.

Components

The SOC uses four levels, each with a specific function:

Level	Count (2018)	Purpose	Code Pattern
Major Group	23	High-level reporting, sector-level analysis	XX-0000
Minor Group	98	Industry-aligned groupings	XX-X000
Broad Occupation	459	Similar duties, sometimes similar skills/training	XX-XX00
Detailed Occupation	867	Specific work activities, finest coding level	XX-XXXX

The code structure embeds the hierarchy: you can derive any parent level from a child code through truncation. This makes aggregation mechanical rather than requiring lookup tables.

When to Use This Pattern

Use multi-level hierarchies when:

• Users have genuinely different granularity needs
• Roll-up and drill-down analysis are common operations
• The domain has natural clusterings at multiple scales
• Cross-system interoperability requires mapping at different levels

Avoid when:

• The hierarchy is artificial (forced structure that doesn’t reflect reality)
• Maintenance cost of multiple levels outweighs benefits
• Single-level classification adequately serves all users

Limitations

Hierarchies impose a single primary dimension of organization. The SOC groups occupations by work similarity, but someone might want to slice by industry, or skill type, or credential requirement. Hierarchies don’t handle multi-dimensional classification well; that requires faceted approaches or tagging.

The “All Other” categories at each level are necessary escape valves but can become dumping grounds that obscure meaningful distinctions.

Related: 02-atom—all-other-escape-valve, 02-atom—task-based-classification, 06-molecule—crosswalks-for-interoperability