Benjamin Admin
18f5d0cb05
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>
94 lines
5.3 KiB
Markdown
94 lines
5.3 KiB
Markdown
# Domain Knowledge Program — the production line for every domain
|
||
|
||
**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 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:
|
||
|
||
```
|
||
Industry → Domain Model → Requirement Sources → Requirements → Capabilities → … → Reality / Verification
|
||
```
|
||
|
||
## The 7-stage checklist (identical for EVERY domain)
|
||
|
||
| # | Stage | Owner |
|
||
|---|---|---|
|
||
| 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 |
|
||
|
||
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.
|
||
|
||
## A domain knows its typical sources → pre-onboarding HYPOTHESIS (the ETO insight)
|
||
|
||
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.
|
||
|
||
## The unit of knowledge is the TRANSITION, not the law (Operational Knowledge)
|
||
|
||
Customers never ask „what's in the CRA?". They ask **„I have ISO 9001 — what do I still need for the
|
||
CRA?"**. The sellable unit is therefore the **transition** (`from → to`), not a single law and not a
|
||
single capability. `knowledge/programs/transitions.yaml` is the **Operational Knowledge backlog**: the
|
||
~20–30 transitions that are actually demanded (out of the ~N·(N−1) theoretically possible), with a
|
||
priority. Nobody buys „EMV domain"; they buy „ISO 9001 → CRA".
|
||
|
||
## Three knowledge layers
|
||
|
||
```
|
||
Regulatory Knowledge (laws · standards · guidelines)
|
||
↓
|
||
Operational Knowledge (transition patterns · playbooks · capability deltas) ← biggest differentiator
|
||
↓
|
||
Verification Knowledge (source code · SBOM · docs · architecture · processes) ← Vision V2 / Req. Verification
|
||
```
|
||
|
||
The middle layer is where we answer not just *what* is required, but *how a company gets there from its
|
||
current maturity*. That is the strongest moat.
|
||
|
||
## Transition Coverage — a second, stronger KPI
|
||
|
||
Besides per-domain maturity, the reference suite reports **Transition Coverage**: per top-transition a
|
||
status DERIVED from the transition-pattern corpus (`reviewed/validated/proven → ✅`, `draft → 🟡`,
|
||
`none → ⚪`). „ISO 9001 → MaschinenVO ⭐⭐⭐⭐⭐ but ⚪" is a far stronger product indicator than „EMV 30 %".
|
||
|
||
## A domain is a TRANSITION PROGRAM with two parallel tracks
|
||
|
||
- **Track A — breadth:** model the domain's remaining requirement sources (EMV, RED, IEC 62443, NIS2 …)
|
||
so the corpus grows. (Stage 2–3, @Legal-KG / @Execution.)
|
||
- **Track B — product:** for each newly modelled source, immediately produce the top transition
|
||
patterns + playbooks + reference scenarios → knowledge customers buy and consultants use. (Stage 4–6,
|
||
@Reasoning.) Track B turns breadth into product value continuously.
|