Benjamin Admin
1a9439d013
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>
59 lines
3.4 KiB
Markdown
59 lines
3.4 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.
|