Strukturierte KI-Ausgaben: JSON-Verträge definieren, validieren und bereitstellen

Eine strukturierte Ausgabe ist ein Vertrag, keine Wahrheitsgarantie

Eine strukturierte Ausgabe ist die Antwort eines KI-Systems in einer vereinbarten Datenform, zum Beispiel als JSON-Objekt mit festgelegten Feldern, Typen und zulässigen Werten. In einer Anwendung ermöglicht dieser Vertrag, das Ergebnis zu parsen und an nachgelagerten Code weiterzugeben, ohne Daten erst aus einem frei formulierten Textabsatz herauslösen zu müssen. Für sich genommen macht er den Inhalt jedoch weder wahr noch vollständig oder für die Ausführung einer Aktion geeignet.

Diese Unterscheidung ist wichtig. Die Aussage „Der Antrag gilt für Dienstag“ lässt sich zwar in eine Zeichenfolge mit einem Datum umwandeln. Die Anwendung muss aber weiterhin wissen, welcher Dienstag gemeint ist, ob die Person dieses Datum tatsächlich genannt hat und ob das Ergebnis mit dem übrigen Antrag übereinstimmt. Die Struktur legt fest, wie eine Antwort dargestellt wird. Ob die Daten korrekt sind, hängt zusätzlich von der Eingabe, der Aufgabe und den Geschäftsregeln ab.

Deshalb solltest du drei Prüfungen getrennt betrachten: Lässt sich die Antwort als JSON lesen? Entspricht sie dem vereinbarten Schema? Sind ihre Werte sinnvoll und durch die verfügbaren Informationen gedeckt? Eine Antwort kann die erste Prüfung bestehen und bei den beiden anderen durchfallen. Sie kann auch einem Schema entsprechen und trotzdem eine falsche Extraktion enthalten.

Dieser Leitfaden veranschaulicht den Entwurf anhand einer fiktiven Extraktion von Urlaubsanträgen. Das Beispiel ist ein Vorschlag für die lokale Implementierung und keine Aussage über ein vorgeschriebenes Format einer bestimmten API. Die konkreten Fähigkeiten eines Anbieters, Parameternamen, unterstützten Modelle und Fehlerzustände musst du in der aktuellen Dokumentation des gewählten Dienstes prüfen.

Entscheiden, ob du eine strukturierte Ausgabe brauchst

Verlange eine strukturierte Ausgabe, wenn das Ergebnis eine Benutzeroberfläche, eine Suche, eine Arbeitswarteschlange, eine automatisierte Regel oder eine Datenbank speisen soll und sich die erwarteten Felder stabil beschreiben lassen. Eine Antragsverwaltung könnte beispielsweise einen Status, eine Antragsart und einheitlich bezeichnete Datumsangaben benötigen. In diesem Fall verursacht eine freie Textantwort mit anschließender Extraktion eine zusätzliche Interpretationsstufe und weitere Fehlerquellen.

Eine Struktur ist nicht immer nötig. Wenn eine Person lediglich eine Erklärung wünscht, ist eine dialogorientierte Antwort womöglich verständlicher als ein Datenobjekt. Reicht eine deterministische Umwandlung aus – etwa das Bereinigen von Leerzeichen oder die Konvertierung eines bereits eindeutig formatierten Datums –, kann eine herkömmliche Funktion einfacher und reproduzierbarer sein, als das Modell damit zu beauftragen. Und wenn die Aufgabe noch keine klar definierten Felder hat, kann ein zu früh festgelegtes Schema verschleiern, dass die Aufgabe selbst noch nicht ausreichend beschrieben ist.

Bei der Entscheidung solltest du auch die Folgen eines Fehlers berücksichtigen. Wenn eine Antwort Zahlungen auslöst, Berechtigungen ändert, Informationen löscht oder eine sensible Entscheidung beeinflusst, ist das Schema nur eine Schutzmaßnahme unter mehreren. Die Anwendung benötigt möglicherweise eine menschliche Bestätigung, zusätzliche Berechtigungen oder eine Regel, die die Aktion so lange verhindert, bis eine Mehrdeutigkeit geklärt ist. Verlass dich nicht darauf, dass das Ausgabeformat solche Entscheidungen zuverlässig absichert.

Bevor du den Vertrag entwirfst, halte fest, wer jedes Feld verwendet und wofür. Wird ein Feld von keiner Komponente genutzt, gehört es möglicherweise nicht in die Ausgabe. Benötigt eine Komponente eine Genauigkeit, die durch die Eingabe nicht gewährleistet ist, solltest du einen Unsicherheitsstatus oder eine Rückfrage vorsehen, statt das Modell zur Erfindung eines Werts zu zwingen.

