Commit Graph

2 Commits

Author SHA1 Message Date
Benjamin Admin 1a9439d013 feat(programs): open Domain Knowledge Program v1 — 7-stage production line + per-domain KPI
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>
2026-06-27 18:49:06 +02:00
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