# 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`.