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>
5.7 KiB
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.