Wenn gültiges JSON nicht genügt: 995 reale KI-Tool-Calling-Experimente

Alle 960 Antworten aus den Intent-Tests dieses Experiments ließen sich als gültiges JSON parsen und bestanden den jeweils vorgesehenen Validierungspfad. Trotzdem wählte das Modell in manchen Fällen die falsche Aktion – etwa beim Unterschied zwischen dem Löschen eines Werts und dem unveränderten Beibehalten.

ArgBridge, der untersuchte reversible Codec, erreichte 91,1 % Genauigkeit bei der exakten Umsetzung der Absicht. Eine einfachere Kontrollvariante mit dem ursprünglichen Tool-Schema ohne Strict-Modus und anschließender lokaler Validierung erreichte 96,4 %. Bei ArgBridge lagen die Kosten je korrekt umgesetzter Absicht in diesem Lauf außerdem 46,1 % höher.

Die 995 Experimente im Titel waren 995 echte API-Anfragen: 35 Schema-Probes und 960 Intent-Tests, aufgebaut auf 56 synthetischen Anweisungen. Es waren keine 995 unabhängigen Kundenworkflows. Die technische Frage lautete: Hilft eine Darstellung, die Datensemantik verlustfrei erhält, einem Modell auch bei der Auswahl der richtigen Operation? Das sind unterschiedliche Eigenschaften.

Die drei Zustände in einem Patch

Nehmen wir eine Update-API mit folgendem Vertrag:

{}                   # vorhandenen Namen unverändert lassen
{"name": None}       # Namen löschen
{"name": "Grace"}    # Namen ersetzen

Diese Patch-Semantik legt die Anwendung fest. JSON selbst bedeutet mit null nicht automatisch „löschen“. Sobald eine API null so verwendet, gehört aber auch die Anwesenheit eines Felds zu ihrem öffentlichen Vertrag.

Die Anforderungen für striktes Function Calling bei OpenAI verlangen geschlossene Objektschemas mit additionalProperties: false; außerdem muss jede deklarierte Eigenschaft in required stehen. Null als erlaubten Typ hinzuzufügen ermöglicht einen null-Wert. Es kann jedoch nicht gleichzeitig das Weglassen eines Felds ausdrücken, wenn null bereits eine fachliche Bedeutung hat.

Ein Adapter, der fehlende Felder mit null auffüllt, kann aus „nichts ändern“ ein „löschen“ machen. Ein Adapter, der null-Werte entfernt, kann einen ausdrücklich gewünschten Löschvorgang verschwinden lassen. Beide Transformationen können gültiges JSON erzeugen und trotzdem die Operation verändern.

Typisierte Dictionaries schaffen einen weiteren Konflikt. Ein Vertrag wie „beliebige Label-Namen mit nullable String-Werten“ benötigt dynamische Schlüssel. Wird das Objekt einfach geschlossen, sind diese Schlüssel ausgeschlossen. Gesucht ist also eine Transportdarstellung, die den ursprünglichen Vertrag unter strengeren Schema-Anforderungen erhält.

Die ursprüngliche Hypothese betraf den Transport: Innerhalb eines unterstützten Teilumfangs sollte ein reversibler Codec fehlende Felder, explizite null-Werte und typisierte Maps erhalten und dabei strikte Schemas erzeugen. Zustandsmarkierungen und Schlüssel-Wert-Paare machten das technisch plausibel: Die Informationen ließen sich explizit darstellen, ohne verschiedene Zustände zusammenzuführen. Für den praktischen Nutzen blieb offen, ob ein Modell diese Darstellung zuverlässig genug erzeugen würde, um ihre Kosten zu rechtfertigen.

Die Architektur: Anwesenheit kodieren, an zwei Grenzen validieren

ArgBridge kompiliert ein unterstütztes Quellschema in ein Wire-Schema und einen internen Transformationsplan. Ein optionales Feld erhält eine explizite Zustandsmarkierung:

