Benjamin_Boenisch/breakpilot-compliance
1
1
Fork 0
Code Issues 24 Pull Requests Actions Packages Projects Releases Wiki Activity
1,651 Commits 38 Branches 1 Tag
a2332fb13de8767e680d7f71aa416c8339ea6311
Commit Graph

6 Commits

Author SHA1 Message Date
Benjamin Admin c7339e68df docs: Architekturprinzip — Ownership auf BEZIEHUNGEN, nicht Knoten + cap.*=kanonische ID 
User-Reframe (die eigentliche Reife): nicht „Session X besitzt Knoten Y", sondern jede Session
besitzt KANTEN. Edge-Ownership-Tabelle: Feature/Cert->Cap = S3 · Cap->Obligation/Procedure/
Control/Evidence = S2 · Citation-Span->Legal-Basis = S1. Kein Owner hält alle ein+ausgehenden
Kanten eines Knotens. `cap.*` = kanonische ID auf obligation_id-Niveau. Capability = EINZIGER
Knoten über 3 Welten (Recht/Produkt/Nachweis) = semantischer Mittelpunkt. Künftiger Vertrag:
Confidence/Disambiguierung bei mehreren Capabilities = Domaene 3, Domaene 2 vertraut geliefertem
cap.X. Domaene 2 ruht stabil bis Wake-up.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-06-26 22:11:43 +02:00
Benjamin Admin aaacec087c feat: Ownership-Konflikt #1 RESOLVED (Capability = geteilter Knoten) + Reasoning#1 Re-Link 
User-Entscheidung: Feature->Capability + Certificate->Capability = Session 3 (Domaene 3), NICHT
Compliance. Capability = GETEILTER Knoten: eingehende Kanten (Feature/Cert->Cap) = Domaene 3 ·
Knoten+IDs+ausgehende Kanten (Cap->Obligation/Procedure/Control/Evidence) = Domaene 2. Expliziter
Vertrag: „Domaene 2 besitzt NIE Wissen, welche Produkte/Zertifikate welche Capabilities brauchen."
+ Ownership-Tabelle in session_ownership_model_v1.md.
Reasoning#1 (Domaene 2, Registry-Kanonisierung): obligations/proposed_obligation_canonical_map.json
— 5 machine_* -> cra_machinery (re-link, Ziele validiert), 7 data_act_*/cra_* pending (Regulierung
nicht geschnitten). RE-LINK, kein Re-Mint.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-06-26 21:54:07 +02:00
Benjamin Admin 37c9b8e773 docs: Domaene-2 Wake-up-Trigger + erster Folgeauftrag Feature Coverage Report 
User-Praezisierung: Domaene 2 ruht NICHT unbestimmt. Wake-up-Trigger (EINER reicht):
Feature Graph>=200 Features · Span-Anker verfuegbar · neue Regulierung ingestiert · Runtime
kennt neue Evidence-Typen. Erster Folgeauftrag (gated auf Feature Library v1):
FEATURE COVERAGE REPORT = Wissenslueckenanalyse pro Feature (Feature->cap.*->Obligation->
Procedure->Evidence -> Coverage %; zeigt fehlende Capability/Procedure/Evidence je Feature).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-06-26 11:24:06 +02:00
Benjamin Admin 429ac957c1 docs: Feature Knowledge Graph + Sequenz (Domaene 3 Rename + Feature Library; Domaene 2 STOPP #59) 
User-Entscheidung: Domaene 3 = „Feature Knowledge Graph" (Kunden kaufen Features, nicht
Capabilities — Advisor beginnt bei „Fernwartung", nicht „cap.transport_encryption"). Besitzt
zusaetzlich Feature Library (~200-400 Features) != Product Profile. Volle Pipeline
Feature Library -> Product Profile -> Capabilities -> Obligations -> Procedures -> Controls -> Evidence.
SEQUENZ: (1) cap.*-Vertrag JETZT an Domaene 3 uebergeben (Multiplikator); (2) Domaene 3 Vollgas
(Feature->cap.*); (3) Domaene 2 STOPP bei #59 (Capability Registry STABIL, nur Bugfixes, bis
Domaene 3 den realen Bedarf zeigt); (4) Domaene 1 Re-Ingest/Spans/Citation.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-06-26 10:45:46 +02:00
Benjamin Admin 2063615d37 feat: Capability Registry v1 API-Vertrag (#59) + Ownership-Modell finalisiert 
#59 (geschaerft, User): capabilities.json -> capability_registry_v1 (contract_version 1.0):
stabile `cap.*`-IDs (NIE umbenennen) + 5 Vertragsfelder (description/guidance_basis/
realizes_obligations/required_procedures/evidence_patterns), PRODUKTNEUTRAL (keine Features).
= stabiler API-Vertrag fuer die Product->Compliance-Schnittstelle (Feature->Capability,
Session 3 mappt read-only dagegen).
session_ownership_model_v1.md RESOLVED: Legal-Owner = Re-Ingest-Session (vergibt KEINE
obligation_id, nur citation_span->legal_basis) · 4. Session -> Quality & Validation (nur
Tests, KEINE Daten) · Compliance 2 Branches DAUERHAFT (A=Build, B=Runtime). 4-Bibliotheken-
Zielbild (Legal/Product/Capability/Evidence).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-06-26 10:35:49 +02:00
Benjamin Admin 63fe2d496e docs: session_ownership_model_v1.md — Arbeitsteilung nach Modell-Besitz + 3 Vertraege 
User-Antwort auf „wie verteilen wir die Arbeit": nach BESITZ der Datenmodelle, NICHT nach
Regulierung. 3 Domaenen (Legal Knowledge / Compliance Execution / Product Knowledge), jede
besitzt EIN Modell (andere read-only). 3 Vertraege: Legal->Compliance citation_span->legal_basis ·
Product->Compliance Feature->Capability (WICHTIGSTE Schnittstelle) · Compliance->Legal
obligation_id->legal_basis. Product Knowledge Graph = naechster Meilenstein (Reasoning-Session
umfokussieren, besitzt schon CanonicalProductRegulatoryProfile+Navigator). NIS2 verschoben.
Offene Fragen: Legal-KG-Owner, IACE-4.-Session, Compliance-2-Branch-Split.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-06-26 10:23:07 +02:00