252 lines
10 KiB
Markdown
252 lines
10 KiB
Markdown
# Wissensdokument 011b — Version 1.2
|
||
|
||
Wenn Brand Rules glaubwürdig sein soll, braucht es eine **technische Übersetzung**: messbar, implementierbar, debugbar. Kein Kundenmaterial, sondern **Systemdesign + Entscheidungslogik + konkrete Checks**.
|
||
|
||
---
|
||
|
||
## Technischer Anhang zur Validierungs-Scorecard
|
||
|
||
### Wie der Marken-TÜV in Brand Rules implementiert wird
|
||
|
||
**Status:** Intern · Fixiert
|
||
|
||
**Version:** 1.2 (ersetzt 1.0)
|
||
|
||
**Zweck:** Technische Spezifikation der Scorecard-Implementierung
|
||
|
||
**Ziel:** Automatisierbare Prüfungen + klare Grenzfall-Logik
|
||
|
||
---
|
||
|
||
### Änderungsvermerk (gemäß Dok. 000 §5.2)
|
||
|
||
| Feld | Wert |
|
||
| --- | --- |
|
||
| Version | 1.0 → 1.2 (konsolidiert zwei Schritte) |
|
||
| Datum | 27.05.2026 |
|
||
| Begründung (v1.1) | Technische Spezifikation der neuen Ebene 1 (DNA-Reifegrad) aus Dok. 011 v1.2 / Dok. 013 §6 – neue Sektion 3a. |
|
||
| Begründung (v1.2) | Override-Regeln in §4.1 ergänzt: K1/K2 ❌ → max. REVISE (Spiegel zu Dok. 011 v1.2). |
|
||
| Betroffene Dokumente | Dok. 011 v1.2 (§2a, §3, §4), Dok. 013 (§6, §9), Dok. 002, Dok. 004 |
|
||
| Entscheidung | Kevin Adametz (Letztinstanz, Dok. 000 §4.1) |
|
||
|
||
---
|
||
|
||
## 1. Leitprinzipien der Implementierung
|
||
|
||
1. **Deterministisch, wo möglich** (Keywords, Regex, strukturierte Regeln)
|
||
2. **LLM nur dort, wo Semantik nötig ist** (Kohärenz, Positionierung, Tonalität)
|
||
3. **Jede Ablehnung muss begründbar sein** (Rule-ID, Evidence, Empfehlung)
|
||
4. **Keine Blackbox** (Audit-Log, Scores, Quellen)
|
||
|
||
> Ziel ist nicht „KI entscheidet", sondern „System prüft".
|
||
|
||
---
|
||
|
||
## 2. Datenmodell (Minimum)
|
||
|
||
### 2.1 Marken-DNA als strukturierte Entität
|
||
|
||
- `brand_id`
|
||
- `dna_version` (semver, z. B. 1.2.0)
|
||
- `identity_core` (1–2 Sätze + optional: Bullet-Claims)
|
||
- `positioning_logic` (Problem, Logik, Abgrenzung)
|
||
- `tone_rules` (Do/Don't + Stilparameter)
|
||
- `topic_corridor` (core_topics, adjacent_topics, taboo_topics)
|
||
- `guardrails` (verbotene Begriffe, verbotene Claims, verbotene Formate)
|
||
- `maturity` (Reifegrad je Baustein + Gesamt — siehe §3a)
|
||
|
||
### 2.2 Validierungsobjekt
|
||
|
||
- `content_id`
|
||
- `content_type` (LI, Website, Angebot)
|
||
- `text`
|
||
- `context` (Zielgruppe, Thema, Kanal)
|
||
- `dna_version_ref`
|
||
- `scores` (K1..K7)
|
||
- `status` (PASS / REVISE / FAIL)
|
||
- `reasons[]` (Rule-ID + Explanation + Evidence)
|
||
- `suggestions[]` (konkrete Korrekturhinweise)
|
||
- `validated_by` (Agent / Human)
|
||
|
||
---
|
||
|
||
## 3. Scorecard-Kriterien: Technische Umsetzung (Ebene 2)
|
||
|
||
### Kriterium 6: Grenzregeln & No-Gos (absolut, deterministisch)
|
||
|
||
**Ziel:** Sofortige Ablehnung bei Verstoß. **Implementierung:** Regel-Engine + Pattern Matching.
|
||
|
||
**Mechaniken:** Keyword-Liste (exakte Matches, case-insensitive) · Lemma-/Stemming-Varianten (optional) · Regex (für Claims wie „Nr. 1", „Marktführer", „garantiert") · Phrase-Matcher (z. B. Aho-Corasick).
|
||
|
||
**Datenstruktur:** `forbidden_terms[]` · `forbidden_phrases[]` · `forbidden_patterns[]` (Regex) · `allowed_exceptions[]` (Whitelist, z. B. wenn in Zitat).
|
||
|
||
**Output:** FAIL · Reason: `GR-TERM-003` („Verbotener Begriff: ‚ganzheitlich'") · Evidence: Fundstelle (Index / Snippet).
|
||
|
||
> Das ist der einfachste, sicherste Teil. Den musst du 100 % deterministic bauen.
|
||
|
||
### Kriterium 3: Sprach- & Tonalitätsregeln (hybrid)
|
||
|
||
**Ziel:** Tonalität + Stilregeln prüfen. **Implementierung:** Kombi aus deterministischen Checks (Länge, Superlative, Buzzwords) + optionaler Klassifikation (LLM oder kleiner Text-Classifier).
|
||
|
||
**Deterministische Checks:** Satzlänge (Durchschnitt/Maximum) · Anteil Passivkonstruktionen (heuristisch) · Anteil Füllwörter (Stopword-Liste) · Superlativ-/Hype-Liste (innovativ, einzigartig, revolutionär …).
|
||
|
||
**Semantische Tonalität (LLM-Check), Prompt-Template:** „Bewerte den Text anhand folgender Ton-Regeln (Do/Don't). Gib nur JSON mit score und Belegen (Zitatstellen)."
|
||
|
||
**Scoring:** ✔️ deterministische Regeln eingehalten + LLM-score hoch · ⚠️ einzelne Abweichungen · ❌ klare Regelverletzung oder LLM-score unter Schwellwert.
|
||
|
||
**Output:** Score + Evidence + konkrete Rewrite-Hinweise.
|
||
|
||
### Kriterium 4: Themenrahmen (semi-deterministisch)
|
||
|
||
**Ziel:** Liegt der Inhalt im erlaubten Themenkorridor?
|
||
|
||
**Option A (einfach):** Themen = Tags mit Keyword-Sets, Score nach Treffern/Gewichtung.
|
||
**Option B (besser):** je Thema ein definierender Text-Snippet, Embed Text + Snippets, Similarity → Top-Topic.
|
||
|
||
**Output:** core_topic / adjacent_topic / out_of_scope · Evidence: Begriffe / Similarities.
|
||
|
||
### Kriterium 5: Entscheidungsfähigkeit (LLM-gestützt + Heuristik)
|
||
|
||
**Ziel:** Ist der Text handlungsfähig oder nur vage?
|
||
|
||
**Implementierung:** Heuristik (weiche Verben/Floskeln: glauben, möchten, helfen, ganzheitlich) + LLM-Klassifikation („Enthält der Text eine klare Konsequenz / These / Entscheidung?").
|
||
|
||
**LLM-Output (JSON):** `decision_strength` (0–100) · `vagueness_flags[]` · `suggested_sharpening`.
|
||
**Mapping:** ≥70 = ✔️ · 40–70 = ⚠️ · <40 = ❌.
|
||
|
||
### Kriterium 1: Identitätskern-Kohärenz (Embedding + LLM-Richter)
|
||
|
||
**2-Stufen-Ansatz:** (1) Embedding-Similarity zwischen Identitätskern und Text/Sätzen. (2) LLM-Adjudication: bekommt Identitätskern + Text + Similarity + Guardrails, Aufgabe „Ist das kohärent? Nenne 1–2 Stellen, die passen/nicht passen."
|
||
|
||
**Mapping:** Similarity hoch + LLM „coherent" → ✔️ · gemischt → ⚠️ · LLM „contradicts" → ❌.
|
||
**Output:** Reason `ID-COH-002` · Evidence: konkrete Textstellen.
|
||
|
||
### Kriterium 2: Positionierungslogik (RAG-gestützte Regeln + LLM)
|
||
|
||
**Implementierung:** Positionierung als strukturierte Regeln („Wir sind NICHT …", „Wir lösen X durch Y"). LLM-Check: „Stärkt der Text diese Abgrenzung oder nivelliert er?" Optional: Embedding-Vergleich gegen Abgrenzungs-Sätze.
|
||
|
||
**Ablehnung bei:** „wir sind flexibel für alle" · „wir machen alles" · Preis-/Feature-Vergleich ohne Logik.
|
||
|
||
### Kriterium 7: Konsistenz zur DNA-Version (deterministisch)
|
||
|
||
**Implementierung:** Jeder Content speichert `dna_version_ref`. Bei DNA-Update: „Revalidate required" oder „compatible" (wenn nur redaktionell). **Regel:** Methodische/strukturelle Updates → Revalidation erzwingen.
|
||
|
||
---
|
||
|
||
## 3a. DNA-Reifegrad — technische Umsetzung (Ebene 1)
|
||
|
||
**Ziel:** die Schärfe der DNA selbst messen, bevor Inhalte geprüft werden. Pro Baustein ein `maturity_score` (0–100) aus hybriden Checks.
|
||
|
||
**Positionierung / Abgrenzung**
|
||
- deterministisch: Weichmacher-Muster als Negativsignal (`flexibel`, `für alle`, `ganzheitlich`, `individuell`, `alles aus einer Hand`)
|
||
- LLM-Richter: „Ist dies ein Ausschluss oder eine Anpreisung?" (Dok. 002 §3.2)
|
||
|
||
**Sprach-/Tonregeln**
|
||
- Anteil **prüfbarer** Regeln (mit erkennbarer Verletzungsbedingung – Don'ts oder positive Regeln mit klarer Verletzung, Dok. 002 §3.3)
|
||
- zu wenige prüfbare Regeln → niedriger Reifegrad
|
||
|
||
**Grenzregeln**
|
||
- Vorhandensein expliziter No-Go-Listen (Begriffe, Formate, Claims)
|
||
- leere Listen → niedriger Reifegrad (Dok. 002 §3.5)
|
||
|
||
**Identitätskern**
|
||
- LLM-Check gegen Testfrage „gilt der Kern auch bei Produkt-/Marktwechsel?"
|
||
- Marktbegriff-/Nutzenversprechen-Detektor (Kern darf keine enthalten, Dok. 002 §3.1)
|
||
|
||
**Themenrahmen**
|
||
- sind Kern-Themen (max. 3) und Tabu-Themen gesetzt? (Dok. 002 §3.4)
|
||
|
||
**Output je Baustein:** `maturity_score`, `gaps[]` (was fehlt), `standard_ref` (Kriterium/Testfrage aus Dok. 002).
|
||
|
||
**Kopplungsregel:** Sinkt die Konfidenz einer Inhaltsprüfung (K1/K2 aus §3) unter Schwellwert UND ist der zugehörige Baustein-Reifegrad niedrig → Status-Begründung referenziert den **Baustein**, nicht den Inhalt (`reason: LOW-DNA-MATURITY`, `baustein_ref`).
|
||
|
||
**Guardrails (Dok. 013 §9 / Dok. 004):**
|
||
- Ausgabe ist **Symptom + Maßstab, nie Substanz** – das System zeigt das Kriterium, schreibt aber die DNA nicht (KI erfindet keine Marke).
|
||
- Reifegrad als **steigende Zahl** darstellen (Fortschritt sichtbar, nicht Versagen).
|
||
|
||
> Der Prüfstand prüft jetzt auch das Maß, gegen das er prüft.
|
||
|
||
---
|
||
|
||
## 4. Entscheidungslogik im Tool (inkl. 4,5 Punkte)
|
||
|
||
### 4.1 Status-Mapping (automatisch)
|
||
|
||
**Override-Regeln (vor dem Score):**
|
||
- Fail bei K6 → `FAIL`
|
||
- ❌ bei K1 oder K2 → Status max. `REVISE` (kein `PASS`), unabhängig vom Score
|
||
|
||
**Danach Score-Mapping:**
|
||
- **PASS:** Score ≥ 6 und keine Override-Verletzung
|
||
- **REVISE:** Score 4–5,5 (oder durch K1/K2-Override gedeckelt)
|
||
- **FAIL:** Score < 4 oder Fail bei K6
|
||
|
||
### 4.2 Was passiert bei 4,5 Punkten?
|
||
|
||
**Standard:** Status = REVISE (automatisch). **Tool-Verhalten:** zeigt die 2–3 größten Hebel (Top Reasons), bietet „Rewrite mit Regeln" an, markiert als „Freigabe nur durch Human Owner".
|
||
|
||
### 4.3 Grenzfall-Regel (Human Gate)
|
||
|
||
Nur der Marken-Owner darf final freigeben bei: Score 5,0–5,5 · keine K6-Verletzung · aber K1 oder K2 = ⚠️.
|
||
|
||
**Warum?** Das sind strategische Nuancen. Da darf der Agent nicht „entscheiden".
|
||
|
||
> Agent empfiehlt. Owner entscheidet.
|
||
|
||
---
|
||
|
||
## 5. Explainability: Wie Ablehnungen begründet werden
|
||
|
||
Jede Ablehnung muss enthalten: `rule_id` · `rule_text` (aus DNA/Guardrail) · `evidence` (Zitat + Position) · `fix_suggestion` (konkreter Vorschlag).
|
||
|
||
**Beispiel:** `GR-TERM-001` Verbotener Begriff „ganzheitlich" · Evidence: Satz 2 · Fix: Ersetzen durch konkreten Scope („Governance", „Risiko", „Entscheidungen").
|
||
|
||
---
|
||
|
||
## 6. Audit-Log & Debugging (für dich als Entwickler)
|
||
|
||
Jeder Validierungsrun speichert: Input · DNA-Version · Feature Flags (welche Checks aktiv) · Model-Version · Ergebnisse je Kriterium · Reifegrad je Baustein (Ebene 1) · Tokenverbrauch je Run (Kostenkontrolle).
|
||
|
||
Damit: Bugs finden, Drift erkennen, Kosten optimieren, Kundenfragen beantworten („Warum abgelehnt?").
|
||
|
||
---
|
||
|
||
## 7. MVP-Umfang (minimal, aber stark)
|
||
|
||
**Phase 1 MVP (empfohlen):**
|
||
- K6 (verbotene Begriffe/Claims) deterministisch
|
||
- K4 (Themen) Keyword + Embedding
|
||
- K3 (Ton) deterministisch + einfacher LLM-Richter
|
||
- K1/K2/K5 zunächst nur LLM-Richter (mit strukturiertem Prompt)
|
||
- K7 Version-Ref
|
||
- Ebene 1 (DNA-Reifegrad): Positionierung + Grenzregeln deterministisch, Rest LLM-Richter
|
||
|
||
**Phase 2:** Embedding + LLM-Adjudication für K1/K2 · feinere Tonalitätsparameter · bessere Themenklassifikation · vollständiger Reifegrad über alle Bausteine.
|
||
|
||
> MVP muss nicht perfekt sein, aber begründbar.
|
||
|
||
---
|
||
|
||
## 8. Sicherheit: Halluzinationen vermeiden
|
||
|
||
Regel: Agent darf niemals Fakten erfinden. Agent darf nur: prüfen, umformulieren, Struktur vorschlagen.
|
||
|
||
Wenn Kontext fehlt: „Unzureichende Informationen" als Status, kein Raten.
|
||
|
||
---
|
||
|
||
## 9. Essenz
|
||
|
||
- Regeln deterministisch
|
||
- Semantik hybrid
|
||
- Grenzfälle menschlich
|
||
- DNA-Reifegrad vor Inhalts-Prüfung
|
||
- alles begründet und auditierbar
|
||
|
||
> Der Marken-Agent ist kein Orakel. Er ist ein Prüfstand.
|
||
|
||
---
|
||
|
||
### Ende – Wissensdokument 011b (Version 1.2)
|
||
|
||
---
|