{"state": "absent"}

{"state": "present", "value": null}

{"state": "present", "value": "Grace"}

Das sind Ausschnitte auf Feldebene; die vollständige Wire-Nachricht enthält zusätzlich ein arguments-Wurzelelement. Pflichtfelder behalten ihre Werte über den jeweiligen untergeordneten Codec. Typisierte Maps werden als entries-Array aus Schlüssel-Wert-Paaren übertragen. Objekte mit festen und dynamischen Feldern verwenden fields und entries. Doppelte Schlüssel und Einträge, die deklarierte Felder überschreiben würden, werden zurückgewiesen.

Für unterstützte, gültige Eingaben x ist die angestrebte Invariante decode(encode(x)) == x – einschließlich der Information, welche Felder vorhanden sind. Leerzeichen, Schlüsselreihenfolge und numerische Schreibweisen mit beliebiger Präzision werden damit nicht erhalten.

Das Modell erzeugt die Wire-Darstellung unmittelbar. Es erzeugt nicht zuerst einen korrekten ursprünglichen Patch, den der Encoder anschließend transportiert. Genau an dieser Stelle reicht die deterministische Roundtrip-Korrektheit nicht mehr aus, um die Zuverlässigkeit des Modells zu beurteilen.

Die Implementierung trennt die Grenzen:

1. Die Kompilierung validiert das Schema, lehnt nicht unterstützte Konstrukte ab und begrenzt die Expansion. Schemas werden defensiv kopiert; entfernte Referenzen sind deaktiviert.
2. Das Kodieren vorhandener Daten validiert den ursprünglichen Wert, transformiert ihn und validiert den erzeugten Wire-Wert.
3. Das Dekodieren der Modellantwort prüft den Wire-Wert, rekonstruiert das ursprüngliche JSON und validiert erneut gegen den vollständigen Originalvertrag. Der mitgelieferte loads-Parser lehnt zusätzlich doppelte Schlüssel im rohen JSON ab, bevor ein Python-Dictionary sie verdecken könnte.
4. Die Ausführung in der Anwendung bleibt Aufgabe des Aufrufers. guarded_call ruft nach dem Dekodieren einen Handler auf. Es authentifiziert und autorisiert nicht, isoliert den Handler nicht und stellt keine Transaktion her.

Die abschließende Prüfung gegen das Quellschema ist erforderlich. Eine markierte Variante kann zu einer Alternative eines ursprünglichen oneOf passen und gleichzeitig eine zweite erfüllen. Das verletzt die geforderte Exklusivität. Die isolierte Validierung des Wire-Zweigs würde dies nicht erkennen.

Auch Ressourcenlimits gehören zur Grenze: eine Million JSON-Bytes, 20.000 Knoten, Tiefe 64 und eine begrenzte Schema-Expansion. Das Release ergänzt Prüfungen für expandierte Schemas, Bundles und CLI-Serialisierung, damit eine Ausgabe nicht das Budget ihres eigenen Lesers überschreiten kann. Das sind konkrete Schutzmaßnahmen, kein vollständiger Beweis gegen Denial-of-Service-Angriffe. Siehe Architektur und Geltungsbereich.

Was die deterministischen Tests zeigen konnten

Der ursprüngliche Offline-Korpus stellte 40 gültige Eingaben exakt wieder her, wies 36 ungültige Quelleingaben zurück und lehnte 12 feindliche Wire-/JSON-Fälle ab. Er führte 87 Assertions aus einer extern erstellten JSON-Schema-Testsuite aus. Weitere 256 Assertions wurden ausdrücklich ausgeschlossen, weil ihre Schemas außerhalb des unterstützten Teilumfangs lagen.

Für diese Assertions liefert die externe Suite unabhängige Urheberschaft. Dadurch werden die lokal entworfenen Workflows oder der Modellbenchmark jedoch nicht unabhängig. Property-Tests und feste Fixtures prüfen nützliche Transportinvarianten. Sie beantworten nicht, ob ein Modell aus einer Anweisung die richtige Zustandsmarkierung auswählt.

