Benjamin Admin
78f0ffa9de
Roadmap item 4. After WHAT applies / WHAT is missing / WHICH first, the GF asks HOW. The Implementation Playbook renders, for one capability, the full journey — why / which regulations it closes / tools / process / evidence / controls — and chains the Optimization Roadmap into per-measure playbooks. Another renderer over the same Capability spine (ADR-003/004), not a new engine: ~95% of the data already exists, it just needs a different rendering. - compliance/playbook/: build_playbook() + playbooks_for_plan() (chains optimization -> playbook, acyclic; reuses leverage for "closes which regulations"). Capabilities without curated content render as honest status:missing stubs — the content-owed signal. - knowledge/implementation_playbooks/: curated knowledge layer (Reasoning Knowledge Acquisition), two deep expert drafts (SBOM, CVD/PSIRT, status draft, expert-draft-not-normative) + README. The bottleneck is now CONTENT, not software; Playbook (own knowledge) != regulatory domain. - ADR-004: Implementation Playbooks = renderer + knowledge layer; content is the bottleneck. - reference suite: "Implementation Playbook" section renders the SBOM journey + Roadmap->Playbook table (high-leverage caps flagged "fehlt (Inhalt)" — content backlog, highest leverage first). - refactor: extracted markdown helpers to reference_scenarios/_helpers.py to keep generate.py under the 500-LOC budget. 9 playbook tests (40 with optimization+transition+company), mypy --strict clean, check-loc 0. Product code with no app caller + knowledge/ADR/reference = non-runtime -> no deploy (ADR-001). 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.