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>
52 lines
3.0 KiB
Markdown
52 lines
3.0 KiB
Markdown
# 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`.
|