# 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) ---