From 90c3fe16b5cbbb07b5dae9df596ad2f6359a5bb1 Mon Sep 17 00:00:00 2001 From: Benjamin Admin Date: Sun, 28 Jun 2026 11:30:30 +0200 Subject: [PATCH] =?UTF-8?q?feat:=20Automotive=20convergence=20stress=20tes?= =?UTF-8?q?t=20=E2=80=94=20same=20capability=20from=20many=20sources=20(Ph?= =?UTF-8?q?ase=20=CE=A9=20#2)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Not another domain to prove agnosticism (Environmental did that) but a DIFFERENT property: can the SAME capability be fed by many overlapping Requirement Sources at once without the model becoming unstable? Realistic setup — a supplier with ISO 9001 + IATF 16949 + TISAX + ASPICE + CSMS + SUMS developing an ECU for OEM X. Seven sources (CRA, UNECE R155/CSMS, R156/SUMS, IATF, TISAX, ASPICE, OEM X) with deliberate overlap, run through the SAME engine (0 runtime code, data only). Three new measurements (user-requested): - Capability Convergence: technical_vulnerability_management = 4 sources across 3 source TYPES (regulation + certification + contract); secure_signed_update_distribution = 4 sources. The overlap is where the economic value lives ("one capability replaces five evidence worlds"). - Existing-vs-New: 13/27 required caps reuse existing cyber/environmental MCAPs (48%) -> the registry is starting to converge; the automotive-specific rest (CSMS/SUMS/ASPICE/functional safety) is expectedly new (a maturity hint, not an architecture break). - Business Leverage: a convergent capability satisfies N regulations AND unlocks the OEM market — more convincing to a GF than "satisfies five laws". (Regulatory Leverage counts regulations; Business Leverage counts regulations + markets/customers.) Ledger gains the automotive row (0/0, 14 new types, data_only); stability stays 7/7 = 100%. The verdict recommends the user's next step: NOT a new domain but PAUSE and analyse the registry for the cross-domain high-convergence core MCAPs. Non-runtime -> no deploy. 12 tests pass, check-loc 0. --- .../integration_ledger.yaml | 10 ++ .../automotive/source_capabilities.yaml | 58 ++++++++ .../architecture_stability_kpi.md | 13 +- .../automotive_convergence_stress_test.md | 36 +++++ .../automotive_convergence_stress_test.py | 127 ++++++++++++++++++ ...test_automotive_convergence_stress_test.py | 62 +++++++++ 6 files changed, 300 insertions(+), 6 deletions(-) create mode 100644 backend-compliance/knowledge/domains/automotive/source_capabilities.yaml create mode 100644 backend-compliance/reference_scenarios/automotive_convergence_stress_test.md create mode 100644 backend-compliance/reference_scenarios/automotive_convergence_stress_test.py create mode 100644 backend-compliance/tests/test_automotive_convergence_stress_test.py diff --git a/backend-compliance/knowledge/architecture_stability/integration_ledger.yaml b/backend-compliance/knowledge/architecture_stability/integration_ledger.yaml index 2ad7993a..0b0c18a4 100644 --- a/backend-compliance/knowledge/architecture_stability/integration_ledger.yaml +++ b/backend-compliance/knowledge/architecture_stability/integration_ledger.yaml @@ -76,6 +76,16 @@ sources: integration_kind: data_only family: non_cyber # FIRST non-cyber domain — the real generality test exercised_by: "customer_mission_5, environmental_stress_test" + - source: "Automotive ECU for OEM X (CRA / UNECE R155+R156 / IATF 16949 / TISAX / ASPICE / OEM spec)" + domain: automotive + target_type: multi_source # 7 OVERLAPPING sources spanning regulation + certification + process + contract + integrated_as: multi_source_required_set + new_runtime_classes: 0 + new_pipeline: false + new_capability_types: 14 # of 27 required caps, 13 reuse existing MCAPs (48% -> registry converging) + integration_kind: data_only + family: cyber # convergence test: same capability fed by many sources, model stayed stable + exercised_by: "automotive_convergence_stress_test" # --- One-time, domain-AGNOSTIC pipeline functions (built once, now FROZEN per Phase Ω). --- # Listed for honesty so the stability KPI cannot be gamed: these are NOT per-domain costs. The last diff --git a/backend-compliance/knowledge/domains/automotive/source_capabilities.yaml b/backend-compliance/knowledge/domains/automotive/source_capabilities.yaml new file mode 100644 index 00000000..120c3e78 --- /dev/null +++ b/backend-compliance/knowledge/domains/automotive/source_capabilities.yaml @@ -0,0 +1,58 @@ +# Automotive multi-source capability data — the CONVERGENCE stress test (Phase Ω, test #2). +# +# Not another domain to validate domain-agnosticism (Environmental already proved that). This tests a +# DIFFERENT property: can the SAME capability be fed by MANY different Requirement Sources at once +# without the model becoming unstable? Realistic setup: a supplier developing an ECU for OEM X, who +# already holds ISO 9001 + IATF 16949 + TISAX + ASPICE (L2/3) + CSMS + SUMS. +# +# Each source lists the capabilities it REQUIRES. Overlap is deliberate and realistic — that overlap is +# exactly where the economic value lives ("one capability replaces five evidence worlds"). Capabilities +# are VERBS / stable ids reused from the cyber + environmental patterns where they recur, so the +# existing-vs-new (registry convergence) measurement is honest. Data only — no runtime code. + +goal: "Develop a new ECU (Steuergerät) and supply OEM X." + +sources: + - id: CRA + type: regulation + requires: [secure_signed_update_distribution, technical_vulnerability_management, + coordinated_vulnerability_disclosure, sbom_creation, access_control_and_authentication, + incident_management, secure_development_lifecycle, product_cyber_risk_assessment] + - id: UNECE_R155_CSMS + type: regulation + requires: [secure_signed_update_distribution, technical_vulnerability_management, + product_cyber_risk_assessment, incident_management, access_control_and_authentication, + cybersecurity_management_system, threat_analysis_and_risk_assessment] + - id: UNECE_R156_SUMS + type: regulation + requires: [secure_signed_update_distribution, software_update_management_system, + identify_software_versions_rxswin, document_update_campaigns] + - id: IATF_16949 + type: certification + requires: [document_and_change_control, supplier_evaluation, release_and_approval_process, + approve_production_parts_ppap, plan_product_quality_apqp] + - id: TISAX + type: certification + requires: [information_security_management, access_control_and_authentication, incident_management, + technical_vulnerability_management, supplier_security, protect_prototypes] + - id: ASPICE + type: process + requires: [assess_software_process_capability, engineer_requirements_process, + verify_software_process, manage_configuration_process] + - id: OEM_X_Spec + type: contract + requires: [secure_signed_update_distribution, technical_vulnerability_management, + provide_functional_safety_evidence, protect_prototypes, supplier_security, + identify_software_versions_rxswin, provide_dedicated_security_contact] + +# The company's certificates/processes -> the capabilities they make probably-present (Welt-1). +# (Management/process discipline + the security baseline an automotive supplier with these certs has.) +company_profile_capabilities: + ISO9001: [document_and_change_control, supplier_evaluation, release_and_approval_process] + IATF16949: [approve_production_parts_ppap, plan_product_quality_apqp] + TISAX: [information_security_management, access_control_and_authentication, incident_management, + technical_vulnerability_management, supplier_security, protect_prototypes] + ASPICE: [assess_software_process_capability, engineer_requirements_process, + verify_software_process, manage_configuration_process] + CSMS: [cybersecurity_management_system, threat_analysis_and_risk_assessment, product_cyber_risk_assessment] + SUMS: [software_update_management_system, document_update_campaigns] diff --git a/backend-compliance/reference_scenarios/architecture_stability_kpi.md b/backend-compliance/reference_scenarios/architecture_stability_kpi.md index 5cd1c947..6d7534a4 100644 --- a/backend-compliance/reference_scenarios/architecture_stability_kpi.md +++ b/backend-compliance/reference_scenarios/architecture_stability_kpi.md @@ -12,11 +12,12 @@ _Der Fokus hat sich verschoben: nicht mehr „kann die Architektur das?", sonder | Public Tender (öffentliche Ausschreibung) | cyber | 0 | 0 | 3 | ✅ | | OEM Specification (Lastenheft) | cyber | 0 | 0 | 4 | ✅ | | ISO 14001 -> Environmental/Material (REACH/RoHS/Batterie/Wasser/Energie/Abfall) | non_cyber | 0 | 0 | 16 | ✅ | +| Automotive ECU for OEM X (CRA / UNECE R155+R156 / IATF 16949 / TISAX / ASPICE / OEM spec) | cyber | 0 | 0 | 14 | ✅ | -- **Architecture Stability: 6/6 = 100%** der Quellen ohne neue Runtime-Klasse und ohne neue Pipeline. -- **Knowledge Velocity: 6/6 = 100%** der Quellen **data-only** integriert (kein Entwickler nötig). -- **Generalität über Cyber hinaus: 1/6 Quellen NICHT-Cyber** (Umwelt) — trugen die Pipeline ebenfalls 0/0. Das ist der eigentliche Test (ein anderes Denkmodell, nicht noch ein Cyber-Regelwerk). -- **Capability-Modell-Frühindikator: 45 neue Typen gesamt, Maximum 16** (Umwelt, erste Nicht-Cyber-Domäne) — in Range, KEIN Granularitätsalarm (Alarm ≈ eine Domäne braucht plötzlich ~80 neue Typen bei 0 Runtime-Change → Modell zu grob/fein). +- **Architecture Stability: 7/7 = 100%** der Quellen ohne neue Runtime-Klasse und ohne neue Pipeline. +- **Knowledge Velocity: 7/7 = 100%** der Quellen **data-only** integriert (kein Entwickler nötig). +- **Generalität über Cyber hinaus: 1/7 Quellen NICHT-Cyber** (Umwelt) — trugen die Pipeline ebenfalls 0/0. Das ist der eigentliche Test (ein anderes Denkmodell, nicht noch ein Cyber-Regelwerk). +- **Capability-Modell-Frühindikator: 59 neue Typen gesamt, Maximum 16** (Umwelt, erste Nicht-Cyber-Domäne) — in Range, KEIN Granularitätsalarm (Alarm ≈ eine Domäne braucht plötzlich ~80 neue Typen bei 0 Runtime-Change → Modell zu grob/fein). ## Ehrlichkeit: die Pipeline-Funktionen sind EINMALIG (jetzt eingefroren) - 6 domänen-AGNOSTISCHE Funktionen, einmal gebaut, nicht je Domäne: `transition_reasoning (RS-005)`, `optimization`, `journey_matcher (ADR-011)`, `playbook`, `completeness`, `company (2A)`. @@ -30,8 +31,8 @@ _Der Fokus hat sich verschoben: nicht mehr „kann die Architektur das?", sonder | **Produktion** (wie TUN/BEWEISEN) | Playbooks, Verification, Reference Scenarios | ## Die drei Erfolgsfragen ab jetzt (statt Coverage) -1. **Musste für eine neue Domäne Runtime-Code geändert werden?** → bisher: **nein** (6/6). -2. **Knowledge Velocity** — neues Wissen ohne Entwickler aufnehmbar? → bisher: **ja** (6/6 data-only). +1. **Musste für eine neue Domäne Runtime-Code geändert werden?** → bisher: **nein** (7/7). +2. **Knowledge Velocity** — neues Wissen ohne Entwickler aufnehmbar? → bisher: **ja** (7/7 data-only). 3. **Architecture Stability** — bestehende Capability/Journey strukturell ändern oder nur Daten ergänzen? → bisher: **nur Daten**. > **Befund:** Über fünf Zielarten und sechs Quellen blieb `Reality → Evidence → Capability → Required → Delta → Journey → Roadmap → Playbooks → Verification` unverändert. Das ist der eigentliche Nachweis: keine Compliance-Architektur, sondern eine allgemeine Requirements-Verifikationsarchitektur, die ihre Generalität UNTER realer fachlicher Belastung behält. Der nächste Test ist nicht ein Feature, sondern die nächste echte Domäne (Umwelt-Cluster · Automotive · Medizintechnik · Payment) — jede als neue Ledger-Zeile, bei stabilem KPI. diff --git a/backend-compliance/reference_scenarios/automotive_convergence_stress_test.md b/backend-compliance/reference_scenarios/automotive_convergence_stress_test.md new file mode 100644 index 00000000..a035f0fa --- /dev/null +++ b/backend-compliance/reference_scenarios/automotive_convergence_stress_test.md @@ -0,0 +1,36 @@ +# Automotive Convergence Stress Test — überlebt EINE Capability viele Quellen? (Phase Ω #2) + +_Nicht noch eine Domäne, sondern eine andere Eigenschaft: bleibt das Modell stabil, wenn dieselbe Capability gleichzeitig aus vielen überlappenden Quellen gespeist wird? Realistisch: ein Zulieferer (ISO 9001 + IATF 16949 + TISAX + ASPICE + CSMS + SUMS) entwickelt ein Steuergerät für OEM X. Sieben Quellen, bewusste Überlappung. Data-only, keine echten Namen._ + +## 1. Sieben überlappende Quellen, eine Engine +- Quellen: `CRA`(regulation), `UNECE_R155_CSMS`(regulation), `UNECE_R156_SUMS`(regulation), `IATF_16949`(certification), `TISAX`(certification), `ASPICE`(process), `OEM_X_Spec`(contract). +- **27 distinct geforderte Capabilities** für „Steuergerät → OEM X" — über dieselbe `assess_transition`-Engine, 0 neue Runtime-Klassen. +- Delta (fehlt dem Profil): **7** Capabilities. + +## 2. Capability Convergence — dieselbe Capability aus vielen Quellen +| Capability | Sources | Distinct Source Types | aus | +|---|---:|---:|---| +| `technical_vulnerability_management` | 4 | 3 | CRA, OEM_X_Spec, TISAX, UNECE_R155_CSMS | +| `secure_signed_update_distribution` | 4 | 2 | CRA, OEM_X_Spec, UNECE_R155_CSMS, UNECE_R156_SUMS | +| `access_control_and_authentication` | 3 | 2 | CRA, TISAX, UNECE_R155_CSMS | +| `incident_management` | 3 | 2 | CRA, TISAX, UNECE_R155_CSMS | +| `identify_software_versions_rxswin` | 2 | 2 | OEM_X_Spec, UNECE_R156_SUMS | +| `protect_prototypes` | 2 | 2 | OEM_X_Spec, TISAX | +| `supplier_security` | 2 | 2 | OEM_X_Spec, TISAX | +| `product_cyber_risk_assessment` | 2 | 1 | CRA, UNECE_R155_CSMS | + +→ **`technical_vulnerability_management`** ist am konvergentesten: **4 Quellen** über **3 Quelltypen** — eine Maßnahme, viele Nachweiswelten. Genau hier entsteht der wirtschaftliche Nutzen (nicht „300 Gesetze", sondern „eine Capability ersetzt fünf Nachweiswelten"). + +## 3. Existing-vs-New — beginnt die Registry zu konvergieren? +- **Bereits vorhandene MCAPs (Reuse aus Cyber/Umwelt): 13/27 = 48%** — z. B. `access_control_and_authentication`, `coordinated_vulnerability_disclosure`, `document_and_change_control`, `incident_management`, `information_security_management` …. +- **Genuin neu (Automotive-spezifisch): 14** — z. B. `approve_production_parts_ppap`, `assess_software_process_capability`, `cybersecurity_management_system`, `document_update_campaigns`, `engineer_requirements_process` …. +- **Lesart:** Spürbare Wiederverwendung (48%) — der Kern beginnt sich zu bilden; der automotive-spezifische Rest (CSMS/SUMS/ASPICE/Funktionssicherheit) ist erwartbar neu. Kein Architekturbruch, sondern ein Hinweis auf den Reifegrad der Capability-Zerlegung. + +## 4. Business Leverage — Märkte + Regulierung, nicht nur „Gesetze" +- `technical_vulnerability_management` erfüllt gleichzeitig **2 Regelwerke** (CRA, UNECE_R155_CSMS) **und** öffnet den **OEM-Markt** (OEM_X_Spec). +- Managementsatz: **„Diese eine Capability erfüllt 2 regulatorische Anforderungen UND ist Eintrittskarte zum OEM-Geschäft"** — überzeugender als „erfüllt 2 Gesetze". (Regulatory Leverage zählt Regelwerke; **Business Leverage** zählt Regelwerke + erschlossene Märkte/Kunden.) + +## Befund + +> **Eine Capability aus bis zu 4 Quellen über 3 Quelltypen — das Modell blieb stabil (0 neue Runtime-Klassen, 0 neue Pipeline; reine Daten).** Convergence ist messbar geworden, und 48% der Automotive-Anforderungen bilden auf BESTEHENDE MCAPs ab — die Registry beginnt zu konvergieren. Nächster Schritt ist bewusst KEINE neue Domäne, sondern **innehalten und die Registry analysieren**: welche MCAPs tauchen domänenübergreifend (CRA·MaschinenVO·OEM·TISAX·ASPICE·Umwelt) am häufigsten auf? Diese hochkonvergenten Capabilities sind der dauerhaft wertvollste Plattformkern. + diff --git a/backend-compliance/reference_scenarios/automotive_convergence_stress_test.py b/backend-compliance/reference_scenarios/automotive_convergence_stress_test.py new file mode 100644 index 00000000..7a1adb4d --- /dev/null +++ b/backend-compliance/reference_scenarios/automotive_convergence_stress_test.py @@ -0,0 +1,127 @@ +# ruff: noqa +# mypy: ignore-errors +"""Automotive convergence stress test — does the SAME capability survive MANY sources? (Phase Ω, test #2) + +Environmental proved domain-agnosticism. This tests a different property: can ONE capability be fed by +many overlapping Requirement Sources at once without the model becoming unstable? Realistic setup — a +supplier with ISO 9001 + IATF 16949 + TISAX + ASPICE + CSMS + SUMS developing an ECU for OEM X. Seven +sources (CRA, UNECE R155/CSMS, R156/SUMS, IATF, TISAX, ASPICE, OEM X) demand heavily OVERLAPPING caps. + +Three new measurements the user asked for: + - Capability Convergence : per capability, how many sources / how many distinct source TYPES feed it. + - Existing-vs-New : how many required caps reuse the EXISTING registry vs are genuinely new + (a registry-convergence signal — high reuse => the core is forming). + - Business Leverage : the most convergent cap satisfies N regulations AND unlocks a market — more + convincing to a GF than "satisfies five laws". + +Data only (a YAML + injected Required caps), zero runtime code. Synthetic, no real names. No deploy. +Run: cd backend-compliance && PYTHONPATH=. python3 reference_scenarios/automotive_convergence_stress_test.py +""" +from __future__ import annotations + +import os +import yaml + +from compliance.company import ( + CompanyContext, Certification, CapabilityMappingEntry, build_company_profile, +) +from compliance.reasoning.enums import Confidence +from compliance.transition_reasoning import ( + TransitionContext, TransitionGoal, TargetRequirement, assess_transition, CoverageStatus, +) + +OUT = [] + + +def w(s=""): + OUT.append(s) + + +_HERE = os.path.dirname(__file__) +A = yaml.safe_load(open(os.path.join(_HERE, "..", "knowledge", "domains", "automotive", "source_capabilities.yaml"), encoding="utf-8")) +SOURCES = A["sources"] + +# ── known capability universe = caps already modelled in the cyber + environmental patterns ── +_K = os.path.join(_HERE, "..", "knowledge", "transition_patterns") +known = set() +for f in os.listdir(_K): + if f.endswith(".yaml"): + p = yaml.safe_load(open(os.path.join(_K, f), encoding="utf-8")) + known |= {a["capability"] for a in p.get("likely_covered", [])} + known |= {d["capability"] for d in p.get("delta_requirements", [])} + +# ── one multi-certified company profile (many overlapping sources) ────────────────────────── +prof_caps = A["company_profile_capabilities"] +cmap = {k: CapabilityMappingEntry(capability_ids=v, confidence=Confidence.MEDIUM) for k, v in prof_caps.items()} +profile = build_company_profile( + CompanyContext(company_id="auto", certifications=[Certification(certification_id=k) for k in prof_caps]), cmap) + +# ── required = union of all source caps for "ECU for OEM X"; delta via the SAME engine ─────── +required = sorted({c for s in SOURCES for c in s["requires"]}) +assess = assess_transition(TransitionContext(company_id="auto", target=TransitionGoal(target_id="ECU_for_OEM_X")), + [TargetRequirement(capability_id=c) for c in required], profile) +delta = sorted({c.capability_id for c in assess.coverage if c.status == CoverageStatus.MISSING}) + +# ── Capability Convergence: per cap -> sources + distinct source types ─────────────────────── +conv = {} +for cap in required: + srcs = [s for s in SOURCES if cap in s["requires"]] + conv[cap] = (sorted(s["id"] for s in srcs), sorted({s["type"] for s in srcs})) +ranked = sorted(required, key=lambda c: (-len(conv[c][0]), -len(conv[c][1]), c)) + +# ── Existing-vs-New (registry convergence signal) ─────────────────────────────────────────── +reuse = sorted(c for c in required if c in known) +fresh = sorted(c for c in required if c not in known) +reuse_pct = round(100 * len(reuse) / len(required)) if required else 0 + +w("# Automotive Convergence Stress Test — überlebt EINE Capability viele Quellen? (Phase Ω #2)") +w("") +w('_Nicht noch eine Domäne, sondern eine andere Eigenschaft: bleibt das Modell stabil, wenn dieselbe Capability gleichzeitig aus vielen überlappenden Quellen gespeist wird? Realistisch: ein Zulieferer (ISO 9001 + IATF 16949 + TISAX + ASPICE + CSMS + SUMS) entwickelt ein Steuergerät für OEM X. Sieben Quellen, bewusste Überlappung. Data-only, keine echten Namen._') +w("") +w("## 1. Sieben überlappende Quellen, eine Engine") +w("- Quellen: %s." % ", ".join("`%s`(%s)" % (s["id"], s["type"]) for s in SOURCES)) +w('- **%d distinct geforderte Capabilities** für „Steuergerät → OEM X" — über dieselbe `assess_transition`-Engine, 0 neue Runtime-Klassen.' % len(required)) +w("- Delta (fehlt dem Profil): **%d** Capabilities." % len(delta)) +w("") + +# ── 2. Capability Convergence ────────────────────────────────────────────── +w("## 2. Capability Convergence — dieselbe Capability aus vielen Quellen") +w("| Capability | Sources | Distinct Source Types | aus |") +w("|---|---:|---:|---|") +for cap in ranked[:8]: + srcs, types = conv[cap] + w("| `%s` | %d | %d | %s |" % (cap, len(srcs), len(types), ", ".join(srcs))) +w("") +top = ranked[0] +w('→ **`%s`** ist am konvergentesten: **%d Quellen** über **%d Quelltypen** — eine Maßnahme, viele Nachweiswelten. Genau hier entsteht der wirtschaftliche Nutzen (nicht „300 Gesetze", sondern „eine Capability ersetzt fünf Nachweiswelten").' % (top, len(conv[top][0]), len(conv[top][1]))) +w("") + +# ── 3. Existing-vs-New (registry convergence) ────────────────────────────── +w("## 3. Existing-vs-New — beginnt die Registry zu konvergieren?") +w("- **Bereits vorhandene MCAPs (Reuse aus Cyber/Umwelt): %d/%d = %d%%** — z. B. %s." % ( + len(reuse), len(required), reuse_pct, ", ".join("`%s`" % c for c in reuse[:5]) + " …")) +w("- **Genuin neu (Automotive-spezifisch): %d** — z. B. %s." % ( + len(fresh), ", ".join("`%s`" % c for c in fresh[:5]) + " …")) +w("- **Lesart:** %s" % ( + "Hohe Wiederverwendung → die Registry konvergiert, ein Kern bildet sich." if reuse_pct >= 60 else + "Spürbare Wiederverwendung (%d%%) — der Kern beginnt sich zu bilden; der automotive-spezifische Rest (CSMS/SUMS/ASPICE/Funktionssicherheit) ist erwartbar neu. Kein Architekturbruch, sondern ein Hinweis auf den Reifegrad der Capability-Zerlegung." % reuse_pct)) +w("") + +# ── 4. Business Leverage ─────────────────────────────────────────────────── +top_srcs, top_types = conv[top] +regs = [s for s in top_srcs if next(x["type"] for x in SOURCES if x["id"] == s) == "regulation"] +contracts = [s for s in top_srcs if next(x["type"] for x in SOURCES if x["id"] == s) == "contract"] +w('## 4. Business Leverage — Märkte + Regulierung, nicht nur „Gesetze"') +w("- `%s` erfüllt gleichzeitig **%d Regelwerke** (%s) **und** öffnet den **OEM-Markt** (%s)." % ( + top, len(regs), ", ".join(regs), ", ".join(contracts) or "—")) +w('- Managementsatz: **„Diese eine Capability erfüllt %d regulatorische Anforderungen UND ist Eintrittskarte zum OEM-Geschäft"** — überzeugender als „erfüllt %d Gesetze". (Regulatory Leverage zählt Regelwerke; **Business Leverage** zählt Regelwerke + erschlossene Märkte/Kunden.)' % (len(regs), len(regs))) +w("") + +# ── Befund ───────────────────────────────────────────────────────────────── +w("## Befund") +w("") +w('> **Eine Capability aus bis zu %d Quellen über %d Quelltypen — das Modell blieb stabil (0 neue Runtime-Klassen, 0 neue Pipeline; reine Daten).** Convergence ist messbar geworden, und %d%% der Automotive-Anforderungen bilden auf BESTEHENDE MCAPs ab — die Registry beginnt zu konvergieren. Nächster Schritt ist bewusst KEINE neue Domäne, sondern **innehalten und die Registry analysieren**: welche MCAPs tauchen domänenübergreifend (CRA·MaschinenVO·OEM·TISAX·ASPICE·Umwelt) am häufigsten auf? Diese hochkonvergenten Capabilities sind der dauerhaft wertvollste Plattformkern.' % ( + len(conv[top][0]), len(conv[top][1]), reuse_pct)) +w("") + +print("\n".join(OUT)) diff --git a/backend-compliance/tests/test_automotive_convergence_stress_test.py b/backend-compliance/tests/test_automotive_convergence_stress_test.py new file mode 100644 index 00000000..e0e85c30 --- /dev/null +++ b/backend-compliance/tests/test_automotive_convergence_stress_test.py @@ -0,0 +1,62 @@ +"""Automotive convergence stress test — the SAME capability from many sources (Phase Ω #2). + +Pins the convergence property: a realistic multi-certified supplier (ISO 9001 + IATF 16949 + TISAX + +ASPICE + CSMS + SUMS) developing an ECU for OEM X feeds the SAME capability from many overlapping +Requirement Sources, and the model stays stable (0 runtime). Checks the three new measurements: +Capability Convergence (sources x distinct types), Existing-vs-New reuse, and Business Leverage. +""" + +from __future__ import annotations + +import os +import subprocess +import sys + + +def _run(): + root = os.path.join(os.path.dirname(__file__), "..") + r = subprocess.run( + [sys.executable, "reference_scenarios/automotive_convergence_stress_test.py"], + cwd=root, env={**os.environ, "PYTHONPATH": "."}, capture_output=True, text=True, + ) + assert r.returncode == 0, r.stderr + return r.stdout + + +def test_runs_end_to_end_multi_source(): + out = _run() + assert "Automotive Convergence Stress Test" in out + assert "27 distinct geforderte Capabilities" in out + assert "0 neue Runtime-Klassen" in out + + +def test_capability_convergence_ranks_the_most_shared_cap_first(): + out = _run() + # the most convergent capability is fed by 4 sources across 3 distinct source types + assert "| `technical_vulnerability_management` | 4 | 3 |" in out + assert "| `secure_signed_update_distribution` | 4 | 2 |" in out + + +def test_existing_vs_new_reuse_signal(): + out = _run() + # 13 of 27 required caps reuse existing cyber/environmental MCAPs (registry converging) + assert "Reuse aus Cyber/Umwelt): 13/27 = 48%" in out + assert "Registry zu konvergieren" in out + + +def test_business_leverage_is_markets_plus_regulation(): + out = _run() + assert "Business Leverage" in out + assert "öffnet den **OEM-Markt**" in out + + +def test_recommends_registry_analysis_not_next_domain(): + out = _run() + assert "innehalten und die Registry analysieren" in out + assert "Plattformkern" in out + + +def test_no_real_company_names(): + out = _run().lower() + for name in ["eto", "owis", "winterhalter", "bmw", "volkswagen", "bosch"]: + assert name not in out