docs: add existing use case context to compiler instruction
3 bestehende Ansätze (IACE deterministisch, Doc-Check LLM, Gap-Analyse regelbasiert) und was der Compiler von jedem übernimmt. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -6,6 +6,56 @@
|
||||
|
||||
---
|
||||
|
||||
## Bestehende Use Cases (WICHTIG — darauf aufbauen!)
|
||||
|
||||
Wir haben bereits 3 Use Cases gebaut, jeder mit anderem Ansatz:
|
||||
|
||||
### 1. IACE CE-Compliance (`/sdk/iace`)
|
||||
- **Ansatz:** Deterministisch, kein LLM
|
||||
- **Technologie:** Tag-basiertes Pattern Matching (Go), 1.114 Hazard Patterns, 476 Maßnahmen
|
||||
- **Flow:** Narrative Text → Parser → Tags → PatternEngine → Hazards → Mitigations → Tech-File
|
||||
- **Pfad:** `ai-compliance-sdk/internal/iace/`
|
||||
- **Learnings:** Pattern Matching skaliert und ist reproduzierbar. Kein LLM nötig für strukturierte Domänen.
|
||||
|
||||
### 2. Doc-Check Agent (`/sdk/agent`)
|
||||
- **Ansatz:** LLM-gesteuert (ZeroClaw-artig)
|
||||
- **Technologie:** LLM mit Tool Calling, RAG-Suche, binäre Prüffragen
|
||||
- **Flow:** Dokument hochladen → LLM prüft gegen Controls → pass/fail pro Frage → Report
|
||||
- **Pfad:** `backend-compliance/compliance/api/agent_doc_check_routes.py`
|
||||
- **Learnings:** LLM kann Dokumente intelligent prüfen, braucht aber klare check_questions um präzise zu sein.
|
||||
|
||||
### 3. Gap-Analyse (`/sdk/gap-analysis`)
|
||||
- **Ansatz:** Regelbasiert, kein LLM
|
||||
- **Technologie:** Go Classifier + SQL-Queries gegen MCs + Priority Engine
|
||||
- **Flow:** Produkt-Profil → Regulatory Classification → MC-Filter → IST-Zustand Assessment → Prioritätsliste
|
||||
- **Pfad:** `ai-compliance-sdk/internal/gap/`
|
||||
- **Learnings:** IST-Zustand (Normen, Zertifizierungen, Prozesse) reduziert Gaps massiv. Ohne IST = 500 Gaps, mit IST = 308.
|
||||
|
||||
### Was der Use-Case Compiler davon übernimmt
|
||||
|
||||
| Von | Übernehmen |
|
||||
|-----|-----------|
|
||||
| **IACE** | Deterministisches Pattern Matching für strukturierte Fragen, Completeness Gates als Vorlage |
|
||||
| **Doc-Check Agent** | LLM-basierte Verifikation für unstrukturierte Fragen, Tool Calling Pattern |
|
||||
| **Gap-Analyse** | MC-Filtering nach Regulation + Scope, IST-Zustand Assessment, Priority Engine |
|
||||
| **Alle drei** | Das generische Frontend-Pattern (Wizard → Fragebogen → Result) |
|
||||
|
||||
### Der Compiler ist die GENERALISIERUNG
|
||||
|
||||
IACE funktioniert nur für CE/Maschinen. Doc-Check nur für Dokumente. Gap-Analyse zeigt Gaps aber keine konkreten Fragen. Der Use-Case Compiler kombiniert alle drei Ansätze in einem generischen System das JEDEN Use Case bedienen kann:
|
||||
|
||||
```
|
||||
IACE (deterministisch) + Doc-Check (LLM) + Gap-Analyse (regelbasiert)
|
||||
↓ ↓ ↓
|
||||
Pattern Matching LLM-Verifikation MC-Filtering + IST
|
||||
↓ ↓ ↓
|
||||
└──────────── Use-Case Compiler ──────────────────────┘
|
||||
↓
|
||||
Generischer Fragebogen für JEDEN Use Case
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Problem
|
||||
|
||||
Die 13.588 MCs sind eine Wissensbasis, aber kein Produkt. Wenn ein Nutzer "Vendor Check" machen will, bekommt er 4.036 Controls — aber keine konkreten Fragen, keinen Fragebogen, keine Nachweissammlung.
|
||||
|
||||
Reference in New Issue
Block a user