Einen Vertrag definieren, der die Aufgabe abbildet

Ein sinnvoller Vertrag beschreibt die Form und die Verwendungsbedingungen jedes Felds. Beginne mit den benötigten Mindestfeldern, weise ihnen Typen zu und entscheide, welche verpflichtend sind. Lege anschließend zulässige Werte, die Darstellung fehlender Daten und Beziehungen zwischen Feldern fest. Trenne diese Regeln schließlich von den Anweisungen an das Modell: Die Anwendung sollte eine überprüfbare Definition behalten, die sich testen lässt, ohne davon abhängig zu sein, was das Modell offenbar verstanden hat.

Bei der Extraktion eines Urlaubsantrags könnte ein zu einfaches Schema für jeden Fall ein Start- und ein Enddatum verlangen. Eine Bitte wie „Ich würde gern nächsten Monat ein paar Tage frei nehmen“ reicht jedoch nicht aus, um genaue Daten zu bestimmen. Erzwingst du trotzdem ausgefüllte Datumsfelder, verleitet das das System zu einer Vermutung. Eine Alternative besteht darin, die Aufgabenstatus ausdrücklich festzulegen: Antrag vollständig, Rückfrage erforderlich oder kein Antrag. Unbekannte Datumswerte können leer bleiben, und eine Frage kann erklären, welche Information noch fehlt.

Das folgende Schema veranschaulicht eine mögliche Entscheidung. Die Bedingung, dass das Enddatum nicht vor dem Startdatum liegen darf, sowie die Beziehung zwischen dem Status und optionalen Feldern müssen zusätzlich in der Anwendung geprüft werden. Setze nicht voraus, dass ein Generierungsmodus oder ein Validator alle hier verwendeten Schlüsselwörter unterstützt. Das lokale Schema und das von einer API akzeptierte Format müssen nicht austauschbar sein. Wenn die entfernte Schnittstelle nur eine Teilmenge unterstützt, passe die entfernte Darstellung an und behalte die vollständigen Prüfungen in deinem Code bei.

Die Konvention für fehlende Werte muss eindeutig sein. In diesem Beispiel wird ein unbekanntes Datum durch null dargestellt, nicht durch eine leere Zeichenfolge, „unbekannt“ oder ein erfundenes Datum. Ein einheitlicher Wert erleichtert die Validierung und verhindert, dass verschiedene Verbraucher denselben Fall unterschiedlich interpretieren. Die Anwendung muss außerdem entscheiden, ob sie zusätzliche Felder akzeptiert oder ablehnt. Werden sie ungeprüft zugelassen, können Versionsfehler oder unerwartete Ausgaben unbemerkt bleiben.

{
  "type": "object",
  "additionalProperties": false,
  "required": ["status", "start_date", "end_date", "clarification_question"],
  "properties": {
    "status": {
      "type": "string",
      "enum": ["complete", "needs_clarification", "not_a_request"]
    },
    "start_date": {
      "type": ["string", "null"],
      "description": "Datum im ISO-Format YYYY-MM-DD, nur wenn der Antrag es stützt"
    },
    "end_date": {
      "type": ["string", "null"],
      "description": "Datum im ISO-Format YYYY-MM-DD, nur wenn der Antrag es stützt"
    },
    "clarification_question": {
      "type": ["string", "null"]
    }
  }
}

Format, Schema und Bedeutung getrennt prüfen

Bei der ersten Validierung wird geprüft, ob sich die empfangenen Bytes als JSON interpretieren lassen. Enthält die Antwort ein abschließendes Komma, zusätzlichen Text außerhalb des Objekts oder ein nicht geschlossenes Anführungszeichen, kann das Parsen fehlschlagen. Bei der zweiten Prüfung geht es darum, ob der geparste Wert die erlaubte Form hat: ein Objekt, die erwarteten Schlüssel und Werte mit passenden Typen. Die dritte Prüfung fragt, ob die Informationen den Antrag korrekt abbilden und den Regeln der Anwendung entsprechen.

