Benjamin Admin
98f67e75d9
Turn the architecture inside-out: instead of refining classes/registries/journeys, force the whole
platform to behave as ONE expert system and run a real consulting project end-to-end — measuring how
often the consultant has to "jump" (special-case glue instead of a clean engine-to-engine handoff). A
Reference Scenario asks "is the knowledge correct?"; a Customer Mission asks "can a customer WORK with
it?". This is the last big architecture test before broad corpus expansion.
- reference_scenarios/mission_machine_builder.py: a synthetic machine builder (ISO9001 + ISMS + CE +
PLC + remote maintenance + cloud + 80 devs + EU; no real names) asks "what must I do in the next 6
months?". Runs the REAL engines: Regulatory Map -> Journey selection -> Capability Delta (RS-005) ->
Roadmap (leverage) -> Playbooks -> Evidence -> Verification -> Completeness, and produces the 6-month
consulting answer ("the top-5 measures close 9/16 = 56%, starting with the ones that satisfy CRA AND
MaschinenVO at once").
- Flow-Continuity audit (the actual test): 5 CLEAN, 2 JUMPS, 2 deliberate DEPENDENCIES. The two real
seams: (1) Scope -> Journey (no `certs x targets -> journeys` selector engine; the data exists in
transitions.yaml, only the selection is glue); (2) Evidence -> Verification (parked, Vision V2). The
two dependencies (cert->capability map @Execution, corpus_status curation) are intended ownership
boundaries, not architecture breaks.
- Finding: the platform carries the WHOLE consulting flow end-to-end. Once the Scope->Journey selector
exists, the foundation is essentially done — from there the work is knowledge, not architecture.
4 end-to-end tests (mission runs, exactly two known jumps, full flow present, no real company names).
check-loc 0. Non-runtime harness -> no deploy (ADR-001).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
63 lines
5.7 KiB
Markdown
63 lines
5.7 KiB
Markdown
# Customer Mission #1 — Maschinenbauer: „Was muss ich in den nächsten 6 Monaten tun?"
|
||
|
||
_KEINE Demo, KEIN Reference Scenario — eine vollständige Simulation eines Beratungsprojekts mit den ECHTEN Engines. Gemessen wird, wie oft der Berater „springen" muss (Sonderlogik statt sauberem Engine-Fluss). Synthetischer Kunde, keine echten Namen._
|
||
|
||
## Der Kunde (synthetisch)
|
||
> ISO 9001 · ISMS (ISO 27001) · CE-Prozess · SPS · Fernwartung · Cloud · 80 Entwickler · Export EU
|
||
> **Eine Frage:** „Was muss ich in den nächsten sechs Monaten tun?"
|
||
|
||
## 1. Scope — was gilt? _(Regulatory Map)_
|
||
- **Gilt:** CRA, MaschinenVO, EMV
|
||
- **Unsicher (Rückfrage):** RED, DataAct, NIS2
|
||
- **Overlaps:** VULNERABILITY_HANDLING, SECURITY_UPDATES
|
||
|
||
## 2. Journey — welche Übergänge? _(aus Zertifikaten + Zielen)_
|
||
- Hat **ISO 27001 + ISO 9001**, Produkt = vernetzte Maschine → Ziel **CRA + MaschinenVO**.
|
||
- Gewählte Journey: **ISO 27001 → CRA + MaschinenVO** (Convergence-Pattern) + QM-Seite ISO 9001 → MaschinenVO.
|
||
- ⚠️ Die Übergänge stehen als DATEN in `knowledge/programs/transitions.yaml`, aber **keine Engine wählt sie aus Zertifikaten+Zielen** — hier manuell selektiert.
|
||
|
||
## 3. Capability Delta — was fehlt? _(Company 2A + RS-005)_
|
||
> 17 zu klären, 0 bereits abgedeckt, 5 vermutlich vorhanden, 12 fehlt, 0 n/a, 0 nicht im Korpus.
|
||
- Vermutlich vorhanden (aus ISMS, Welt 1): incident_management, technical_vulnerability_management, access_control_and_authentication, secure_development_lifecycle …
|
||
- Fehlt (Delta): 12 Capabilities, z. B. ce_conformity_assessment_and_technical_documentation, coordinated_vulnerability_disclosure, exploited_vuln_and_incident_reporting, machine_safety_risk_assessment …
|
||
|
||
## 4. Roadmap — was zuerst? _(Optimization, größter Hebel)_
|
||
> 16 identifizierte Anforderungen aus 2 Regelwerken -> 12 Massnahmen (Ø Hebel 1.3).
|
||
- **Top-Maßnahmen:** `ce_conformity_assessment_and_technical_documentation`(2), `product_cyber_risk_assessment`(2), `protection_against_corruption_of_safety_functions`(2), `secure_signed_update_distribution`(2), `coordinated_vulnerability_disclosure`(1)
|
||
|
||
## 5. Playbooks — wie umsetzen? _(Berater-Renderer)_
|
||
- 2 von 12 Maßnahmen haben ein Playbook; 10 brauchen Inhalt (Maschinensicherheits-Playbooks @IACE delegiert).
|
||
|
||
## 6. Nachweise — was belegen? _(expected_evidence)_
|
||
- Geforderte Nachweise (Auszug): advisory_process, config_export, cvd_policy, declaration_of_conformity, machine_risk_assessment, operating_instructions …
|
||
|
||
## 7. Verification — kann ich es BEWEISEN?
|
||
- ⚠️ **Nicht gebaut** — der Verification-Layer (Evidence × Reality → bewiesen) ist Vision V2 (geparkt, Task #45).
|
||
|
||
## 8. Completeness — wie sicher/vollständig? _(auditierbar)_
|
||
> Identifiziert 6 · bewertet 2 · offen 4 · Unsicherheiten 1 · Begründung ja
|
||
- Offen/begründet: `DataAct`(query_required), `EMV`(future_corpus), `NIS2`(future_corpus), `RED`(future_corpus)
|
||
|
||
## Die 6-Monats-Antwort (Beratungsnarrativ)
|
||
|
||
> „Sie sind als Maschinenbauer von **CRA + MaschinenVO** (und EMV) betroffen; RED/Data Act/NIS2 sind erst nach **einer Rückfrage** (`generates_usage_data`) zu klären. Ihr ISMS deckt die Informationssicherheits-Seite *wahrscheinlich* ab (zu bestätigen). Offen sind **12 Maßnahmen**. **Wenn Sie in den nächsten 6 Monaten die Top-5 nach regulatorischem Hebel umsetzen, schließen Sie 9 von 16 identifizierten Anforderungen (56%)** — beginnend mit den Maßnahmen, die CRA UND MaschinenVO gleichzeitig erfüllen. Für jede gibt es ein Umsetzungs-Playbook und die geforderten Nachweise; was wir noch NICHT bewerten konnten (EMV/RED/NIS2), weisen wir transparent aus."
|
||
|
||
## Flow-Continuity-Audit — der eigentliche Test
|
||
|
||
| Übergang | Status | Befund |
|
||
|---|---|---|
|
||
| Onboarding → Scope | ✅ sauber | Regulatory Map leitet aus dem Produktprofil CRA/MaschinenVO/EMV ab; RED/DataAct/NIS2 unsicher. |
|
||
| Scope → Journey | ⚠️ SPRUNG | Kein Selektor-Engine `certs × applicable-targets → journeys` — die Journey-Wahl ist Glue (Daten existieren in transitions.yaml). |
|
||
| Journey → Capability Delta | ✅ sauber | assess_transition(Company-Profil, Required) → Coverage + Delta; sauberer Engine-Handoff. |
|
||
| Zertifikate → Capabilities (Dependency) | 🔌 Dependency | cert→capability-Map ist Execution-owned + injiziert (hier gemockt) — bewusste Ownership-Grenze, kein Architektur-Bruch. |
|
||
| Capability Delta → Roadmap | ✅ sauber | roadmap_from_delta(assessment, covers_targets) → Maßnahmen nach Hebel; sauber. |
|
||
| Roadmap → Playbook | ✅ sauber | playbooks_for_plan(plan, knowledge) → Reise je Maßnahme; fehlender Inhalt = ehrliche `missing`-Stubs. |
|
||
| Playbook → Evidence | ✅ sauber | expected_evidence trägt aus Pattern/Playbook durch — Datenfeld, kein Bruch. |
|
||
| Evidence → Verification | ⚠️ SPRUNG | Verification-Layer fehlt (bewusst geparkt, Vision V2 / Requirements Verification Platform). |
|
||
| Completeness (Dependency) | 🔌 Dependency | corpus_status (welche Regelwerke validiert) wird kuratiert/injiziert, nicht aus dem Korpus abgeleitet. |
|
||
|
||
**5 sauber · 2 Sprünge · 2 bewusste Dependencies.**
|
||
|
||
**Befund:** Die Plattform trägt den **gesamten Beratungsfluss** end-to-end — von der Kundenfrage bis zur priorisierten 6-Monats-Maßnahmenliste mit Playbooks, Nachweisen und ehrlicher Vollständigkeit. **Genau ZWEI echte Sprünge:** (1) **Scope → Journey** — es fehlt ein Selektor-Engine `Zertifikate × Ziele → Journeys` (die Daten existieren, nur die Auswahl ist Glue); (2) **Evidence → Verification** — bewusst geparkter Layer (Vision V2). Die zwei Dependencies (cert→capability-Map @Execution, corpus_status-Kuratierung) sind gewollte Ownership-Grenzen, keine Architektur-Brüche. → **Wenn der Scope→Journey-Selektor steht, ist das Fundament im Wesentlichen fertig; ab dann ist die Arbeit Wissen, nicht Architektur.**
|
||
|