D1 – verbindlicher Development-Vertrag v1

Diese Dokumentation präregistriert die spätere Entwicklung, führt sie aber nicht aus. Die aktuelle Phase enthält keinen D1-Code. Implementation und Development benötigen eine ausdrückliche weitere Freigabe. Die getrennt freigegebene Representation Completion ist Testautorarbeit und zählt nicht als D1-Development-Runde.

Datenbestand
Genau 32 bestehende unabhängige Generator-B-Development-Kerne. Die ursprünglichen Daten enthalten ausschließlich Baumdarstellungen. Der menschliche Nutzer hat inzwischen die unabhängige Ergänzung um genau je eine Postfix- und Relationsdarstellung durch denselben isolierten Autor freigegeben. Diese 64 zusätzlichen Datensätze dürfen erst nach erfolgreicher separater Zertifizierung und Versiegelung als Development-Inputs gebunden werden. D1-Entwicklung entwirft sie nicht selbst. Der Originalsatz bleibt unverändert; die Ergänzung wird als später erzeugter Development-Satz gekennzeichnet.

Die bindende Development-Menge wäre danach 96 Darstellungen derselben 32 Kerne. Das sind 32 unabhängige Kerne, keine 96 unabhängigen Problembeobachtungen. Roster und Herkunft müssen die Zuordnung eindeutig belegen. Keine Ersatzfälle, neuen semantischen Kerne, Distraktoren, Evidenzänderungen, Claims oder Minimalpaare. Keine Auswahl leichter erfolgreicher Teilmengen.

Die 60 versiegelten E006-Datensätze und ihre privaten Dateien sind ausgeschlossen. Keine Generierung oder vollständige Generator-B-Verifikation, die diese Dateien mitliest. Im jetzigen D1-Spezifikationsschritt wurden nur öffentliche Development-Metadaten/Strukturgrößen gelesen, keine Diagnose berechnet.

Development-Reihenfolge
Lexikographische Reihenfolge der 32 registrierten ursprünglichen Kern-IDs; je Kern tree, postfix, relation. Die später zertifizierte Autorzuordnung bindet je Format die konkrete öffentliche Input-ID und den Hash, ohne Auswahl nach Inhalt oder Diagnose. Der Prüfling erhält stets die tatsächliche Originalform der jeweiligen freigegebenen Development-Darstellung, nicht ein im Harness vereinheitlichtes Format. Original-IDs sind keine semantischen Features.

Pro Runde folgen alle 96 Originalform-Diagnosen und die 48 bereits ausgeführten historischen nativen D0-Regressionsfälle in unveränderter damaliger Sequenz. Genau ein Diagnoseversuch je festem Payload und Runde. Kein fallweises Reparieren, Nachreichen oder Wiederholen. Erst nach dem vollständigen definierten Batch werden Fehler analysiert; kritische Stop-Regeln beenden ihn sofort. Protokollierte nicht mehr ausgeführte Restfälle bleiben sichtbar.

Representation Correctness
Ein unabhängiger Auditpfad liest nur öffentliche Development-Evidenz und Claim. Er prüft Intake/Scope-/Token-/Argument-/Parameterbindung, jede interne lokale Relation auf allen Scope-Belegungen, die vollständige Evidence-Liste, die Query-Wahrheitsfunktion und die Projektion auf Quellwelten. Der Auditpfad darf nicht den D1-Interpreter als seine Referenz importieren. Originalform und intern erzeugte Evidenz sind beide zu persistieren.

Epistemic Correctness
Aus den unabhängig geprüften öffentlichen Quellbelegungen wird der normative KNOWN_TRUE/KNOWN_FALSE/UNKNOWN-Status im Audit bestimmt und mit der Antwort verglichen. Development-Labels/Zertifikate dürfen nur als Auditkontrolle verwendet werden, niemals als Anfrage- oder Implementationsquelle. Verborgene tatsächliche Wahrheit ist nicht dasselbe wie epistemische Begründbarkeit. Die originale Development-Ground-Truth bleibt unverändert. Bestehende private Testdaten werden nicht gelesen.

Representation-Fehler und epistemische Fehler getrennt berichten. Wenn Interpretation falsch ist, wird die epistemische Kernbeurteilung als NOT ASSESSABLE markiert; die end-to-end Antwort kann trotzdem als gegen die Quellaufgabe falsch dokumentiert werden. Bei korrekter Interpretation und falscher epistemischer Entscheidung keine weitere Intake-Reparatur vorschieben: STOP gemäß Kern-Grenze.

Cross-Representation Consistency
Für jeden ursprünglichen Kern müssen alle drei Originalformen nachweislich ihre eigenen D1-Interpretationspfade durchlaufen. Vergleich vollständiger Evidenz-/Claim-Semantik, nicht bloß gleicher Herkunftsetiketten oder gleich falscher Antworten. Unterschiedliche interne Scope-/Zeilenordnungen sind nur bei bewiesener Modellkorrespondenz zulässig. Raw Outputs, Intakepfad und interne Evidenz je Darstellung werden getrennt archiviert.

Provenienz
Jede Runde erhält eigenes unveränderliches Verzeichnis mit Inputroster/Hashes, vollständigem D1-Codehash einschließlich bytegleichem D0-Kern, Architekturspezifikations-/Kriterienhash, Intake-Rohdaten, interner Evidenz, Rohantworten, Fehlern, Auditresultaten und begründeter Änderungsliste. Vorherige Runden nie überschreiben. Case-ID, Kern-ID, Darstellung, Rundennummer und technische Ausführung getrennt erfassen. Erfolgreiche spätere Runde löscht keinen früheren Fehler.

Die letzte erfolgreiche Runde ist nur ein Development-Befund. Der alte 48/48-Pilot bleibt historische Referenz in seinem Testraum. Development-Erfolg ist weder E006 PASS noch eine Freigabe des versiegelten Tests. D1 kann erst nach eigenständiger Testpräregistrierung und ausdrücklicher Ausführungsfreigabe Gegenstand eines versiegelten Versuchs werden.
