D1 – Auditplan v1

Status: Plan, kein implementierter Audit und keine Diagnoseausführung.

1. Vor Ausführung
Präregistrierungs-, Generator-B-, Development-Completion-, D0- und historischen Regressionhashes prüfen. Erfolgreiche unabhängige Representation Completion und alle 32 Äquivalenzzertifikate müssen vorliegen. Die spätere D1-Version und der Auditharness werden vor der ersten Diagnose eingefroren. Developmentroster bleibt vollständig; Kriterien und Budget unverändert.

2. Informationsgrenze
Nur die öffentlichen Development-Inputs und fixierten historischen nativen Inputs gelangen zum Prüfling. Keine privaten Dateien, Labels, Zertifikate, Taxonomie, E006-Pfade oder erwarteten Antworten. Jede Originaldarstellung direkt am Eingang protokollieren. Der Entwicklungsharness darf sie nicht vorvereinheitlichen. Der neue interne Interpreter ist mitgeprüfter Code und trägt eigenen Hash.

Der spätere Diagnoseprozess soll denselben vorhandenen isolierten Python-Modus ohne Nutzer-/Workspace-Hooks, ohne Tools, mit temporärem Arbeitsverzeichnis, minimalem Umgebungssatz und ausschließlich eigenen freigegebenen Codekopien verwenden. Keine zusätzliche Host-, Netzwerk- oder Paketfreigabe. Die Anwendungskontrolle behauptet keine OS-Sperre gegen alle Dateizugriffe; technische Möglichkeiten des gemeinsamen Filesystems und Grenzen der Ledger-Evidenz sind offenzulegen. Benötigt echte Zugriffssperre zusätzliche Privilegien/Infrastruktur, STOP statt improvisieren.

3. Getrennte Representation-Prüfung
Ein unabhängiger audit-only Referenzpfad interpretiert die öffentlichen Formen nach dem Vertrag; keine Wiederverwendung des D1-Parsers als Oracle. Prüft die Interpretation jeder Formel auf sämtlichen Belegungen ihres Scopes, den Queryfaktor samt negativen Claimwerten und die gemeinsame Weltprojektion. Originalinput, parsing provenance, interner native Vertrag und Rohantwort müssen die Attribution ermöglichen. Ein gefalteter Truth-/Knownness-Nachweis im Intake wäre unzulässig. Jede Evidence bleibt erhalten.

4. Getrennte epistemische Prüfung
Der Auditor berechnet aus der Quelle normative zulässige Welten und Claimwerte und vergleicht die Antwort. Development-private.json und Completion-Zertifikate dürfen erst auf Auditseite als Gegenprüfung gelesen werden; niemals vom Diagnoseprozess oder als Implementationsquelle. Kein bestehender Gesamtverifieraufruf, der sealed-test-Dateien liest. Unklare oder widersprüchliche Development-Ground-Truth bedeutet STOP, keine Änderung von Generator B.

5. Regression und Invarianz
48 native historische Ausgaben gegen die unveränderten Rohreferenzen prüfen. Drei Darstellungen je der 32 Development-Kerne semantisch und epistemisch vergleichen, Actual-Intakepfad dokumentieren. Fehlerquoten sowohl nach Darstellungen als auch nach Kern/Tripel berichten; keine Pseudoreplikation. Falls Representation falsch, Kernbefund NOT ASSESSABLE. Korrekte Darstellung plus falscher epistemischer Befund löst Kern-STOP aus.

6. Development-Runden
Jede Runde und Änderung separat archivieren. Eine Reparatur braucht konkrete Gegenüberstellung zum vorab fixierten Formatvertrag und muss als Intake-/Interpretationsfehler nachweisbar sein. Keine neue Regel aus dem beobachteten Ergebnis ableiten. Höchstens zwei Reparaturrunden; kritische Stop-Regeln gehen vor Budget. Erfolgreiche Runde überschreibt keine Fehlversuche. Eine erneute Ausführung nach technischer Abweichung ist keine kostenlose Wiederholung.

7. Abschluss
Auditresultate sind eigene Artefakte mit Quellen und Grenzen der Unabhängigkeit. Keine automatische Annahme, dass zwei selbst erstellte Implementationen unabhängig fehlerfrei sind. Formel-/Modellbeweise und Zugangsnachweise sind getrennt vom Diagnose-Score zu dokumentieren. Keine versiegelte E006-Ausführung folgt automatisch aus Development-Erfolg. Nach jeder Entwicklungsgenehmigung und deren definiertem Abschluss STOP; die jetzige Phase bleibt reine Präregistrierung.
