Prüfbare Vorgaben für KI-Agenten

Menschen können bei mehrdeutigen Anforderungen nachfragen und eine Entscheidung dokumentieren. Eine automatisierte Auswertung kann nur die vorgegebenen Regeln, Eingaben und Beobachtungen anwenden. BrainGrid bietet dazu Praxisleitlinien; sie sind weder kontrollierte Studie noch Korrektheitsgarantie. Die Beispiele verdeutlichen das Problem ; die passende Auswertungsmethode bleibt kontextabhängig.

Anweisungen können aufbewahrt werden; Reviews werden aber klarer, wenn der Auswertungsvertrag als eigenes geprüftes Artefakt vorliegt. Ein arXiv-Preprint von 2026 zu Delegation Contracts für Coding-Agenten schlägt vier Fragen zur Nachprüfbarkeit vor: Was war beauftragt, was durfte der Agent, was kam zurück, welche Belege stützen es. Das ist ein vorgeschlagener Rahmen, kein Beweis universeller Vollständigkeit. Eine Vorgabe kann die ersten beiden beantworten und danach den Soll-Ist-Abgleich füttert.

1. Ziel - ein Satz. Was nach dem Run wahr sein muss, das vorher nicht wahr war. Braucht das Ziel drei Sätze, sind es vermutlich zwei Aufgaben.
2. Grenzen - der Berechtigungsrahmen. Welche Dateien sich ändern dürfen, welche nicht, welches Verhalten tabu ist. Grenzen machen aus Scope Creep eine Feststellung statt einer Diskussion.
3. Akzeptanzkriterien - explizite Entscheidungen. Jedes benennt Auswertungsverfahren, Eingabe oder Fixture, erwartete Beobachtung und Entscheidungsregel. Subjektive Ergebnisse benennen die Person, deren Urteil dokumentiert wird.
4. Validierungsplan - welche Checks zählen. Tests, Typen, Lint, Build, Schemas, Invariantenchecks und manuelle Inspektionen werden vorab benannt. Ein Pass gilt nur für diese Checks, ihre Eingaben und die geprüfte Umgebung.

Einen gesprächigen Prompt in diese Form zu kompilieren dauert Minuten. Reality Graph schreibt dieselben vier Bausteine als das Artefakt, gegen das es den Run prüft, damit die Datei die Session überlebt, aus der sie stammt. Von Hand sieht das so aus:

PROMPT (was man natürlich tippen würde)
"Die Rate-Limiting-Antworten verwirren die Clients, kannst du die
429er hilfreicher machen?"

KOMPILIERTE VORGABE (wogegen der Run verifiziert wird)
Ziel:      429-Antworten tragen einen korrekten Retry-After-Header
Grenzen:   nur api/middleware/* · Rate-Limit-Schwellen unverändert
Kriterien: [1] Retry-After bei jeder 429-Antwort vorhanden
           [2] Wert = Rest des Fensters in Sekunden (±1 s)
           [3] leere/fehlerhafte Client-IDs bekommen 429, nicht 500
           [4] 2xx- und übrige 4xx-Pfade byte-identisch zu vorher
Validierung: Unit-Tests (vorab geschrieben) · Typen · Lint · Build
             manuell: Header hinter dem CDN sichtbar (Staging)

• Adjektive in beobachtbare Entscheidungsregeln übersetzen. Ein Grenzwert braucht Einheit, Lastprofil, Umgebung, Messmethode und Toleranz. Sonst kann eine präzise wirkende Zahl genauso mehrdeutig sein wie „schnell“.
• Unglückspfade benennen. Leere Eingaben, Duplikate, fehlende Berechtigungen, Timeouts. Bleiben sie ungenannt, erfindet der Agent seine eigene Policy - und seine selbstgeschriebenen Tests bestätigen genau diese Erfindung.
• Kriterien an Verhalten binden, nicht an Implementierung. „Nutzt einen Token Bucket“ altert schlecht und verbietet bessere Lösungen; „erlaubt 100 Requests pro Minute pro Client“ ist die eigentliche Anforderung.
• Das leichteste Format wählen, das entscheidbar bleibt. Given-When-Then, Schemas, Eigenschaftsprüfungen, Invarianten, Beispiele und dokumentierte manuelle Inspektionen können passen. Das Format macht ein Verfahren explizit; es verleiht keine Korrektheit.

• Kleine Aufgaben überspezifizieren. Die Form kann nach unten skalieren; die nötige Tiefe bestimmt das Risiko. Ein kleiner Diff mit großen Folgen kann umfangreiche Grenzen und Validierung rechtfertigen.
• Spezifizieren ohne Abgleichen. Eine Vorgabe, gegen die niemand prüft, ist Dokumentations-Theater. Der Abgleich danach ist der Grund, sie zu schreiben.
• Vollständigkeit erwarten. Checks decken ab, was Vorgabe und Auswertung ausdrücken. Absicht vollständig zu formalisieren bleibt laut einem arXiv-Preprint von 2026 ein offenes Forschungsproblem. Die Methode dokumentiert erklärte Absicht; sie stellt weder deren Richtigkeit noch Vollständigkeit fest.
• Das Modell seine eigenen Kriterien schreiben lassen - ungelesen. Mit KI entwerfen ist fein; den Entwurf ungeprüft übernehmen stellt genau die Zirkularität wieder her, die die Vorgabe brechen soll.

Reality Graph kann Ziel, Grenzen, Kriterien und Validierungsplan eines Runs festhalten und die konfigurierten Checks im Verifikations-Loop dagegen geprüft, und das Ergebnis landet in einem Prüfbericht. Dieser Bericht ist Evidenz zum protokollierten Scope und den ausgeführten Checks, kein formaler Beweis und keine Garantie für Korrektheit, Vertraulichkeit, Sicherheit oder Compliance.