Cross-Team Taxonomy Alignment

Two teams independently building knowledge bases will independently build incompatible taxonomies. This is not a failure of communication — it is a structural outcome. Each team optimizes for their own retrieval patterns, their own vocabulary, and their own mental model of the domain. The problem surfaces when an organization attempts to merge knowledge bases, build a unified search layer, or connect an AI system that needs to reason across both. At that point, the incompatibility is a migration project with no obvious owner.

1. Map the Incompatibility Types Not all incompatibilities are equally expensive to fix. Three types: terminological (same concept, different names — fixable with alias mapping), structural (same content, different organization — fixable with remapping rules), conceptual (genuinely different models of the domain — requires negotiation). Identify which type each conflict is before estimating remediation cost. Terminological conflicts are cheap. Conceptual conflicts are expensive.
2. Build a Crosswalk First A taxonomy crosswalk is a mapping document that links terms from taxonomy A to their equivalents in taxonomy B. Before any structural changes, document all known equivalences, near-equivalences, and genuine gaps. The crosswalk reveals the alignment effort required and becomes the specification for any automated mapping. It also surfaces the conceptual conflicts — terms that have no clean equivalent on the other side.
3. Negotiate Canonical Terms at the Conceptual Conflicts Terminological and structural conflicts can be resolved technically. Conceptual conflicts require a decision. Two teams with genuinely different models of the same concept need a conversation that ends in a written resolution: which model is canonical, what the canonical term is, and how each team's legacy content is reclassified. Document the decision and who made it. Undocumented conceptual resolutions get relitigated every time a new contributor encounters the inconsistency.
4. Implement a Reconciliation Layer Rather Than Forcing Convergence For taxonomies that must remain partially independent (different teams, different governance, different update cadences), a reconciliation layer is often better than forcing full convergence. The reconciliation layer maintains mappings between the two systems and handles cross-taxonomy queries programmatically. This preserves each team's ability to evolve their taxonomy without requiring coordination on every change — at the cost of maintaining the mapping layer.

# Taxonomy crosswalk: Sales KB ↔ Engineering KB
crosswalk:
  - sales_term: "Client Onboarding"
    engineering_term: "Provisioning"
    type: structural
    notes: "Sales covers relationship + process. Engineering covers technical setup. Overlap in weeks 1–2."
    canonical_for_unified: "Client Onboarding (Process) / Provisioning (Technical)"

  - sales_term: "API Integration"
    engineering_term: "Integration"
    type: terminological
    notes: "Identical concept. Engineering term is broader (covers non-API). Alias maps both to Engineering term."
    canonical_for_unified: "Integration"
    alias_mapping: ["API Integration → Integration"]

  - sales_term: "Renewal Risk"
    engineering_term: null
    type: gap
    notes: "No Engineering equivalent. Concept belongs entirely to Sales KB."
    canonical_for_unified: "Renewal Risk (Sales KB only)"

  - sales_term: "Incident"
    engineering_term: "Incident"
    type: conceptual
    notes: >
      Sales defines 'Incident' as any negative client-facing event.
      Engineering defines 'Incident' as production system failure only.
      DECISION (2026-02-14, Greg + ATLAS): Use qualified terms:
      'Client Incident' (Sales) and 'System Incident' (Engineering).
    canonical_for_unified: "Qualified — see notes"