D1 – Architekturspezifikation v1

Status: ausschließlich Spezifikation. Kein D1-Code, keine Ausführung.

1. Prüfling und Messgrenze
D1 ist ein neuer abgeleiteter epistemischer Prüfling. Seine Messgrenze beginnt bei der vollständigen ursprünglichen Darstellung einschließlich Evidenz und Claim. Intake, formatspezifische Interpretation, interne Evidenzerzeugung, unveränderter epistemischer D0-Kern und Antwortprojektion liegen sämtlich INNERHALB dieser Grenze. Eine vorgelagerte gemeinsame Kanonisierung ist ausgeschlossen. Kein Ergebnis wird dem D0-Prüfling allein zugeschrieben.

D0 bleibt unveränderte Referenz: outputs/epistemic-pilot-preparation/instrument/diagnose.py, SHA-256 25483906b0b10803617044f108dd9852d6dc97ed13973a6f843064e618362c0c. Die zukünftige D1-Version muss diesen Quelltext bytegleich als Kern verwenden. Änderungen daran sind nicht zulässig; diese Architektur entscheidet sich für Wiederverwendung statt für einen neu implementierten äquivalenten Solver. Die alte Datei wird nicht bearbeitet. Kopie und Herkunft müssten vor späterer Ausführung gehasht werden.

2. Öffentliche Aufnahme
D1 akzeptiert egb-finite-boolean-v1 aus dem eingefrorenen Generator-B-Vertrag: case_id, contract, universe(atoms,domain), evidence(representation,statements), claim. Der Prüfling erhält ausschließlich diesen öffentlichen Datensatz. IDs sind reine Korrelation und dürfen keine Verzweigung, Logik oder Faktornamen steuern. Universum vollständig übernehmen, auch unbeschränkte Atome. Domain besteht aus Boolean false/true; keine Typkoercion von Zahlen oder Strings. Keine erwarteten Labels, verborgenen Welten, Zertifikate, Kern-/Familienzuordnungen oder Paarinformationen in der Anfrage.

Eingangsbytes und strukturiertes Originalobjekt werden unverändert als Rohartefakte erhalten. Reine JSON-Serialisierung außerhalb des Prüflings darf keine Formelstruktur verändern. Der representation-Wert wählt innerhalb D1 ausschließlich den passenden Formatinterpreter.

Zusätzlich hat D1 einen expliziten nativen Regressionseingang für finite_provided_evidence. Dieser leitet dieselben unveränderten Daten an denselben eingefrorenen Kern und gibt dessen vollständigen bisherigen Vertrag zurück. Kein Mapping dieses nativen Antwortvertrags auf Generator-B-Kategorien. Dieser Modus dient ausschließlich der registrierten D0-Regression.

3. Interpretationsregeln
Tree: Jede ref bezieht sich auf ein deklariertes Atom. Verschachtelung und Argumentpositionen werden erhalten. not hat genau ein Argument; iff und implies genau zwei. all/any/xor/count verwenden die nichtleere vertragliche Argumentliste. all ist Konjunktion, any Disjunktion, xor ungerade Parität, iff Wertgleichheit, implies ist nur bei true/false falsch. count zählt wahre Argumentvorkommen und prüft das inklusive Intervall minimum..maximum. Argumentvorkommen niemals deduplizieren. Operatorparameter werden nicht optimiert. Integerparameter sind keine Booleans.

Postfix: Die vollständige Tokenfolge wird im Prüfling verarbeitet. push referenziert ein deklariertes Atom. Für jeden Operator werden die letzten arity Operanden in ihrer ursprünglichen Links-nach-rechts-Reihenfolge verwendet; beim implies ist der erste Operand Antezedens. Stackunterlauf, falsche Arity und ein Endstack mit anderer Größe als eins sind Formatfehler. Keine vor der D1-Grenze erzeugte Baumform als Ersatzinput. Ein interner symbolischer Stack beziehungsweise interner Baum ist zulässig und wird durch Token-/Operanden-Provenienz nachvollziehbar gemacht.

Relation: scope-Reihenfolge legt die Spaltenzuordnung fest. true_rows sind eindeutige binäre Zeichenketten passender Länge. Unaufgeführte Scope-Tupel machen diese einzelne Formel falsch; nicht aufgeführte ganze Welten dürfen nicht stillschweigend global ausgeschlossen werden. Lokale Evidenzrelationen gelten konjunktiv. Claim wird getrennt als Wahrheitsfunktion behandelt, niemals als zusätzlich behauptete Evidenz.

Ungültige Operatoren/Parameter/Referenzen werden nicht repariert, geraten oder durch Defaults ergänzt. Keine Umdeutung von count, iff, implies oder UNKNOWN nach Development-Ergebnissen.

4. Explizite interne Evidenz
Die kleinste gewählte Erweiterung bildet jede einzelne öffentliche Formel auf eine endliche Wahrheitsrelation ab, unabhängig von den anderen Evidenzformeln. Die Interpretation darf dafür die fest definierte Operatorsemantik über lokale Belegungen auswerten. Sie darf nicht Evidenz gemeinsam lösen, relevante Formeln auswählen, unter Evidenz vereinfachen oder den erwarteten epistemischen Status berechnen.

