Benjamin Admin
9c02c2c4a2
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>
Domain Knowledge Programs — from architecture to domains
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 production line (reusable for EVERY domain)
Regulatory Corpus → Obligations → Capabilities → Transition Patterns → Playbooks → Reference Scenarios → Completeness
Each domain delivers the SAME artifacts. Once they land, the existing engines automatically extend: Scope · Gap · Capability Delta · Optimization · Playbooks · Reference Scenarios · Regulatory Completeness.
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 |
|---|---|---|
| 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 |
Programs (planned)
| 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 | — |
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.