ba-taxonomy-standard

name	ba-taxonomy-standard
description	Shared conventions used across all PlausibleBA skills. Load this skill whenever producing, validating, or comparing any PlausibleBA taxonomy — Capability Maps, Concept Models, Value Streams, or any other structured artefact. It defines the numbering system, column order, naming conventions, MECE rules, and XLSX formatting standards that keep all outputs consistent and cross-referenceable.

PlausibleBA Taxonomy Standard

This file defines the house conventions shared across all PlausibleBA skills and artefacts. Any skill that produces a taxonomy, register, or structured model MUST follow these standards so outputs remain consistent and cross-referenceable.

---

Taxonomy Numbering

Every node in any PlausibleBA hierarchy carries a positional number encoding its place in the schema. This is the primary sort key — sorting by Number reproduces the full hierarchy at a glance and is far easier to validate than grouping by level.

Format: <L1>.<L2>.<L3>.<L4> — dot-separated integers, one segment per level.

1           ← L1 node: first top-level item
1.1         ← L2 node: first child of item 1
1.1.1       ← L3 node: first child of domain 1.1
1.1.2       ← L3 node: second child of domain 1.1
1.2         ← L2 node: second child of item 1
2           ← L1 node: second top-level item
2.1.1.1     ← L4 node: optional sub-level

Rules:

• Numbers are assigned sequentially within each parent, starting at 1
• Numbers are stable once assigned — insertions get the next available integer, not fractional numbers (no 1.1.1a or 1.1.1.5 inserted between existing items)
• Sorting by Number MUST reproduce the exact hierarchy — if it doesn't, the numbering is wrong
• The Number column is always column A and the default sort key in every XLSX output
• All XLSX outputs are pre-sorted by Number on delivery — the hierarchy is visible the moment the file opens

---

Standard Column Order

All PlausibleBA taxonomy XLSX outputs follow this column order. Meaningful content appears immediately after the positional columns; structural metadata moves to the right.

Position	Column	Notes
1	Number	Always col A; primary sort key; pre-sorted on delivery
2	Level	e.g. L1 / L2 / L3 / L4 — skill-specific labels
3	Name	Primary label; indented by level in the Name column
4	Description	Full description; wrap text enabled
5	Business Object	The core concept grounding this item (where applicable)
6	Type	Classification (e.g. Execution / Governance, or skill-specific)
7	Parent №	Number of parent node; blank for top-level items
8	Parent Name	Parent label for readability
9	ID	Machine-readable identifier; prefix_<snake_case_name>

Tags column: omitted from all standard outputs. Add only if a specific skill requires it for a documented purpose.

---

Naming Conventions

Verb–Noun pattern is the preferred convention for operational nodes (L3 and below):

• ✅ "Manage Credit Portfolio", "Assess Counterparty Risk", "Deliver Field Service"
• ❌ "Credit Assessment" (noun-only), "Assessing Risk" (gerund), "Finance Dept" (org unit)

The verb must be managerial, not operational:

• ✅ Manage, Govern, Oversee, Coordinate, Assure, Enable
• ❌ Assess, Process, Send, Calculate, Check (these describe activities, not stable abilities)

Structural grouping nodes (L1, L2) may use Noun-phrase labels where Verb–Noun feels forced (e.g. "Product Management", "Customer Acquisition").

ID format: <prefix>_<snake_case_name>

• Capability IDs: cap_manage_credit_portfolio
• Business Object IDs: obj_credit_application
• Value Stream IDs: vs_mortgage_origination
• Stage IDs: stg_application_assessment

---

MECE Rule

All sibling nodes at the same level within a parent must be:

Mutually Exclusive — no two siblings overlap in scope. If two nodes could describe the same item, their boundaries are not clearly defined. Merge or redefine.

Collectively Exhaustive — together, siblings cover the full scope of their parent with no gaps. If something happens within the parent's domain and no child accounts for it, a node is missing.

Apply the MECE check at every level before finalising any taxonomy. Run a cross-domain uniqueness check to catch semantic duplicates that span different parents.

---

Branding Requirement

Every PlausibleBA XLSX output must include a branding line. This is non-negotiable and applies to all tabs in all skills.

Format: Generated by the PlausibleBA Skills Library | www.plausibleba.com

Styling: italic, #2E75B6 font, #F2F7FF background fill, full-width merged cell above the header row. Height: 14pt.

The Capability Summary tab (or equivalent executive summary tab) must also include this line in the title block area, visible without scrolling.

---

XLSX Tab Order

All multi-tab PlausibleBA outputs follow this mandatory sequence:

1. [Artefact] Summary — executive-facing view; always the first tab and the one that opens by default
2. [Artefact] Register — the full taxonomy, pre-sorted by Number
3. Validation Summary — PASS / NOTE / FAIL checks
4. Legend — colour coding, numbering system, conventions, website link

---

XLSX Formatting Standards

Colour coding (consistent across all PlausibleBA skills)

Fill	Hex	Usage
Dark blue	#1F3864	Header rows
Mid blue	#2E75B6	L1 rows
Light blue	#BDD7EE	L2 rows
Pale blue	#DDEEFF	L3 Execution / primary type
Yellow	#FFF2CC	L3 Governance / secondary type
Green	#C6EFCE	Validation PASS
Blue-grey	#DDEBF7	Validation NOTE
Red	#FFC7CE	Validation FAIL

Fonts

• All cells: Arial, size 10
• L1 rows: bold, white text on dark blue
• L2 rows: bold, dark blue text on light blue
• L3+: regular weight

Freeze panes

• Always freeze row 1 (header) — freeze_panes = "A2"

Row heights

• Header: 22pt
• L1/L2 rows: 18pt
• L3 rows with description: 32pt

Standard worksheets (every PlausibleBA XLSX)

1. [Artefact Name] — the main register, pre-sorted by Number
2. Validation Summary — PASS / NOTE / FAIL checks
3. Legend — colour coding, numbering, conventions, next steps

---

Cross-Taxonomy References

When multiple PlausibleBA artefacts exist for the same domain (e.g. a Capability Map and a Value Stream), they share the same Business Objects as the binding thread.

A Business Object that appears in a Capability Map should carry the same name and ID in the Concept Model and in Value Stream stage definitions. Consistency here is what enables cross-validation:

• A Capability with no corresponding Value Stream stage is a candidate for review
• A Value Stream stage with no grounding Capability is a red flag
• A Business Object in the Concept Model with no corresponding Capability indicates a gap

---

Versioning

PlausibleBA artefact files should include a version note in the Legend sheet:

Standard version:   PlausibleBA Taxonomy Standard v1.0
Generated by:       ba-capability-mapping v1.0.0
Date:               YYYY-MM-DD

When this standard is updated, the version number increments. Skills reference the standard version they were built against so outputs remain reproducible.