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>
Before the next Journey: the LANGUAGE. With 5 knowledge objects but no vocabulary, the same reise gets
named four different ways (ISO9001->MaschinenVO vs Quality Management->Product Safety vs ...). The spec
answers ONE question: which terms are IDENTITIES and which are REPRESENTATIONS of the same meaning?
- spec docs-src/architecture/domain-vocabulary-spec-v1.md (PROPOSAL): identity hierarchy
(Requirement RQ / Capability MCAP [Registry 2C] / regulation-source-target / Journey Class MJRN
[PROVISIONAL] / Journey instance / Playbook MPLB); canonical name + aliases; capability vocabulary =
the Capability Registry (not rebuilt); reorder Vocabulary -> Transition #2 -> #3 -> Rule of Three.
- knowledge/vocabulary/regulations.yaml: regulation/standard IDENTITIES (id + canonical + aliases).
SOLVES the regulation-ID normalization the KPIs flagged: CRA == "Cyber Resilience Act" == "Regulation
(EU) 2024/2847" all resolve to `cra`; ISO9001/QMS -> iso9001; etc. Shared artifact (@Legal-KG/@Execution
please adopt).
- knowledge/vocabulary/journey_classes.yaml (PROVISIONAL): clusters our transitions into classes
(Information Security -> Product Cybersecurity; Quality Management -> Product Compliance/Safety).
Finding: ISO9001->MaschinenVO is an INSTANCE of an existing class (like ISO9001->CRA, ISO13485->MDR),
not a new kind -> avoids duplication. Journey Class is a new abstraction -> its own Rule of Three (no
MJRN minting yet).
- reference suite: both KPIs now read aliases from regulations.yaml instead of hard-coded maps; the
"Regelwerk-ID-Normalisierung" line flips TODO -> PASS. KPI numbers unchanged (vocab is a superset).
- Side effect = Requirements Intelligence: a Tender "Security Patch Procedure" resolves to MCAP-0017.
7 vocabulary tests (17 with domain programs), check-loc 0. Knowledge data + spec + reference harness =
non-runtime -> no deploy (ADR-001). No new module, no runtime change, no minting (Freeze).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Customers don't buy "EMV domain"; they buy "we have ISO 9001, help us with the CRA". The sellable
unit of knowledge is the TRANSITION (from -> to), not the law and not the capability. This reframes
the backlog from "model EMV next" to "the top demanded transitions". No new runtime framework (ADR-010).
- knowledge/programs/transitions.yaml: the Operational Knowledge backlog — the ~20-30 actually demanded
transitions (of ~N*(N-1) possible) with priority. ISO27001->CRA, ISO9001->CRA, ISO9001->MaschinenVO
(all 5-star), IEC62443->CRA, TISAX->CRA, ISO27001/IEC62443->NIS2, ISO14001->Umweltrecht.
- Transition Coverage KPI (reference suite, computed-not-stored): per transition a status DERIVED from
the transition-pattern corpus (reviewed/validated/proven -> Gold, draft -> 🟡, none -> ⚪). Honest
current state: ISO27001->CRA ✅ reviewed, ISO9001->CRA 🟡 draft, rest ⚪. Highest-priority gap =
ISO9001->MaschinenVO (the next Track-B work) — a far stronger product indicator than "EMV 30% modelled".
- Three knowledge layers documented: Regulatory -> Operational (transitions/playbooks/deltas, the
biggest differentiator) -> Verification (Vision V2). A domain is a TRANSITION PROGRAM with two tracks:
Track A breadth (model sources, @Legal-KG/@Execution) + Track B product (transitions/playbooks/RTS
per source, @Reasoning).
- ADR-010: the transition is the unit of knowledge; Transition Coverage KPI; three layers; two tracks.
10 program/transition-contract tests, check-loc 0. Knowledge data + ADR + reference harness =
non-runtime -> no deploy (ADR-001). No new module, no runtime change.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The real bottleneck is domain MODELLING. Phase B is organized as one program with sub-programs per
domain, each run through the SAME 7-stage production line. No new runtime framework, no new module
(ADR-009, Freeze v1.0) — only program data + a derived reporting view.
- Customer enters by INDUSTRY, not regulation: Industry -> Domain Model -> Requirement Sources ->
Requirements -> Capabilities -> ... -> Completeness.
- 7-stage checklist identical for every domain (Domain Model / Requirement Sources / Capability
Registry / Transition Patterns / Playbooks / Reference Scenarios / Completeness) with per-stage
ownership. README generalized to the framework.
- Each domain lists typical_requirement_sources + typical_certifications -> pre-onboarding capability
HYPOTHESIS (the ETO insight; feeds Company 2A as inferred, never confirmed).
- Backlog v1 (by customer value): 1 Industrial Automation, 2 Environmental, 3 Automotive, 4 Medical,
5 Energy. Five domain-definition shells (environmental restructured to the unified shape, law-first
preserved).
- Per-domain KPI is DERIVED from the real corpus (computed-not-stored; sources modelled / transition
patterns / playbooks / reference scenarios), NOT a curated number. Reference suite renders maturity
bars: Industrial Automation 43% (3/7 sources) leads, Environmental 0% (work ahead). Backlog (value)
and KPI (corpus state) are deliberately separated.
- ADR-009: Domain Knowledge Program framework. Honest known refinement: regulation-ID normalization
(CRA vs Cyber Resilience Act) aliased in the KPI.
7 program-contract tests (backlog order + industry-first + derived-not-stored), check-loc 0.
Knowledge data + ADR + reference harness = non-runtime -> no deploy (ADR-001).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The architecture is stable; from here the value comes from DOMAINS, not more software. Phase B is
organized as law-first Domain Knowledge Programs, each delivering the same production line: Corpus ->
Obligations -> Capabilities -> Transition Patterns -> Playbooks -> Reference Scenarios -> Completeness.
No new runtime framework (Freeze v1.0).
- knowledge/programs/README.md: reusable Domain Program blueprint (production line, per-stage ownership,
law-first ordering, planned programs Environmental/Automotive/IEC62443/Functional-Safety).
- knowledge/programs/environmental.yaml: the Environmental domain as DATA. Law-first: B1 Environmental
Regulatory Corpus (water/chemicals/emissions/energy/waste/product-responsibility — law + obligations
only) -> B2 Capability Model -> B3 Transition Patterns (ISO 14001 -> corpus, built LAST). ISO 14001
is a source state, NOT the domain.
- Ownership handoffs: B1 -> Legal Knowledge, B2 -> Compliance Execution, B3+/playbooks/reference ->
Reasoning. Coordinate via the board; no session builds another's artifacts.
- reference suite: "Domain Knowledge Programs" section renders the program stages + a measurable
Completeness baseline (6 areas, 0 assessed today) that flips automatically as stages land.
- ADR-008: from architecture to domains; Phase B as law-first programs; architecture frozen.
6 program-contract tests (law-first order + ownership pinned), check-loc 0. Knowledge data + ADR +
reference harness = non-runtime -> no deploy (ADR-001). No new module, no runtime change.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
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>
Roadmap item 2: the RTS now pin MaschinenVO + convergence Expected Outcomes, so the
convergence USP is a living regression, not just a one-off section.
- RTS-003 (machine + ISMS, networked): full multi-regulation archetype — maschinenvo
expected_delta + convergence expected_multi_target (links TP-ISO27001-CRA-MaschinenVO-v1).
Generator runs the convergence pattern through RS-005: 4/4 machine-safety delta MISSING +
4/4 expected multi-target caps converge. PASS.
- RTS-001 (component): MaschinenVO modeled as `uncertain` (a pure component is usually not a
machine; deciding question is_safety_component) — engine must never assert it applies. Honest,
parallel to the Data-Act handling.
- RTS-002 (machine, QMS-only): MaschinenVO `applies` (is_machine) but LOW convergence — no ISMS
means the cyber side is entirely delta, so few caps are shared. The honest contrast that the
convergence USP rewards companies who already run an ISMS.
- generator: per-RTS maschinenvo/convergence Soll-Ist checks; convergence pattern run once and
reused. Data Act stays `uncertain` everywhere, never asserted.
All 3 RTS PASS. 18 tests (transition+company), mypy --strict clean, check-loc 0.
Non-runtime (knowledge + reference harness) -> no deploy (ADR-001).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The first multi-regulation pattern: each capability declares `covers_targets`, so we
can answer the convergence USP — "which capability satisfies CRA AND MaschinenVO at once?"
- knowledge: transition_pattern_iso27001_to_cra_maschinenvo_v1.yaml (pattern_type:
regulatory_convergence, status draft). The cyber-safety bridge = MaschinenVO Annex III
1.1.9 "protection against corruption" overlapping CRA integrity. 4 convergence
capabilities cover BOTH; 5 CRA-only; 3 MaschinenVO-only.
- product: compliance/transition_reasoning/convergence.py — regulatory_convergence()
pure/deterministic/computed-not-stored, no new graph/class (freeze v1.0 untouched).
No app caller yet -> non-runtime, no deploy (ADR-001).
- reference suite: Cross-Regulation Capability Mapping section renders the customer
sentence "von N neuen Massnahmen erfuellen M gleichzeitig CRA und MaschinenVO".
- README: term -> Regulatory Transition / Convergence Pattern; covers_targets documented.
- tests: test_regulatory_convergence (18 transition+company pass), mypy --strict clean.
Curated expert knowledge, AI first draft (L1/draft) — Annex/Article refs indicative,
review_required by a machinery-safety expert.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Three ANONYMIZED reference transition scenarios (no real company names stored) = canonical
regression scenarios that test the KNOWLEDGE, not just the engine. Each pins an Expected
Outcome (expected_likely_covered + expected_delta); every commit must reproduce it (identical
or better).
- RTS-001 automotive supplier (TISAX+ISO27001) -> CRA: mature ISMS, standard CRA delta.
- RTS-002 classic machine builder (ISO9001) -> CRA: only process discipline -> MUCH larger delta
(10 missing vs 3 covered). New TP-ISO9001-CRA-v1 pattern (different shape).
- RTS-003 networked machine builder (ISMS) -> CRA: highlights the Data Act.
Data Act is modelled as UNCERTAIN (a hypothesis), never a fixed gilt/gilt-nicht: the generator
checks the engine SURFACES the uncertainty + the deciding question (generates_usage_data) and
never wrongly ASSERTS applicability. All three RTS PASS.
Non-runtime knowledge + reference harness -> no deploy (ADR-001). Names deliberately absent.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Transition KNOWLEDGE Patterns (renamed term -- curated knowledge, not an algorithm):
- 4 maturity levels: draft -> reviewed -> validated (domain expert) -> proven (field). "approved"
dropped; target is validated. TP-ISO27001-CRA set to reviewed (L2).
- 3 enrichments per pattern: confidence_source: relationship (curated, not an LLM estimate ->
computed-not-stored); why_asked (customer-facing: why the source does not suffice here); dropped_if
(what makes the question unnecessary). Applied to TP-ISO27001-CRA.
- New TP-ISMS-TISAX (draft): different character -- info-security module mostly covered; delta is
automotive-specific (prototype protection, TISAX labels, VDA ISA self-assessment, ENX assessment,
Art. 28 data protection). Proves the architecture is GENERIC, not CRA-tailored.
- Reference scenario 4 generalized to loop over ALL patterns through RS-005: both carried (CRA
17->17, TISAX 13->13) -> a living genericity + regression test for every future pattern.
Non-runtime knowledge + reference harness -> no deploy (ADR-001). Next: ISO9001->IATF16949.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
(1) Harden the first Transition Pattern to the gold-standard template per quality checklist:
versioned transition_goal (ISO27001:2022 -> CRA, applies 2027-12-11), source_state_variants
(certified/isms_introduced/expired/limited_scope), each likely_covered assumption with a typed
relationship (supports|partially_supports, never equivalent) + verification + rationale (the Warum)
+ an auditor-checkable reviewable_claim, delta as missing-capability + needed-info, an explicit
rejected_assumptions section, and a determinism_goal. README schema updated to match.
(2) New Reference-Suite scenario 4 (Transition): the generator READS the pattern YAML and runs it
through the RS-005 Planning Engine + Company 2A -> coverage + question requests. Proves the
architecture fully carries the pattern (17 caps -> 17 coverage + 17 requests; 9 HIGH delta = the
real CRA gaps, 8 probably-covered from the ISMS). Now a living regression test: every future pattern
runs through the same engine.
Non-runtime knowledge + reference harness -> no deploy (ADR-001). Next: ISMS->TISAX once approved.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Reasoning session's new Knowledge Acquisition responsibility (re-charter): build and curate
the Transition Knowledge Base under backend-compliance/knowledge/transition_patterns/ (beside
reasoning/, not under it -- it is knowledge, not an engine).
First professional pattern TP-ISO27001-CRA-v1 (status: draft): separates what a mature ISMS
likely covers at the ORG level (probably_covered, needs product-level confirmation, never
auto-"erfuellt") from the CRA-specific delta with no ISO 27001 analogue (SBOM, support period +
secure signed updates, coordinated vulnerability disclosure, Art. 14 authority reporting,
product cyber risk assessment, CE conformity / technical documentation). Expert draft, not a
normative proof; review_required before customer use.
Non-runtime knowledge -> no deploy (ADR-001). Next: ISMS->TISAX.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Benjamin Admin