feat(programs): open Domain Knowledge Program v1 — 7-stage production line + per-domain KPI
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>
This commit is contained in:
Benjamin Admin
@@ -1,51 +1,58 @@
|
||||
# Domain Knowledge Programs — from architecture to domains
|
||||
# Domain Knowledge Program — the production line for every domain
|
||||
|
||||
**The architecture is stable. From here the value comes from DOMAINS, not more software.**
|
||||
The runtime architecture (scope, regulatory map, capability delta, optimization, playbooks, intake,
|
||||
production, completeness) is frozen. A new regulatory domain is a **data + knowledge** project that
|
||||
extends every existing view automatically — no new runtime framework (see ADR-008, Freeze v1.0).
|
||||
**The architecture is stable. From here the value comes from DOMAIN MODELLING, not more software.**
|
||||
The real bottleneck is no longer architecture or controls or even „knowledge" — it is **domain
|
||||
modelling**. Phase B is therefore organised as ONE program with sub-programs per domain, each run
|
||||
through the SAME production line. No new runtime framework (ADR-008/009, Freeze v1.0).
|
||||
|
||||
## The production line (reusable for EVERY domain)
|
||||
## The customer enters by INDUSTRY, not by regulation
|
||||
|
||||
A customer never says „explain ISO 9001". They say „I build packaging machines" / „I'm an automotive
|
||||
supplier" / „I build parking systems". So the pipeline starts at the industry:
|
||||
|
||||
```
|
||||
Regulatory Corpus → Obligations → Capabilities → Transition Patterns → Playbooks → Reference Scenarios → Completeness
|
||||
Industry → Domain Model → Requirement Sources → Requirements → Capabilities → … → Reality / Verification
|
||||
```
|
||||
|
||||
Each domain delivers the SAME artifacts. Once they land, the existing engines automatically extend:
|
||||
Scope · Gap · Capability Delta · Optimization · Playbooks · Reference Scenarios · Regulatory Completeness.
|
||||
## The 7-stage checklist (identical for EVERY domain)
|
||||
|
||||
## Law-first (a deliberate ordering)
|
||||
|
||||
Start from the **law**, not from a management system. A management system (e.g. ISO 14001) is NOT
|
||||
the domain — it is one possible source state. The customer asks *„welche Anforderungen gelten für mein
|
||||
Produkt?"*, not *„wie komme ich von ISO 14001 weg?"*. So the order is:
|
||||
|
||||
```
|
||||
Recht → Obligations → Capabilities → (Managementsystem) → Delta
|
||||
```
|
||||
|
||||
A management-system→corpus transition pattern is built LAST, once BOTH sides are known.
|
||||
|
||||
## Ownership per stage (coordinate via the board, do not duplicate)
|
||||
|
||||
| Stage | Artifact | Owner |
|
||||
| # | Stage | Owner |
|
||||
|---|---|---|
|
||||
| B1 Corpus + Obligations | legal sources, obligations registry | **Legal Knowledge / Obligation Registry** |
|
||||
| B2 Capability Model | new capabilities in the Master Capability Registry | **Compliance Execution** |
|
||||
| B3 Transition Patterns | source-state → corpus delta patterns | **Reasoning (Knowledge Acquisition)** |
|
||||
| Playbooks | implementation playbooks per capability | **Reasoning** |
|
||||
| Reference Scenarios | canonical regression + expected outcomes | **Reasoning** |
|
||||
| Completeness | corpus-status registry per domain | **Reasoning / curation** |
|
||||
| 1 | **Domain Model** (industry → what world is this?) | Reasoning / curation |
|
||||
| 2 | **Requirement Sources** (which regulations/standards/specs apply) | Legal Knowledge |
|
||||
| 3 | **Capability Registry** (capabilities the sources require) | Compliance Execution |
|
||||
| 4 | **Transition Patterns** (source-state → domain delta) | Reasoning |
|
||||
| 5 | **Playbooks** (how to implement each capability) | Reasoning |
|
||||
| 6 | **Reference Scenarios** (canonical regression + expected outcomes) | Reasoning |
|
||||
| 7 | **Completeness** (auditable coverage per domain) | Reasoning / curation |
|
||||
|
||||
## Programs (planned)
|
||||
This is the scaling mechanism: every new domain reuses the same production line; the existing engines
|
||||
(Scope, Gap, Capability Delta, Optimization, Playbooks, Reference, Completeness) extend automatically.
|
||||
|
||||
| Program | File | Status |
|
||||
|---|---|---|
|
||||
| Environmental Knowledge Program | `environmental.yaml` | started (B1 handed off) |
|
||||
| Automotive Knowledge Program | _planned_ | — |
|
||||
| OT / IEC 62443 Knowledge Program | _planned_ | — |
|
||||
| Functional Safety Knowledge Program | _planned_ | — |
|
||||
## A domain knows its typical sources → pre-onboarding HYPOTHESIS (the ETO insight)
|
||||
|
||||
Each program is a machine-readable definition (`*.yaml`) consumed by the reference suite to track its
|
||||
progress; future sessions flip stage `status` as artifacts land, and the Completeness engine reports
|
||||
the domain flipping `unsupported → validated` automatically.
|
||||
Each domain definition lists `typical_requirement_sources` and `typical_certifications`. So before
|
||||
onboarding, BreakPilot can say „this process world is *probably* present" — as a **hypothesis, not a
|
||||
truth**. We don't want to know whether an automotive supplier has ISO 9001 (everyone does); we want
|
||||
to know **which company capabilities are therefore probably already present** (feeds Company 2A as
|
||||
`inferred`, never `confirmed`).
|
||||
|
||||
## Per-domain KPI — reproducible, not marketing
|
||||
|
||||
Progress per domain is **derived from the Regulatory Completeness Engine + the actual corpus**
|
||||
(computed-not-stored): identified requirement sources · modelled capabilities · transition patterns ·
|
||||
playbooks · passed reference scenarios · consciously declared corpus gaps. Rendered as a bar
|
||||
(`Industrial ███████░░░ 70 %`). These are reproducible quality metrics — no curated numbers.
|
||||
|
||||
## Domain Knowledge Program v1 — backlog (by current customer value)
|
||||
|
||||
| Rank | Domain | File | Typical sources |
|
||||
|---|---|---|---|
|
||||
| 1 | **Industrial Automation** | `industrial_automation.yaml` | CRA · MaschinenVO · EMV · RED · Data Act · IEC 62443 · NIS2 |
|
||||
| 2 | Environmental | `environmental.yaml` | Wasser · Chemikalien · Luft · Energie · Abfall · Produktverantwortung |
|
||||
| 3 | Automotive | `automotive.yaml` | IATF · TISAX · UNECE R155/R156 · ASPICE · OEM-Lastenhefte |
|
||||
| 4 | Medical | `medical.yaml` | MDR · IEC 62304 · ISO 14971 |
|
||||
| 5 | Energy | `energy.yaml` | je nach Zielmarkt |
|
||||
|
||||
The work shifts decisively from software development to knowledge production; the competitive
|
||||
advantage now comes from the quality and breadth of the modelled domains.
|
||||
|
||||
@@ -0,0 +1,19 @@
|
||||
# Domain Knowledge Program — Automotive (backlog rank 3). A domain DEFINITION, not corpus content.
|
||||
# 7-stage progress is DERIVED from the corpus (computed-not-stored). See programs/README.md.
|
||||
|
||||
id: PROG-automotive
|
||||
name: "Automotive Domain"
|
||||
industry: "Automobilzulieferer, OEM-Zulieferkette"
|
||||
customer_entry: "Ich bin Automobilzulieferer."
|
||||
backlog_rank: 3
|
||||
rationale: "großer Markt; OEM-Lastenhefte = früher Business-Requirement-Anwendungsfall."
|
||||
status: planned
|
||||
|
||||
typical_requirement_sources: [IATF16949, TISAX, "UNECE R155", "UNECE R156", ASPICE, OEM_Lastenheft]
|
||||
typical_certifications: [ISO9001, IATF16949, TISAX, ISO27001]
|
||||
|
||||
ownership: "Stufe 1 Reasoning · 2 Legal-KG · 3 Execution · 4-7 Reasoning"
|
||||
note: >
|
||||
ISMS→TISAX-Transition-Pattern existiert bereits (Vorarbeit). UNECE R155 (Cybersecurity Management
|
||||
System) ↔ CRA = quellenübergreifender Convergence-Kandidat. OEM-Lastenheft = erster Business
|
||||
Requirement (siehe Vision V2 / Requirements Verification, NICHT jetzt).
|
||||
@@ -0,0 +1,18 @@
|
||||
# Domain Knowledge Program — Energy (backlog rank 5). A domain DEFINITION, not corpus content.
|
||||
# 7-stage progress is DERIVED from the corpus (computed-not-stored). See programs/README.md.
|
||||
|
||||
id: PROG-energy
|
||||
name: "Energy Domain"
|
||||
industry: "Energieerzeugung/-verteilung, Anlagen kritischer Infrastruktur"
|
||||
customer_entry: "Ich baue Anlagen für Energieerzeugung / kritische Infrastruktur."
|
||||
backlog_rank: 5
|
||||
rationale: "Zielmarkt-abhängig; nach den klareren Industrie-/Produkt-Domänen."
|
||||
status: planned
|
||||
|
||||
typical_requirement_sources: [NIS2, IEC62443, CRA, "netzcode/marktabhängig"]
|
||||
typical_certifications: [ISO27001, IEC62443]
|
||||
|
||||
ownership: "Stufe 1 Reasoning · 2 Legal-KG · 3 Execution · 4-7 Reasoning"
|
||||
note: >
|
||||
Stark zielmarkt-abhängig (Netzcodes, nationale Vorgaben). NIS2/IEC62443 teilen sich Capabilities
|
||||
mit Industrial Automation → Wiederverwendung wahrscheinlich hoch.
|
||||
@@ -1,57 +1,33 @@
|
||||
# Environmental Knowledge Program — a regulatory DOMAIN, not an ISO-14001 project.
|
||||
# Machine-readable program definition consumed by the reference suite to track progress.
|
||||
# Domain Knowledge Program — Environmental (backlog rank 2). A domain DEFINITION, not corpus content.
|
||||
# LAW-FIRST: Umweltrecht -> Obligations -> Capabilities -> ISO 14001 -> Delta (never the reverse).
|
||||
# 7-stage progress is DERIVED from the corpus (computed-not-stored). See programs/README.md.
|
||||
|
||||
id: PROG-environmental
|
||||
name: "Environmental Knowledge Program"
|
||||
customer_question: "Welche Umweltanforderungen gelten für mein Produkt (z. B. Industriespülmaschine)?"
|
||||
status: started # planned | started | in_progress | complete
|
||||
name: "Environmental Domain"
|
||||
industry: "Hersteller mit Umweltpflichten (z. B. Industriespülmaschinen, Anlagenbau)"
|
||||
customer_entry: "Welche Umweltanforderungen gelten für mein Produkt (z. B. Industriespülmaschine)?"
|
||||
backlog_rank: 2
|
||||
rationale: "konkreter Kundenbezug (Abwasser/Chemikalien) — direkt nach Industrial Automation."
|
||||
status: started
|
||||
|
||||
principle: >
|
||||
ISO 14001 ist KEIN Umweltrecht, sondern ein Managementsystem. Wir starten beim Recht und fragen
|
||||
erst danach, welche vorhandenen Managementsysteme davon wahrscheinlich schon etwas abdecken.
|
||||
ISO 14001 ist KEIN Umweltrecht, sondern ein Managementsystem (= ein Quellzustand). LAW-FIRST:
|
||||
erst das Recht, dann welche vorhandenen Managementsysteme davon wahrscheinlich schon etwas abdecken.
|
||||
|
||||
# the reusable production line, instantiated for this domain
|
||||
blueprint: [corpus, obligations, capabilities, transition_patterns, playbooks, reference_scenarios, completeness]
|
||||
# Stage 2 — the requirement-source areas of this domain (each becomes laws/obligations at Stage 2-3)
|
||||
typical_requirement_sources: [water, chemicals, emissions, energy, waste, product_responsibility]
|
||||
typical_certifications: [ISO14001, ISO9001] # pre-onboarding capability HYPOTHESIS (nicht Wahrheit)
|
||||
|
||||
stages:
|
||||
- id: B1
|
||||
name: "Environmental Regulatory Corpus"
|
||||
owner: "Legal Knowledge / Obligation Registry"
|
||||
status: open # handed off — not built here
|
||||
note: "Zunächst NUR Rechtsquellen + Pflichten (noch keine ISO, keine Capabilities)."
|
||||
areas: # the six environmental obligation areas the customer actually faces
|
||||
- water # Wasser / Abwasser
|
||||
- chemicals # Chemikalien (REACH/CLP)
|
||||
- emissions # Emissionen
|
||||
- energy # Energie
|
||||
- waste # Abfall
|
||||
- product_responsibility # Produktverantwortung
|
||||
# Reasoning capabilities to be modelled (Stage 3, @Execution) once the corpus lands
|
||||
target_capabilities:
|
||||
- chemical_management
|
||||
- wastewater_management
|
||||
- emissions_monitoring
|
||||
- hazardous_substance_management
|
||||
- energy_data_capture
|
||||
- environmental_incident_management
|
||||
|
||||
- id: B2
|
||||
name: "Environmental Capability Model"
|
||||
owner: "Compliance Execution"
|
||||
status: open # depends on B1; Registry grows here
|
||||
depends_on: [B1]
|
||||
capabilities:
|
||||
- chemical_management
|
||||
- wastewater_management
|
||||
- emissions_monitoring
|
||||
- hazardous_substance_management
|
||||
- energy_data_capture
|
||||
- environmental_incident_management
|
||||
|
||||
- id: B3
|
||||
name: "Transition Patterns (ISO 14001 -> Environmental Corpus)"
|
||||
owner: "Reasoning (Knowledge Acquisition)"
|
||||
status: blocked # LAST — only once both sides (corpus + capabilities) are known
|
||||
depends_on: [B1, B2]
|
||||
note: "Erst jetzt sinnvoll: ISO 14001 als Quellzustand gegen den Umwelt-Korpus (User: law-first)."
|
||||
|
||||
# once B1-B3 land these extend AUTOMATICALLY via the existing engines (no new runtime architecture)
|
||||
downstream_auto: [playbooks, reference_scenarios, optimization, scope, capability_delta, completeness]
|
||||
|
||||
acceptance: >
|
||||
Regulatory Completeness kippt `Environmental` von unsupported/open auf assessed; die sechs Bereiche
|
||||
sind als Obligations + Capabilities im validierten Korpus, das ISO-14001-Delta als Transition Pattern.
|
||||
Messbar an der Reference Suite (Environmental-Zelle UNSUPPORTED -> PASS).
|
||||
ownership: "Stufe 1 Reasoning · 2 Legal-KG (HANDOFF, nur Recht+Pflichten) · 3 Execution (HANDOFF) · 4-7 Reasoning"
|
||||
note: >
|
||||
B3 (ISO 14001 -> Korpus-Transition) entsteht ZULETZT, erst wenn Recht + Capabilities bekannt sind.
|
||||
Acceptance: Regulatory Completeness kippt `Environmental` von unsupported/open auf assessed.
|
||||
|
||||
@@ -0,0 +1,22 @@
|
||||
# Domain Knowledge Program — Industrial Automation (backlog rank 1, highest current customer value).
|
||||
# A domain DEFINITION, not corpus content. The 7-stage progress is DERIVED from the corpus by the
|
||||
# reference suite (computed-not-stored), never stored here. See programs/README.md for the checklist.
|
||||
|
||||
id: PROG-industrial-automation
|
||||
name: "Industrial Automation Domain"
|
||||
industry: "Maschinen-/Anlagenbau, Industrieautomation, Parksysteme, Verpackungsmaschinen"
|
||||
customer_entry: "Ich baue Verpackungsmaschinen / Parksysteme / Industrieanlagen."
|
||||
backlog_rank: 1
|
||||
rationale: "höchster aktueller Kundennutzen — bereits am weitesten modelliert (CRA + MaschinenVO)."
|
||||
status: in_progress
|
||||
|
||||
# Stage 2 — the requirement sources that typically apply to this industry
|
||||
typical_requirement_sources: [CRA, MaschinenVO, EMV, RED, DataAct, IEC62443, NIS2]
|
||||
|
||||
# pre-onboarding capability HYPOTHESIS (nicht Wahrheit, vgl. ETO): feeds Company 2A as `inferred`
|
||||
typical_certifications: [ISO9001, ISO27001]
|
||||
|
||||
ownership: "Stufe 1 Reasoning · 2 Legal-KG · 3 Execution · 4-7 Reasoning"
|
||||
note: >
|
||||
Diese Domäne hat den Vorlauf: CRA + MaschinenVO sind als Convergence-Pattern, RTS und Playbooks
|
||||
bereits (teilweise) im Korpus. EMV/RED/IEC62443/NIS2 sind identifiziert, aber noch nicht modelliert.
|
||||
@@ -0,0 +1,18 @@
|
||||
# Domain Knowledge Program — Medical (backlog rank 4). A domain DEFINITION, not corpus content.
|
||||
# 7-stage progress is DERIVED from the corpus (computed-not-stored). See programs/README.md.
|
||||
|
||||
id: PROG-medical
|
||||
name: "Medical Domain"
|
||||
industry: "Medizinprodukte-Hersteller, Medizintechnik"
|
||||
customer_entry: "Ich baue Medizinprodukte / Medizintechnik."
|
||||
backlog_rank: 4
|
||||
rationale: "hoher Leidensdruck (MDR), aber spezialisierter Markt → nach Industrial/Automotive."
|
||||
status: planned
|
||||
|
||||
typical_requirement_sources: [MDR, IEC62304, ISO14971, IEC60601, CRA]
|
||||
typical_certifications: [ISO13485, ISO14971]
|
||||
|
||||
ownership: "Stufe 1 Reasoning · 2 Legal-KG · 3 Execution · 4-7 Reasoning"
|
||||
note: >
|
||||
IEC 62304 (Software-Lebenszyklus) ↔ CRA secure-development = quellenübergreifender Convergence-
|
||||
Kandidat. ISO 14971 (Risikomanagement) ↔ Produkt-Risikoanalyse. Erst nach Industrial/Automotive.
|
||||
Reference in New Issue
Block a user