Skip to content

Slice Explosion Control

Intent

Bound slicing complexity using budgets, conventions, and review gates.

Structure

Slice explosion control is an architecture for keeping slicing complexity bounded. Structurally it introduces a ‘budget’, naming conventions, a review gate, and a refactoring cadence.

  • Budget: explicit limits on slice counts per element and per profile
  • Conventions: consistent naming and discriminator choices to reduce ambiguity
  • Review gate: profiling experts review new slices for overlap, implementability, and example coverage
  • Tooling support: reports on slice counts and validation performance over time
  • Refactoring plan: scheduled reduction of complexity with migration guidance

Key Components

Slicing budget

  • Set an explicit budget for number of slices per element
  • Require justification for exceeding the budget
  • Track slice count growth over time
  • Prefer value sets or extensions when appropriate
  • Keep slicing aligned with implementer capability

Slice naming

  • Use consistent slice names across profiles
  • Make names meaningful for implementers
  • Avoid renaming slices without migration guidance
  • Keep slice discriminators simple
  • Document naming conventions

Review gate

  • Require review from profiling experts for new slices
  • Check slice invariants and bindings
  • Confirm examples validate all slices
  • Catch slice overlap/ambiguity early
  • Use tooling output to support review

Refactor plan

  • Schedule periodic refactoring of complex profiles
  • Track hotspots (slow validation, repeated confusion)
  • Prefer incremental refactors to avoid big-bang changes
  • Provide migration guidance for refactors
  • Retest across products after refactoring

Behavior

Slicing governance behavior

Slicing gets added when it’s the simplest way to express interoperable variation; otherwise it’s avoided.

Decision rules

  • Prefer value sets, MustSupport policy, or separate profiles over complex slicing when feasible.
  • If slicing is required, choose the simplest discriminator and smallest number of slices.
  • Require examples for every slice and at least one negative example when overlap risk is high.

Manage growth

  • Track slice counts and validation performance as a regression indicator.
  • When budgets are exceeded, require an ADR or explicit justification.
  • Periodically refactor: consolidate slices, split profiles, or revise constraints with migration notes.

Benefits

  • Avoid brittle profiles
  • Better tooling performance

Trade-offs

  • May need later refactoring