markemacht/docs/00_Methodik-Verfassung/Wissensdokument_011b.md

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)

---