Benjamin Admin
cfafa31ea2
Roadmap item 5. GAP analysis and measure-prioritisation are the SAME computation: Required − Known = the Capability Delta. The Capability Delta Engine (RS-005) computes it once; renderers read that ONE delta. Interview Renderer (missing info → questions) was already built; this adds the Roadmap/Management Renderer (missing capabilities → measures ranked by regulatory leverage). - compliance/optimization/: regulatory_leverage() + select_within_budget() (pure leverage math) + roadmap_from_delta(assessment, ...) — the keystone binding optimization to the RS-005 delta (dependency optimization → transition_reasoning, acyclic; the delta engine stays hermetic). leverage(measure) = number of regulatory requirements it closes at once (e.g. patch management → CRA+MaschinenVO+IEC62443+ISO27001 = 4). No new corpus, no new meta-model class (freeze v1.0). - Welt-1 honesty: percentages are exact count ratios over the IDENTIFIED requirements (the known delta), never "% gesetzeskonform". - reference suite: "Regulatory Optimization" section runs the SAME convergence delta → ranked measures + budget answer + the management sentence "of N identified requirements you close M with the top-K measures (X%) — highest regulatory leverage". - ADR-003: Capability Delta Engine — one delta, many renderers; rename Gap → Capability Delta. 13 optimization tests (31 with transition+company), mypy --strict clean, check-loc 0. Product code with no app caller + ADR/reference = non-runtime → no deploy (ADR-001). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
57 lines
3.3 KiB
Markdown
57 lines
3.3 KiB
Markdown
# ADR-003: Capability Delta Engine — one delta, many renderers
|
||
|
||
- **Status:** Accepted
|
||
- **Datum:** 2026-06-27
|
||
- **Typ:** Architektur-Entscheidung
|
||
- **Bezug:** [ADR-002](ADR-002-transition-is-data-not-architecture.md), [`../transition-reasoning-spec-v1.md`](../transition-reasoning-spec-v1.md), Architektur-Freeze v1.0, [[transition-reasoning]], [[regulatory-intelligence-vision]]
|
||
|
||
## Kontext
|
||
|
||
GAP-Analyse („Was fehlt mir / welche Informationen brauche ich noch?") und
|
||
Maßnahmenpriorisierung („Womit soll ich anfangen?") wurden bisher als zwei Features gedacht.
|
||
Sie sind aber **dieselbe Berechnung**:
|
||
|
||
```
|
||
Required Capabilities − Known Capabilities = Capability Delta
|
||
```
|
||
|
||
`Known` entsteht aus Company Profile + Zertifizierungen + Nachweisen + beantworteten Fragen
|
||
(Company 2A). `Required` entsteht aus den Zielregelwerken (CRA, MaschinenVO, Data Act, …).
|
||
Die Differenz ist das **Capability Delta**. Erst beim Output verzweigt es sich nach Zielgruppe.
|
||
|
||
Das Risiko: das Delta in mehreren Engines getrennt neu zu berechnen (eine „Gap Engine", eine
|
||
„Roadmap Engine"). Dann driften die Sichten auseinander und es gibt mehr als eine Wahrheit.
|
||
|
||
## Entscheidung
|
||
|
||
1. **Es gibt genau EINE Capability Delta Engine** (`compliance/transition_reasoning`, RS-005).
|
||
Sie berechnet `Required − Known = Capability Delta` ein einziges Mal.
|
||
|
||
2. **Alle Zielgruppen-Outputs sind RENDERER über demselben Delta — keine zweite Berechnung:**
|
||
- **Interview Renderer** — fehlende *Informationen* → Fragen (`TransitionQuestionRequest`, gebaut).
|
||
- **Roadmap / Management Renderer** — fehlende *Capabilities* → Maßnahmen nach regulatorischem
|
||
Hebel (`compliance/optimization`, gebaut).
|
||
- **Evidence Renderer** — fehlende *Evidence* → Nachweis-Upload (später).
|
||
- **(Ticket/Control Renderer)** — fehlende *Controls* → Tickets (später).
|
||
|
||
3. **Abhängigkeitsrichtung:** Renderer hängen von der Delta-Engine ab, nie umgekehrt
|
||
(`optimization → transition_reasoning`, azyklisch). Die Delta-Engine bleibt hermetisch
|
||
(0 Fremd-Import), damit sie die einzige Quelle der Wahrheit bleibt.
|
||
|
||
4. **Begriff:** „Gap" → **„Capability Delta"**. Es beschreibt präziser, was berechnet wird
|
||
(eine Differenz von Fähigkeiten), und trägt durch alle Renderer.
|
||
|
||
## Konsequenzen
|
||
|
||
- **Eine Wahrheit, viele Sichten.** Jede neue Capability, jedes neue Regelwerk und jeder neue
|
||
Nachweis verbessert automatisch ALLE Renderer gleichzeitig — kein Sicht-Drift.
|
||
- **Kundenreise in drei Fragen, eine Datenbasis:** (1) *Was gilt für mich?* → Reasoning/Scope →
|
||
(2) *Was fehlt mir?* → Capability Delta → (3) *Womit anfangen?* → Optimierungsplan.
|
||
- **Regulatory Leverage** (Roadmap-Renderer): `leverage(Maßnahme) = Anzahl Regelwerke/Anforderungen,
|
||
die sie gleichzeitig schließt`. Ranking nach Hebel + kumulative Abdeckung + Budget-Auswahl.
|
||
- **Welt-1-Disziplin:** der Prozentwert des Roadmap-Renderers ist ein exakter Abzählwert über die
|
||
**identifizierten** Anforderungen (bekanntes Delta), **kein** „% gesetzeskonform" (Welt 2).
|
||
- **Freeze-konform:** kein neues Metamodell, kein neuer Graph — Renderer sind reine, deterministische
|
||
Sichten (computed-not-stored). Neue Regelwerke bleiben ein Datenproblem (ADR-002).
|
||
- Diese ADR ist non-runtime → kein Deploy (siehe [ADR-001](ADR-001-runtime-deploy-policy.md)).
|