Benjamin Admin
ecae5bc7f1
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>
77 lines
4.8 KiB
Markdown
77 lines
4.8 KiB
Markdown
# 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).
|