AUFTRAG AN CODEX
D1 – MULTI-REPRESENTATION EPISTEMIC DIAGNOSIS
PRÄREGISTRIERUNG UND DEVELOPMENT-VERTRAG

STATUS

D0:
- eingefrorener bisheriger epistemischer Prüfling
- ursprünglicher versiegelter Pilot: 48/48
- akzeptiert ausschließlich finite_provided_evidence

Generator B:
- unabhängig erzeugt
- eingefroren
- 32 Development-Kerne
- 20 versiegelte Test-Kerne
- 3 Darstellungen pro Test-Kern
- insgesamt 60 versiegelte Testdatensätze
- 10 Minimalpaare

Generator-B-Testvertrag:

Die drei Darstellungen sind eine experimentelle Variable:

1. Baumstruktur
2. Postfix-/Stackdarstellung
3. extensionale Relationsdarstellung

Eine vorgelagerte gemeinsame Kanonisierung ist NICHT zulässig.

Interne Interpretation/Kanonisierung durch den Prüfling ist zulässig,
wenn der Prüfling zunächst die vollständige Originaldarstellung erhält.

E006 wurde NICHT ausgeführt.

Kein versiegelter E006-Testfall wurde diagnostiziert.


============================================================
1. ZIEL
============================================================

Entwickle noch NICHT sofort D1.

Erstelle zuerst einen verbindlichen Development-Vertrag für D1.

D1 soll später folgende zusätzliche Fähigkeit gegenüber D0 besitzen:

D1 erhält die vollständige Originalrepräsentation eines Problems und
interpretiert diese selbst, bevor die epistemische Diagnose erfolgt.

Die getestete Systemgrenze von D1 umfasst daher:

ORIGINALDARSTELLUNG
→ Interpretation
→ interne Evidenzrepräsentation
→ epistemische Diagnose

Die Interpretation gehört ausdrücklich zum Prüfling.


============================================================
2. D0 BLEIBT UNVERÄNDERT
============================================================

D0 darf NICHT verändert werden.

Insbesondere nicht:

- Diagnosealgorithmus
- epistemische Regeln
- bekannte/unknown Logik
- Evaluator
- ursprüngliche Testfälle
- ursprüngliche Resultate

D0 bleibt Referenzinstrument.


============================================================
3. D1 DARF KEIN ADAPTER VOR D0 SEIN
============================================================

D1 darf nicht lediglich aus folgendem Aufbau bestehen:

Generator-B-Input
→ externer semantischer Adapter
→ D0

wenn der Adapter bereits die experimentelle Darstellungsvariation
beseitigt.

Die Verarbeitung der Originaldarstellung muss Bestandteil der
Prüfgrenze von D1 sein.

Zulässig ist:

D1
  ├─ Representation Intake
  ├─ Interpretation
  ├─ interne Repräsentation
  └─ epistemischer Kern

Nicht zulässig:

externer Normalisierer
→ kanonische finite_provided_evidence
→ unveränderter D0-Prüfling

und anschließend Behauptung von Darstellungsinvarianz.


============================================================
4. ERLAUBTE REPRÄSENTATIONEN
============================================================

D1 darf ausschließlich für die vom unabhängigen Testautor definierten
RepräsentationsKLASSEN entwickelt werden:

A. Baum

Erhalten und interpretieren:

- Baumverschachtelung
- Argumentzuordnung
- Operatorparameter
- ursprüngliche Claimdarstellung


B. Postfix / Stack

Erhalten und interpretieren:

- Tokenfolge
- Stacksemantik
- Operatorparameter
- ursprüngliche Claimdarstellung


C. Extensionale Relation

Erhalten und interpretieren:

- Relationsscopes
- Spaltenzuordnung
- Wahrheitszeilen
- ursprüngliche Claimdarstellung

D1 darf wissen, wie diese drei FORMATE definiert sind.

D1 darf NICHT die 60 versiegelten konkreten Testdatensätze sehen.


============================================================
5. DEVELOPMENT-DATEN
============================================================

Für Entwicklung und technische Prüfung dürfen ausschließlich die
32 Generator-B-Development-Kerne verwendet werden.

Versiegelte Testdaten bleiben tabu.

Development und Test bleiben strikt getrennt.


============================================================
6. DEVELOPMENT NICHT SOFORT AUSFÜHREN
============================================================

Vor der ersten Ausführung eines Generator-B-Development-Falls:

erstelle und archiviere:

- D1-Architekturspezifikation
- erlaubte Änderungen gegenüber D0
- verbotene Änderungen
- erwartete interne Verträge
- Fehlerklassen
- Acceptance Criteria
- Development-Budget
- Stop-Regeln

Erst danach darf Development beginnen.


============================================================
7. D1-ARCHITEKTURPRINZIP
============================================================

Bevorzuge die kleinste mögliche Erweiterung.

Keine neue Agentenarchitektur.

Keine LLM-Schicht.

Kein SEARCH.

Kein Memory.

Kein Training.

Keine heuristische Reparatur.

Keine neue Colony-Infrastruktur.

D1 soll möglichst bestehen aus:

Representation Intake
→ deterministische Interpretation
→ explizite interne Evidenz
→ bestehende oder nachweislich äquivalente epistemische Diagnose

Die Interpretation darf komplex sein.

Sie muss aber:

- deterministisch
- auditierbar
- reproduzierbar

sein.


============================================================
8. WICHTIGE TRENNUNG

D1 besitzt zwei getrennt zu prüfende Fähigkeiten:

A. REPRESENTATION CORRECTNESS

Hat D1 die Originaldarstellung korrekt interpretiert?

