Benjamin_Boenisch/breakpilot-compliance
1
1
Fork 0
Code Issues 24 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
b6cfc0a50371fb7ede15f70a9aea071af68461fe
breakpilot-compliance/backend-compliance/reference_scenarios/reference_scenario_suite_v1.md
T
Benjamin Admin b6cfc0a503 feat(knowledge-production): Playbook Draft Generator — prepare the corpus deterministically 
The bottleneck is not content, it is knowledge PRODUCTION. Instead of writing 200 playbooks by
hand, generate drafts deterministically from data the software already owns, then have an expert
review them. Mirrors the legal pipeline (Gesetz -> Parser -> Obligation -> Review) for BreakPilot's
own knowledge: new Capability -> Registry -> Transition Pattern -> Playbook Draft Generator ->
Expert Review -> versioned Playbook.

- compliance/knowledge_production/: generate_playbook_draft(capability, requirement, control_links)
  + drafts_from_pattern(pattern) -> one PlaybookDraft per delta capability. Owned fields (why /
  closes_regulations / expected_evidence / typical_controls) are assembled with per-field provenance;
  the practitioner know-how (tools / process_steps / how_others) is left as an explicit TODO.
- DraftStatus lifecycle (Freigabestatus): draft_generated -> in_review -> reviewed -> validated ->
  proven. Deterministic, NO LLM in the core (any model enrichment stays offline/advisory/propose-only).
- ADR-005: extends "the engine does not change, the corpus grows" with "and the corpus is not written
  by hand — it is deterministically prepared, then curated".
- reference suite: "Knowledge Production" section turns the convergence pattern into 12 auto-assembled
  drafts (why/closes/evidence filled, tools/steps TODO) -> review 12 drafts, don't write 12 playbooks.

10 tests (50 with playbook/optimization/transition/company), mypy --strict clean, check-loc 0.
Product code with no app caller + ADR/reference = non-runtime -> no deploy (ADR-001). Freeze-safe.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-06-27 13:31:31 +02:00

23 KiB
Raw Blame History

Reference Scenario Suite v1

Kein Doku-Artefakt — die erste Ground Truth / Living Reference Suite. Erzeugt aus den REALEN deployten Engines (aktueller deployter main) via reference_scenarios/generate.py. Jede Architecture Coverage-Zelle ist aus dem echten Lauf ABGELEITET; sobald eine Domaene landet, kippt die Zelle automatisch (z. B. Sz2/Environmental UNSUPPORTED -> PASS). Beantwortet dauerhaft: „Ist BreakPilot besser als vor sechs Monaten?" — anhand echter Kundensituationen, nicht LOC.

Synthetische Cert->Capability-Mappings sind als ILLUSTRATIV markiert; die echte Tabelle gehoert Compliance Execution (siehe Master Capability Registry).

Szenario 1 — Maschinenbauer mit ISMS + SBOM + Remote Access

Frage: „Was gilt fuer uns, und reicht das?"

Input: Maschine, vernetzt (Remote/Cloud), Firmware, Rolle Hersteller, Maerkte EU/DE; Company: ISMS (ISO27001) + SBOM + Incident Response.

Expected Regulatory Map