Für tree/postfix besteht der Scope einer Formel aus ihren syntaktisch referenzierten Atomen in der Universumsreihenfolge. Syntaktisch vorhandene, aber semantisch entbehrliche Atome bleiben im Scope. Für relation bleibt der ausdrücklich gelieferte Scope in seiner Reihenfolge erhalten. Alle Atomdomains bleiben [false,true]. Keine semantische Pruning-Regel, kein Auslassen tautologischer Evidenz, keine Zusammenführung unterschiedlicher Evidenzstatements.

Interner Vertrag: finite_provided_evidence, context_variables=[], queries.task=q und queries.access=a. q ist ein frischer Boolean-Ausgang für den Claim, a ein frisches unabhängiges Singleton mit Domain [false]. IDs für Variablen und Faktoren werden deterministisch aus öffentlichen strukturellen Positionen erzeugt, ohne Fall-ID, Familie, Label oder private Daten. Jede Evidenzformel erhält genau einen Faktor mit ihren zulässigen lokalen Wahrheitszeilen. Jede when-Bedingung ist konstant vars=[]/allowed=[[]]. when ist Pflichtfeld des D0-Kerns.

Der Claim erhält genau einen definierenden Faktor über seinen Scope plus q: Für jede Scope-Belegung b gibt es exakt die Zeile (b, Wahrheitswert des Claim bei b). Beide Möglichkeiten q=false/true müssen erhalten bleiben; q selbst erhält immer die vollständige Boolean-Domain. Claim nicht auf true festsetzen und keine Evidenzmodelle vorab filtern.

Der intern erzeugte Vertrag, Original-Scope-Mappings, öffentliche Statementpositionen, Querybindung und Interpretationsspur müssen auditierbar persistiert werden. Die Spur beschreibt Parsing/Interpretation, nicht neue epistemische Gründe. Hilfsvariable a ist technische Bindung an einen Zweifragenkern, keine Aussage über realen Zugang.

5. Semantischer Nachweis
Sei M(E) die Menge vollständiger Quellbelegungen, die sämtliche Evidenz erfüllen. Die internen Evidenzfaktoren definieren dieselbe Menge auf denselben Originalatomen. Für jede solche Belegung gibt es genau eine Erweiterung um q=Claim(belegung) und a=false; umgekehrt projiziert jedes interne Modell auf genau eine Quellbelegung. Damit ist die Menge möglicher q-Werte identisch zur Menge der Claimwerte in M(E). Diese Korrespondenz wird im Audit unabhängig von erwarteten Diagnosen geprüft.

Diese Konstruktion erhöht die Zahl der Variablen nur um q und a; bei vier/fünf Development-Atomen sind es sechs/sieben interne Variablen. Bei maximal sieben Development-Evidenzstatements sind es maximal acht interne Faktoren. Keine Gate-Hilfsvariable pro Operator, kein neuer Solver und keine Laufzeitoptimierung nach Resultaten.

6. Epistemischer Kern und Ausgabe
Der unveränderte D0-Kern bestimmt bekannte Rollenwerte aus den internen Modellen. Bei genau einem erfüllbaren leeren Kontext wird ein vorhandenes Boolean known.task unverändert zu epistemic=KNOWN und known_value=dem Wert. Bei task_values=[false,true], TASK_GAP und fehlendem known.task wird epistemic=UNKNOWN und known_value=null. Der erhaltene case_id wird unverändert zurückgegeben.

Fehlendes known.task allein reicht nicht für UNKNOWN. Widerspruch, fehlende/mehrere Profile, unerwartete Accesswerte, widersprüchliche Profil-/Known-Angaben und Nicht-Boolean-Werte sind Fehler mit STOP, keine heuristische Klassifikation. Raw D0-output bleibt unverändert archiviert. Keine bekannten/unknown Schwellen, neue Relevanzregeln oder neue Begründungen aus question_contributions.

7. Erlaubte/verbotene Änderungen
Erlaubt nach gesonderter Freigabe sind ausschließlich neuer Intake, drei deterministische Interpretationspfade, explizite interne Evidenzerzeugung, überprüfte Format-/Querybindung, Antwortserialisierung sowie Development-Harness und Audit außerhalb des Prüflings. D0-Kern wird bytegleich wiederverwendet.

Verboten sind Änderungen an D0, dessen Evaluator/Tests/Resultaten, Colony-Versionen, Generator B oder bestehenden Development-Kernen. Kein SEARCH, Memory, Training, LLM, neue Agentenarchitektur, Taxonomie-Sonderfall, fallbezogene Heuristik, private Ground Truth im Prüfling, neue Runtime, Pakete oder Sandbox-Erweiterung. Kein externer Normalisierer vor der D1-Messgrenze. Kein E006-Testinput an D1.
