feat(vocabulary): Domain Vocabulary — identity vs representation; regulation aliases fix the KPI normalization

Before the next Journey: the LANGUAGE. With 5 knowledge objects but no vocabulary, the same reise gets
named four different ways (ISO9001->MaschinenVO vs Quality Management->Product Safety vs ...). The spec
answers ONE question: which terms are IDENTITIES and which are REPRESENTATIONS of the same meaning?

- spec docs-src/architecture/domain-vocabulary-spec-v1.md (PROPOSAL): identity hierarchy
  (Requirement RQ / Capability MCAP [Registry 2C] / regulation-source-target / Journey Class MJRN
  [PROVISIONAL] / Journey instance / Playbook MPLB); canonical name + aliases; capability vocabulary =
  the Capability Registry (not rebuilt); reorder Vocabulary -> Transition #2 -> #3 -> Rule of Three.
- knowledge/vocabulary/regulations.yaml: regulation/standard IDENTITIES (id + canonical + aliases).
  SOLVES the regulation-ID normalization the KPIs flagged: CRA == "Cyber Resilience Act" == "Regulation
  (EU) 2024/2847" all resolve to `cra`; ISO9001/QMS -> iso9001; etc. Shared artifact (@Legal-KG/@Execution
  please adopt).
- knowledge/vocabulary/journey_classes.yaml (PROVISIONAL): clusters our transitions into classes
  (Information Security -> Product Cybersecurity; Quality Management -> Product Compliance/Safety).
  Finding: ISO9001->MaschinenVO is an INSTANCE of an existing class (like ISO9001->CRA, ISO13485->MDR),
  not a new kind -> avoids duplication. Journey Class is a new abstraction -> its own Rule of Three (no
  MJRN minting yet).
- reference suite: both KPIs now read aliases from regulations.yaml instead of hard-coded maps; the
  "Regelwerk-ID-Normalisierung" line flips TODO -> PASS. KPI numbers unchanged (vocab is a superset).
- Side effect = Requirements Intelligence: a Tender "Security Patch Procedure" resolves to MCAP-0017.

7 vocabulary tests (17 with domain programs), check-loc 0. Knowledge data + spec + reference harness =
non-runtime -> no deploy (ADR-001). No new module, no runtime change, no minting (Freeze).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

docs-src/architecture/domain-vocabulary-spec-v1.md

