Files
breakpilot-compliance/docs-src/architecture/adr/ADR-008-from-architecture-to-domains.md
T
Benjamin Admin 9c02c2c4a2 feat(programs): start the Environmental Knowledge Program — domains, not architecture
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>
2026-06-27 14:36:03 +02:00

3.4 KiB

ADR-008: From architecture to domains — Phase B as law-first Knowledge Programs

Kontext

Die Plattform ist außergewöhnlich vollständig: Produkt-/Company-Profil, Scope, Regulatory Map, Interpretation, Capability Registry, Capability Delta, Optimization, Playbooks, Knowledge Intake, Knowledge Production, Regulatory Completeness, Reference Scenarios. Der Engpass ist nicht mehr Software, sondern: „Ist das Wissen fachlich richtig und vollständig?"

Damit endet die Plattformentwicklung und die eigentliche Wissensentwicklung beginnt. Der Wettbewerbsvorteil entsteht ab jetzt aus Qualität und Tiefe des Korpus, nicht aus mehr Software.

Entscheidung

  1. Die Runtime-Architektur wird bewusst stabil gehalten. Kein weiteres Runtime-Framework. Phase B fügt KEINE Architektur hinzu — sie fügt Domänen (Daten + Wissen) hinzu.

  2. Phase B wird in Domain Knowledge Programs organisiert, nicht in einzelne Regelwerk-Features. Jedes Programm liefert dieselbe Produktionsstraße: Regulatory Corpus → Obligations → Capabilities → Transition Patterns → Playbooks → Reference Scenarios → Completeness. Geplant: Environmental · Automotive · OT/IEC 62443 · Functional Safety.

  3. Law-first. Ein Managementsystem (z. B. ISO 14001) ist NICHT die Domäne, sondern ein möglicher Quellzustand. Reihenfolge: Recht → Obligations → Capabilities → (Managementsystem) → Delta. Der Kunde fragt „welche Anforderungen gelten für mein Produkt?", nicht „wie komme ich von ISO 14001 weg?". Das Quellzustand→Korpus-Transition-Pattern entsteht ZULETZT, wenn beide Seiten bekannt sind.

  4. Erstes Programm: Environmental Knowledge Program (knowledge/programs/environmental.yaml), als vollständige Domäne mit denselben Artefakten wie CRA/MaschinenVO. Stufen: B1 Environmental Regulatory Corpus (Wasser/Chemikalien/Emissionen/Energie/Abfall/ Produktverantwortung — nur Recht + Pflichten) → B2 Environmental Capability ModelB3 Transition Patterns (ISO 14001 → Korpus).

Konsequenzen

  • Programme statt Features: jedes Programm ist eine maschinenlesbare Definition (programs/*.yaml), deren Stufen-Status kippt, wenn Artefakte landen. Die Reference Suite + Completeness dokumentieren den Fortschritt je Domäne automatisch (Environmental-Zelle unsupported → validated).
  • Ownership-Handoffs (Board): B1 → Legal Knowledge / Obligation Registry, B2 → Compliance Execution (Capability Registry wächst), B3 + Playbooks + Reference Scenarios → Reasoning. Keine Session baut die Artefakte einer anderen; Koordination über das Board.
  • Jede neue Domäne erweitert AUTOMATISCH Scope, Gap, Capability Delta, Optimization, Playbooks, Reference Scenarios und Completeness — ohne Änderung der Runtime-Architektur. Genau das Ziel, das der Freeze v1.0 erreichen sollte.
  • Reifegrad: bis hierher wurde Architektur gebaut; ab jetzt werden Domänen gebaut.
  • Diese ADR ist non-runtime → kein Deploy (siehe ADR-001).