Für Industrielle Verpackungsmaschine (machinery) — Maschine; vernetzt; Firmware; Rolle: manufacturer; Märkte: EU, DE gelten nach derzeitigem Stand wahrscheinlich: CRA, MaschinenVO, EMV. Unsicher (fehlende Fakten): RED, DataAct, NIS2. Ausgeschlossen: keine. Nicht abgedeckt (Regelkorpus fehlt): keine. Ermittelt: 12 registry-verlinkte Pflichten. Es wurden keine weiteren Regelwerke im aktuellen Korpus identifiziert.

  • CRA (Cyber Resilience Act (EU) 2024/2847) — Pflichten: sbom_creation, provide_security_updates, support_period_maintenance, signed_update_integrity, vuln_handling_process, coordinated_vulnerability_disclosure, exploited_vuln_reporting_authorities, user_authentication_required, no_default_credentials, event_logging_security_events, remote_access_attack_surface_min, remote_access_confidentiality_integrity
  • MaschinenVO (Maschinenverordnung (EU) 2023/1230) — Pflichten: Pflichten für dieses Regelwerk sind noch nicht registry-verlinkt.
  • EMV (EMV-Richtlinie 2014/30/EU) — Pflichten: Pflichten für dieses Regelwerk sind noch nicht registry-verlinkt.
  • unsicher RED — fehlt: Besitzt das Produkt ein Funkmodul (WLAN, Bluetooth, Mobilfunk)?
  • unsicher DataAct — fehlt: Erzeugt das vernetzte Produkt nutzbare Produkt-/Nutzungsdaten?
  • unsicher NIS2 — fehlt: Unternehmensgröße (Mitarbeiterzahl / Umsatz)?, In welchem Sektor ist das Unternehmen tätig (Anhang I/II)?, Fällt das Unternehmen als wesentliche/wichtige Einrichtung unter NIS2?
  • Overlap VULNERABILITY_HANDLING: vuln_handling_process, coordinated_vulnerability_disclosure
  • Overlap SECURITY_UPDATES: provide_security_updates, signed_update_integrity
  • 1 Nachweis repo_scan => 2 Pflichten
  • 1 Nachweis policy => 5 Pflichten
  • 1 Nachweis ticket => 3 Pflichten
  • 1 Nachweis test_report => 3 Pflichten
  • 1 Nachweis config_export => 6 Pflichten
  • 1 Nachweis pentest => 3 Pflichten

Input — Company Context (ILLUSTRATIVES Mapping: ISO27001 -> incident_response, supplier_management, asset_management)

  • candidate: cap_patch_management — declared (declaration:maschinenbau)
  • candidate: cap_incident_response — inferred (certification:ISO27001)
  • candidate: cap_supplier_management — inferred (certification:ISO27001)
  • candidate: cap_asset_management — inferred (certification:ISO27001)
  • CONFIRMED: cap_sbom_management — confirmed (Nachweis: sbom.json)

Expected Interpretation

Auslegung „5 Jahre Updates -> CRA erfuellt" -> uncertain Ihre Interpretation ist wahrscheinlich unsicher. Kein bekanntes Auslegungsmuster erkannt — bewusst keine Scheinsicherheit. Diese Auslegung betrifft kein Regelwerk Ihrer aktuellen Produkt-Map.

Expected RCI (CRA-Novelle gegen gespeicherte Baseline)

affects_product = True — 1 neu, 2 geändert, 0 entfällt, 0 bereits abgedeckt, 2 zu prüfen, 0 nicht relevant.

  • cra_new_disclosure_duty -> new (fehlende Nachweise: -)
  • sbom_creation -> changed (fehlende Nachweise: repo_scan)
  • vuln_handling_process -> changed (fehlende Nachweise: policy, ticket)

Expected Unsupported Domains

  • keine — alle getriggerten Domaenen sind im Korpus

Known Gaps: Interpretation kennt kein CRA-Muster (RS-001) · MaschinenVO/EMV-Pflichten nicht registry-verlinkt (RS-004) · cap/MCAP/Pflicht-Evidence nicht gejoint = Company-Gap (RS-003).

Architecture Coverage

Layer Status Hinweis
Company Context PASS ISO27001 + SBOM + Declaration
Product Profile PASS Maschine, vernetzt, Firmware
Navigator PASS ready_for_scope
Scope PASS CRA/MaschinenVO/EMV + 3 unsicher
Regulatory Map PASS Overlaps + 1-Nachweis-N-Pflichten
CRA Obligations PASS 12 registry-verlinkt
MaschinenVO/EMV Obligations PARTIAL Scope ja, Pflichten nicht verlinkt → RS-004
Interpretation PARTIAL kein CRA-Muster → RS-001
RCI PASS 1 neu, 2 geaendert
Company Gap TODO cap↔MCAP↔Pflicht nicht gejoint → RS-003
Environmental N/A keine Umwelt-Trigger

Szenario 2 — Industriespuelmaschine mit Abwasser/Chemikalien

Frage: „Welche Umweltbereiche sind noch nicht abgedeckt?"

Input: Maschine mit Chemikalien-Dosierung + Abwasserauslass; Umwelt-Trigger gesetzt.

Expected Regulatory Map

