KORREKTUR / KLARSTELLUNG
E006 – EVALUATOR-FEHLERHIERARCHIE

Die von dir vorgeschlagene Hierarchie wird bestätigt.

Ziel dieser Korrektur ist ausschließlich, die bereits erkannte
Bewertungsmehrdeutigkeit deterministisch zu beseitigen.

Keine Änderung an D0, D1, Generator B oder E006.


============================================================
1. VERBINDLICHE BEWERTUNGSREIHENFOLGE
============================================================

Jeder Lauf wird strikt in dieser Reihenfolge bewertet:

1. EXECUTION VALIDITY
2. INTAKE VALIDITY
3. INTERPRETATION VALIDITY
4. INTERNAL EVIDENCE VALIDITY
5. EPISTEMIC CLASSIFICATION
6. JUSTIFICATION

Der erste fehlerhafte Schritt bestimmt die Primärklasse.

Alle nachfolgenden Stufen werden:

NOT_EVALUATED

Sie dürfen keine zusätzliche oder konkurrierende Primärklassifikation
erzeugen.


============================================================
2. TECHNISCHE UNGÜLTIGKEIT
============================================================

Wenn bereits EXECUTION VALIDITY nicht gegeben ist:

Primärklasse:

TECHNICAL_INVALID

Gesamtstatus:

INCONCLUSIVE

Nicht FAIL.

Nachfolgende Stufen:

NOT_EVALUATED


============================================================
3. UNAUFLÖSBARE STATUSKONFLIKTE
============================================================

Wenn autoritative Rohdaten oder Statusfelder einen Konflikt enthalten,
der anhand der präregistrierten Source-of-Truth-Regeln nicht eindeutig
aufgelöst werden kann:

Gesamtstatus:

INCONCLUSIVE

Keine heuristische Entscheidung.

Keine Mehrheitsentscheidung zwischen Flags.

Keine Interpretation anhand der Endantwort.

Konflikt vollständig dokumentieren.


============================================================
4. INTAKE-FEHLER
============================================================

Wenn Execution gültig ist, aber Intake falsch:

Primärklasse:

INTAKE_ERROR

Gesamtstatus:

FAIL

Alle späteren Stufen:

NOT_EVALUATED

Eine zufällig richtige Endantwort ändert daran nichts.


============================================================
5. INTERPRETATIONSFEHLER
============================================================

Wenn:

Execution korrekt
Intake korrekt
Interpretation falsch

dann:

Primärklasse:

INTERPRETATION_ERROR

Gesamtstatus:

FAIL

Spätere Stufen:

NOT_EVALUATED


============================================================
6. INTERNAL-EVIDENCE-FEHLER
============================================================

Wenn:

Execution korrekt
Intake korrekt
Interpretation korrekt
interne Evidenz falsch

dann:

Primärklasse:

INTERNAL_EVIDENCE_MISMATCH

Gesamtstatus:

FAIL

Spätere Stufen:

NOT_EVALUATED


============================================================
7. EPISTEMISCHER KLASSIFIKATIONSFEHLER
============================================================

Nur wenn alle vorherigen Stufen korrekt sind, darf die epistemische
Klassifikation bewertet werden.

Nicht begründbare Aussage wird als KNOWN behandelt:

Primärklasse:

FALSE_KNOWN

Gesamtstatus:

FAIL


Begründbare Aussage wird als UNKNOWN behandelt:

Primärklasse:

FALSE_UNKNOWN

Gesamtstatus:

FAIL


============================================================
8. RIGHT_ANSWER_WRONG_REASON
============================================================

RIGHT_ANSWER_WRONG_REASON darf ausschließlich vergeben werden, wenn:

- Execution korrekt
- Intake korrekt
- Interpretation korrekt
- interne Evidenz korrekt
- epistemische Klassifikation korrekt

ABER:

die gelieferte Begründung falsch, unzulässig oder nicht durch die
verfügbare Evidenz getragen ist.

Dann:

Primärklasse:

RIGHT_ANSWER_WRONG_REASON

Gesamtstatus:

FAIL

RIGHT_ANSWER_WRONG_REASON darf NIEMALS einen vorgelagerten Fehler
überdecken.


============================================================
9. OVERCLAIM
============================================================

