Ein Vorschlag kann gültig sein und vor seiner Ausführung trotzdem ungültig werden. Deshalb reicht eine Autorisierung zum Zeitpunkt des Vorschlags nicht aus. Zwischen Empfehlung und Konsequenz kann sich der relevante Zustand verändern. Eine Berechtigung kann auslaufen. Ein Schwellenwert kann überschritten werden. Eine notwendige Bedingung kann nicht mehr erfüllt sein. Eine um 14:00 Uhr genehmigte Zahlung kann um 16:00 Uhr bereits nicht mehr zulässig sein. Die architektonische Frage lautet daher nicht, ob die Handlung früher gültig war. Entscheidend ist, ob die für die Konsequenz erforderlichen Bedingungen noch gelten, wenn die Konsequenz tatsächlich eintreten soll. Genau dafür gibt es eine Commit-Grenze. Bevor eine externe Zustandsänderung real wird, muss das System die Bedingungen erfüllen, die für genau diese Handlung im aktuellen Zustand gelten. Eine frühere Genehmigung kann das nicht ersetzen. Ebenso wenig eine frühere Validierung. Wenn sich eine relevante Bedingung geändert hat, muss sich der Pfad zur Ausführung schließen. Die architektonische Unterscheidung lautet: Der Vorschlag beschreibt, was geschehen könnte. Die Commit-Grenze bestimmt, ob es jetzt geschehen darf. Der Commit macht es wirksam. Die eigentliche Frage lautet deshalb nicht: Kann das System unmittelbar vor der Ausführung noch einmal prüfen? Sondern: Kann eine folgenreiche Zustandsänderung stattfinden, ohne die Bedingungen zu durchlaufen, die zum Zeitpunkt des Commit tatsächlich gelten? Wenn ja, ist die Commit-Grenze keine wirkliche Grenze.

Ein Agent kann zu etwas technisch in der Lage sein, ohne dazu berechtigt zu sein. Diese Unterscheidung wird kritisch, sobald Modelle Tools aufrufen, Workflows auslösen oder externe Zustände verändern können. Tool-Zugriff schafft Fähigkeit. Er schafft keine Autorität. Das Gleiche gilt für das Reasoning eines Modells. Ein Modell kann zu dem Ergebnis kommen, dass eine Rückerstattung erfolgen sollte, eine Zahlung freigegeben oder ein Datensatz geändert werden sollte. Das schafft noch keine Berechtigung, dies tatsächlich zu tun. Eine nicht umgehbare Architektur muss diese beiden Pfade getrennt halten. Fähigkeit kann vorhanden sein. Autorität muss für die konkrete Handlung, den konkreten Geltungsbereich und die konkreten Bedingungen unabhängig festgestellt werden. Und das System darf keinen alternativen Weg von Fähigkeit zu Ausführung anbieten, wenn diese Autorität fehlt. Genau hier werden viele agentische Architekturen fragil. Wenn das Modell ein Tool direkt erreichen kann oder wenn Tool-Zugriff selbst als Beweis für Berechtigung behandelt wird, fällt Autorität mit Fähigkeit zusammen. Die architektonische Unterscheidung lautet: Fähigkeit bestimmt, was getan werden kann. Autorität bestimmt, was getan werden darf. Die eigentliche Frage lautet deshalb nicht: Kann das System Autorität prüfen? Sondern: Kann Fähigkeit oder Tool-Zugriff einen ausführbaren Pfad schaffen, obwohl die erforderliche Autorität nicht festgestellt wurde? Wenn ja, ist Autorität keine Grenze. Dann ist sie lediglich eine Konvention.

Ein generiertes Ergebnis ist noch kein operatives Ergebnis. Diese Unterscheidung klingt klein. Architektonisch ist sie fundamental. Das Modell erzeugt einen Kandidaten. Die Freigabe ist ein davon getrenntes Ereignis. Dazwischen liegt die Frage der Zulässigkeit. Ein Kandidat kann sprachlich überzeugend, vollständig und in sich konsistent sein und trotzdem die Bedingungen für eine operative Nutzung nicht erfüllen. Wenn Generierung und Freigabe zu einem einzigen Schritt zusammenfallen, werden diese Bedingungen lediglich zu Empfehlungen. Das System kann sie prüfen. Aber nichts verhindert, dass der erzeugte Output trotzdem weiterverwendet wird. Genau darum geht es beim Umgehungsproblem dieser Serie. Eine echte Freigabegrenze bedeutet: Ein Kandidat darf nicht allein deshalb operativ werden, weil seine Generierung erfolgreich abgeschlossen wurde. Er muss die für die Freigabe definierten Bedingungen erfüllen. Wenn diese Bedingungen scheitern, bleibt der Kandidat nicht freigegeben. Eine neue Generierung kann es erneut versuchen. Aber auch sie muss dieselben anwendbaren Freigabebedingungen erfüllen. Eine erneute Generierung darf keinen alternativen Weg um die Freigabegrenze schaffen. Und kein nachgelagerter Pfad darf einen Kandidaten nur deshalb als freigegeben behandeln, weil er bereits existiert. Die architektonische Unterscheidung lautet: Generierung erzeugt einen Kandidaten. Freigabe macht ihn für einen definierten Zweck zulässig. Die eigentliche Frage lautet deshalb nicht: Kann das System einen Output zurückhalten? Sondern: Gibt es irgendeinen Pfad von der Generierung zur operativen Nutzung, der nicht durch die erforderlichen Freigabebedingungen führt? Wenn ein solcher Pfad existiert, ist Freigabe keine Grenze. Dann ist sie nur eine Präferenz.