Als Projektverantwortlicher verlangte ich deshalb eine semantische Evaluation mit einem echten Modell. Bestandene Roundtrip-Tests reichten als Nachweis für zuverlässige Tool-Nutzung nicht aus. Der Vergleich mit aktuellen Alternativen musste sowohl die beabsichtigten Aktionen als auch Schema-Akzeptanz, zusätzlichen Tokenbedarf, Latenz und Kosten erfassen.

Ein eingefrorener Benchmark mit sechs Ansätzen

Der Korpus enthält 56 englische Anweisungen für flache Einstellungen, verschachtelte Einstellungen, typisierte Labels und einen Kontrollworkflow mit Pflichtfeldern. Sieben primäre Kategorien decken Weglassen, explizites null, gewöhnliche Änderungen, Verschachtelung, Dictionaries, Mehrdeutigkeit sowie ungültige beziehungsweise adversariale Eingaben ab – jeweils acht Anweisungen pro Kategorie.

Anweisungen und Workflow-Kennungen stehen in scenarios.json. Erwartete Aktionen und exakte Patches stehen getrennt in expected.json. Diese Soll-Ergebnisse wurden vor der Inferenz festgelegt und nie an das Modell übermittelt. Die Trennung verhindert, dass die Antwort mitgeliefert wird. Sie begründet keine unabhängig erstellte Referenzwahrheit.

Jeder unterstützte Ansatz erhielt dieselbe Anweisung, denselben Originalvertrag, Anfangszustand, dieselben Regeln und Modelleinstellungen. Die Transportdarstellung unterschied sich. Die sechs Varianten waren:

• ArgBridge: ursprüngliches generiertes Wire-Schema und reversibler Decoder.
• Faktorisiertes ArgBridge: gemeinsam genutzte Beschreibungen und wiederkehrende Schemaknoten über lokale Referenzen; Wire-Werte und Decoder blieben unverändert.
• Handgeschriebene strikte Operationen: ein speziell für die vier Workflows entworfener Wrapper mit Operationslisten.
• Originalschema ohne Strict-Modus + Validierung: ursprüngliches Schema mit explizitem strict: false, anschließend Validierung gegen den Originalvertrag.
• OpenAI-Agents-Strict-Konvertierung: die dokumentierte Transformation aus openai-agents 0.24.0, gefolgt von der Prüfung des Originalvertrags.
• Mastra-Strict-Konvertierung: der dokumentierte OpenAI-Kompatibilitätspfad aus schema-compat 1.3.17 und dessen exportierter null-Normalizer, gefolgt von derselben Prüfung.

Die SDK-Varianten bewerten diese konkreten Transformationspfade, nicht vollständige Agent-Frameworks. Die dokumentierte Untersuchung berücksichtigte Korrekturen aus dem Jahr 2026; historische Fehler ersetzten keine Tests der installierten Implementierungen. Beide Frameworks können manuelle Wrapper oder nicht strikte Tools einbinden. Genauer Umfang der Vergleiche.

Verwendet wurde der feste Snapshot gpt-5.4-mini-2026-03-17 über die Responses API: Reasoning-Aufwand none, Temperatur 0, maximal 512 Ausgabetokens, keine parallelen Tool-Aufrufe, store: false und Standard-Service-Tier. Drei Wiederholungen wurden in deterministisch randomisierter Reihenfolge verschachtelt. Temperatur 0 war eine Einstellung, keine Zusicherung identischer Antworten.

Sechs Varianten × 56 Szenarien × drei Wiederholungen ergäben 1.008 Intent-Tests. Der Agents-Konverter lehnte den Dictionary-Workflow lokal ab; dadurch entfielen 48 Tests: 960 tatsächlich ausgeführte Intent-Anfragen plus 35 Probes ergeben 995. Die nicht unterstützten Fälle bleiben in der Bewertung der Abdeckung sichtbar.

