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

4 Commits

Author SHA1 Message Date
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