10 KiB
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
- Deterministisch, wo möglich (Keywords, Regex, strukturierte Regeln)
- LLM nur dort, wo Semantik nötig ist (Kohärenz, Positionierung, Tonalität)
- Jede Ablehnung muss begründbar sein (Rule-ID, Evidence, Empfehlung)
- 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_iddna_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_idcontent_type(LI, Website, Angebot)textcontext(Zielgruppe, Thema, Kanal)dna_version_refscores(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(keinPASS), 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.