Für Industriespuelmaschine (machinery) — Maschine; Firmware; Rolle: manufacturer; Märkte: EU, DE gelten nach derzeitigem Stand wahrscheinlich: CRA, MaschinenVO, EMV. Unsicher (fehlende Fakten): RED, DataAct, NIS2. Ausgeschlossen: keine. Nicht abgedeckt (Regelkorpus fehlt): environment_water, chemicals, energy_resources. Ermittelt: 10 registry-verlinkte Pflichten. Es wurden keine weiteren Regelwerke im aktuellen Korpus identifiziert.

  • CRA (Cyber Resilience Act (EU) 2024/2847) — Pflichten: sbom_creation, provide_security_updates, support_period_maintenance, signed_update_integrity, vuln_handling_process, coordinated_vulnerability_disclosure, exploited_vuln_reporting_authorities, user_authentication_required, no_default_credentials, event_logging_security_events
  • MaschinenVO (Maschinenverordnung (EU) 2023/1230) — Pflichten: Pflichten für dieses Regelwerk sind noch nicht registry-verlinkt.
  • EMV (EMV-Richtlinie 2014/30/EU) — Pflichten: Pflichten für dieses Regelwerk sind noch nicht registry-verlinkt.
  • unsicher RED — fehlt: Besitzt das Produkt ein Funkmodul (WLAN, Bluetooth, Mobilfunk)?
  • unsicher DataAct — fehlt: Erzeugt das vernetzte Produkt nutzbare Produkt-/Nutzungsdaten?
  • unsicher NIS2 — fehlt: Unternehmensgröße (Mitarbeiterzahl / Umsatz)?, In welchem Sektor ist das Unternehmen tätig (Anhang I/II)?, Fällt das Unternehmen als wesentliche/wichtige Einrichtung unter NIS2?
  • Overlap VULNERABILITY_HANDLING: vuln_handling_process, coordinated_vulnerability_disclosure
  • Overlap SECURITY_UPDATES: provide_security_updates, signed_update_integrity
  • 1 Nachweis policy => 5 Pflichten
  • 1 Nachweis ticket => 3 Pflichten
  • 1 Nachweis test_report => 3 Pflichten
  • 1 Nachweis config_export => 4 Pflichten

Expected Unsupported Domains

  • environment_water (Trigger: discharges_to_wastewater) -> Abwasser-/Gewässerrecht (z. B. AbwV, WRRL) — noch nicht im Korpus.
  • chemicals (Trigger: uses_cleaning_chemicals) -> Chemikalienrecht (REACH/CLP/Detergenzien/Biozide) — noch nicht im Korpus.
  • energy_resources (Trigger: consumes_energy_or_water) -> Energie-/Ökodesign-Recht — noch nicht im Korpus.

Expected Interpretation (Umwelt -> bewusst nicht bewertet)

Ihre Interpretation ist wahrscheinlich unsicher. Kein bekanntes Auslegungsmuster erkannt — bewusst keine Scheinsicherheit. Für environment_water, chemicals liegt noch kein Regelkorpus vor — diese Aspekte werden nicht bewertet (future_corpus_needed).

Known Gaps: Abwasser/Chemikalien/Energie sind unsupported_domain — Environmental Corpus fehlt (RS-002).

Architecture Coverage

Layer Status Hinweis
Product Profile PASS Maschine + Umwelt-Komponenten
Scope PASS
Regulatory Map PASS CRA/MaschinenVO/EMV
Environmental (Abwasser/Chemikalien/Energie) UNSUPPORTED ehrlich „noch nicht im Korpus" → RS-002
Interpretation (Umwelt) PARTIAL future_corpus_needed statt Scheinsicherheit

Szenario 3 — ISO27001-zertifiziertes Unternehmen

Frage: „Welche Capabilities sind inferred, declared oder confirmed?"

ILLUSTRATIVES Mapping: ISO27001 -> incident_response, supplier_management, asset_management

Expected Company Capability Profile (4-Zustands-Trust-Model)

  • cap_incident_response — inferred (Quelle: certification:ISO27001)
  • cap_supplier_management — inferred (Quelle: certification:ISO27001)
  • cap_asset_management — inferred (Quelle: certification:ISO27001)
  • cap_patch_management — confirmed (Nachweis: patch-policy.pdf)

