| 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:
- [Artefact] Summary — executive-facing view; always the first tab and the one that opens by default
- [Artefact] Register — the full taxonomy, pre-sorted by Number
- Validation Summary — PASS / NOTE / FAIL checks
- 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)
- [Artefact Name] — the main register, pre-sorted by Number
- Validation Summary — PASS / NOTE / FAIL checks
- 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.
