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