Das folgende Objekt kann gültiges JSON sein und die grundlegenden Typanforderungen des Vertrags erfüllen: Der Status besagt, dass der Antrag vollständig ist, beide Datumsangaben sind Zeichenfolgen und es gibt keine Rückfrage. Wenn die Person jedoch Urlaub „vom 12. bis zum 10.“ beantragt hat, ist die Antwort widersprüchlich. Ebenso kann ein intern stimmiger Zeitraum im Text nicht belegt sein. Eine Typprüfung ersetzt keine Überprüfung, ob die Ausgabe zur Eingabe passt.

Semantische Regeln solltest du als explizite Bedingungen formulieren und, wenn möglich, durch reproduzierbare Tests abdecken. Für dieses Beispiel gilt: Ist status gleich complete, müssen beide Datumsangaben vorhanden und gültige Kalenderdaten sein; das Enddatum darf nicht vor dem Startdatum liegen. Bei needs_clarification muss erklärt werden, welche Information fehlt. Bei not_a_request darf kein Urlaubsantragsprozess gestartet werden. Die konkrete Richtlinie kann sich unterscheiden, sollte aber nicht der stillschweigenden Interpretation des Verbrauchers überlassen bleiben.

Unterscheide auch zwischen einer ungültigen Antwort und einer gültigen Antwort, die besagt, dass die Aufgabe nicht abgeschlossen werden kann. needs_clarification kann eine vertragsgemäße Antwort und kein technischer Fehler sein. Wenn die API eine Ablehnung, einen Generierungsfehler oder einen Abbruch in einem eigenen Format meldet, muss die Anwendung diesen Status gemäß der Dokumentation des Anbieters behandeln. Fasse solche Fälle nicht zu einem scheinbar normalen Objekt zusammen, ohne zu wissen, was passiert ist.

Einen Generierungsmodus wählen, ohne Kompatibilität vorauszusetzen

Einige APIs bieten spezielle Optionen, um strukturierte Ausgaben anzufordern. Bezeichnungen, Voraussetzungen und Grenzen sind jedoch produktspezifisch und können sich ändern. Die offizielle Dokumentation zu Amazon Nova behandelt Anforderungen an strukturierte Ausgaben und Formate wie JSON. Die Dokumentation von Anthropic beschreibt strukturierte Ausgaben mit einem JSON-Schema und dem Parameter output_config. Google dokumentiert strukturierte Ergebnisse für die Gemini API und verweist auf JSON-Schemas. OpenAI stellt die Funktion für strukturierte Ausgaben in der API vor. Diese Quellen beziehen sich auf konkrete Produkte und belegen nicht, dass sie denselben Vertrag, denselben Grad an Einschränkung oder dieselbe Fehlerbehandlung verwenden.

Microsoft Learn enthält ebenfalls eine Seite über strukturierte Ausgaben für Chatmodelle in der Dokumentation zu Foundry Classic. Diese Abgrenzung ist wichtig: Ein Dokumentationspfad, der einem bestimmten Produkt oder Modus zugeordnet ist, darf nicht als universelle Spezifikation für alle Microsoft-Dienste behandelt werden. Ebenso gehören Dokumentationen zu Claude Code und Claude Platform zu unterschiedlichen Produkten. Eine Option aus dem einen Produkt sollte nicht automatisch auf das andere übertragen werden.

Prüfe vor der Auswahl in der aktuellen Primärdokumentation, welcher Modus angeboten wird, welche Modelle oder Versionen abgedeckt sind, welche Teile des Schemas akzeptiert werden, wie optionale Felder und Aufzählungen behandelt werden, wie Ablehnungen oder unvollständige Generierungen gemeldet werden und welche Antwortstruktur die Anwendung erhält. Halte fest, wann und welche Dokumentationsversion du konsultiert hast. Ist eine Anforderung deines Vertrags nicht spezifiziert, behandle sie als Unsicherheit und überprüfe sie mit Tests in der vorgesehenen Umgebung – nicht als garantierte Fähigkeit.

Verwechsle eine JSON-Anforderung nicht mit der erzwungenen Einhaltung eines Schemas. Ein Modus, der eine syntaktisch gültige JSON-Antwort erzeugt, kann den Parseraufwand verringern. Die Anwendung muss trotzdem Schlüssel, Typen und Aufgabenregeln prüfen. Selbst wenn die Dokumentation eines Modus Schemaeinschränkungen beschreibt, solltest du die lokale Validierung beibehalten: Der Vertrag, der das Verbrauchersystem schützt, muss an der Vertrauensgrenze der Anwendung geprüft werden.

Die Validierung in der Anwendung implementieren

