Benjamin Admin
0b962b41fa
Fulfils the board delegation Reasoning -> IACE (line 45): expert FIRST DRAFTS for the 4 MaschinenVO capabilities the Reference-Suite playbook dashboard lists as "content missing": machine_safety_risk_assessment (ISO 12100), mechanical_safety_and_guards (ISO 14120/14119/13850/13849), operating_instructions_and_safety_information (ISO 12100 6.4 / IEC 82079), protection_against_corruption_of_safety_functions (MaschVO Annex III 1.1.9 = the CRA<->MaschinenVO cyber-safety bridge). Schema per knowledge/implementation_playbooks/README.md. status: draft (expert draft, non-normative). Includes the optional canonical_action verb-formulation (capability-is- a-verb experiment). New files only -> non-runtime, no deploy, conflict-free ride-along. Capability ids unchanged (Execution registry contract). Owner verifies + integrates. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Implementation Playbooks — curated knowledge ("wie komme ich dort hin?")
Curated implementation KNOWLEDGE in machine-readable form — not an algorithm, not runtime code.
After the Capability Delta Engine says WHAT is missing and the Optimization renderer says WHICH
measure first, a Playbook says HOW to implement one capability: why it is required, which tools and
process steps stand it up, which evidence proves it, which controls it maps to, and which regulatory
gaps it closes. The renderer is compliance/playbook/; this directory holds the content it renders.
Nothing imports these at runtime — compliance/playbook reads them and assembles a Playbook
view. Adding or curating a playbook is therefore non-runtime → no deploy (ADR-001).
Playbook vs. regulatory domain (a deliberate distinction)
- A Playbook is BreakPilot's OWN knowledge layer:
Capability → recommended approach → tools → process → typical evidence → controls. It does not introduce a new regulation. - A regulatory domain (e.g. ISO 14001 → environmental law) is a new regulatory knowledge domain (obligations, applicability), owned with Legal Knowledge / Execution.
These scale independently. Once a domain lands, every new capability it needs can immediately be embedded into the SAME playbook mechanism — which is why playbooks come first.
The bottleneck is CONTENT, not software
The renderer is small and done. The value now grows with the number and depth of playbooks.
A capability with no playbook renders as a status: missing stub (the honest "content owed" signal).
This is Reasoning's Knowledge Acquisition responsibility (same as ../transition_patterns/):
AI produces the first draft offline; BreakPilot reviews, versions and OWNS the library.
Maturity lifecycle
draft (L1) → reviewed (L2, internal) → validated (L3, domain expert) → proven (L4, field).
Curated content is an EXPERT DRAFT, never a normative requirement; tools/steps are recommended
practice, not a mandatory catalogue. Controls are injected from the Execution layer (may be
empty until linked) — no Execution data lives in the playbook content or in Reasoning product code.
Schema (per file)
id · capability_id · status · title · why · tools[] · process_steps[{title, detail}]
· expected_evidence[] · typical_controls[] (indicative) · how_others_do_it · disclaimer.
closes_regulations / leverage are NOT stored here — the renderer supplies them from the
Optimization leverage (covers_targets), so one playbook serves every regulation it closes.
Catalogue
| Playbook | Capability | status |
|---|---|---|
playbook_sbom_creation_v1.yaml |
sbom_creation | draft (L1) |
playbook_coordinated_vulnerability_disclosure_v1.yaml |
coordinated_vulnerability_disclosure (PSIRT) | draft (L1) |
Next candidates (high-leverage CRA/MaschinenVO delta): security_update_support_period ·
secure_signed_update_distribution · product_cyber_risk_assessment.