Expected Master Capability Registry (computed confidence, policy-versioniert)

  • ISO27001 supports MCAP-00001 -> inferred/low (policy capability-policy-v0) — computed, nicht gespeichert
  • ir-runbook.pdf confirms MCAP-00001 -> confirmed/high — nur echtes Artefakt erreicht confirmed

Known Gaps: cap_* (Company 2A) und MCAP-* (Registry) sind noch nicht verlinkt (RS-003).

Architecture Coverage

Layer Status Hinweis
Company Context PASS ISO27001 + Declaration + Evidence
Trust-State (declared/inferred/confirmed) PASS Zertifizierung nie confirmed
Master Capability Registry PASS computed confidence, policy-versioniert
cap ↔ MCAP Linking TODO zwei Vokabulare unverbunden → RS-003

Szenario 4 — Transition (RS-005 fährt JEDEN Knowledge Pattern)

Genericity-Beweis: derselbe Algorithmus trägt jeden Transition Knowledge Pattern, nicht nur den CRA.

ISO/IEC 27001 → TISAX (TP-ISMS-TISAX-v1, status=draft)

13 zu klären, 0 bereits abgedeckt, 8 vermutlich vorhanden, 5 fehlt, 0 n/a, 0 nicht im Korpus.

  • Delta zuerst (HIGH): data_protection_processing_on_behalf, prototype_protection, tisax_assessment_via_enx, tisax_label_scope_selection, vda_isa_self_assessment
  • vermutlich abgedeckt: information_security_management, access_control_and_authentication, asset_and_configuration_management, incident_management, supplier_security, cryptography, physical_security, security_awareness_training
  • Pattern getragen: ja (13 caps → 13 coverage + 13 requests)

ISO/IEC 27001 → Cyber Resilience Act (TP-ISO27001-CRA-v1, status=reviewed)

17 zu klären, 0 bereits abgedeckt, 8 vermutlich vorhanden, 9 fehlt, 0 n/a, 0 nicht im Korpus.

  • Delta zuerst (HIGH): ce_conformity_assessment_and_technical_documentation, coordinated_vulnerability_disclosure, exploited_vuln_and_incident_reporting, product_cyber_risk_assessment, public_security_advisories, sbom_creation, secure_by_default_no_default_credentials, secure_signed_update_distribution, security_update_support_period
  • vermutlich abgedeckt: incident_management, technical_vulnerability_management, supplier_security, access_control_and_authentication, cryptography, security_logging_and_monitoring, secure_development_lifecycle, asset_and_configuration_management
  • Pattern getragen: ja (17 caps → 17 coverage + 17 requests)

ISO 9001 → Cyber Resilience Act (TP-ISO9001-CRA-v1, status=draft)

13 zu klären, 0 bereits abgedeckt, 3 vermutlich vorhanden, 10 fehlt, 0 n/a, 0 nicht im Korpus.

  • Delta zuerst (HIGH): access_control_and_authentication, ce_conformity_assessment_and_technical_documentation, coordinated_vulnerability_disclosure, exploited_vuln_and_incident_reporting, product_cyber_risk_assessment, sbom_creation, secure_development_lifecycle, secure_signed_update_distribution, security_update_support_period, technical_vulnerability_management
  • vermutlich abgedeckt: document_and_change_control, supplier_evaluation, release_and_approval_process
  • Pattern getragen: ja (13 caps → 13 coverage + 13 requests)

Architecture Coverage

Layer Status Hinweis
Transition ISOIEC27001→TISAX PASS draft · 5 HIGH-Delta + 8 zu bestätigen
Transition ISOIEC27001→Cyber Resilience Act PASS reviewed · 9 HIGH-Delta + 8 zu bestätigen
Transition ISO9001→Cyber Resilience Act PASS draft · 10 HIGH-Delta + 3 zu bestätigen
RS-005.1 Renderer (Fragetext) TODO verschoben — Engine liefert nur Requests

Reference Transition Scenarios (RTS) — kanonische Regression (Soll/Ist)

Anonymisierte Archetypen (KEINE Firmennamen). Jeder RTS pinnt ein Expected Outcome; jeder Commit muss es reproduzieren (identisch oder besser). Data Act = uncertain, nie fix „gilt/gilt-nicht".