Die Anwendung sollte die Antwort an einer kontrollierten Stelle parsen und validieren, bevor sie sie an die nächste Komponente übergibt. Eine praktische Reihenfolge lautet: API-Ergebnis empfangen; zuerst die dokumentierten Transport- und Generierungsstatus prüfen; den relevanten Inhalt extrahieren; JSON parsen; prüfen, ob die oberste Ebene ein Objekt mit zulässigen Schlüsseln ist; Typen und Werte validieren; und zuletzt die Geschäftsregeln anwenden. Scheitert ein Schritt, muss der Ablauf genügend Informationen zur Diagnose bewahren, ohne so zu handeln, als wäre das Ergebnis korrekt.

Das folgende Beispiel ist mit der Python-Standardbibliothek ausführbarer Code. Es erwartet eine JSON-Zeichenfolge, lässt genau vier Schlüssel zu, prüft Typen, interpretiert Datumsangaben im ISO-Format und wendet Bedingungen zwischen Status, Datumsangaben und Rückfrage an. Es prüft nicht, ob ein Datum tatsächlich im Eingabetext vorkam. Dafür musst du den Text aufbewahren, eine Methode zur Überprüfung von Belegen festlegen und diese separat testen. Auch die Fehlerbehandlung für die API ist damit nicht abgedeckt; sie muss an den verwendeten Dienst angepasst werden.

Das Beispiel weist zusätzliche Felder bewusst zurück. Diese Richtlinie verhindert, dass eine unerwartete Änderung unbemerkt bleibt, auch wenn ein System mit kontrollierter Weiterentwicklung eine andere Regel wählen kann. Entscheidend ist, dass du die Entscheidung ausdrücklich triffst und den Vertrag versionierst. Wenn du in der Produktion eine externe Validierungsbibliothek verwendest, lege eine kompatible Version fest, teste ihre Regeln und behandle die Validatorfehler als Teil deiner internen Schnittstelle – nicht als Grund, die Prüfung zu überspringen.

Wandle Fehler nicht stillschweigend in Standardwerte um. Wenn end_date fehlt, kann das Auffüllen mit start_date die Bedeutung des Antrags verändern. Ist ein Datum ungültig, kann die Umwandlung in null ein wichtiges Fehlersignal auslöschen. Gib stattdessen lieber ein typisiertes Validierungsergebnis zurück – gültig, Rückfrage erforderlich oder ungültig – und entscheide transparent, ob ein erneuter Versuch, eine Rückfrage an die Person oder eine Überprüfung nötig ist.

import json
from datetime import date

REQUIRED = {
    "status",
    "start_date",
    "end_date",
    "clarification_question",
}
STATUSES = {"complete", "needs_clarification", "not_a_request"}


def validate(raw):
    try:
        data = json.loads(raw)
    except json.JSONDecodeError as exc:
        raise ValueError("Ungültiges JSON") from exc

    if not isinstance(data, dict) or set(data) != REQUIRED:
        raise ValueError("Objekt mit fehlenden oder unerwarteten Schlüsseln")
    if data["status"] not in STATUSES:
        raise ValueError("Nicht zulässiger Status")

    for key in ("start_date", "end_date", "clarification_question"):
        value = data[key]
        if value is not None and not isinstance(value, str):
            raise ValueError(f"Falscher Typ: {key}")

    dates = []
    for key in ("start_date", "end_date"):
        value = data[key]
        if value is None:
            dates.append(None)
            continue
        parsed = date.fromisoformat(value)
        if parsed.isoformat() != value:
            raise ValueError(f"Falsches Datumsformat: {key}")
        dates.append(parsed)

    start, end = dates
    if data["status"] == "complete":
        if start is None or end is None or end < start:
            raise ValueError("Vollständiger Zeitraum fehlt oder ist widersprüchlich")
        if data["clarification_question"] is not None:
            raise ValueError("Ein vollständiger Antrag sollte keine Rückfrage enthalten")
    elif data["status"] == "needs_clarification":
        if not data["clarification_question"]:
            raise ValueError("Gib an, welche Information geklärt werden muss")
    elif data["status"] == "not_a_request":
        if start is not None or end is not None:
            raise ValueError("Ein Text, der kein Antrag ist, sollte keine Daten enthalten")

    return data


if __name__ == "__main__":
    sample = '{"status":"complete","start_date":"2027-06-12","end_date":"2027-06-14","clarification_question":null}'
    print(validate(sample))

Für jeden Fehlerfall eine Reaktion festlegen

