Benjamin Admin
a98076196b
The mature step after Medical is not the next domain but understanding WHY the registry converges.
Three derived views over existing data (no ML, no new architecture):
1. Why converge? — a domain matrix per cross-domain MCAP + a curated REASON (the moat: not "MCAP-X
exists" but "why MCAP-X must exist": software product / supply chain / product operation /
universal process).
2. Capability Families — ~75 MCAPs collapse to ~15 curated families (knowledge/capability_families/
families.yaml), each with the reason it is universal or domain-specific.
3. Core vs Domain — a COMPUTED property (not a new class): Core recurs across >=2 independent domains
AND source types; Domain stays in one. Medical made it obvious (new medical caps are nearly all
Domain; update/SBOM/access/logging are Core).
Non-runtime -> no deploy. 4 tests pass, check-loc 0.
49 lines
4.4 KiB
YAML
49 lines
4.4 KiB
YAML
# Capability Families — the curated WHY behind convergence (Phase Ω: understand the core, not add domains).
|
|
#
|
|
# Medical proved the registry CONVERGES: completely different worlds (clinical/MDR/patient safety) still
|
|
# surface the same capabilities at the top. The question is no longer "which MCAPs?" but "WHY do they
|
|
# recur?". The answer is that ~60-70 MCAPs reduce to a small set of FAMILIES — and each family has a
|
|
# reason it is universal. That reason is the moat: not "MCAP-0017 exists" but "why MCAP-0017 must exist".
|
|
#
|
|
# This file is CURATED INSIGHT (the reason), not computed. Assignment of a capability to a family is by
|
|
# token match, FIRST family in this order wins — so cross-cutting CORE families are checked before
|
|
# DOMAIN-specific ones. Core vs Domain itself is NOT stored here; it is COMPUTED from the data (a cap is
|
|
# Core when it recurs across independent domains + source types). `kind` below is only the family's
|
|
# expected nature, used as a hint in the report. No new runtime, no new architecture.
|
|
|
|
families:
|
|
# ── CORE families (expected to recur across domains) ──────────────────────────────────────
|
|
- {id: risk, label: "Risk", kind: core, tokens: [risk, hazard, threat],
|
|
reason: "Universeller Prozess — jede Regulierung verlangt eine Risikobeurteilung."}
|
|
- {id: update, label: "Update", kind: core, tokens: [update],
|
|
reason: "Softwareprodukt — jedes vernetzte Produkt muss sicher aktualisierbar sein."}
|
|
- {id: vulnerability, label: "Vulnerability", kind: core, tokens: [vulnerability, vuln],
|
|
reason: "Produktbetrieb — Schwächen über die Lebensdauer behandeln."}
|
|
- {id: identity_access, label: "Identity & Access", kind: core, tokens: [access, authentication, identification, credentials],
|
|
reason: "Wer/was darf — Identität und Zugriff."}
|
|
- {id: inventory, label: "Inventory & Composition", kind: core, tokens: [sbom, inventory, material, substance, substances, rxswin],
|
|
reason: "Lieferkette/Stoffstrom — was steckt im Produkt? (SBOM = Software, Stoffliste = Material)."}
|
|
- {id: supplier, label: "Supplier", kind: core, tokens: [supplier, suppliers],
|
|
reason: "Lieferantensteuerung — Verantwortung über die Kette."}
|
|
- {id: incident, label: "Incident & Reporting", kind: core, tokens: [incident, advisories, disclosure],
|
|
reason: "Vorfälle erkennen, behandeln und melden."}
|
|
- {id: monitoring, label: "Monitoring & Audit", kind: core, tokens: [monitoring, logging, surveillance, audits, audit],
|
|
reason: "Beobachtung — Betrieb und Umfeld überwachen."}
|
|
- {id: lifecycle, label: "Lifecycle & Development", kind: core, tokens: [lifecycle, development, engineer, versions],
|
|
reason: "Produkt-/Software-Lebenszyklus."}
|
|
- {id: evidence_docs, label: "Documentation & Evidence", kind: core, tokens: [document, documentation, declaration, conformity, technical],
|
|
reason: "Nachweisführung — Konformität dokumentieren."}
|
|
- {id: configuration, label: "Configuration & Asset", kind: core, tokens: [configuration, asset],
|
|
reason: "Konfiguration und Asset-Kontrolle."}
|
|
# ── DOMAIN families (expected to stay within one domain) ──────────────────────────────────
|
|
- {id: environmental, label: "Environmental/Material", kind: domain, tokens: [environmental, water, wastewater, energy, waste, emission, emissions, chemical, rohs, reach, battery, recycling, passport],
|
|
reason: "Umwelt-/Stoff-spezifisch."}
|
|
- {id: medical, label: "Medical", kind: domain, tokens: [clinical, medical, benefit, safety, classify, udi, device, capa],
|
|
reason: "Medizin-/Patientensicherheit-spezifisch."}
|
|
- {id: automotive, label: "Automotive", kind: domain, tokens: [aspice, csms, sums, cybersecurity, prototype, campaigns, ppap, apqp, functional],
|
|
reason: "Automotive-/Funktionssicherheit-spezifisch."}
|
|
- {id: machine_safety, label: "Machine Safety", kind: domain, tokens: [machine, mechanical, guards, operating, corruption],
|
|
reason: "Maschinensicherheit-spezifisch."}
|
|
- {id: process_qms, label: "Process & QMS", kind: domain, tokens: [release, change, capability, improvement, aspects, compliance, verify, design, ce]
|
|
,reason: "QM-/Prozessdisziplin."}
|