@@ -0,0 +1,76 @@
+# Domain Vocabulary — specification (PROPOSAL v1)
+
+- **Status:** PROPOSAL / draft. Beantwortet EINE Frage, bevor die nächste Journey entsteht. KEIN
+  Runtime-Modul, KEIN Parser, KEINE neue Architektur.
+- **Datum:** 2026-06-28
+- **Bezug:** [[master-capability-registry-2c]], [journey-model-spec-v1.md](journey-model-spec-v1.md), [ADR-010](adr/ADR-010-operational-knowledge-transition-unit.md), [[strategy-requirements-intelligence]]
+
+## 1. Problem: es fehlt die SPRACHE
+
+Wir haben fünf Wissensobjekte (Requirement · Capability · Journey · Playbook · Reference Scenario),
+aber kein **Vokabular**. Heute heißt eine Transition `ISO9001 → MaschinenVO`. Dieselbe Reise könnte
+auch `Quality Management → Product Safety`, `QMS → Machinery Compliance` oder `Operational Excellence
+→ CE` heißen. Bei 40 Requirement Sources / 300 Capabilities / 150 Journeys / 500 Playbooks wird die
+**Benennung selbst zum Problem** — und ohne Vokabular modellieren wir dieselbe fachliche Sache mehrfach
+unter verschiedenen Namen (genau die Duplikation, die wir bei Controls/Capabilities vermieden haben).
+
+## 2. Die EINE Frage
+
+> **Welche Begriffe unseres Systems sind IDENTITÄTEN, und welche sind nur DARSTELLUNGEN derselben
+> fachlichen Bedeutung?**
+
+## 3. Antwort: Identitäten vs. Darstellungen
+
+| Ebene | Identität (stabile ID) | Owner | Darstellungen (canonical name + aliases) |
+|---|---|---|---|
+| Requirement | `RQ-xxxxx` | Legal/Execution | „SBOM-Pflicht" / Art.-Refs |
+| Capability | `MCAP-xxxxx` (Registry 2C) | **Execution** | „Patch Management" + [Software Updates, Security Updates, Update Management, Patch Process, Vulnerability Remediation, Security Patch Procedure] |
+| **Requirement Source / Target** (Regelwerk/Norm) | `reg:cra`, `reg:iso9001` … | **shared (Legal/Execution), Reasoning seedet** | „Cyber Resilience Act" + [CRA, Reg. (EU) 2024/2847]; „ISO 9001" + [QMS, Quality Management System] |
+| **Journey Class** | `MJRN-xxxxx` (**PROVISIONAL**) | **Reasoning** | „Quality Management → Product Compliance" |
+| Journey (Instanz) | `(source-id → target-id)` | Reasoning | `iso9001 → maschinenvo` |
+| Playbook | `MPLB-xxxxx` | Reasoning | „SBOM aufbauen" |
+
+**Identität = die Sache; Darstellung = jeder Name dafür.** Eine Journey-Instanz ist stabil, weil ihre
+Endpunkte (Source/Target) IDENTITÄTEN sind, nicht Strings — egal ob man „ISO9001", „QMS" oder
+„Operational Excellence" schreibt.
+
+## 4. Capability-Vokabular = Capability Registry (2C), NICHT neu bauen
+
+Canonical Name + Aliases einer Capability sind bereits ein **Registry-2C-Konzern** (Execution): die
+Registry hat stabile `MCAP`-IDs + Relationstypen `equivalent`/`related` (= Synonyme) + Provenance.
+Das Domain Vocabulary DUPLIZIERT das nicht — es macht es nur explizit und ergänzt zwei NEUE Ebenen,
+die Reasoning besitzt: **Regelwerk-Identitäten** und **Journey Class**.
+
+## 5. Sofort-Nutzen: Regelwerk-Normalisierung (löst einen offenen TODO)
+
+`reg:cra` mit canonical „Cyber Resilience Act" + aliases `[CRA, Cyber Resilience Act, Reg. (EU)
+2024/2847]` löst genau die **Regelwerk-ID-Normalisierung**, die Transition-Coverage-KPI + Knowledge
+Intake bisher als TODO führen (CRA vs „Cyber Resilience Act"). `knowledge/vocabulary/regulations.yaml`
+wird die SHARED Quelle; die Reference-Suite-KPIs lesen Aliase daraus statt aus hartkodierten Maps.
+
+## 6. Journey Class (PROVISIONAL — eigene Rule of Three)
+
+Eine Journey CLASS clustert Instanzen, die „dieselbe Reise" sind. `knowledge/vocabulary/journey_classes.yaml`
+clustert unsere realen Transitionen — z. B. **`Information Security → Product Cybersecurity`**
+(ISO27001→CRA, TISAX→CRA, IEC62443→CRA) und **`Quality Management → Product Compliance/Safety`**
+(ISO9001→CRA, ISO9001→MaschinenVO, später ISO13485→MDR). So schreibt man NICHT für jede Zertifizierung
+eine neue Journey. **Journey Class ist eine NEUE Abstraktion → provisional (kein MJRN-Mint), bis sie
+sich selbst an ≥3 Instanzen je Klasse bewährt** ([[rule-of-three-canonicalization]]).
+
+## 7. Nebeneffekt: Requirements Intelligence (Vision V2)
+
+Wenn später ein Tender „Security Patch Procedure" fordert, erkennt BreakPilot den Alias von `MCAP-0017`,
+ohne dass irgendwo „Patch Management" steht. Stabile Begriffe → konsistente Parser, Tender-Vergleiche,
+Playbooks, Knowledge Intake. Das ist die Grundlage der Requirements Verification Platform
+([[strategy-requirements-intelligence]]).
+
+## 8. Reihenfolge (User 2026-06-28)
+
+`Vocabulary` → `Transition #2` → `Transition #3` → Rule of Three → Journey kanonisch. Die nächsten zwei
+Journeys zeigen, OB das Journey-MODELL stabil ist; das Vokabular zeigt, OB wir dieselbe fachliche Sache
+immer GLEICH benennen — langfristig mindestens genauso wichtig.
+
+## 9. Was das NICHT ist
+
+- Kein Runtime/Parser/Engine, kein MCAP/MJRN-Minting (Freeze unberührt). Seed-Daten + Spec.
+- Non-runtime → kein Deploy (ADR-001).