Es gab keine API-Fehler und keine automatischen Wiederholungsversuche. Kein echter Anwendungshandler wurde aufgerufen; Zustandsänderungen wurden lokal simuliert. Das eingefrorene Protokoll beschreibt Freigabe, Budgetreservierungen, Request-Hashes und den Umgang mit unklaren Kosten.

Die Struktur war in dieser Stichprobe immer gültig. Die Absicht nicht.

Alle 35 Probes wurden akzeptiert: 31 strikte und vier nicht strikte Anfragen. Alle 960 Intent-Antworten enthielten einen Tool-Aufruf, waren als JSON lesbar und bestanden den vorgesehenen lokalen Validierungspfad. Auch die nicht strikten Ausgaben waren in dieser Stichprobe gültig. Eine Garantie für Schema-Konformität bietet der nicht strikte Modus damit nicht.

Exakte Korrektheit erforderte die vorgesehene Aktion und den exakten Patch, einschließlich der Anwesenheit von Feldern. Rückfragen und Ablehnungen wurden anhand der Aktion und einer nicht leeren Begründung bewertet, nicht anhand der Qualität dieser Begründung. Eine zusätzliche Zustandsmetrik unterschied falsche Patches von falschen Endzuständen.

Die Ergebnisse einschließlich der Kosten je exakt korrekt umgesetzter Absicht:

• Originalschema ohne Strict-Modus + Validierung: 162/168, 96,4 %, 0,00049550 US-Dollar je korrekter Absicht.
• Faktorisiertes ArgBridge: 155/168, 92,3 %, 0,00068952 US-Dollar.
• ArgBridge: 153/168, 91,1 %, 0,00072384 US-Dollar.
• Handgeschriebener strikter Wrapper: 138/168, 82,1 %, 0,00065954 US-Dollar, mit dem unten beschriebenen Zuordnungsfehler.
• Mastra-Konvertierung: 93/168, 55,4 %, 0,00088372 US-Dollar für den getesteten Transformationspfad.
• Agents-Konvertierung: 39/120 beobachtete Tests, 32,5 %, 0,00157413 US-Dollar. Unter Einbeziehung der 48 nicht unterstützten Tests beträgt die Korrektheit über die vollständige Abdeckung 39/168 beziehungsweise 23,2 %. Das ist eine Abdeckungsanpassung, kein weiterer gemessener Lauf.

Der Kostennenner umfasst korrekte Updates, Rückfragen und Ablehnungen. Der Zähler enthält alle ausgeführten Intent-Anfragen der jeweiligen Variante, auch solche mit falscher Absicht, aber keine separaten Schema-Probes. Auf Basis der ungerundeten Kosten lag ArgBridge je korrekter Absicht 46,1 % über der nicht strikten Kontrolle. Die aus der Nutzung berechneten Gesamtkosten aller 995 Anfragen betrugen 0,54992475 US-Dollar. Grundlage waren die vom Provider gemeldeten Tokens und die dokumentierten Preise, keine unabhängige Rechnungsabstimmung.

In den 168 paarweise vergleichbaren Tests verlor das ursprüngliche ArgBridge neun Fälle, die die nicht strikte Kontrolle richtig löste, und gewann keinen. Drei Wiederholungen teilen sich jeweils ein Szenario; die Zahlen begründen daher weder statistische Unabhängigkeit noch eine allgemeine Aussage über Produktionseinsatz. Vollständige Live-Ergebnisse und Rohdaten.

Drei Fehler, die ein Schema nicht wegvalidieren kann

