Benjamin Admin
16d6ad4122
5th machinery-safety playbook, capability ce_conformity_assessment_and_technical_ documentation — referenced by the ISO27001->CRA+MaschinenVO transition pattern and listed as content-missing. Covers MaschVO conformity assessment (Annex XI), technical file (Annex IV), EU declaration (Annex V) and CE marking; notes the CRA<->MaschinenVO integrated technical file. status: draft, with canonical_action verb. New file only -> non-runtime, no deploy, conflict-free ride-along. capability_id unchanged. 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.