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