Ein Modell kann einen Kandidaten erzeugen. Es sollte aber nicht selbst entscheiden dürfen, ob dieser Kandidat das Recht erworben hat, verwendet zu werden. Das klingt selbstverständlich. In der Praxis verschwimmt diese Grenze jedoch schnell. Ein Modell erzeugt eine Antwort, bewertet anschließend sein eigenes Vertrauen, prüft, ob die Evidenz „ausreichend aussieht“, und kommt zu dem Schluss, dass das Ergebnis akzeptabel sei. Damit wurde nichts Wesentliches getrennt. Noch immer beurteilt derselbe probabilistische Prozess die Zulässigkeit seines eigenen Outputs. Eine echte Validierungsgrenze verlangt etwas anderes. Die Bedingungen für Akzeptanz müssen außerhalb des Kandidaten selbst festgelegt werden. Das Modell darf diese Bedingungen weder selbst definieren noch durch Selbstbestätigung erfüllen oder ein negatives Ergebnis überschreiben können. Ein einfaches Beispiel: Wenn ein Fall eine aktuelle autoritative Quelle verlangt, kann die Aussage des Modells „Die erforderliche Quelle ist vorhanden“ diese Bedingung nicht selbst herstellen. Die maßgebliche Bedingung muss unabhängig von dieser Behauptung existieren. Das bedeutet nicht, dass jede Validierung mathematisch deterministisch sein muss. Es bedeutet, dass der Kandidat nicht die letzte Instanz für seine eigene Zulässigkeit sein darf. Die architektonische Unterscheidung lautet: Generierung erzeugt einen Kandidaten. Validierung entscheidet, ob dieser Kandidat weiterverwendet werden darf. Die eigentliche Frage lautet deshalb nicht: Kann das System den Output validieren? Sondern: Kann das Modell seinen eigenen Kandidaten allein dadurch zulässig machen, dass es behauptet, die maßgeblichen Bedingungen seien erfüllt? Wenn ja, ist die Validierungsgrenze nicht unabhängig.

Eine Regel kann für ein System verfügbar sein, ohne irgendetwas tatsächlich zu steuern. Sie kann in einem Policy-Repository liegen. Sie kann über RAG abgerufen werden. Sie kann sogar im Modellkontext stehen. Das sagt zunächst nur: Die Regel ist vorhanden. Für Governance reicht Anwesenheit nicht aus. Das System muss wissen, welche institutionelle Struktur für den konkreten Fall tatsächlich verbindlich ist. Ein Kundenfall kann beispielsweise unter einen normalen Serviceprozess fallen oder unter ein reguliertes Beschwerdeverfahren. Beide Regelwerke existieren. Das Modell sollte nicht selbst inferieren, welches institutionelle Regime gilt. Das muss feststehen, bevor man sich auf seine Interpretation verlässt. Wenn das Modell entscheiden darf, welches Regelwerk „wohl passen dürfte“, bleibt institutionelle Gültigkeit weiterhin innerhalb der Inferenz. Die architektonische Unterscheidung lautet daher: verfügbar → aktiv → verbindlich Der verbindliche Zustand hat zwei unterschiedliche Aspekte: die institutionelle Struktur, die für den Fall gilt, und das autoritative Wissen, das diese Struktur überhaupt befüllen darf. Das Erste legt fest, was gilt. Das Zweite legt fest, welche Quellen innerhalb dieser Struktur legitim zählen dürfen. Beides ist konzeptionell verschieden, muss aber Teil des Zustands sein, der den jeweiligen Lauf bestimmt. Verfügbar bedeutet: Das System kann darauf zugreifen. Aktiv bedeutet: Es gehört zum institutionellen Zustand, der für den aktuellen Fall relevant ist. Verbindlich bedeutet: Das System kann keine regulierte Freigabe oder keinen Commit erreichen, solange die anwendbare institutionelle Struktur nicht für diesen Lauf verbindlich festgestellt wurde. Gerade dieser letzte Schritt ist entscheidend. Eine verbindliche Regel ist nicht bloß Information, die das Modell berücksichtigen soll. Das System darf ein reguliertes Ergebnis nicht erreichen können, ohne dass diese Regel berücksichtigt wurde. Genau darin liegt der Zweck eines deklarativen Zustands: Institutionelle Entscheidungen, die außerhalb der Inferenz getroffen wurden, werden in Bedingungen übersetzt, die für die aktuelle Ausführung tatsächlich wirksam sind.