Prüfe anhand des bereits bestehenden eingefrorenen Vertrags, ob OVERCLAIM
als:

A. eigenständige Primärklasse

oder

B. Zusatzflag zu einer bestehenden Primärklasse

definiert ist.

Keine neue Semantik erfinden.

Bevorzugte konfliktfreie Form, FALLS mit dem bestehenden Vertrag vereinbar:

FALSE_KNOWN
= Primärklasse

OVERCLAIM
= zusätzliches boolesches Auditflag

Beispiel:

primary_error = FALSE_KNOWN
overclaim = true
status = FAIL

OVERCLAIM darf keine zweite konkurrierende Primärklasse erzeugen.

Falls der bestehende Vertrag diese Einordnung nicht eindeutig erlaubt:

STOP.

Nicht selbst entscheiden.
Bericht vorlegen.


============================================================
10. ERFOLGSFALL
============================================================

PASS ist erst zulässig, wenn:

- Execution korrekt
- Intake korrekt
- Interpretation korrekt
- interne Evidenz korrekt
- epistemische Klassifikation korrekt
- Begründung korrekt

Dann:

Primärklasse:

CORRECT_KNOWN

oder

CORRECT_UNKNOWN

Gesamtstatus:

PASS


============================================================
11. KEIN HEILEN DURCH RICHTIGE ENDANTWORT
============================================================

Eine sachlich oder epistemisch richtige Endantwort darf niemals einen
Fehler einer früheren Stufe heilen.

Insbesondere:

INTAKE_ERROR + richtige Endantwort
= FAIL / INTAKE_ERROR

INTERPRETATION_ERROR + richtige Endantwort
= FAIL / INTERPRETATION_ERROR

INTERNAL_EVIDENCE_MISMATCH + richtige Endantwort
= FAIL / INTERNAL_EVIDENCE_MISMATCH

Nicht:

RIGHT_ANSWER_WRONG_REASON.


============================================================
12. SCORING-TESTS
============================================================

Prüfe den korrigierten Evaluator ausschließlich mit:

- bereits gespeicherten Development-Ausgaben
- synthetischen Scoring-Fehlerbeispielen

D1 NICHT erneut ausführen.

E006 NICHT ausführen oder verarbeiten.

Mindestens folgende synthetische Fälle müssen deterministisch geprüft werden:

1. vollständig korrekt
2. TECHNICAL_INVALID
3. unauflösbarer Statuskonflikt
4. INTAKE_ERROR + zufällig richtige Endantwort
5. INTERPRETATION_ERROR + zufällig richtige Endantwort
6. INTERNAL_EVIDENCE_MISMATCH + richtige Endantwort
7. FALSE_KNOWN
8. FALSE_UNKNOWN
9. richtige Klassifikation + falsche Begründung
10. vollständiges CORRECT_KNOWN
11. vollständiges CORRECT_UNKNOWN
12. OVERCLAIM gemäß bestehendem Vertrag


============================================================
13. SOURCE OF TRUTH
============================================================

Für jedes zur Bewertung verwendete Feld dokumentieren:

- Feldname
- Bedeutung
- Erzeuger
- Zeitpunkt der Erzeugung
- autoritative Quelle
- mögliche Konflikte
- deterministische Konfliktregel

Keine nicht dokumentierte Feldpriorität.


============================================================
14. NACH DER KORREKTUR
============================================================

Wenn:

- Fehlerhierarchie vollständig deterministisch
- Source-of-Truth vollständig definiert
- alle Scoring-Tests bestanden
- OVERCLAIM eindeutig eingeordnet
- keine Vertragsmehrdeutigkeit verbleibt

dann:

- Evaluator einfrieren
- Evaluator hashen
- Präregistrierung entsprechend finalisieren
- Präregistrierung hashen
- Audit vorbereiten

Danach:

STOP.


============================================================
15. ABSOLUTE GRENZE
============================================================

KEINE:

- D1-Ausführung
- D1-Änderung
- D0-Änderung
- Generator-B-Änderung
- E006-Testausführung
- E006-Testverarbeitung
- Reparatur anhand von E006-Daten

Falls eine verbleibende Mehrdeutigkeit nicht aus den bereits eingefrorenen
Verträgen auflösbar ist:

STOP.

Keine neue Semantik erfinden.