RTS-001 — Automotive supplier with a mature ISMS — embedded electronics + software, CE products, OEM supply chain

Start TISAX+ISO27001 → CRA. 17 zu klären, 0 bereits abgedeckt, 8 vermutlich vorhanden, 9 fehlt, 0 n/a, 0 nicht im Korpus.

  • Expected Delta erfüllt: ja (7/7 Soll-Delta in der Ist-Lücke)
  • Expected likely_covered erfüllt: ja
  • Data Act: Engine sagt uncertain (Soll: uncertain; nie asserted) → ok
  • MaschinenVO: Soll uncertain (Komponente, deciding: is_safety_component) → Engine asserted nicht: ok

RTS-002 — Classic machine builder with only a QMS — precision systems, CE products, no ISMS

Start ISO9001 → CRA. 13 zu klären, 0 bereits abgedeckt, 3 vermutlich vorhanden, 10 fehlt, 0 n/a, 0 nicht im Korpus.

  • Expected Delta erfüllt: ja (9/9 Soll-Delta in der Ist-Lücke)
  • Expected likely_covered erfüllt: ja
  • Data Act: Engine sagt uncertain (Soll: uncertain; nie asserted) → ok
  • MaschinenVO gilt (is_machine): Safety-Delta machine_safety_risk_assessment, mechanical_safety_and_guards, operating_instructions_and_safety_information — geringe Konvergenz ohne ISMS (RS-004 reg-map-Gate offen)

RTS-003 — Machine builder with an ISMS and networked products — connected machines that may generate usage data

Start ISO27001 → CRA. 17 zu klären, 0 bereits abgedeckt, 8 vermutlich vorhanden, 9 fehlt, 0 n/a, 0 nicht im Korpus.

  • Expected Delta erfüllt: ja (7/7 Soll-Delta in der Ist-Lücke)
  • Expected likely_covered erfüllt: ja
  • Data Act: Engine sagt uncertain (Soll: uncertain; nie asserted) → ok
  • MaschinenVO gilt (is_machine): 4/4 Safety-Delta in der Ist-Lücke (Convergence-Pattern) → ok
  • Konvergenz CRA∩MaschinenVO: 4/4 erwartete Multi-Target-Caps → ok (4 von 12 Capabilities decken >= 2 Regelwerke gleichzeitig ab (CRA + MaschinenVO).)

Architecture Coverage

Layer Status Hinweis
RTS-001 (TISAX→CRA+MaschVO) PASS 7/7 Delta-Soll · likely_covered ok · DataAct=uncertain · MaschVO=uncertain(ok)
RTS-002 (ISO9001→CRA+MaschVO) PASS 9/9 Delta-Soll · likely_covered ok · DataAct=uncertain · MaschVO=applies (geringe Konvergenz, kein ISMS)
RTS-003 (ISO27001→CRA+MaschVO) PASS 7/7 Delta-Soll · likely_covered ok · DataAct=uncertain · MaschVO=applies 4/4 Safety-Delta · Konvergenz ok

Regulatory Convergence — CRA + MaschinenVO (Cross-Regulation Capability Mapping)

Der USP: welche Capability deckt MEHRERE Regelwerke gleichzeitig? (Convergence Pattern, RTS-003-Archetyp.)

Cross-Regulation Capability Mapping (Delta): 4 von 12 Capabilities decken >= 2 Regelwerke gleichzeitig ab (CRA + MaschinenVO).

Konvergenz — diese neuen Maßnahmen decken BEIDE Regelwerke gleichzeitig:

  • ce_conformity_assessment_and_technical_documentation
  • product_cyber_risk_assessment
  • protection_against_corruption_of_safety_functions
  • secure_signed_update_distribution

Pro Regelwerk benötigt (Delta): CRA=9, MaschinenVO=7

Kundensatz: „Von den 12 neuen Maßnahmen erfüllen 4 gleichzeitig CRA und MaschinenVO." (heute liefert das praktisch kein Tool)

Architecture Coverage

Layer Status Hinweis
Regulatory Convergence Pattern PASS 2 Targets, 12 Delta-Capabilities
Cross-Regulation Capability Mapping PASS 4 von 12 Capabilities decken >= 2 Regelwerke gleichzeitig ab (CRA + MaschinenVO).

