Files

T

Benjamin Admin ecae5bc7f1 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>

2026-06-28 08:11:30 +02:00

4.8 KiB

Raw Blame History

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, ADR-010, 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).

4.8 KiB Raw Blame History