# 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).