Regulatory Optimization — größter regulatorischer Hebel zuerst

Dieselbe Berechnung wie die GAP-Analyse, anderer Renderer: das Capability Delta (RS-005) wird nach regulatorischem Hebel priorisiert (eine Maßnahme schließt N Regelwerke gleichzeitig). Welt-1: % über die IDENTIFIZIERTEN Anforderungen, kein Compliance-Urteil.

Kompression: 16 identifizierte Anforderungen aus 2 Regelwerken -> 12 Massnahmen (Ø Hebel 1.3).

Top-Maßnahmen nach regulatorischem Hebel (Roadmap):

# Maßnahme Hebel deckt kumuliert
1 ce_conformity_assessment_and_technical_documentation 2 CRA+MaschinenVO 2/16 (12%)
2 product_cyber_risk_assessment 2 CRA+MaschinenVO 4/16 (25%)
3 protection_against_corruption_of_safety_functions 2 CRA+MaschinenVO 6/16 (38%)
4 secure_signed_update_distribution 2 CRA+MaschinenVO 8/16 (50%)
5 coordinated_vulnerability_disclosure 1 CRA 9/16 (56%)
6 exploited_vuln_and_incident_reporting 1 CRA 10/16 (62%)

Managementsatz: „Wenn Sie zuerst diese 5 Maßnahmen umsetzen, schließen Sie 9 von 16 identifizierten Anforderungen (56%) — höchster regulatorischer Hebel." (Hebel skaliert mit jedem weiteren Regelwerk/Convergence-Pattern.)

Eine Wahrheit, zwei Renderer: dasselbe Capability Delta liefert dem Auditor Fragen (Interview) und dem GF Maßnahmen (Roadmap).

Architecture Coverage

Layer Status Hinweis
Capability Delta Engine (RS-005) PASS ein Delta, mehrere Renderer
Roadmap/Management Renderer (Hebel) PASS 16 identifizierte Anforderungen aus 2 Regelwerken -> 12 Massnahmen (Ø Hebel 1.3).
Budget-Priorisierung PASS Top-5 → 56% der identifizierten Anforderungen

Implementation Playbook — wie komme ich dort hin? (Berater-Renderer)

Nach „was fehlt?" (Delta) und „womit anfangen?" (Hebel) die nächste Ebene: wie umsetzen? Pro Maßnahme eine komplette Reise aus kuratiertem Wissen + Hebel + (injizierten) Execution-Links. Inhalt ist der Engpass, nicht die Software.

Reise pro Maßnahme (aus der Roadmap): 2 von 12 Maßnahmen haben ein Playbook; 10 brauchen noch Inhalt (Knowledge Acquisition).

Beispielreise — sbom_creation (draft, schließt CRA)

Warum? Der CRA verlangt von Herstellern, die Komponenten ihres Produkts zu identifizieren und zu dokumentieren (Schwachstellenbehandlung, Annex I Teil II). Eine SBOM ist das maschinenlesbare Inventar aller (auch transitiven) Software-Bestandteile mit Version und Lizenz. Ohne SBOM kann niemand verlässlich sagen, welche Produkte von einer neuen Schwachstelle (CVE) betroffen sind — SBOM ist damit die Voraussetzung für Schwachstellenüberwachung, Security-Updates und Meldepflichten.

  • Tools: CycloneDX (Format, OWASP), SPDX (Format, Linux Foundation), Syft (Generator, Container/Filesystem), cdxgen (Generator, Multi-Ökosystem), Trivy (Generator + Scan), OWASP Dependency-Track (Verwaltung + kontinuierliche Überwachung)
  • Prozess: Format festlegen → Automatisch im Build erzeugen → Transitive Abhängigkeiten + Versionen + Lizenzen erfassen → Pro Release versionieren und ablegen → An Schwachstellenüberwachung anbinden → Release-Gate setzen
  • Nachweise: Maschinenlesbare SBOM (CycloneDX/SPDX) je ausgelieferter Produktversion, CI-Job-Konfiguration, die die SBOM automatisch erzeugt, Dependency-Track-Projekt (oder gleichwertig) mit laufender Überwachung
  • Wie andere es tun: Verbreitete Praxis: CycloneDX automatisch in der CI via Syft/cdxgen erzeugen und nach OWASP Dependency-Track pushen, das kontinuierlich gegen neue CVEs prüft. Reifere Organisationen gaten Releases auf das Vorhandensein einer SBOM und teilen sie auf Anfrage mit Kunden/Behörden.

