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

Name: ba-taxonomy-standard
Author: plausibleba

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.