Benjamin_Boenisch/breakpilot-compliance
1
1
Fork 0
Code Issues 24 Pull Requests Actions Packages Projects Releases Wiki Activity

feat: Cross-Domain MCAP Convergence Analysis — which capabilities carry the system (Phase Ω pause)

Browse Source 
After Automotive, pause on domains and ask the deeper question: not "which MCAPs occur most often?"
(frequency deceives) but "which MCAPs CARRY the largest part of the system?". A deterministic MCAP
Impact Score (no AI) aggregates over the EXISTING data only:

  Impact = distinct Sources + Target Types + Domains + Journeys + Regulatory + Business Leverage

Critically anti-frequency-deception: a `likely_covered` cap is attributed to its source CERT (one
source), not to every target regulation — otherwise generic management caps win on raw frequency.
With that fix the Core surfaces the true cross-cutting nodes: secure_signed_update_distribution (18),
technical_vulnerability_management (17), access_control, incident_management, sbom_creation,
product_cyber_risk_assessment — exactly the bridges the user predicted; the high-frequency single-
domain environmental management caps correctly drop out.

Four reports, pure aggregation (no runtime, no new architecture): Core (highest impact), Emerging
(>=2 domains), Isolated (1 source/journey — specialised or convergence-not-yet-seen), Suspicious
(too coarse: generic verbs; too fine: hyper-specific isolated names) — an abstraction-level review
tool for domain experts. 11/62 caps already reach impact >=8; the method is ready to reveal whether a
30-50 MCAP core forms as Medical/Payment arrive. Non-runtime -> no deploy. 5 tests pass, check-loc 0.
This commit is contained in:
Benjamin Admin
2026-06-28 11:48:04 +02:00
parent a2332fb13d
commit c160bb8291
3 changed files with 258 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
backend-compliance/reference_scenarios/mcap_convergence_analysis.md
+47
View File
@@ -0,0 +1,47 @@
# Cross-Domain MCAP Convergence Analysis — wo konvergiert das Wissensmodell?
_Nicht „welche MCAPs kommen am häufigsten vor?" (Häufigkeit täuscht), sondern „welche MCAPs TRAGEN den größten Teil des Systems?". Deterministischer **Impact-Score** (kein ML), internes Engineering-Werkzeug, reine Aggregation über vorhandene Daten (5 Transition Patterns + 7 Automotive-Quellen). Non-runtime, keine echten Namen._
## Impact-Score (deterministisch)
> `Impact = distinct Sources + distinct Target-Types + distinct Domains + distinct Journeys + Regulatory Leverage + Business Leverage`
- 62 distinct Capabilities (MCAP-Kandidaten) über alle Quellen aggregiert.
## 1. Core MCAPs — höchster Impact (die tragenden Knoten)
| Capability | Impact | Sources | Types | Domains | Journeys |
|---|---:|---:|---:|---:|---:|
| `secure_signed_update_distribution` | **18** | 5 | 2 | 2 | 4 |
| `technical_vulnerability_management` | **17** | 5 | 3 | 2 | 4 |
| `access_control_and_authentication` | **15** | 4 | 2 | 2 | 5 |
| `incident_management` | **14** | 4 | 2 | 2 | 4 |
| `product_cyber_risk_assessment` | **13** | 3 | 1 | 2 | 4 |
| `secure_development_lifecycle` | **11** | 2 | 2 | 2 | 4 |
| `supplier_security` | **11** | 3 | 2 | 2 | 3 |
| `ce_conformity_assessment_and_technical_documentation` | **9** | 2 | 1 | 1 | 3 |
| `coordinated_vulnerability_disclosure` | **9** | 1 | 1 | 2 | 4 |
| `sbom_creation` | **9** | 1 | 1 | 2 | 4 |
→ Hoher Impact = ein Knoten verbindet viele Quellen ÜBER Typen/Domänen/Journeys hinweg — nicht „in 40 Dokumenten einer Normenfamilie".
## 2. Emerging MCAPs — verbinden ≥2 Domänen (Brücken zwischen Anforderungswelten)
- `secure_signed_update_distribution` — 2 Domänen (automotive, industrial_automation), 2 Typen.
- `technical_vulnerability_management` — 2 Domänen (automotive, industrial_automation), 3 Typen.
- `access_control_and_authentication` — 2 Domänen (automotive, industrial_automation), 2 Typen.
- `incident_management` — 2 Domänen (automotive, industrial_automation), 2 Typen.
- `product_cyber_risk_assessment` — 2 Domänen (automotive, industrial_automation), 1 Typen.
- `secure_development_lifecycle` — 2 Domänen (automotive, industrial_automation), 2 Typen.
- `supplier_security` — 2 Domänen (automotive, industrial_automation), 2 Typen.
- `coordinated_vulnerability_disclosure` — 2 Domänen (automotive, industrial_automation), 1 Typen.
- _(Echtes „Wachstum über Zeit" braucht historische Snapshots — hier Proxy = Domänen-Spannweite jetzt.)_
## 3. Isolated MCAPs — nur 1 Quelle/Journey (Review: spezialisiert ODER Konvergenz übersehen?)
- 36 Stück, u. a.: `account_energy_consumption`, `cybersecurity_management_system`, `document_update_campaigns`, `document_waste_streams`, `issue_battery_passport`, `machine_safety_risk_assessment`, `measure_air_emissions`, `mechanical_safety_and_guards`.
## 4. Suspicious MCAPs — Abstraktionsgrad-Verdacht (Experten-Review)
- **Evtl. zu grob** (generisches Verb, breit aber nur 1 Typ): `document_and_change_control`, `manage_chemical_substances`.
- **Evtl. zu fein** (isoliert + sehr spezifischer Name): `operating_instructions_and_safety_information`, `provide_dedicated_security_contact`, `provide_functional_safety_evidence`, `restrict_hazardous_substances_rohs`, `secure_by_default_no_default_credentials`, `threat_analysis_and_risk_assessment`.
- Die Analyse sagt damit nicht nur WELCHE MCAPs wichtig sind, sondern auch, ob sie auf dem **richtigen Abstraktionsniveau** definiert sind.
## Befund
> **Ein Kern beginnt sich zu zeigen:** 11 von 62 Capabilities erreichen Impact ≥ 8 (tragende Knoten), 14 verbinden ≥2 Domänen. Bislang ist das Wissensmodell noch jung (5 Patterns + 1 Automotive-Profil), aber die Methode steht: sobald Medical/Payment/weitere Domänen als DATEN hinzukommen, zeigt dieselbe Aggregation, ob sich der erwartete stabile Kern von 30–50 hochkonvergenten MCAPs bildet — der gemeinsame Strukturkern hinter sehr unterschiedlichen Anforderungswelten. Das ist ein tieferer Wertnachweis als „eine weitere Norm unterstützt". Reine Aggregation, 0 Runtime, 0 neue Architektur.