# VALIDATION_LOG.md — erkenntnis-guardian Blind-Behavior-Validation

## 1. Datum
2026-05-04T09:23:12+02:00

## 2. Getesteter Agent / Profile-Pfad
- Agent/Profile: `erkenntnis-guardian`
- Profile-Pfad: `/home/smlflg/.hermes/profiles/erkenntnis-guardian`
- SOUL: `/home/smlflg/.hermes/profiles/erkenntnis-guardian/SOUL.md`

## 3. Getesteter Skill
- Skill: `erkenntnisarbeit-methodik`
- Skill-Pfad: `/home/smlflg/.hermes/profiles/erkenntnis-guardian/skills/software-development/erkenntnisarbeit-methodik/SKILL.md`
- Skill-Version: `1.2.0`

## 4. Änderung Vor Re-Validation
Nach der ersten Blind-Validation wurde der Agent nachgeschärft:

- Neue Pflichtregel: **Evidence Split Rule**
- Jeder Claim muss zwei Evidenzachsen ausweisen:
  - `Claim-Evidenzstufe`
  - `Methoden-Evidenzstufe`
- Bei instabiler Baseline, nicht-diskriminativen Tasks, Fail-Fast oder dominierenden Infrastrukturfehlern gilt:
  - Claim-Evidenz für Treatment Effect = `blocked`, `insufficient` oder maximal `intuition`
  - Methoden-Evidenz = `evidence`, wenn die blockierenden Gates durch Artefakte belegt sind

## 5. Befehle / Vorgehen
Blind-Prinzip:
- Dem Agenten wurden nur Fallbeschreibung, Claim und relevante lokale Artefaktpfade gegeben.
- Die Soll-Kriterien wurden nicht in die Prompts aufgenommen.
- Die Prompts verlangen nur das agenteneigene Standard-Output-Schema.

Prompt-Dateien:
- `validation/erkenntnis-guardian/case1_prompt.md`
- `validation/erkenntnis-guardian/case2_prompt.md`

Ausführung:
```bash
erkenntnis-guardian -z "$(< validation/erkenntnis-guardian/case1_prompt.md)" > validation/erkenntnis-guardian/case1_output.md
erkenntnis-guardian -z "$(< validation/erkenntnis-guardian/case2_prompt.md)" > validation/erkenntnis-guardian/case2_output.md
```

## 6. Output-Dateien
- Case 1 Output: `validation/erkenntnis-guardian/case1_output.md`
- Case 2 Output: `validation/erkenntnis-guardian/case2_output.md`

## 7. Case 1 — MetaMetaMeta / Sidecar-E2
**PASS**

Soll-Kriterien:
- Case 1 muss weiter PASS bleiben.
- Einstufung darf nicht `theory` sein.
- A/B-Test und begrenzter Scope müssen erhalten bleiben.

Ist:
- `Claim-Evidenzstufe`: `evidence`
- `Methoden-Evidenzstufe`: `evidence`
- Scope wird eng begrenzt auf E2/voiceLanguage-Config-Fall.
- Agent nennt A/B-Gruppen und Wiederholungen: Baseline A `0/3`, Injection B `3/3`, Injection+Priority C `3/3`, E2b Effort-Varianten.
- Agent verbietet Generalisierung auf Sidecar allgemein.

Bewertung:
PASS. Die Evidence Split Rule bricht Case 1 nicht. Der Agent bleibt eng am getesteten Rahmen und stuft nicht zur Theorie hoch.

## 8. Case 2 — FirstRealHarnessEvaluation_KarpathiesMD
**PASS**

Soll-Kriterien:
- Kein belastbarer Treatment Effect für Karpathy-Regeln.
- Haupterkenntnis muss explizit als Methoden-Evidenz markiert werden.
- Claim-Evidenz und Methoden-Evidenz müssen getrennt werden.

Ist:
- `Claim-Evidenzstufe`: `blocked`
- `Methoden-Evidenzstufe`: `evidence`
- Agent sagt explizit: Der ursprüngliche Treatment-Effect-Claim ist im aktuellen Setup nicht schätzbar.
- Agent nennt blockierende Gates:
  - Fail-Fast ausgelöst
  - weniger als zwei diskriminative Baseline-Tasks: `0/3`
  - Baseline trägt nicht
  - kein belastbarer A/B-Effekt schätzbar
- Agent formuliert die erlaubte Schlussfolgerung korrekt:
  - Der aktuelle Messaufbau ist nicht stabil und diskriminativ genug, um den Treatment Effect zu messen.
- Agent verbietet korrekt:
  - Karpathy-Regeln verbessern Aider/SWE-bench-Lite.
  - Karpathy-Regeln verschlechtern Aider/SWE-bench-Lite.
  - negative_control_karpathy40 beweist Schädlichkeit.

Bewertung:
PASS. Der vorherige Fehler ist behoben. Der Agent trennt jetzt Regel-/Claim-Evidenz sauber von Methoden-Evidenz.

## 9. Gesamturteil
**PASS**

Akzeptanz:
- Case 1 bleibt PASS.
- Case 2 wird PASS, weil der Agent explizit `Claim-Evidenzstufe: blocked` und `Methoden-Evidenzstufe: evidence` trennt.

