---
title: "KYE Protocol™ — Taxonomies · step 2 of the KYE™ stack"
description: "KYE™ taxonomies — parent / child classification of the names in the KYE™ vocabulary. Step 2 of the canonical 8-step KYE™ stack: Dictionaries → Taxonomies →…"
url: https://kyeprotocol.com/taxonomies/
lang: en
source: "KYE Protocol"
---

> KYE™ taxonomies — parent / child classification of the names in the KYE™ vocabulary. Step 2 of the canonical 8-step KYE™ stack: Dictionaries → Taxonomies →…

Step 2 · Taxonomies

# Sort KYE™ names into parent / child trees.

Step 1 names the things. Step 2 groups them. You get 16 signed taxonomies so an auditor, regulator, or developer can talk about a whole class without listing every member.

1 · What ships

## Sixteen v1.0 canonical trees.

Each tree is a published JSON file with a stable `$id` URL. Each value carries a SHA-256 hash. You can cite a class, not a list.

- Entity-class taxonomy
- Capability-family taxonomy
- Side-effect-level taxonomy
- Data-class taxonomy
- Decision-code taxonomy
- Lifecycle-state taxonomy
- Jurisdiction taxonomy
- Sector-namespace taxonomy
- Profile-family taxonomy
- Certification-tier taxonomy
- Risk-tier taxonomy
- Evidence-kind taxonomy
- Signal-family taxonomy
- Action-family taxonomy
- Redaction-class taxonomy
- Oversight-role taxonomy

2 · Why bother

## Cite a class, not a list.

A rule that says "deny `move_money` for `tier_3` agents" stays stable as new tools ship. The taxonomy resolves the class for you, so policy authors do not chase every new member.

- **Auditors** map `side_effect_level` values to ISO 42001 controls without re-listing each tool.
- **Regulators** ask for `data_class = pii` coverage under GDPR Art. 30, and the taxonomy enumerates the leaves.
- **Developers** filter the Signal Bus by `signal_family` instead of by event name.
- **Operators** set policy on `risk_tier` bands aligned to NIST AI RMF tiers 1–4.

3 · Taxonomy vs ontology

## Hierarchy first. Then meaning.

A taxonomy organises terms. An ontology defines how terms relate. KYE™ needs both — taxonomy first, then ontology — so rules stay short and meaning stays explicit.

- **Taxonomy says:** `card_purchase` is a kind of `payment_initiation`.
- **Ontology says:** `card_purchase` needs an `authority_grant` bound by an `amount_limit`.
- **You query the tree** to find all kinds of payment. You query the ontology to find what each one needs.

4 · How you wire it in

## Three patterns. Two minutes each.

Fetch the JSON. Bind a leaf to a payload field. Validate in CI. The same trees feed your OpenAPI schemas, your webhook filters, and your audit reports.

- **Bind a payload field.** Constrain `side_effect_level` in JSON Schema 2020-12 to taxonomy leaves only.
- **Filter a webhook.** Subscribe to events where `signal_family ∈ {risk, drift, evidence}`.
- **Report on a class.** Group Evidence Packs by `action_family` for an EU AI Act Annex IV log.

Where to go next

## Continue the stack →

Step 3 adds the meaning layer. Step 4 turns the named classes into wire-level JSON contracts.

[← Step 1 · Dictionaries](https://kyeprotocol.com/vocabulary/) [Step 3 · Ontology →](https://kyeprotocol.com/ontology/) [Step 4 · Schemas](https://kyeprotocol.com/schemas/)

## Ready to see your AI agents flagged?

Start in shadow mode. We’ll deliver your first Evidence Pack™ in 4–8 weeks.

[Apply for pilot →](https://kyeprotocol.com/pilot-apply/) [Try the sandbox →](https://kyeprotocol.com/sandbox/demos/)

Canonical KYE™ surfaces referenced on this page: [Evidence Pack™](https://kyeprotocol.com/evidence-pack/) · [KYE Protocol™](https://kyeprotocol.com/).