B. EPISTEMIC CORRECTNESS

Hat D1 aus der interpretierten Evidenz die korrekte epistemische
Diagnose erzeugt?

Diese Fehlerklassen niemals zusammenwerfen.


============================================================
9. INTERMEDIATE REPRESENTATION

Falls D1 intern finite_provided_evidence oder eine äquivalente kanonische
Form verwendet, ist das zulässig.

ABER:

Diese Form muss innerhalb der D1-Prüfgrenze erzeugt werden.

Für Development muss die erzeugte interne Evidenz auditierbar sein.

Damit kann getrennt festgestellt werden:

INPUT korrekt interpretiert?
JA/NEIN

EPISTEMISCHE DIAGNOSE korrekt?
JA/NEIN


============================================================
10. D0-REGRESSION

D1 darf die epistemische Bedeutung von D0 nicht stillschweigend verändern.

Erstelle deshalb einen Regressionstest.

Wenn D1 direkt oder über eine eindeutig äquivalente interne Repräsentation
dieselbe Evidenz wie D0 erhält, müssen D0 und D1 epistemisch äquivalent
entscheiden.

Verwende dafür ausschließlich bereits freigegebene historische bzw.
Development-Daten.

NICHT die 60 E006-Testdatensätze.


============================================================
11. DEVELOPMENT-BUDGET

Vor Development ein festes Änderungsbudget definieren.

Mindestens:

- maximale Anzahl Development-Runden
- erlaubte Fehlerarten, die repariert werden dürfen
- verbotene semantische Änderungen
- Kriterien für Abbruch

Eine Development-Runde bedeutet:

Implementierung
→ definierter Development-Test
→ Analyse
→ gegebenenfalls erlaubte Reparatur

Keine unbegrenzte Optimierung bis 100 %.


============================================================
12. ERLAUBTE REPARATUREN

Während Development dürfen ausschließlich Fehler im neuen
Representation-Intake bzw. dessen formaler Interpretation repariert werden,
wenn sie auf eine falsche Implementierung der bereits präregistrierten
Formatspezifikation zurückzuführen sind.

Beispiele:

- falsche Stackoperation
- falsche Baumargumentzuordnung
- falsches Relationsspalten-Mapping
- Parserfehler
- Serialisierungsfehler

NICHT erlaubt:

- epistemische Regeln aufgrund beobachteter Development-Ergebnisse verändern
- Sonderfälle für konkrete Aufgaben einbauen
- fallbezogene Heuristiken
- Generator-B-Taxonomie nachbauen
- Known/Unknown-Schwellen optimieren


============================================================
13. KRITISCHE STOP-LINIE

Wenn D1 nur dadurch Development-Fälle korrekt lösen kann, dass der
epistemische Kern gegenüber D0 semantisch verändert werden muss:

STOP.

Nicht verändern.

Berichten:

D1 REPRESENTATION EXTENSION NOT SUFFICIENT.


============================================================
14. DEVELOPMENT-ERFOLG

Vor Testbeginn Kriterien präregistrieren.

Mindestens getrennt:

- Representation Correctness
- Epistemic Correctness
- D0 Regression
- Cross-Representation Consistency

Kein Kriterium nach Sichtung der Resultate verändern.


============================================================
15. CROSS-REPRESENTATION TEST

Für Development-Kerne mit mehreren Darstellungen getrennt prüfen:

Baum
Postfix
Relation

Die interne Interpretation darf nach erfolgreicher Verarbeitung zu
derselben semantischen Evidenz führen.

Aber die drei Originalformen müssen tatsächlich durch die jeweils
spezifizierte D1-Verarbeitung gelaufen sein.

Keine vorgelagerte Vereinheitlichung.


============================================================
16. PROVENIENZ

Persistieren:

- D1-Spezifikation
- Development-Vertrag
- alle Codeversionen
- Hashes
- jede Development-Runde
- verwendete Development-IDs
- beobachtete Fehler
- vorgenommene Änderungen
- Begründung jeder Änderung
- Regressionsergebnisse

Keine erfolgreiche Runde darf frühere Fehlversuche überschreiben.


============================================================
17. GENERATOR B BLEIBT EINGEFROREN

NICHT:

- Generator B verändern
- Testautor erneut um Anpassungen bitten
- Testfälle verändern
- Development-Fälle nachträglich ersetzen
- neue "leichtere" Development-Fälle erzeugen

Generator B ist fertig.


============================================================
18. E006 BLEIBT VERSIEGELT

Unter keinen Umständen:

- einen der 60 Testdatensätze an D1 übergeben
- Testfälle für Smoke-Tests verwenden
- Test-Ground-Truth lesen, um D1 zu entwickeln
- einzelne Testfälle probeweise ausführen
- E006-Ergebnisse berechnen


============================================================
19. NÄCHSTER STOP

Diese Codex-Phase besteht zunächst NUR aus:

1. D1-Architekturspezifikation
2. Development-Vertrag
3. Development-Budget
4. Acceptance Criteria
5. D0-Regressionsplan
6. Auditplan

NOCH KEIN D1-CODE.

Nach Erstellung:

STOP.

Bericht vorlegen.

Erst nach ausdrücklicher Freigabe darf D1 implementiert und auf
Generator-B-Development ausgeführt werden.


============================================================
20. ERFOLGSDEFINITION

Erfolg dieser Phase bedeutet:

"D1 ist vollständig präregistriert und kann entwickelt werden, ohne den
versiegelten E006-Test zu kontaminieren."

Nicht:

"D1 funktioniert."

Nicht:

"E006 PASS."