Eine sinnvolle Fehlerpolitik unterscheidet mindestens vier Situationen. Erstens: Transport- oder Dienstfehler – es wurde keine verwendbare Antwort erhalten. Zweitens: Generierungsfehler oder Ablehnung – die API kann melden, dass sie das angeforderte Ergebnis nicht erzeugt hat. Drittens: Format- oder Schemafehler – der Inhalt lässt sich nicht parsen oder entspricht dem Vertrag nicht. Viertens: semantische Fehler – die Form besteht die Prüfungen, aber der Inhalt ist unvollständig, widersprüchlich oder nicht belegt.

Für jede Kategorie sollte es ein ausdrücklich festgelegtes Ergebnis geben. Ein dokumentierter vorübergehender Fehler kann einen begrenzten erneuten Versuch rechtfertigen. Eine mehrdeutige Anfrage wiederholt zu senden, schafft jedoch keine Informationen, die in der Eingabe fehlten. Ein Schemafehler kann einen erneuten Versuch mit klareren Anweisungen rechtfertigen, sofern die Zahl der Versuche begrenzt und die Ausgabe erneut validiert wird. Ein semantisch widersprüchlicher Wert kann eine Rückfrage an die Person oder eine menschliche Überprüfung erfordern. Eine Ablehnung sollte entsprechend der Produktrichtlinie und den vom Anbieter dokumentierten Einzelheiten angezeigt oder behandelt werden.

Setze Grenzen, damit keine endlosen Wiederholungen entstehen, und korrigiere Werte nicht automatisch, wenn sich dadurch die Bedeutung ändern kann. Erzeugt ein erneuter Versuch eine andere Ausgabe, wähle nicht stillschweigend die vermeintlich passendere aus. Bewahre den Validierungsstatus, die Vertragsversion und eine kategorisierte Fehlerursache auf. Bei folgenreichen Vorgängen solltest du vor der tatsächlichen Ausführung eine Bestätigungsstufe erwägen.

Technische Protokolle sollten eine Diagnose mit möglichst geringer Datenoffenlegung ermöglichen. Speichere Korrelationskennungen, die Vertragsversion, die Fehlerkategorie und erforderliche Messwerte. Prüfe, ob der Eingabetext oder die vollständige Ausgabe wirklich aufbewahrt werden müssen; wenn nicht, protokolliere sie nicht standardmäßig. Werden sie gespeichert, lege geeignete Zugriffsrechte, Aufbewahrungsfristen und Schutzmaßnahmen entsprechend der Sensibilität der Daten fest.

Reale Eingaben und Grenzfälle testen

Tests sollten das Verhalten überprüfen und nicht nur zeigen, dass sich ein Beispiel parsen lässt. Erstelle einen kleinen, wartbaren Satz repräsentativer Eingaben, erwarteter Ergebnisse und einzuhaltender Regeln. Berücksichtige gewöhnliche, mehrdeutige, unvollständige, widersprüchliche und themenfremde Fälle. Für jeden Fall sollte feststehen, welche Ausgaben akzeptabel sind und welche Entscheidung die Anwendung nach deren Empfang trifft.

Bei einem Urlaubsantrag könnte eine klare Eingabe vollständige Datumsangaben in einem stimmigen Zeitraum enthalten. Ein mehrdeutiger Fall könnte „am Freitag“ nennen, ohne genügend zeitlichen Kontext zu liefern. Ein anderer könnte Daten nennen, aber das Jahr auslassen. Ein unvollständiger Fall könnte kein Enddatum enthalten. Teste auch einen umgekehrten Zeitraum, ein unmögliches Datum, einen falschen Typ, einen zusätzlichen Schlüssel und eine Antwort, die kein JSON ist. Entscheide für jeden Fall, ob die Anwendung ihn akzeptiert, eine Rückfrage stellt oder ihn ablehnt. Lass diese Entscheidung nicht während der Integration einer improvisierten Interpretation überlassen.

Ergänze semantische Tests mit vorbereiteten Ausgaben und beschränke dich nicht auf Tests mit dem Modell. Wenn du ausschließlich echte Generierungen testest, können die Ergebnisse variieren. Dann ist schwer zu erkennen, ob die Generierung, der Vertrag oder der verbrauchende Code versagt hat. Deterministische Tests des Validators ermöglichen die Prüfung konkreter Fälle; Integrationstests zeigen, wie sich der gesamte Ablauf mit der tatsächlich vorgesehenen API und Konfiguration verhält.

