Freeze Obligation Registry v1 spec (citability + two-graph)
Schreibt das Zielmodell fest: Legal Obligation = gemeinsame Sprache zwischen Legal Knowledge Graph (Chat) und Compliance Execution Graph (Engine). - Registry-Schema v1 (id/tier/legal_basis/guidance_basis/facets/citation_anchor_ids/ relationships/decision_method) - Zitierfähigkeit hängt an der OBLIGATION, nicht an Controls (Regulierungsänderung = Anchor tauschen, Controls unverändert) - legal_basis (Primärrecht) vs guidance_basis (NIST/OWASP/...) + source_role (LEGAL_BASIS/GUIDANCE/EVIDENCE/IMPLEMENTATION/OUT_OF_SCOPE) - HARTE Regel: LEGAL_MINIMUM nur mit Primärrechts-Anker - Beziehungsgraph: requires/implements/supports/produces_evidence_for/depends_on/derived_from - Citation-Anchor-Pipeline Document→Obligation (KEIN Re-Ingest zum Control-Neubau) Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
Benjamin Admin
@@ -0,0 +1,130 @@
|
||||
# Obligation Registry v1 — Schema, Zitierfähigkeit, Zwei-Graphen-Architektur
|
||||
|
||||
Status: **Spec festgeschrieben (2026-06-24)**. Baut auf
|
||||
[legal_obligation_layer_v1.md](legal_obligation_layer_v1.md) +
|
||||
[obligation_aggregation_validation.md](obligation_aggregation_validation.md).
|
||||
Die Obligation Discovery Pipeline v1 ist gegen Ground Truth validiert
|
||||
(SBOM 12 vs 10, Vuln 8 vs 7, out_of_scope + conditional Applicability korrekt).
|
||||
|
||||
## Leitsatz
|
||||
|
||||
**Die Legal Obligation ist das fachliche Wissensobjekt der Plattform** — nicht der Master
|
||||
Control. Controls sind Prüfstrategien / Erkennungsmuster / Evidenzsammler FÜR eine Obligation.
|
||||
Ohne Zitierfähigkeit ist die Registry fachlich nicht belastbar: die erste Kundenfrage ist
|
||||
immer „**Wo steht das?**".
|
||||
|
||||
## Zwei Assets, zwei Graphen, EIN Join (nicht verschmelzen, verbinden)
|
||||
|
||||
- **Asset 1 — Compliance Knowledge** (bereits gebaut): 313k atomare Controls, 33k Master
|
||||
Controls, ~14k use-case-gemappt, Dedup, Obligation Layer, Applicability, Tiering, G/C/E.
|
||||
- **Asset 2 — Zitierfähige Wissensbasis** (entsteht in anderer Session): Dokument → Chunk →
|
||||
Paragraph → Span → Zitat.
|
||||
|
||||
Die beiden werden **NICHT verschmolzen** (das wäre wie eine normalisierte DB nach CSV zu
|
||||
exportieren und neu zu importieren). Sie werden über die **Obligation gekoppelt**:
|
||||
|
||||
```
|
||||
GRAPH 1 — Legal Knowledge Graph (Chat/Advisor) GRAPH 2 — Compliance Execution Graph (Engine)
|
||||
Regulation → Annex/Artikel → Paragraph → Span Obligation → Control → Criterion → Evidence → Finding
|
||||
\ /
|
||||
\____ LEGAL OBLIGATION ______/ ← gemeinsame Sprache (der Join)
|
||||
```
|
||||
Chat: „diese Aussage stammt aus Absatz X." · Engine: „diese Obligation ist nicht erfüllt." →
|
||||
beide meinen DIESELBE `obligation_id`.
|
||||
|
||||
## Registry-Schema v1
|
||||
|
||||
```yaml
|
||||
id: # snake_case, regulierungs-agnostisch (z.B. sbom_complete)
|
||||
name: # kurz
|
||||
description: # 1 Satz
|
||||
tier: # LEGAL_MINIMUM | BEST_PRACTICE | IMPLEMENTATION_GUIDANCE | EVIDENCE
|
||||
family: # Organisationshilfe (z.B. sbom, vulnerability_handling)
|
||||
applicability: # universal | conditional:<pred> | domain:<x>
|
||||
facets: # welche Evidenz-Facetten die Pflicht belegt
|
||||
governance: bool
|
||||
capability: bool
|
||||
evidence: bool
|
||||
legal_basis: # PRIMÄRRECHT — Pflicht zwingend (mind. 1 Anker für LEGAL_MINIMUM)
|
||||
- source: CRA
|
||||
regulation_code: eu_2024_2847
|
||||
article: "" # falls zutreffend
|
||||
annex: "Annex I, Part II"
|
||||
section: ""
|
||||
paragraph: ""
|
||||
span_id: "" # harter Anker in die zitierfähige Wissensbasis (Asset 2)
|
||||
document_version: ""
|
||||
citation: "" # menschenlesbar
|
||||
guidance_basis: # SEKUNDÄR — Umsetzung/Best Practice, NICHT Pflicht
|
||||
- source: NIST SSDF
|
||||
anchor: ""
|
||||
role: best_practice # implementation_guidance | best_practice
|
||||
member_controls: # control_uuids (Prüflogik aus Asset 1)
|
||||
citation_anchor_ids: # span/paragraph-Anker (Asset 2) — auf der OBLIGATION, NICHT auf Controls
|
||||
relationships: # siehe Beziehungsgraph
|
||||
decision_method: # CONTENT/LLM | CONTENT/EMBEDDING | FIELD/REGEX | BEHAVIOR/PLAYWRIGHT ...
|
||||
out_of_scope: [] # ausgeschlossene Cluster + Begründung
|
||||
```
|
||||
|
||||
## Zitierfähigkeit hängt an der OBLIGATION (nicht an Controls)
|
||||
|
||||
258 SBOM-Controls → 11 Obligations: nur die **Obligation** speichert
|
||||
`CRA / Annex I / Paragraph X / chunk_id / span_id / document_version`. Die 258 Controls zeigen
|
||||
nur auf die `obligation_id`. Folge: **Regulierungsänderung (CRA v1→v2) = `citation_anchor`
|
||||
tauschen, Controls bleiben identisch.** Massive Pflegeersparnis + Versionsstabilität.
|
||||
|
||||
## `legal_basis` vs `guidance_basis` + `source_role`
|
||||
|
||||
Damit beim Verschmelzen von CRA + NIST + OWASP zu einer Obligation NICHT verloren geht, was
|
||||
Pflicht / Best Practice / Evidenz / Umsetzung ist, klassifiziert die Discovery-Pipeline jeden
|
||||
Member/Cluster mit einer **`source_role`**:
|
||||
|
||||
```
|
||||
LEGAL_BASIS → Primärrecht (begründet die Pflicht)
|
||||
GUIDANCE → NIST/OWASP/ENISA/BSI/ISO (Umsetzung/Best Practice)
|
||||
EVIDENCE → Nachweis/Bericht/Audit
|
||||
IMPLEMENTATION → technische Umsetzungsanweisung
|
||||
OUT_OF_SCOPE → gehört nicht zur Obligation (andere Regulierung/Domäne)
|
||||
```
|
||||
|
||||
## HARTE Tier-Regel
|
||||
|
||||
Eine Obligation wird **`LEGAL_MINIMUM` nur mit mindestens einem Primärrechts-Anker**
|
||||
(`legal_basis` nicht leer). Ohne Primärrechts-Anker:
|
||||
`BEST_PRACTICE | IMPLEMENTATION_GUIDANCE | EVIDENCE` — **aber niemals Pflicht.**
|
||||
|
||||
## Beziehungsgraph (Ontologie)
|
||||
|
||||
**Strukturell** (bereits in der Pipeline): `same_obligation`, `sub_obligation`,
|
||||
`applicability_variant`, `evidence_for`, `governance_for`, `out_of_scope`.
|
||||
|
||||
**Semantisch (NEU, P2-Ergänzung):** `requires`, `implements`, `supports`,
|
||||
`produces_evidence_for`, `depends_on`, `derived_from`. Beispiele:
|
||||
```
|
||||
sbom_established --supports--> vulnerability_handling --supports--> incident_reporting
|
||||
authentication --requires--> credential_management
|
||||
```
|
||||
→ für den Compliance Advisor extrem wertvoll (er kann Pflicht-Ketten erklären).
|
||||
|
||||
## Citation-Anchor-Pipeline (Document → Obligation, NICHT Document → Control)
|
||||
|
||||
Der neue Ingest erzeugt zusätzlich zu Chunk/Embedding: `paragraph_uuid`, `span_uuid`,
|
||||
`document_version`, `legal_citation`, `referenced_articles`, `referenced_regulations`.
|
||||
**Erst danach** läuft Obligation Discovery, sodass jede neu entdeckte Obligation sofort ihre
|
||||
Primärquelle bekommt:
|
||||
```
|
||||
Neue Dokumente → Chunking → Span IDs → LLM („welche Obligation(en)?") → Confidence
|
||||
→ Review → obligation.citation_anchor_ids[]
|
||||
```
|
||||
Die alten Controls werden wiederverwendet; die Pipeline erzeugt zusätzlich Obligation→Evidence
|
||||
und Obligation→Citation-Anchors. **Kein Re-Ingest zum Neubau von Controls.**
|
||||
|
||||
## Sequenz (geändert — Registry vor weiteren Cuts)
|
||||
|
||||
```
|
||||
SBOM ✓ → Vuln ✓ → Registry v1 (DIESE Spec) → Ontologie/Beziehungsgraph ergänzen
|
||||
→ Authentication → Remote Access → Logging → Updates
|
||||
```
|
||||
Begründung: Schema jetzt billig änderbar; bei 300–1000 Obligations wird jede Schemaänderung
|
||||
teuer. Fortschritt wird daran gemessen, ob jede neue Obligation die Registry besser macht —
|
||||
nicht an neuen Controls.
|
||||
Reference in New Issue
Block a user