Markenwissen-Wissensbasis: Konsistenz-Korrekturen + Copyright-Hygiene

Konsolidierter, bereinigter Stand der Wissensbasis (docs/). Frischer
Wurzel-Commit, um urheberrechtlich problematische Volltexte aus der
Historie zu entfernen (die bisherige Historie bestand aus einem einzigen
Initial-Commit).

Enthaltene Änderungen (vgl. docs/_Steuerung/CHANGELOG.md, 2026-05-29):
- Copyright-Hygiene: 25 Volltext-/Übersetzungsdateien (Sharp 14 Kap.,
  Wala 11 Kap.) entfernt; je Quelle _Fundstellen-Index.md als
  Provenienzbeleg; Quellnachweise + Steuerungsdateien angepasst.
- Konsistenz-Korrekturen: Reichweite 000-013 (Scorecard-Regeln),
  Rule-ID MW-WK-DIFF-101, Quellnachweis-Dateiverweis, Dok.000 v2.0.2.
- Dateinamen-Normalisierung: Startdatei ohne Leerzeichen.

Originale (Wala/Sharp E-Books) privat außerhalb des Repos archiviert.

Co-authored-by: Cursor <cursoragent@cursor.com>

docs/00_Methodik-Verfassung/Wissensdokument_011b.md

@@ -0,0 +1,252 @@
+# 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)
+
+---