Wenn sich das Schema ändert, brauchst du Tests für die Kompatibilität zwischen Versionen. Erwartet ein Verbraucher ein Feld, das nicht mehr vorhanden ist, kann eine scheinbar kleine Änderung die Verarbeitung unterbrechen. Versioniere den Vertrag und lege fest, wie Produzent und Verbraucher ausgerollt werden – etwa durch eine Übergangsphase, in der beide Versionen unterstützt werden, oder durch eine abgestimmte Umstellung. Behandle Änderungen an Feldnamen oder Nullwerten nicht als bloße Kosmetik.

Den Vertrag bereitstellen und pflegen

Für einen produktiv eingesetzten Vertrag brauchst du eine verantwortliche Stelle, eine Version und einen Änderungsprozess. Bewahre die Definition zusammen mit dem Code auf, der sie validiert, und protokolliere, welche Version für jedes verarbeitete Ergebnis verwendet wurde. Bevor du Felder, Typen, Aufzählungen oder Regeln für fehlende Werte änderst, prüfe die betroffenen Verbraucher und ergänze gezielte Regressionstests. Ändern sich Modell, Prompt, Konfiguration oder API, wiederhole die relevanten Tests: Der Vertrag ersetzt nicht die Prüfung des Verhaltens des Gesamtsystems.

Miss getrennt, welcher Anteil der Antworten parsbar ist, dem Schema entspricht, semantische Regeln besteht und eine Rückfrage oder Prüfung erfordert. Eine einzige Erfolgskennzahl verdeckt wichtige Unterschiede. Wenn beispielsweise fast alle Antworten gültiges JSON sind, sagt das noch nicht, ob extrahierte Datumsangaben mit den Anträgen übereinstimmen. Kennzahlen brauchen stabile Definitionen und sollten keine sensiblen Inhalte erfassen, wenn eine aggregierte Kategorie ausreicht.

Beobachte Änderungen in der Dokumentation und bei Anbieterversionen, aber setze nicht voraus, dass ein Update exakt dieselben Fähigkeiten wie die bisherige Konfiguration bietet. Halte fest, welche Kombination getestet wurde, und prüfe die Kompatibilitätsbedingungen, bevor du sie änderst. Die Dokumentationsseite eines Dienstes bezieht sich auf den dort beschriebenen Dienst und Geltungsbereich. Sie bescheinigt kein identisches Verhalten bei einem anderen Produkt, einer anderen Version oder einem anderen Modell.

Wenn das System Entscheidungen mit Folgen trifft, ergänze eine dem Risiko angemessene Schutzmaßnahme. Das kann eine menschliche Überprüfung, eine ausdrückliche Bestätigung oder eine unabhängige Kontrolle sein. Entwirf außerdem einen Wiederherstellungsweg: Was geschieht mit ausstehenden Ergebnissen? Wie wird ein fälschlich validierter Wert korrigiert? Wie verhinderst du, dass eine Aktion nach einem erneuten Versuch doppelt ausgeführt wird? Ein Datenvertrag ist Teil eines betrieblichen Ablaufs und kein Ersatz für dessen Kontrollen.

Praktische Kriterien für den Abschluss des Entwurfs

Bevor du die Arbeit abschließt, prüfe, ob die Struktur einem echten Produktbedarf entspricht und nicht nur dem Wunsch, JSON zu erhalten. Der Vertrag sollte klein genug sein, dass jedes Feld einen klaren Zweck hat, zugleich aber ausreichend ausdrücken können, wenn etwas unsicher oder nicht vorhanden ist oder nicht zur Aufgabe gehört. Gibt es für mehrdeutige Fälle keine sichere Darstellung, ist der Entwurf noch nicht produktionsreif.

Stelle sicher, dass der Verbraucher die empfangene Antwort validiert und nicht nur die gesendeten Anweisungen. Prüfe Format, Schlüssel, Typen und semantische Regeln getrennt. Lege fest, was blockiert, was wiederholt und wonach gefragt wird. Teste diese Entscheidungen mit überprüfbaren Beispielen – darunter eine Eingabe mit unzureichenden Informationen und eine Ausgabe, die gültig aussieht, aber dem Text widerspricht.

Halte zum Schluss externe Unsicherheiten fest: konkrete API-Kompatibilität, Schemaeinschränkungen, Modellabdeckung und Fehlerdarstellung. Kläre sie anhand der offiziellen Produktdokumentation und durch Tests mit der Version, die tatsächlich bereitgestellt werden soll. So kann der lokale Vertrag eine Sicherheits- und Wartungsgrenze bleiben, auch wenn sich der Generierungsmodus ändert.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.