Roadmap → Implementation (Top-Maßnahmen nach Hebel):

Maßnahme Hebel schließt Playbook
ce_conformity_assessment_and_technical_documentation 2 CRA+MaschinenVO fehlt (Inhalt)
product_cyber_risk_assessment 2 CRA+MaschinenVO fehlt (Inhalt)
protection_against_corruption_of_safety_functions 2 CRA+MaschinenVO fehlt (Inhalt)
secure_signed_update_distribution 2 CRA+MaschinenVO fehlt (Inhalt)
coordinated_vulnerability_disclosure 1 CRA ✓ draft
exploited_vuln_and_incident_reporting 1 CRA fehlt (Inhalt)

Derselbe Capability-Strang, neuer Renderer: aus Diagnose wird Beratung. Die fehlt-Einträge sind der ehrliche Content-Backlog (höchster Hebel zuerst befüllen).

Architecture Coverage

Layer Status Hinweis
Implementation Playbook Renderer PASS Reise pro Capability (why/tools/process/evidence/controls)
Roadmap → Playbook (Verkettung) PASS 2/12 Maßnahmen mit Playbook
Playbook-Inhalt (Knowledge) TODO 10 Capabilities brauchen noch Inhalt

Knowledge Production — Playbook-Entwürfe automatisch assemblieren

Der Engpass ist nicht Content, sondern Wissensproduktion. Der Corpus wird nicht von Hand geschrieben, sondern deterministisch aus vorhandenen Daten (Transition Pattern + Leverage + injizierte Controls) vorbereitet — dann fachlich kuratiert (wie Gesetz→Parser→Obligation→Review).

Aus 1 Pattern → 12 Playbook-Entwürfe (status: draft_generated): eigene Felder (Warum/schließt/Nachweise) aus den Daten gefüllt, der Experte ergänzt nur Tools/Prozess/How-others.

Beispiel-Entwurf — sbom_creation (draft_generated)

  • Warum (aus Pattern): CRA requires an SBOM; MaschinenVO does not.
  • schließt CRA · Nachweise sbom
  • Provenance: why←transition_pattern:why_asked, closes_regulations←leverage:covers_targets, expected_evidence←transition_pattern:expected_evidence
  • TODO (Experte/Offline-Propose): tools, process_steps, how_others_do_it

So reviewt der Experte 12 Entwürfe statt 12 Playbooks zu schreiben. Derselbe Generator bereitet später ISO14001-/IATF-Entwürfe vor, sobald der Corpus da ist.

Architecture Coverage

Layer Status Hinweis
Playbook Draft Generator (deterministisch) PASS 12 Entwürfe aus 1 Pattern, kein LLM im Kern
Provenance + TODO + Freigabestatus PASS draft_generated→reviewed→validated→proven
Draft-Generatoren neue Domänen (Phase A) TODO Transition-/Reference-Scenario-Drafts

Gaps → Epics (Backlog — nur erfasst, NICHT implementiert)

Epic Titel schliesst Coverage-Luecke
RS-001 Interpretation Pattern Library Sz1 Interpretation PARTIAL -> PASS (CRA-Muster)
RS-002 Environmental Corpus (Pilotdomaene) Sz2 Environmental UNSUPPORTED -> PASS
RS-003 Capability Linking (cap↔MCAP) + Company-Gap Sz1/Sz3 Company Gap TODO -> PASS
RS-004 MaschinenVO/EMV Registry Linking Sz1/Sz2 MaschinenVO/EMV PARTIAL -> PASS

Suite-Status (Roll-up)

  • Coverage-Zellen gesamt: 38
  • PASS: 28 · PARTIAL: 3 · UNSUPPORTED: 1 · TODO: 5 · N/A: 1 · NEEDS_FACTS: 0
  • Fortschritt = PASS-Anteil steigt, wenn Epics RS-001…004 landen (objektiver Maßstab, kein LOC).
Reference in New Issue View Git Blame Copy Permalink