Ein gewünschter Löschvorgang wurde zum Weglassen. In null-04 lautete die englische Anweisung „Clear the saved timezone so that the field is absent.“ Nach den eingefrorenen API-Regeln erfordert das Löschen eines gespeicherten Felds den Patch {"settings":{"timezone":null}}. ArgBridge dekodierte stattdessen {"settings":{}} und behielt die Zeitzone bei. Beide ArgBridge-Varianten scheiterten in allen drei Wiederholungen; die nicht strikte Kontrolle bestand alle drei. Der Codec erhielt die falsche Entscheidung über die Feldanwesenheit korrekt.

Der Endzustand war richtig, der Patch falsch. In nested-08 sollte das dunkle Theme ausdrücklich beibehalten und nur die Zeitzone auf UTC geändert werden. Beide ArgBridge-Varianten schrieben trotzdem in jeder Wiederholung zusätzlich das bereits aktuelle Theme. Der Endzustand war damit korrekt, der exakte Patch verletzte aber die Soll-Vorgabe. In einer realen Integration könnten redundante Schreibvorgänge für Audit-Ereignisse oder nebenläufige Änderungen relevant sein; solche Folgewirkungen wurden hier nicht gemessen.

Fehlender Kontext wurde durch eine Vermutung ersetzt. Bei „Increase the ticket priority“ in ambiguous-06 verlangten die Regeln eine Rückfrage. Das ursprüngliche ArgBridge leitete in einer Wiederholung stattdessen ein Ticket und eine Zielpriorität ab. Ein Typvalidator kann den fehlenden fachlichen Kontext nicht rekonstruieren, sobald das Modell eine plausible, formal passende Antwort geliefert hat.

Auch die nicht strikte Kontrolle war nicht fehlerfrei. Bei „Set the quota to nothing“ löschte sie ebenfalls das Quota-Feld, obwohl die Soll-Vorgabe eine Rückfrage verlangte. ArgBridge lieferte zehn falsche, nicht leere Patches: sieben erzeugten einen falschen simulierten Endzustand, drei schrieben das Theme redundant. Die nicht strikte Kontrolle lieferte drei falsche, nicht leere Patches. Da kein echter Handler ausgeführt wurde, belegt das Experiment keinen real entstandenen Schaden.

Auch die manuelle Vergleichsvariante musste kritisiert werden

Der manuelle strikte Wrapper war als starke Vergleichsvariante vorgesehen. Nach dem Lauf zeigte sich jedoch eine unzureichend dokumentierte Zuordnung: Er verwendete Blattnamen wie timezone, ohne sie ausdrücklich settings.timezone zuzuordnen. Tatsächliche Modellantworten nannten diesen Widerspruch bei Rückfragen. Im verschachtelten Workflow erzielte er 29/48 korrekte Ergebnisse, ArgBridge 42/48 und die nicht strikte Variante 48/48.

Dieser Fehler verhindert eine Aussage über die Überlegenheit gegenüber einem vollständig spezifizierten manuellen Wrapper. Er wurde dokumentiert und nicht stillschweigend im eingefrorenen Benchmark repariert.

Das Release ergänzt einen separaten Vergleich mit expliziten Pfaden. Dieser und ArgBridge stellten in deterministischen Tests jeweils 41 erwartete Update-Patches wieder her. Die vier Schemadarstellungen des manuellen Wrappers benötigten 817 Inhaltstokens, ArgBridge 1.281; auch die Referenzargumente waren kleiner. Das sind Offline-Kodierungen, keine Modellergebnisse. Für den überarbeiteten Wrapper gibt es keine gemessene Live-Akzeptanz oder Intent-Genauigkeit. Überarbeiteter Vergleich und Abwägungen.

Reversibilität hat einen Preis

Im ursprünglichen Korpus aus zwölf Schemas belegten die Quellschemas 1.611 Bytes, die generierten Wire-Schemas 8.305 Bytes: eine Expansion um Faktor 5,16. Die Faktorisierung reduzierte das auf 7.527 Bytes beziehungsweise Faktor 4,67, bei unveränderten Wire-Werten und unverändertem Decoder.

