Benjamin Admin
90c3fe16b5
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.
3.4 KiB
3.4 KiB
Architecture Stability + Knowledge Velocity — Phase Ω (Evidence of Generality)
Der Fokus hat sich verschoben: nicht mehr „kann die Architektur das?", sondern „wo versagt sie bei echtem Fachwissen?". Diese zwei KPIs erhebt kaum jemand. Eine neue Domäne ist eine ZEILE im Ledger (Daten), nie eine Codeänderung — genau das macht den KPI auditierbar.
Architecture Stability — pro Quelle: neue Runtime-Klassen? neue Pipeline? neue Capability-Typen?
| Quelle | Familie | neue Runtime-Klassen | neue Pipeline | neue Capability-Typen | Ergebnis |
|---|---|---|---|---|---|
| Cyber Resilience Act (CRA) | cyber | 0 | 0 | 13 | ✅ |
| Maschinenverordnung (MaschinenVO) | cyber | 0 | 0 | 4 | ✅ |
| TISAX | cyber | 0 | 0 | 5 | ✅ |
| 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: 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). - Die letzte (
journey_matcher) war der letzte architektonische Baustein (ADR-011). Ab hier: Wissensarbeit, nicht Architektur.
Drei saubere Wissensebenen (greifen ineinander, vermischen sich nicht)
| Ebene | Inhalt |
|---|---|
| Beschreibend (was IST) | Requirements, Capabilities, Evidence |
| Transformation (wie BEWEGEN) | Delta, Journey, Roadmap |
| Produktion (wie TUN/BEWEISEN) | Playbooks, Verification, Reference Scenarios |
Die drei Erfolgsfragen ab jetzt (statt Coverage)
- Musste für eine neue Domäne Runtime-Code geändert werden? → bisher: nein (7/7).
- Knowledge Velocity — neues Wissen ohne Entwickler aufnehmbar? → bisher: ja (7/7 data-only).
- 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 → Verificationunverä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.