ERQYO
Event Rhythm Qualifier · Yoked Operator · Adaptive Decision Runtime
ERQYO ist eine Laufzeitarchitektur für agentische Systeme, die nicht nur entscheiden müssen, was sie tun, sondern auch wann und ob sie es überhaupt dürfen. Im Repository von AnyLAI gibt es dafür eine Referenzimplementierung.
ERQYO
Rhythmus beeinflusst die Qualifizierung. Randbedingungen bestimmen die Ausführung.
Die Forschungsfrage
Agentische Systeme wählen zunehmend selbst ihren Zeitpunkt: jetzt nachfassen oder warten, handeln oder fragen, eskalieren oder übergeben. Ein aus früherem Verhalten gelerntes Timing ist nützlich.
Es ist aber genau die Art von Signal, die sich niemals selbst eine Erlaubnis erteilen können darf. ERQYO trennt beides und macht die Trennung zu einer Frage der Struktur statt guter Absichten.
ERQ · YO
ERQ · Event Rhythm Qualifier
“Was erscheint als Nächstes angemessen, gegeben das Ereignis, den Zustand, den Rhythmus und den zeitlichen Kontext?”
Die adaptive Seite. Sie liest Ereignis- und Zustandskontext, Rhythmus, Akteursuhren und Beziehungskontext und schlägt einen qualifizierten Kandidaten vor. Ihr Ausgabetyp hat kein Feld, in dem sich eine Erlaubnis ausdrücken ließe.
YO · Yoked Operator
“Darf dieses qualifizierte Ergebnis unter den maßgeblichen Randbedingungen ausgeführt werden, und wie?”
Die kontrollierte Seite. Sie ist an maßgebliche Randbedingungen gekoppelt, nicht an ERQ selbst: Befugnis, Richtlinien, Nachweise, Schutzmaßnahmen und harte zeitliche Grenzen erreichen sie direkt und laufen nie durch den Qualifier.
Der Entscheidungsweg
- Ereignis / Zustandsänderung
- Operativer Zustand
- Mögliche Ergebnisse
- ERQqualifiziert
- Qualifizierter Kandidat
- YOführt aus
- Qualifiziertes Ergebnis
Gelernter Rhythmus kann nur den Vorschlag beeinflussen. Befugnis, Richtlinien und Nachweise erreichen den Operator direkt.
Textbeschreibung des Diagramms
Ein Ereignis oder eine Zustandsänderung aktualisiert den operativen Zustand. Rhythmus, Akteursuhren und zeitlicher Kontext fließen in ERQ in die Qualifizierung möglicher Ergebnisse ein, woraus ein qualifizierter Kandidat entsteht. Der Yoked Operator prüft diesen Kandidaten gegen Befugnis, Richtlinien, Nachweise, Schutzmaßnahmen und harte Grenzen, die ihn direkt erreichen, und erzeugt das qualifizierte Ergebnis.
Zehn Ergebnisse
Ein geschlossenes Vokabular. Jedes Ergebnis bedeutet etwas anderes, und genau auf diese Unterschiede kommt es an.
- ACT
- Die Aktion jetzt ausführen.
- RESPOND
- Dem Gegenüber antworten: eine kommunikative Form des Handelns.
- WAIT
- Noch nicht. Das Warten hält fest, wann und bei welchen Ereignissen neu bewertet wird; es ist semantisch, nie ein bloßes Sleep.
- ASK
- Erforderliche Angaben oder Nachweise fehlen.
- REASSESS
- Eine Abhängigkeit hat sich verändert; erneut qualifizieren.
- DELEGATE
- An einen anderen Akteur übergeben, der die Befugnis hat.
- ESCALATE
- An eine höhere Instanz eskalieren, etwa kurz vor einer Frist oder einer Grenze.
- HANDOFF
- Den Fall einem Menschen übergeben, weil die Laufzeit dafür keine Befugnis hat.
- ABSTAIN
- Die Konfidenz reicht für eine Entscheidung nicht aus. Nicht dasselbe wie BLOCK.
- BLOCK
- Eine Richtlinie oder eine harte Grenze verbietet es.
Die Live-Darstellung auf dieser Website nutzt acht davon. RESPOND, eine kommunikative Form des Handelns, und DELEGATE, die Übergabe an einen anderen Akteur mit Befugnis, vervollständigen das Vokabular.
Zeitliche Rahmen
Der früheste und der späteste Zeitpunkt sind harte Grenzen: ein vertragliches Zeitfenster, eine regulatorische Frist, eine Bedenkzeit. Der bevorzugte Zeitpunkt ist weich, und nur dort darf der Rhythmus mitreden. Der Operator liest die harten Grenzen und nie die Präferenz, sodass aus einer gelernten Gewohnheit keine Frist werden kann.
Dynamisches WAIT
Ein WAIT wird zusammen mit den Bedingungen aufgezeichnet, die es wieder öffnen: ein Zeitpunkt oder eine Art von Ereignis. Gelernter Rhythmus darf ein Warten nur innerhalb der jeweils geltenden harten Grenzen verschieben.
Befugnis
Befugnis ist ein Mandat, Operationen in einem Geltungsbereich für einen Zeitraum auszuführen. Die Referenzimplementierung kennt sechs Freigabemodi, von der Einzelfreigabe bis zum Vier-Augen-Prinzip; eine dem Vorstand vorbehaltene Entscheidung kann von der Laufzeit nie erfüllt werden und wird immer eskaliert. Ein Vorschlag, dessen Begründung behauptet, die Prüfungen seien bestanden, geht trotzdem an einen Menschen, denn der Operator liest die Begründung nie.
Replay von Entscheidungen
Jede Entscheidungsspur hält die Vertragsversion fest, unter der die Entscheidung getroffen wurde, damit sie sich später erneut abspielen lässt. Das Replay weist eine Spur zurück, die es nicht interpretieren kann, und menschliche Übersteuerungen werden aufgezeichnet, nie erschlossen.
RhythmBench
Neun deterministische Szenarien vergleichen die Laufzeit mit einer rhythmus- und governance-blinden Baseline, die innerhalb des Benchmarks definiert ist. Ein Vergleich mit anderen Produkten oder Frameworks wurde nicht angestellt und darf nicht in die Zahlen hineingelesen werden.
- 1Übereiltes Nachfassen
- 2Frist bei geduldigem Rhythmus
- 3Handeln ohne Mandat
- 4Bedenkzeit
- 5Veraltete Nachweise
- 6Über dem Limit
- 7Ruhezeiten
- 8Doppelte Zustellung
- 9Verbotene Operation
Die Trennung ausprobieren
Unten läuft in Ihrem Browser ein vereinfachtes Modell der Idee. Ändern Sie den Rhythmus, und nur die Wahrscheinlichkeiten bewegen sich; ändern Sie eine Randbedingung, und das Ergebnis ändert sich unabhängig von ihnen.
› Ereignis customer.message.received 23:40
ERQ · vorgeschlagen
- ACT56%
- WAIT30%
- HANDOFF14%
YO · entschieden
- ✓ Harte Grenze
- ✓ Nachweise widerspruchsfrei
- ✓ Qualifizierung sicher genug
- ✓ Nachweise vorhanden
- ✓ Befugnis zugeordnet
- ✗ Fenster offen
Ergebnis
WAITNoch nicht; zu einem festgelegten Zeitpunkt wieder aufnehmen
Die Aktion ist erlaubt, aber nicht jetzt. Die Laufzeit wartet auf das Fenster, und das Warten wird festgehalten.
ERQ: ACT → YO: WAIT
Eine Illustration, berechnet in Ihrem Browser: ein vereinfachtes Modell der Trennung ERQ → YO mit illustrativen Zahlen und acht der zehn Ergebnisse von ERQYO. Es ist nicht die ERQYO-Referenzimplementierung.
Aktueller Stand der Implementierung
Das Repository von AnyLAI enthält eine Referenzimplementierung: Verträge, Qualifier, Operator, Rhythmusmodell, Laufzeit und RhythmBench, im September 2026 gemergt und durch 64 Tests abgedeckt.
Die Implementierung wird nicht produktiv betrieben. Es gibt keine API, keine Benutzeroberfläche und keinen Aufrufer im Produktivbetrieb. Die einzige Integration läuft im Schattenmodus im Prototyp AnyClinical, hinter Flags, die ausgeschaltet sind.
- 0Verträge und Entscheidungsspurumgesetzt
- 1Deterministisches ACT, WAIT, ESCALATE und BLOCKumgesetzt
- 2Uhren, zeitliche Rahmen und semantisches WAITumgesetzt
- 3Rhythmusmodell (Median-Baseline) und Schattenmodusumgesetzt
- 4Beziehungsrhythmus: Ruhezeiten, Antworttaktumgesetzt
- 5Befugnis, Delegation und Vier-Augen-Prinzipumgesetzt
- 6RhythmBenchumgesetzt
- 7Öffentliche Referenzspezifikation und SDKnicht begonnen
- –Produktivbetriebkeiner
Verwandte Arbeiten
ERQYO steht neben COADF: COADF beschreibt, wie KI-gestützte Software gebaut und gesteuert wird, ERQYO, wie eine Laufzeit unter dieser Governance entscheidet.
Es baut auf etablierten Ideen auf, etwa Regeln als Daten zu führen und einen Vorschlag von der Erlaubnis zu seiner Ausführung zu trennen, und erhebt nicht den Anspruch, als Erstes diese Trennung vorgenommen zu haben.
Grenzen
Grenzen
- Das Rhythmuslernen ist eine deterministische Median-Baseline, kein trainiertes Modell.
- Nicht produktiv betrieben: keine API, keine Benutzeroberfläche, keine produktive Integration.
- RhythmBench vergleicht nur mit seiner eigenen eingebauten Baseline.
- ERQYO verleiht keine eigene rechtliche oder organisatorische Befugnis; die Befugnis muss von der Organisation kommen, die es einsetzt.
- Die öffentliche Spezifikation und das SDK sind noch nicht geschrieben.
Siehe auch
COADFVeröffentlichtes Framework
Ein veröffentlichtes Framework, um KI-gestützte Software unter expliziter Governance zu bauen: acht Prinzipien, ein Kontrollmanifest und Fences, die in der CI erzwungen werden.
COADFAnyClinicalPrototyp zur Workflow-Governance · unveröffentlicht
Governance eines Workflows in der klinischen Koordination: Einwilligung, Eskalation, Übergabe und Enthaltung. Keine Diagnose.
AnyClinicalTrust ArchitectureUmgesetzte Plattformarchitektur
Provenienz, Nachweise, Konfidenz, Befugnis und Audit, so angeordnet, dass sich Vertrauen an jeder Grenze prüfen lässt.
Trust Architecture