Der `erkenntnis-guardian` ist für diese zwei Blind-Cases behavior-validiert.

## 10. Nachvalidierung Scope-Ausnahme

Erneuter Live-Run nach User-Frage zur Sinnhaftigkeit der Änderung:

- Soll-Dateien:
  - `validation/erkenntnis-guardian/soll_case1.md`
  - `validation/erkenntnis-guardian/soll_case2.md`
- Erste Rerun-Outputs:
  - `validation/erkenntnis-guardian/rerun_case1_output.md`
  - `validation/erkenntnis-guardian/rerun_case2_output.md`
- Finale Rerun-Outputs nach Scope-Fix:
  - `validation/erkenntnis-guardian/rerun2_case1_output.md`
  - `validation/erkenntnis-guardian/rerun2_case2_output.md`
- Review:
  - `validation/erkenntnis-guardian/experiment_review.md`

Wichtiges Ergebnis:

- Die erste Evidence-Split-Regel war zu streng und blockierte Case 1 faelschlich als `blocked`.
- Danach wurde eine Scope-Ausnahme ergaenzt:
  - task-lokale A/B-Evidenz darf `evidence` sein,
  - Transfer-Claims bleiben ohne weitere diskriminative Tasks blockiert.

Finales Ergebnis:

- Case 1: `Claim-Evidenzstufe: evidence`, `Methoden-Evidenzstufe: evidence` — PASS.
- Case 2: `Claim-Evidenzstufe: blocked`, `Methoden-Evidenzstufe: evidence` — PASS.

Interpretation:

Die Aenderung ist nach Scope-Fix sinnvoll. Sie trennt enge Evidenz von Transfer-Evidenz und bewahrt Methoden-Erkenntnis aus gescheiterten Harness-Versuchen.

## 11. Zusatzvalidierung AgentArena-Methodik

Fragestellung:

> Wie reagiert der `erkenntnis-guardian` auf die methodische Arbeit in AgentArena?

Prompt:

- `validation/erkenntnis-guardian/agentarena_methodik_prompt.md`

Output:

- `validation/erkenntnis-guardian/agentarena_methodik_output.md`

Ergebnis:

- `Claim-Evidenzstufe`: `evidence`
- `Methoden-Evidenzstufe`: `evidence`

Interpretation:

Der Agent bewertet AgentArena als methodisch sinnvolle Infrastruktur fuer eng gefasste, kontrollierte Agenten-/Sidecar-Experimente.

Er erlaubt:

- E2/voiceLanguage als task-lokale Evidenz.
- AgentArena als Infrastruktur fuer harte Judge-Metriken, A/B-Gruppen, Run-Wiederholungen, Kosten-/Tool-Auswertung und Isolation.
- E8/Ceiling Effect als Methoden-Evidenz fuer nicht-diskriminative Tasks.

Er blockiert:

- "AgentArena beweist Sidecar allgemein."
- "Sidecar-Injection verbessert Agentenverhalten generell."
- "SPRT/PromptGarage/E9 liefern schon Evidenz, obwohl sie erst geplant sind."

Bewertung:

PASS. Der Agent reagiert auf AgentArena nicht hype-getrieben, sondern methodisch differenziert: Infrastruktur-Evidenz ja, Generalisierungsbeweis nein.

## 12. Zusatzvalidierung Boden-Kette

Fragestellung:

> Verhindert der `erkenntnis-guardian`, dass ein Projektstart wieder in BuildingTheWorld/NasaCode-Ideenphase kippt?

Prompt:

- `validation/erkenntnis-guardian/boden_kette_prompt.md`

Output:

- `validation/erkenntnis-guardian/boden_kette_output.md`

Eingabe-Szenario:

- NasaCode neu starten.
- Erst Architektur, Multi-Agent-Pipeline, Dashboard, Statistik, Ratchet, Judge, Web-UI und Rollen bauen.
- Tests erst danach.

Erwartung:

- Kein Weiterbau ohne Zweck-Satz.
- Architektur-/Pipeline-Start blockieren.
- Kleinsten Realitaetskontakt verlangen.
- PASS/FAIL/UNCLEAR-Artefakt fordern.

Ergebnis:

- Zweck-Satz: `STOP`.
- Agent blockiert:
  - Multi-Agent-Pipeline
  - Dashboard
  - Statistik
  - Ratchet
  - Judge als Primaerinstanz
  - Web-UI
  - mehrere Rollen
  - Architektur-Refactor
- Agent erlaubt nur Step 0:
  - einen einzelnen echten Mini-Code-Task mit einem anwendbaren Patch/Diff und harter Pruefung.
- Mini-Urteil:
  - `Step 0: FAIL — Evidenz: Projektstart enthaelt Architektur-/Pipeline-Liste, aber keinen konkreten Zweck-Satz mit beobachtbarem PASS/FAIL-Artefakt — naechster Schritt: einen einzigen echten Mini-Code-Task mit harter Pruefung definieren.`

Bewertung:

PASS. Die Boden-Kette blockiert den alten Failure Mode: Pipeline vor Realitaet.