Benjamin Admin
80f2e2f619
Medical before Payment: the harder scientific test (safety AND security coupled, full lifecycle, deep risk/evidence demands). ISO 13485 runs through the SAME engine as ISO 27001 -> CRA, only new data, 0 runtime. The key result: IEC 81001-5-1 (health-software security) pulls in the SAME security MCAPs as the CRA, so Medical REUSES cyber capabilities (the safety/security coupling appears as capability reuse) while adding 7 genuinely new medical caps (clinical evaluation, software safety classification, ISO 14971 risk file, benefit-risk). rejected_assumptions intact. Effect on the convergence core: secure_signed_update_distribution 18 -> 24 and technical_vulnerability_management 17 -> 23, now spanning 3 domains (cyber + industrial + medical) — the core visibly GROWS, exactly the convergence signal. New 5th report: MISSING CONVERGENCE — deterministic (no ML) token-cluster detector for potential structural duplications: a name token shared by >=3 MCAPs across >=2 distinct sources is flagged for EXPERT REVIEW (never auto-merged). Surfaces e.g. the `risk` cluster (6 risk MCAPs across 6 sources) and `security`/`software`; single-source decompositions are filtered out. Complements Suspicious by looking at cross-source duplication, not single MCAPs. Also records the durable modelling rule extracted from the frequency fix: evidence is attributed to its ORIGIN; its value against a target is computed later (relevance(evidence,target)). Ledger now 8 sources, Architecture Stability 8/8 = 100%. Non-runtime -> no deploy. 29 tests pass, check-loc 0.
41 lines
3.5 KiB
Markdown
41 lines
3.5 KiB
Markdown
# 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 | ✅ |
|
|
| ISO 13485 -> Medical device (MDR / IEC 62304 / ISO 14971 / IEC 81001-5-1) | non_cyber | 0 | 0 | 7 | ✅ |
|
|
|
|
- **Architecture Stability: 8/8 = 100%** der Quellen ohne neue Runtime-Klasse und ohne neue Pipeline.
|
|
- **Knowledge Velocity: 8/8 = 100%** der Quellen **data-only** integriert (kein Entwickler nötig).
|
|
- **Generalität über Cyber hinaus: 2/8 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: 66 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)
|
|
1. **Musste für eine neue Domäne Runtime-Code geändert werden?** → bisher: **nein** (8/8).
|
|
2. **Knowledge Velocity** — neues Wissen ohne Entwickler aufnehmbar? → bisher: **ja** (8/8 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.
|
|
|