Capability Versioning¶

Why This Exists¶

This document defines how Business Capabilities are versioned.

Capabilities are more stable than implementations, but they still evolve. Versioning makes changes traceable and helps teams understand whether a change is conceptual, operational, or implementation-level.

Owner¶

The owner is the Chief Product Officer and Enterprise Architect.

Each owning Practice is responsible for maintaining version information for its capabilities.

Business Value¶

Capability versioning creates business value by preserving traceability across documentation, workflows, APIs, data, UX, KPIs, and customer outcomes.

Version Format¶

Use semantic versioning for capability definitions:

MAJOR.MINOR.PATCH

Segment	Meaning
`MAJOR`	Business meaning, ownership, or outcome changes.
`MINOR`	New relationships, maturity changes, SOPs, rules, events, data, APIs, or UX changes.
`PATCH`	Clarifications, wording fixes, metadata updates, or non-substantive corrections.

Capability ID Stability¶

The capability ID must remain stable across versions unless the capability is split, merged, retired, or reclassified through governance.

Example:

COMP-001 v1.0.0
COMP-001 v1.1.0
COMP-001 v2.0.0

Versioning Triggers¶

Version changes are required when:

The capability definition changes.
Ownership changes.
The accountable Digital Professional changes.
SOPs or Business Rules change.
APIs or Events change.
Data or Organizational Memory relationships change.
UX changes affect customer operation.
KPIs or maturity levels change.

Capability Version Flow¶

flowchart LR
    Draft[v0.x Draft]
    Baseline[v1.0 Baseline]
    Minor[v1.x Evolution]
    Major[v2.0 Redefinition]
    Retired[Retired]

    Draft --> Baseline
    Baseline --> Minor
    Minor --> Major
    Baseline --> Retired
    Major --> Retired

Version History¶

Each capability document should include a version history table.

Version	Date	Change	Approved by
0.1.0	YYYY-MM-DD	Initial draft.	TBD

Relationship to Implementation Versioning¶

Capability versioning is not the same as API, data schema, workflow, or application release versioning. Implementations may change more frequently than capability definitions.