Each page.tsx exceeded the 500-LOC hard cap. Extracted components and hooks into colocated _components/ and _hooks/ directories; page.tsx is now a thin orchestrator. - controls/page.tsx: 944 → 180 LOC; extracted ControlCard, AddControlForm, LoadingSkeleton, TransitionErrorBanner, StatsCards, FilterBar, RAGPanel into _components/ and useControlsData, useRAGSuggestions into _hooks/; types into _types.ts - training/page.tsx: 780 → 288 LOC; extracted ContentTab (inline content generator tab) into _components/ContentTab.tsx - control-provenance/page.tsx: 739 → 122 LOC; extracted MarkdownRenderer, UsageBadge, PermBadge, LicenseMatrix, SourceRegistry into _components/; PROVENANCE_SECTIONS static data into _data/provenance-sections.ts - iace/[projectId]/verification/page.tsx: 673 → 196 LOC; extracted StatusBadge, VerificationForm, CompleteModal, SuggestEvidenceModal, VerificationTable into _components/ Zero behavior changes; logic relocated verbatim. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
405 lines
16 KiB
TypeScript
405 lines
16 KiB
TypeScript
export interface ProvenanceSection {
|
|
id: string
|
|
title: string
|
|
content: string
|
|
}
|
|
|
|
export const PROVENANCE_SECTIONS: ProvenanceSection[] = [
|
|
{
|
|
id: 'methodology',
|
|
title: 'Methodik der Control-Erstellung',
|
|
content: `## Unabhaengige Formulierung
|
|
|
|
Alle Controls in der Canonical Control Library wurden **eigenstaendig formuliert** und folgen einer
|
|
**unabhaengigen Taxonomie**. Es werden keine proprietaeren Bezeichner, Nummern oder Strukturen
|
|
aus geschuetzten Quellen uebernommen.
|
|
|
|
### Dreistufiger Prozess
|
|
|
|
1. **Offene Recherche** — Identifikation von Security-Anforderungen aus oeffentlichen, frei zugaenglichen
|
|
Frameworks (OWASP, NIST, ENISA). Jede Anforderung wird aus mindestens 2 unabhaengigen offenen Quellen belegt.
|
|
|
|
2. **Eigenstaendige Formulierung** — Jedes Control wird mit eigener Sprache, eigener Struktur und eigener
|
|
Taxonomie (z.B. AUTH-001, NET-001) verfasst. Kein Copy-Paste, keine Paraphrase geschuetzter Texte.
|
|
|
|
3. **Too-Close-Pruefung** — Automatisierte Aehnlichkeitspruefung gegen Quelltexte mit 5 Metriken
|
|
(Token Overlap, N-Gram Jaccard, Embedding Cosine, LCS Ratio, Exact-Phrase). Nur Controls mit
|
|
Status PASS oder WARN (+ Human Review) werden freigegeben.
|
|
|
|
### Rechtliche Grundlage
|
|
|
|
- **UrhG §44b** — Text & Data Mining erlaubt fuer Analyse; Kopien werden danach geloescht
|
|
- **UrhG §23** — Hinreichender Abstand zum Originalwerk durch eigene Formulierung
|
|
- **BSI Nutzungsbedingungen** — Kommerzielle Nutzung nur mit Zustimmung; wir nutzen BSI-Dokumente
|
|
ausschliesslich als Analysegrundlage, nicht im Produkt`,
|
|
},
|
|
{
|
|
id: 'filters',
|
|
title: 'Filter in der Control Library',
|
|
content: `## Dropdown-Filter
|
|
|
|
Die Control Library bietet 7 Filter-Dropdowns, um die ueber 3.000 Controls effizient zu durchsuchen:
|
|
|
|
### Schweregrad (Severity)
|
|
|
|
| Stufe | Farbe | Bedeutung |
|
|
|-------|-------|-----------|
|
|
| **Kritisch** | Rot | Sicherheitskritische Controls — Verstoesse fuehren zu schwerwiegenden Risiken |
|
|
| **Hoch** | Orange | Wichtige Controls — sollten zeitnah umgesetzt werden |
|
|
| **Mittel** | Gelb | Standardmaessige Controls — empfohlene Umsetzung |
|
|
| **Niedrig** | Gruen | Nice-to-have Controls — zusaetzliche Haertung |
|
|
|
|
### Domain
|
|
|
|
Das Praefix der Control-ID (z.B. \`AUTH-001\`, \`SEC-042\`). Kennzeichnet den thematischen Bereich.
|
|
Die haeufigsten Domains:
|
|
|
|
| Domain | Anzahl | Thema |
|
|
|--------|--------|-------|
|
|
| SEC | ~700 | Allgemeine Sicherheit, Systemhaertung |
|
|
| COMP | ~470 | Compliance, Regulierung, Nachweispflichten |
|
|
| DATA | ~400 | Datenschutz, Datenklassifizierung, DSGVO |
|
|
| AI | ~290 | KI-Regulierung (AI Act, Transparenz, Erklaerbarkeit) |
|
|
| LOG | ~230 | Logging, Monitoring, SIEM |
|
|
| AUTH | ~200 | Authentifizierung, Zugriffskontrolle |
|
|
| NET | ~150 | Netzwerksicherheit, Transport, Firewall |
|
|
| CRYP | ~90 | Kryptographie, Schluesselmanagement |
|
|
| ACC | ~25 | Zugriffskontrolle (Access Control) |
|
|
| INC | ~25 | Incident Response, Vorfallmanagement |
|
|
|
|
Zusaetzlich existieren spezialisierte Domains wie CRA, ARC (Architektur), API, PKI, SUP (Supply Chain) u.v.m.
|
|
|
|
### Status (Release State)
|
|
|
|
| Status | Bedeutung |
|
|
|--------|-----------|
|
|
| **Draft** | Entwurf — noch nicht freigegeben |
|
|
| **Approved** | Freigegeben fuer Kunden |
|
|
| **Review noetig** | Muss manuell geprueft werden |
|
|
| **Zu aehnlich** | Too-Close-Check hat Warnung ausgeloest |
|
|
| **Duplikat** | Wurde als Duplikat eines anderen Controls erkannt |
|
|
|
|
### Nachweis (Verification Method)
|
|
|
|
| Methode | Farbe | Beschreibung |
|
|
|---------|-------|-------------|
|
|
| **Code Review** | Blau | Nachweis durch Quellcode-Inspektion |
|
|
| **Dokument** | Amber | Nachweis durch Richtlinien, Prozesse, Schulungen |
|
|
| **Tool** | Teal | Nachweis durch automatisierte Scans/Monitoring |
|
|
| **Hybrid** | Lila | Kombination aus mehreren Methoden |
|
|
|
|
### Kategorie
|
|
|
|
Thematische Einordnung (17 Kategorien). Kategorien sind **thematisch**, Domains **strukturell**.
|
|
Ein AUTH-Control kann z.B. die Kategorie "Netzwerksicherheit" haben.
|
|
|
|
### Zielgruppe (Target Audience)
|
|
|
|
| Zielgruppe | Bedeutung |
|
|
|------------|-----------|
|
|
| **Unternehmen** | Fuer Endkunden/Firmen relevant |
|
|
| **Behoerden** | Spezifisch fuer oeffentliche Verwaltung |
|
|
| **Anbieter** | Fuer SaaS/Plattform-Anbieter |
|
|
| **Alle** | Allgemein anwendbar |
|
|
|
|
### Dokumentenursprung (Source)
|
|
|
|
Filtert nach der Quelldokument-Herkunft des Controls. Zeigt alle Quellen sortiert nach
|
|
Haeufigkeit. Die wichtigsten Quellen:
|
|
|
|
| Quelle | Typ |
|
|
|--------|-----|
|
|
| KI-Verordnung (EU) 2024/1689 | EU-Recht |
|
|
| Cyber Resilience Act (EU) 2024/2847 | EU-Recht |
|
|
| DSGVO (EU) 2016/679 | EU-Recht |
|
|
| NIS2-Richtlinie (EU) 2022/2555 | EU-Recht |
|
|
| NIST SP 800-53, CSF 2.0, SSDF | US-Standards |
|
|
| OWASP Top 10, ASVS, SAMM | Open Source |
|
|
| ENISA Guidelines | EU-Agentur |
|
|
| CISA Secure by Design | US-Behoerde |
|
|
| BDSG, TKG, GewO, HGB | Deutsche Gesetze |
|
|
| EDPB Leitlinien | EU Datenschutz |`,
|
|
},
|
|
{
|
|
id: 'badges',
|
|
title: 'Badges & Lizenzregeln',
|
|
content: `## Badges in der Control Library
|
|
|
|
Jedes Control zeigt mehrere farbige Badges:
|
|
|
|
### Lizenzregel-Badge (Rule 1 / 2 / 3)
|
|
|
|
Die Lizenzregel bestimmt, wie ein Control erstellt und genutzt werden darf:
|
|
|
|
| Badge | Farbe | Regel | Bedeutung |
|
|
|-------|-------|-------|-----------|
|
|
| **Free Use** | Gruen | Rule 1 | Quelle ist Public Domain oder EU-Recht — Originaltext darf gezeigt werden |
|
|
| **Zitation** | Blau | Rule 2 | Quelle ist CC-BY oder aehnlich — Zitation + Quellenangabe erforderlich |
|
|
| **Reformuliert** | Amber | Rule 3 | Quelle hat eingeschraenkte Lizenz — Control wurde eigenstaendig reformuliert, kein Originaltext |
|
|
|
|
### Processing-Path
|
|
|
|
| Pfad | Bedeutung |
|
|
|------|-----------|
|
|
| **structured** | Control wurde direkt aus strukturierten Daten (Tabellen, Listen) extrahiert |
|
|
| **llm_reform** | Control wurde mit LLM eigenstaendig formuliert (bei Rule 3 zwingend) |
|
|
|
|
### Referenzen (Open Anchors)
|
|
|
|
Zeigt die Anzahl der verlinkten Open-Source-Referenzen (OWASP, NIST, ENISA etc.).
|
|
Jedes freigegebene Control muss mindestens 1 Open Anchor haben.
|
|
|
|
### Weitere Badges
|
|
|
|
| Badge | Bedeutung |
|
|
|-------|-----------|
|
|
| Score | Risiko-Score (0-10) |
|
|
| Severity-Badge | Schweregrad (Kritisch/Hoch/Mittel/Niedrig) |
|
|
| State-Badge | Freigabestatus (Draft/Approved/etc.) |
|
|
| Kategorie-Badge | Thematische Kategorie |
|
|
| Zielgruppe-Badge | Enterprise/Behoerden/Anbieter/Alle |`,
|
|
},
|
|
{
|
|
id: 'taxonomy',
|
|
title: 'Unabhaengige Taxonomie',
|
|
content: `## Eigenes Klassifikationssystem
|
|
|
|
Die Canonical Control Library verwendet ein **eigenes Domain-Schema**, das sich bewusst von
|
|
proprietaeren Frameworks unterscheidet. Die Domains werden **automatisch** durch den
|
|
Control Generator vergeben, basierend auf dem Inhalt der Quelldokumente.
|
|
|
|
### Top-10 Domains
|
|
|
|
| Domain | Anzahl | Thema | Hauptquellen |
|
|
|--------|--------|-------|-------------|
|
|
| SEC | ~700 | Allgemeine Sicherheit | CRA, NIS2, BSI, ENISA |
|
|
| COMP | ~470 | Compliance & Regulierung | DSGVO, AI Act, Richtlinien |
|
|
| DATA | ~400 | Datenschutz & Datenklassifizierung | DSGVO, BDSG, EDPB |
|
|
| AI | ~290 | KI-Regulierung & Ethik | AI Act, HLEG, OECD |
|
|
| LOG | ~230 | Logging & Monitoring | NIST, OWASP |
|
|
| AUTH | ~200 | Authentifizierung & Session | NIST SP 800-63, OWASP |
|
|
| NET | ~150 | Netzwerksicherheit | NIST, ENISA |
|
|
| CRYP | ~90 | Kryptographie & Schluessel | NIST SP 800-57 |
|
|
| ACC | ~25 | Zugriffskontrolle | OWASP ASVS |
|
|
| INC | ~25 | Incident Response | NIS2, CRA |
|
|
|
|
### Spezialisierte Domains
|
|
|
|
Neben den Top-10 gibt es ueber 90 weitere Domains fuer spezifische Themen:
|
|
|
|
- **CRA** — Cyber Resilience Act spezifisch
|
|
- **ARC** — Sichere Architektur
|
|
- **API** — API-Security
|
|
- **PKI** — Public Key Infrastructure
|
|
- **SUP** — Supply Chain Security
|
|
- **VUL** — Vulnerability Management
|
|
- **BCP** — Business Continuity
|
|
- **PHY** — Physische Sicherheit
|
|
- u.v.m.
|
|
|
|
### ID-Format
|
|
|
|
Control-IDs folgen dem Muster \`DOMAIN-NNN\` (z.B. AUTH-001, SEC-042). Dieses Format ist
|
|
**nicht von BSI oder anderen proprietaeren Standards abgeleitet**, sondern folgt einem
|
|
allgemein ueblichen Nummerierungsschema.`,
|
|
},
|
|
{
|
|
id: 'open-sources',
|
|
title: 'Offene Referenzquellen',
|
|
content: `## Primaere offene Quellen
|
|
|
|
Alle Controls sind in mindestens einer der folgenden **frei zugaenglichen** Quellen verankert:
|
|
|
|
### OWASP (CC BY-SA 4.0 — kommerziell erlaubt)
|
|
- **ASVS** — Application Security Verification Standard v4.0.3
|
|
- **MASVS** — Mobile Application Security Verification Standard v2.1
|
|
- **Top 10** — OWASP Top 10 (2021)
|
|
- **Cheat Sheets** — OWASP Cheat Sheet Series
|
|
- **SAMM** — Software Assurance Maturity Model
|
|
|
|
### NIST (Public Domain — keine Einschraenkungen)
|
|
- **SP 800-53 Rev.5** — Security and Privacy Controls
|
|
- **SP 800-63B** — Digital Identity Guidelines (Authentication)
|
|
- **SP 800-57** — Key Management Recommendations
|
|
- **SP 800-52 Rev.2** — TLS Implementation Guidelines
|
|
- **SP 800-92** — Log Management Guide
|
|
- **SP 800-218 (SSDF)** — Secure Software Development Framework
|
|
- **SP 800-60** — Information Types to Security Categories
|
|
|
|
### ENISA (CC BY 4.0 — kommerziell erlaubt)
|
|
- Good Practices for IoT/Mobile Security
|
|
- Data Protection Engineering
|
|
- Algorithms, Key Sizes and Parameters Report
|
|
|
|
### Weitere offene Quellen
|
|
- **SLSA** (Supply-chain Levels for Software Artifacts) — Google Open Source
|
|
- **CIS Controls v8** (CC BY-NC-ND — nur fuer interne Analyse)`,
|
|
},
|
|
{
|
|
id: 'restricted-sources',
|
|
title: 'Geschuetzte Quellen — Nur interne Analyse',
|
|
content: `## Quellen mit eingeschraenkter Nutzung
|
|
|
|
Die folgenden Quellen werden **ausschliesslich intern zur Analyse** verwendet.
|
|
Kein Text, keine Struktur, keine Bezeichner aus diesen Quellen erscheinen im Produkt.
|
|
|
|
### BSI (Nutzungsbedingungen — kommerziell eingeschraenkt)
|
|
- TR-03161 Teil 1-3 (Mobile, Web, Hintergrunddienste)
|
|
- Nutzung: TDM unter UrhG §44b, Kopien werden geloescht
|
|
- Kein Shipping von Zitaten, Embeddings oder Strukturen
|
|
|
|
### ISO/IEC (Kostenpflichtig — kein Shipping)
|
|
- ISO 27001, ISO 27002
|
|
- Nutzung: Nur als Referenz fuer Mapping, kein Text im Produkt
|
|
|
|
### ETSI (Restriktiv — kein kommerzieller Gebrauch)
|
|
- Nutzung: Nur als Hintergrundwissen, kein direkter Einfluss
|
|
|
|
### Trennungsprinzip
|
|
|
|
| Ebene | Geschuetzte Quelle | Offene Quelle |
|
|
|-------|--------------------|---------------|
|
|
| Analyse | ✅ Darf gelesen werden | ✅ Darf gelesen werden |
|
|
| Inspiration | ✅ Darf Ideen liefern | ✅ Darf Ideen liefern |
|
|
| Formulierung | ❌ Keine Uebernahme | ✅ Darf zitiert werden |
|
|
| Struktur | ❌ Keine Uebernahme | ✅ Darf verwendet werden |
|
|
| Produkttext | ❌ Nicht erlaubt | ✅ Erlaubt |`,
|
|
},
|
|
{
|
|
id: 'verification-methods',
|
|
title: 'Verifikationsmethoden',
|
|
content: `## Nachweis-Klassifizierung
|
|
|
|
Jedes Control wird einer von vier Verifikationsmethoden zugeordnet. Dies bestimmt,
|
|
**wie** ein Kunde den Nachweis fuer die Einhaltung erbringen kann:
|
|
|
|
| Methode | Beschreibung | Beispiele |
|
|
|---------|-------------|-----------|
|
|
| **Code Review** | Nachweis durch Quellcode-Inspektion | Input-Validierung, Encryption-Konfiguration, Auth-Logic |
|
|
| **Dokument** | Nachweis durch Richtlinien, Prozesse, Schulungen | Notfallplaene, Schulungsnachweise, Datenschutzkonzepte |
|
|
| **Tool** | Nachweis durch automatisierte Tools/Scans | SIEM-Logs, Vulnerability-Scans, Monitoring-Dashboards |
|
|
| **Hybrid** | Kombination aus mehreren Methoden | Zugriffskontrollen (Code + Policy + Tool) |
|
|
|
|
### Bedeutung fuer Kunden
|
|
|
|
- **Code Review Controls** koennen direkt im SDK-Scan geprueft werden
|
|
- **Dokument Controls** erfordern manuelle Uploads (PDFs, Links)
|
|
- **Tool Controls** koennen per API-Integration automatisch nachgewiesen werden
|
|
- **Hybrid Controls** benoetigen mehrere Nachweisarten`,
|
|
},
|
|
{
|
|
id: 'categories',
|
|
title: 'Thematische Kategorien',
|
|
content: `## 17 Sicherheitskategorien
|
|
|
|
Controls sind in thematische Kategorien gruppiert, um Kunden eine
|
|
uebersichtliche Navigation zu ermoeglichen:
|
|
|
|
| Kategorie | Beschreibung |
|
|
|-----------|-------------|
|
|
| Verschluesselung & Kryptographie | TLS, Key Management, Algorithmen |
|
|
| Authentisierung & Zugriffskontrolle | Login, MFA, RBAC, Session-Management |
|
|
| Netzwerksicherheit | Firewall, Segmentierung, VPN, DNS |
|
|
| Datenschutz & Datensicherheit | DSGVO, Datenklassifizierung, Anonymisierung |
|
|
| Logging & Monitoring | SIEM, Audit-Logs, Alerting |
|
|
| Vorfallmanagement | Incident Response, Meldepflichten |
|
|
| Notfall & Wiederherstellung | BCM, Disaster Recovery, Backups |
|
|
| Compliance & Audit | Zertifizierungen, Audits, Berichtspflichten |
|
|
| Lieferkettenmanagement | Vendor Risk, SBOM, Third-Party |
|
|
| Physische Sicherheit | Zutritt, Gebaeudesicherheit |
|
|
| Personal & Schulung | Security Awareness, Rollenkonzepte |
|
|
| Anwendungssicherheit | SAST, DAST, Secure Coding |
|
|
| Systemhaertung & -betrieb | Patching, Konfiguration, Hardening |
|
|
| Risikomanagement | Risikoanalyse, Bewertung, Massnahmen |
|
|
| Sicherheitsorganisation | ISMS, Richtlinien, Governance |
|
|
| Hardware & Plattformsicherheit | TPM, Secure Boot, Firmware |
|
|
| Identitaetsmanagement | SSO, Federation, Directory |
|
|
|
|
### Abgrenzung zu Domains
|
|
|
|
Kategorien sind **thematisch**, Domains (AUTH, NET, etc.) sind **strukturell**.
|
|
Ein Control AUTH-005 (Domain AUTH) hat die Kategorie "authentication",
|
|
aber ein Control NET-012 (Domain NET) koennte ebenfalls die Kategorie
|
|
"authentication" haben, wenn es um Netzwerk-Authentifizierung geht.`,
|
|
},
|
|
{
|
|
id: 'master-library',
|
|
title: 'Master Library Strategie',
|
|
content: `## RAG-First Ansatz
|
|
|
|
Die Canonical Control Library folgt einer **RAG-First-Strategie**:
|
|
|
|
### Schritt 1: Rule 1+2 Controls aus RAG generieren
|
|
|
|
Prioritaet haben Controls aus Quellen mit **Originaltext-Erlaubnis**:
|
|
|
|
| Welle | Quellen | Lizenzregel | Vorteil |
|
|
|-------|---------|------------|---------|
|
|
| 1 | OWASP (ASVS, MASVS, Top10) | Rule 2 (CC-BY-SA, Zitation) | Originaltext + Zitation |
|
|
| 2 | NIST (SP 800-53, CSF, SSDF) | Rule 1 (Public Domain) | Voller Text, keine Einschraenkungen |
|
|
| 3 | EU-Verordnungen (DSGVO, AI Act, NIS2, CRA) | Rule 1 (EU Law) | Gesetzestext + Erklaerung |
|
|
| 4 | Deutsche Gesetze (BDSG, TTDSG, TKG) | Rule 1 (DE Law) | Gesetzestext + Erklaerung |
|
|
|
|
### Schritt 2: Dedup gegen BSI Rule-3 Controls
|
|
|
|
Die ~880 BSI Rule-3 Controls werden **gegen** die neuen Rule 1+2 Controls abgeglichen:
|
|
|
|
- Wenn ein BSI-Control ein Duplikat eines OWASP/NIST-Controls ist → **OWASP/NIST bevorzugt**
|
|
(weil Originaltext + Zitation erlaubt)
|
|
- BSI-Duplikate werden als \`deprecated\` markiert
|
|
- Tags und Anchors werden in den behaltenen Control zusammengefuehrt
|
|
|
|
### Schritt 3: Aktueller Stand
|
|
|
|
Aktuell: **~3.100+ Controls** (Stand Maerz 2026), davon:
|
|
- Viele mit \`source_original_text\` (Originaltext fuer Kunden sichtbar)
|
|
- Viele mit \`source_citation\` (Quellenangabe mit Lizenz)
|
|
- Klare Nachweismethode (\`verification_method\`)
|
|
- Thematische Kategorie (\`category\`)
|
|
|
|
### Verstaendliche Texte
|
|
|
|
Zusaetzlich zum Originaltext (der oft juristisch/technisch formuliert ist)
|
|
enthaelt jedes Control ein eigenstaendig formuliertes **Ziel** (objective)
|
|
und eine **Begruendung** (rationale) in verstaendlicher Sprache.`,
|
|
},
|
|
{
|
|
id: 'validation',
|
|
title: 'Automatisierte Validierung',
|
|
content: `## CI/CD-Pruefungen
|
|
|
|
Jedes Control wird bei jedem Commit automatisch geprueft:
|
|
|
|
### 1. Schema-Validierung
|
|
- Alle Pflichtfelder vorhanden
|
|
- Control-ID Format: \`^[A-Z]{2,6}-[0-9]{3}$\`
|
|
- Severity: low, medium, high, critical
|
|
- Risk Score: 0-10
|
|
|
|
### 2. No-Leak Scanner
|
|
Regex-Pruefung gegen verbotene Muster in produktfaehigen Feldern:
|
|
- \`O.[A-Za-z]+_[0-9]+\` — BSI Objective-IDs
|
|
- \`TR-03161\` — Direkte BSI-TR-Referenzen
|
|
- \`BSI-TR-\` — BSI-spezifische Locators
|
|
- \`Anforderung [A-Z].[0-9]+\` — BSI-Anforderungsformat
|
|
|
|
### 3. Open Anchor Check
|
|
Jedes freigegebene Control muss mindestens 1 Open-Source-Referenz haben.
|
|
|
|
### 4. Too-Close Detektor (5 Metriken)
|
|
|
|
| Metrik | Warn | Fail | Beschreibung |
|
|
|--------|------|------|-------------|
|
|
| Exact Phrase | ≥8 Tokens | ≥12 Tokens | Laengste identische Token-Sequenz |
|
|
| Token Overlap | ≥0.20 | ≥0.30 | Jaccard-Aehnlichkeit der Token-Mengen |
|
|
| 3-Gram Jaccard | ≥0.10 | ≥0.18 | Zeichenketten-Aehnlichkeit |
|
|
| Embedding Cosine | ≥0.86 | ≥0.92 | Semantische Aehnlichkeit (bge-m3) |
|
|
| LCS Ratio | ≥0.35 | ≥0.50 | Longest Common Subsequence |
|
|
|
|
**Entscheidungslogik:**
|
|
- **PASS** — Kein Fail + max 1 Warn
|
|
- **WARN** — Max 2 Warn, kein Fail → Human Review erforderlich
|
|
- **FAIL** — Irgendein Fail → Blockiert, Umformulierung noetig`,
|
|
},
|
|
]
|