Faceted Taxonomy in Practice

Faceted taxonomy is the right structural choice for most enterprise knowledge bases, and most teams implement it wrong. The correct model: facets are independent, orthogonal dimensions. Each dimension classifies a different property of the content. A single item can have exactly one value per facet dimension, or multiple values if the dimension is multi-valued. What facets are not: a second hierarchical structure layered on top of the first.

1. Identify Genuine Dimensions A facet dimension should answer one specific question about content retrieval. "What topic is this about?" (Topic facet). "What audience needs this?" (Audience facet). "What process phase does this apply to?" (Process facet). "What product does this relate to?" (Product facet). Each dimension is independent — knowing a value in one dimension tells you nothing about the values in others.
2. Define Facet Values Exhaustively Each facet dimension needs an exhaustive, closed list of values. Not "these are some examples" — the actual, complete list. Open-ended facets become uncontrolled folksonomies in weeks. Contributors create idiosyncratic values that duplicate existing ones with different terminology. Close the list and route new value requests through governance.
3. Enforce Single-Assignment Where Appropriate Some facet dimensions should have exactly one value per item (Complexity: Tier 1 / Tier 2 / Tier 3). Others are legitimately multi-valued (Tags: an item can have multiple topic tags). The distinction matters for filter UX and for ensuring the facet actually constrains classification rather than becoming a tag cloud.
4. Define Cross-Facet Combinations Document which cross-facet combinations are meaningful and which indicate a misclassification. "Process Phase: Incident Response" + "Audience: Prospect" is a combination that should not exist — it indicates either the wrong audience tag or the wrong process phase. These invariant combinations become automated validation rules in a mature system.

# Faceted taxonomy schema — Knowledge Base
facets:
  topic:
    type: multi-value
    values:
      - Infrastructure
      - Security
      - Compliance
      - Integrations
      - AI Systems
      - Sales Process
      - Client Success
    governance: "New values require taxonomy committee approval"

  audience:
    type: single-value
    values:
      - Internal — Engineering
      - Internal — Sales
      - Internal — Leadership
      - Client — Technical
      - Client — Executive
    governance: "Strictly single-value. If genuinely multi-audience, create separate items."

  process_phase:
    type: single-value
    values:
      - Discovery
      - Onboarding
      - Delivery
      - Incident Response
      - Offboarding
      - Reference
    governance: "Reference = evergreen docs with no process phase. Use sparingly."

  complexity:
    type: single-value
    values:
      - Tier 1 (routine)
      - Tier 2 (requires judgment)
      - Tier 3 (specialist only)
    governance: "Tier classification reviewed by domain lead on publication."

# Invariant combinations (flag for review if detected):
invalid_combinations:
  - process_phase: "Discovery"
    audience: "Internal — Engineering"
    note: "Discovery content is Sales-facing. Engineering runbooks belong in Delivery."