Bytes sind keine abgerechneten Tokens. Für dieselben kanonischen Schemadarstellungen betrugen die Tokenzahlen 415 im Original, 1.874 bei ArgBridge und 1.750 bei der faktorisierten Variante. Die separate Live-Evaluation mit vier Workflows erfasste die Provider-Nutzung und tokenisierte die tatsächlich erzeugten Argumentstrings.

In diesem Lauf benötigte das ursprüngliche ArgBridge durchschnittlich 34,7 Argumenttokens, die nicht strikte Variante 14,9. Die mediane Provider-Latenz lag bei 1,030 gegenüber 0,850 Sekunden. Das sind Beobachtungen eines sequenziellen Laufs in seiner Netzwerkumgebung, keine isolierten Kausalschätzungen oder Produktionsgarantien. Die Faktorisierung senkte die Kosten der Intent-Anfragen gegenüber dem ursprünglichen ArgBridge um 3,5 %, beseitigte aber weder die semantischen Fehler noch den Mehraufwand.

Technisches Urteil nach einem negativen Ergebnis

Die eng begrenzte Fähigkeit bleibt untersuchenswert: automatisch reversibler Transport, wenn strikte geschlossene Schemas eine Integrationsanforderung sind und der ursprüngliche Vertrag Feldanwesenheit oder typisierte Maps benötigt. Das Experiment hat nicht gezeigt, dass diese Vereinfachung Entwicklungszeit spart, Modellgenauigkeit verbessert oder Kundennachfrage erzeugt.

Für wenige stabile Tools kann ein fachlich zugeschnittener Operations-Wrapper verständlicher und kleiner sein. Wenn nicht strikte Tools mit lokaler Validierung die Integrationsanforderungen erfüllen, sind sie eine ernst zu nehmende Kontrollvariante. Passt die native Semantik eines Frameworks bereits zur API, kann eine zusätzliche Kodierung Komplexität ohne Nutzen erzeugen.

Auf Grundlage der berichteten Ergebnisse entschied ich mich gegen weiteren Produktausbau und für ein experimentelles Open-Source-Release. Weitergeführt wurden Paketierung, Dokumentation und die Behebung nachweisbarer Fehler. Weitere Produktfunktionen hätten weder die offene Frage der Modellzuverlässigkeit beantwortet noch fehlende Belege für Kundennachfrage geliefert.

Für ein Team, das KI-Systeme entwickelt, ergeben sich konkrete Lehren:

1. Erfolg an der Operationsgrenze definieren. Beabsichtigte Aktion, exakten Patch und Endzustand getrennt messen. Gültiges JSON ist ein Zwischensignal.
2. Den ursprünglichen Vertrag abschließend validieren. Eine verlustbehaftete Schema-Transformation erhält seine Bedeutung nicht automatisch. Berechtigungen und Ausführungsregeln bleiben von der Validierung getrennt.
3. Die einfachste geeignete Alternative mitmessen. Ein generiertes Protokoll muss seinen zusätzlichen Schema-, Argument- und Interpretationsaufwand gegenüber einem sauber spezifizierten manuellen Wrapper und dem Originalvertrag rechtfertigen.
4. Abdeckung und Kostennenner offenlegen. Zurückgewiesene Schemas, akzeptierte falsche Patches und mehrdeutige Anweisungen gehören in die Ergebnisse. Kosten pro Anfrage allein können billige Fehler belohnen.
5. Widerlegte Hypothesen erhalten. Eingaben einfrieren, tatsächliche Ausgaben aufbewahren und spätere Korrekturen getrennt kennzeichnen. Eine bessere Vergleichsvariante begründet ein neues Experiment; sie schreibt das alte nicht um.

Das veröffentlichte Paket bietet aussagekräftige technische Nachweise: begrenztes Parsing, deterministische Tests und Property-Tests, explizite Ablehnungen, reproduzierbare Artefakte und CI. Diese Nachweise belegen weder Product-Market-Fit noch produktionssichere Tool-Ausführung.

