Benjamin Admin
cefacb87af
The focus has shifted: no more architecture epics (the Journey Matcher was the last building block). The question is no longer "can the architecture do this?" but "where does it fail under real domain knowledge?". This operationalises the two KPIs almost nobody measures, as a non- runtime, auditable ledger: - Architecture Stability : per integrated Requirement Source — new runtime classes? new pipeline? - Knowledge Velocity : can a domain EXPERT integrate a source data-only, without a developer? A new domain is a ROW in knowledge/architecture_stability/integration_ledger.yaml (data), never a code change — so the KPI improves by adding data, which IS the proof. Current state: 6 sources across 5 target types (CRA, MaschinenVO, TISAX, Tender, OEM, Environmental) = 6/6 = 100% stability and 100% data-only. The pipeline functions are listed honestly as one-time, domain-agnostic infrastructure (now frozen), so the KPI cannot be gamed. The test is a LIVING GUARDRAIL: it fails the day a source needs runtime code, surfacing the exact moment generality breaks. Non-runtime -> no deploy. 5 tests pass, check-loc 0.
2.9 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 integrierter Anforderungsquelle: neue Runtime-Klassen? neue Pipeline?
| Quelle | Zieltyp | als | neue Runtime-Klassen | neue Pipeline | Ergebnis |
|---|---|---|---|---|---|
| Cyber Resilience Act (CRA) | regulation | transition_pattern_data | 0 | 0 | ✅ |
| Maschinenverordnung (MaschinenVO) | regulation | transition_pattern_data | 0 | 0 | ✅ |
| TISAX | certification | transition_pattern_data | 0 | 0 | ✅ |
| Public Tender (öffentliche Ausschreibung) | contract | injected_required_set | 0 | 0 | ✅ |
| OEM Specification (Lastenheft) | contract | injected_required_set | 0 | 0 | ✅ |
| Environmental / Material evidence target | environmental | injected_required_set | 0 | 0 | ✅ |
- 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).
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 (6/6).
- Knowledge Velocity — neues Wissen ohne Entwickler aufnehmbar? → bisher: ja (6/6 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.