KI-Unterstützung und Grenzen der Studie

KI-Unterstützung: Codex übernahm große Teile der Recherche, Implementierung, Testentwicklung, Analyse und Release-Vorbereitung sowie der Arbeit an den Evaluationswerkzeugen. Auch dieser Artikel wurde mit KI-Unterstützung erstellt.

Implementierung, synthetischer Korpus und Bewertungslogik stammen aus demselben Entwicklungsprozess. Eine getrennte Datei mit Soll-Ergebnissen ist kein unabhängiger Reviewer. Dass 960 Bewertungen und 995 Kostenberechnungen ohne Abweichungen neu berechnet wurden, bestätigt die Konsistenz mit den gespeicherten Antworten und derselben Bewertungslogik. Es validiert die Soll-Vorgaben nicht unabhängig. Eine externe Sicherheitsprüfung, Kundenadoption oder kommerzielle Validierung wird nicht behauptet.

Die Studie umfasst einen Modell-Snapshot, vier kleine Workflows, 56 englische Anweisungen und korrelierte Wiederholungen. Diese deutsche Übersetzung ist keine zusätzliche deutschsprachige Modellevaluation. Es gibt keinen verblindeten Holdout, keinen Vergleich mehrerer Modelle, keinen Lasttest und keine echte nachgelagerte Ausführung. Das neue Release-Beispiel wurde offline mit simuliertem SDK-Transport getestet. Die historische Provider-Akzeptanz darf nicht als neuer Live-Test dieses Beispiels dargestellt werden.

Der Compiler lehnt viele JSON-Schema-Konstrukte bewusst ab. Dezimales multipleOf übernimmt das Verhalten von Python/jsonschema, einschließlich des dokumentierten Grenzfalls 0,3/0,1. macOS, alternative Interpreter und jede erlaubte Abhängigkeitskombination sind nicht verifiziert. Bessere Evidenz würde aus unabhängig bereitgestellten Workflows und einem neuen Vergleich auf zurückgehaltenen Szenarien gegen den überarbeiteten manuellen Wrapper entstehen.

Weitere Funktionsentwicklung würde eine konkrete Integration voraussetzen, die strikte Generierung benötigt, sowie eine neue Evaluation auf zurückgehaltenen Szenarien gegen den überarbeiteten manuellen Wrapper. Diese müsste einen praktischen Vorteil zeigen. Die bisherigen Ergebnisse rechtfertigen einen solchen Ausbau nicht.

Release prüfen und Evidenz reproduzieren

• Experimentelles GitHub-Prerelease ArgBridge v0.1.0a1: Wheel, Source-Distribution, Quellcode-ZIP des exakten Commits und SHA-256-Manifest. Es gibt keine PyPI-Veröffentlichung.
• Release-Quellcode bei 10556c99833149059ea9b86621a6b41acd7c0684: Architektur, CLI, Tests und Beispiele.
• Vollständige Evaluation der 995 Anfragen, gespeicherte Antworten, Analyse und Audit.
• Anleitung zur Offline-Reproduktion: Der historische Commit a9cd459c8cd58624af8102e1dc714c81678a79f9 und seine festgelegten Abhängigkeiten reproduzieren den damaligen Plan und ermöglichen die Neuberechnung der publizierten Analyse. Release-Code darf das eingefrorene Experiment nicht stillschweigend ersetzen. Ein neuer Live-Lauf benötigt eigene Zugangsdaten und kostenpflichtige Inferenz.
• CI des finalen Release-Commits: Alle 13 Jobs bestanden, einschließlich Windows/Ubuntu mit Python 3.11–3.15, Mindestversionen der Abhängigkeiten, Offline-Evaluation und Packaging. Die 113 unterschiedlichen Tests sind keine 113 unabhängigen Modellexperimente.