Convergence Guard

Was macht Convergence Guard?

Convergence Guard ist ein Entscheidungsanalyse-Protokoll für Probleme, deren Hauptfehlermodus die vorzeitige Konvergenz ist: das Akzeptieren einer plausiblen kausalen Geschichte oder Handlung, bevor entscheidungsrelevante Alternativen getrennt und getestet wurden.

Es handelt sich nicht um eine Abstimmung unter Agenten. Informationsisolierte Arbeiter können weiterhin Modell-Priors, Trainingsverzerrungen, Beweise und Framings teilen. Schlussfolgerungsunabhängigkeit ist nicht Beweisunabhängigkeit. Übereinstimmung unter Arbeitern zählt niemals als unabhängige reale Bestätigung an sich.

Kerninvarianten

1. Trenne Beweis-Herkunft, Schlussfolgerung, Annahmen, Einschränkungen und Unbekannte, bevor Modelle generiert werden.
2. Suche nach kausal unterschiedlichen Modellen in wirklich isolierten Kontexten, wenn der Vollmodus ausgeführt wird.
3. Halte die frühe Qualitätsprüfung vor der kausalen Raumerfassung verborgen.
4. Zähle doppelte oder nahezu identische Modelle nicht als bestätigende Beweise.
5. Unterscheide kausale Plausibilität von der besten Handlung unter Unsicherheit.
6. Erlaube, dass Modelle sich gegenseitig ausschließen, koexistieren, verschachtelt sein oder interagieren können; erzwinge nicht jeden Vergleich in A ODER B.
7. Bevorzuge Modelle und Handlungen, die unterscheidbare, entscheidungsrelevante Vorhersagen erzeugen.
8. Konvergiere nur, wenn die Beweise und Entscheidungskriterien eine vertretbare Handlung stützen. Gib andernfalls ein explizites Unzulänglichkeitsergebnis plus die informativste nächste Beobachtung oder den informativsten Test zurück.
9. Verwende die Sprache des Benutzers für die endgültige Antwort, es sei denn, der Benutzer fordert eine andere Sprache an.

Aktivierung und Modi

Verwende Convergence Guard, wenn:

• mindestens zwei kausal unterschiedliche Erklärungen oder Handlungen plausibel bleiben;
• ein falsches frühes Commitment Ressourcen wesentlich verschwenden, die wahre Ursache verbergen, einen Lock-in-Effekt erzeugen oder einen schwer umkehrbaren Fehler verursachen würde;
• zusätzliche Beobachtungen, Vergleiche oder Interventionen die entscheidungsrelevante Unsicherheit reduzieren könnten;
• die Aufgabe offen genug ist, um eine strukturierte Analyse zu rechtfertigen.

Verwende das vollständige Protokoll nicht für einfache Faktenabfragen, Routineverfahren, Syntaxbearbeitungen, einen Fehler mit bekannter Ursache oder einen Fall, bei dem die faktenbasierte Prüfung nur eine praktikable Handlung übrig lässt.

Führe vor der Bezahlung des Vollmodus eine günstige Triage durch. Bevorzuge eine gewöhnliche Analyse, wenn direkte unterscheidende Beweise den wichtigen Mechanismus bereits klären, eine günstige entscheidende Prüfung vor dem Commitment durchgeführt werden kann und die verfügbare Handlung kostengünstig oder leicht umkehrbar ist. Steigere den Einsatz zum Vollmodus hauptsächlich, wenn mehrere aktive kausale Modelle bestehen und mindestens ein zusätzliches Risiko wesentlich ist: gemeinsame Beweis-Herkunft/Abhängigkeit, Framing- oder Open-World-Suchrisiko, schwer trennbare Confounding/Interaktion oder ein kostspieliges/schwer umkehrbares vorzeitiges Commitment. Die KOEXISTIERENDE oder INTERAGIERENDE Struktur allein ist kein Grund, den Vollmodus zu verwenden, wenn ein günstigerer Arbeitsablauf sie zuverlässig etablieren kann. Siehe den Anwendbarkeitsleitfaden.

Vollmodus

Der Vollmodus erfordert echte Kontextisolierung für jede Operation, deren Wert von Unabhängigkeit oder Blindheit abhängt. Simuliere niemals mehrere aufeinanderfolgende Personas in einem Kontext und melde dies als Vollmodus-Lauf.

Obligatorische Sub-Agenten-Ausführung und Modellautorisierung

• Immer wenn der vollständige Convergence Guard ausgewählt oder angefordert wird, starte tatsächlich separate Sub-Agenten über die Sub-Agenten/Worker-Orchestrierungswerkzeuge des Hosts für die isolationsabhängigen Rollen des Protokolls (beginnend mit den drei B1-Sucharbeitern, dann frische C1/C2, D1, D2 und bedingte Prüfer, falls zutreffend). Plane nicht nur, sie zu starten, simuliere ihre Ausgaben im Koordinator oder bezeichne sequenzielle Aufforderungen oder Ad-hoc-lokale Modell-API-Aufrufe als gestartete Sub-Agenten.
• Verwende die bestehende vom Benutzer autorisierte Modellkonfiguration des Hosts für diese Sub-Agenten. Wähle niemals ein lokal gehostetes Modell oder einen lokalen Inferenz-Endpunkt (einschließlich LM Studio, Ollama, llama.cpp oder einen localhost OpenAPI-kompatiblen Server) für irgendeine Protokollphase aus, wechsle nicht zu einem solchen, starte es nicht oder rufe es nicht auf ohne die ausdrückliche Autorisierung des Benutzers für diese Nutzung. Ein auffindbarer Endpunkt, ein installiertes Modell, ein vorheriger Benchmark oder die technische Fähigkeit, ihn aufzurufen, ist keine Benutzerautorisierung. Wenn das konfigurierte Sub-Agenten-Modell lokal ist und die Autorisierung fehlt, frage vor dem Start.
• Wenn der Host die erforderlichen Sub-Agenten nicht starten kann oder ihre Kontextgrenzen nicht verifiziert werden können, behaupte nicht den Vollmodus. Erkläre den spezifischen Blocker und fordere ausdrückliche Zustimmung an, bevor du in den reduzierten Modus wechselst oder ein anderes Modell/eine andere Laufzeitumgebung vorschlägst. Ersetze niemals stillschweigend ein lokales Modell für die angeforderten Sub-Agenten.
• Halte fest, welche Sub-Agenten-Operationen tatsächlich ausgeführt wurden, welches Modell/welche Laufzeitumgebung autorisiert war und ob die Isolationsprüfungen bestanden wurden. Ein erfolgreicher Start von Sub-Agenten ist für diesen Arbeitsablauf notwendig, beweist aber für sich genommen keine Kontextisolierung; alle unten stehenden Anforderungen an die Zulassungsliste und Grenzsicherung gelten weiterhin.

Ein separater Worker, Chat, Thread, Fenster oder eine separate Sitzung ist für sich genommen kein Beweis für Isolierung. Isolierung ist eine Eigenschaft der effektiven Eingabegrenze des Workers, nicht des Benutzeroberflächencontainers.

Für jede isolationsabhängige Operation behandle die durch dieses Protokoll definierten Stufeneingaben als eine explizite Kontext-Zulassungsliste. Zusätzlich zu den Host/System/Sicherheitsanweisungen darf der Worker nur die Beweise und Stufeneingaben erhalten, die das Protokoll für diese Rolle autorisiert.

Der Worker darf entscheidungsrelevantes Material außerhalb dieser Zulassungsliste nicht erhalten oder abrufen durch:

• Transkripte oder Zusammenfassungen des übergeordneten Gesprächs;
• Aufgaben, Ausgaben oder Schlussfolgerungen von Geschwister-Workern;
• vorherige Kandidatenausgaben oder -bewertungen;
• Kontospeicher oder referenzierte Chat-Verläufe;
• projektübergreifenden Kontext;
• gemeinsame Notizblöcke, Übergaben, Zusammenfassungen oder Retrieval-Indizes mit früheren Schlussfolgerungen;
• gespeicherten Verlauf eines wiederverwendeten Workers;
• Koordinatorpräferenzen oder Auswahlsignale, gegenüber denen die Stufe blind sein soll.

Reale Fakten sind nicht allein deshalb verboten, weil sie zuvor beobachtet wurden. Wenn solche Informationen relevant sind, nimm sie explizit mit entsprechender Herkunft in die sachliche Zusammenfassung auf, anstatt einem Worker zu erlauben, eine frühere Interpretation oder Schlussfolgerung implizit zu übernehmen.

Wenn die Laufzeitumgebung verbotenen entscheidungsrelevanten Kontext einfügen oder abrufen kann oder wenn die relevante Grenze nicht mit angemessener Sicherheit festgelegt werden kann, erfüllt diese Operation nicht den Vollmodus. Verwende den reduzierten Modus nur mit ausdrücklicher Zustimmung des Benutzers und gib die Einschränkung explizit an.

Eine negative Sentinel-Sonde oder ein Worker-Selbstbericht bedeutet nur KEIN LECK BEOBACHTET, nicht bestätigte Isolierung. Stelle jede erforderliche Grenze durch Laufzeitebenen-Nachweise fest, die sowohl den anfänglichen Kontext als auch spätere Retrieval-/Tool-Zugriffe abdecken; andernfalls protokolliere UNKLAR. Siehe Grenzsicherung.

Erstelle für API-basierte Worker jede Anfrage aus einem frischen Satz von zugelassenen Nachrichten: erforderliche Host/System/Sicherheitsanweisungen plus die autorisierten Eingaben der Rolle. Füge nicht den Zustand des übergeordneten Gesprächs/Sitzung an; beschränke Speicher, Retrieval und Tool-Zugriff auf dieselbe Grenze, einschließlich bei Folgenaufrufen. Ein frischer API-Aufruf oder eine niedrige Temperatur allein beweist keine Isolierung. Verwende modellunterstützte Generierungseinstellungen; dieses Protokoll schreibt nicht temperature=0.2 vor.

Reduzierter Modus

Wenn Isolierung nicht verfügbar ist, ist der Vollmodus nicht verfügbar. Verwende mit ausdrücklicher Zustimmung des Benutzers den reduzierten Modus, kennzeichne ihn deutlich und behaupte keine unabhängige Agentenbestätigung oder Blindstufen-Garantien.

Phase A – Die Entscheidung festlegen

A1. Faktenbasis

Wenn das Problem von externem Zustand abhängt, erstelle eine kompakte Beweiszusammenfassung. Verfolge die Herkunft explizit:

• BESTÄTIGT – direkt beobachtet in Code, Daten, Logs, Dokumentation, Messungen oder einer anderen überprüfbaren Quelle;
• BERICHTET – von einem Benutzer, Zeugen, Betreiber oder einer sekundären Quelle angegeben, aber in diesem Lauf nicht unabhängig überprüft;
• STARK ABGELEITET – gestützt durch eine kohärente Beweiskette, aber nicht direkt beobachtet;
• HYPOTHESE / ANNAHME – plausibel, aber nicht verifiziert;
• EINSCHRÄNKUNG – eine reale Grenze wie Zeit, Budget, Richtlinie, Kompatibilität, Sicherheit, Architektur oder eine explizite Benutzerentscheidung;
• OFFENE FRAGE – ein Unbekanntes, das die Entscheidung wesentlich ändern könnte.

Stufe BERICHTET oder STARK ABGELEITET nicht stillschweigend auf BESTÄTIGT hoch.

BESTÄTIGT gilt für das, was tatsächlich überprüft wurde, nicht automatisch für jede Behauptung, die von einer überprüften Quelle aufgestellt wird. Wenn ein offizieller Bericht beispielsweise angibt, dass Ereignis X eingetreten ist, kann es BESTÄTIGT sein, dass der Bericht diese Aussage macht, während Ereignis X selbst BERICHTET bleibt, es sei denn, die zugrunde liegenden Beweise sind direkt überprüfbar.

A1.1 Quellenrichtlinie auf Behauptungsebene

Bewerte für jede wesentliche Behauptung die Behauptung und ihre Beweiskette, anstatt die Wahrheit nach dem Ruf der Quelle zuzuweisen.

Bevorzuge nach Möglichkeit die nächste überprüfbare Primärevidenz, aber behandle primär, offiziell, peer-reviewed, institutionell oder Experte nicht als automatische Wahrheitslabels.

Verwende Primärmaterial für faktenbasierte Rückverfolgbarkeit. Für bevölkerungsbezogene oder kumulative wissenschaftliche Behauptungen kann ein transparenter systematischer Review, eine Metaanalyse oder eine andere qualitativ hochwertige Synthese entscheidungsrelevanter sein als jede einzelne Primärstudie, wenn ihre Methoden und die enthaltenen Beweise rückverfolgbar sind.

Halte für entscheidungsrelevante Behauptungen nach Möglichkeit fest:

• nächste verfügbare Primärquelle;
• Quellentyp;
• Überprüfbarkeit der zugrunde liegenden Beweise;
• Methode oder Datenverfügbarkeit;
• zeitliche Nähe zum Ereignis;
• Unabhängigkeit / gemeinsame Beweis-Herkunft;
• bekannte Widersprüche, wesentliche Anreize oder Konflikte;
• epistemische Rolle im aktuellen Lauf.

Verwende diese Quellenrollen:

• BEWEIS – bezieht sich direkt auf die Behauptung und ist überprüfbar genug, um sie zu stützen;
• BESTÄTIGUNG – stützt unabhängig bereits in der Zusammenfassung enthaltene Beweise;
• KONTEXT – nützlicher Hintergrund, der die Behauptung nicht wesentlich belegt;
• NUR HINWEIS – verweist auf eine potenziell relevante Behauptung oder Quelle, die zurückverfolgt werden muss, bevor sie Beweisgewicht tragen kann;
• UNGESTÜTZT – enthält derzeit nicht genügend überprüfbare Unterstützung, um die Entscheidung zu beeinflussen.

Der Ruf einer Quelle kann die Suchpriorität lenken, aber muss nicht die Herkunft auf Behauptungsebene ersetzen.

Sekundärquellen sind nützlich für Orientierung und Entdeckung, aber verfolge materielle Behauptungen nach Möglichkeit bis zur nächsten verfügbaren Primärevidenz zurück.

Interessenvertretungs-, parteiische, randständige, anonyme oder anderweitig schwer verifizierbare Quellen sind nicht automatisch ausgeschlossen. Sie können Hinweise liefern. Wenn sie direkt überprüfbare zugrunde liegende Beweise offenlegen, bewerte dieses Material unter denselben Regeln auf Behauptungsebene wie jede andere Quelle; wenn die zugrunde liegende Unterstützung nicht festgestellt werden kann, behalte die Behauptung als NUR HINWEIS, BERICHTET oder UNGESTÜTZT, wie angemessen.

Wenn eine Institution oder ein Geheimdienst eine Bewertung veröffentlicht, deren zugrunde liegende Beweise klassifiziert oder nicht verfügbar sind, kann es BESTÄTIGT sein, dass die Bewertung existiert und ein angegebenes Vertrauensniveau hat; die verborgenen stützenden Beweise selbst sind nicht BESTÄTIGT.

Multipliziere die Unterstützung nicht durch Medienwiederholung oder Zitationsanzahl. Wenn mehrere Berichte von einer vorgelagerten Beobachtung, einem Datensatz, einem Leak, einem Papier, einem Briefing oder einem Dokument abstammen, behandle sie als einen Beweisast, es sei denn, es wird echte Unabhängigkeit festgestellt.

Bewahre widersprüchliche Primärevidenz explizit auf, anstatt sie wegzumitteln oder allein durch Quellenprestige aufzulösen.

Behandle Anreize, Zugehörigkeit, Finanzierung, Ideologie oder Interessenkonflikte als mögliche Verzerrungskanäle, die zu untersuchen sind, nicht als automatischen Beweis, dass eine Behauptung falsch ist. Ebenso verringern nicht verfügbare Rohdaten die Überprüfbarkeit, beweisen aber für sich genommen nicht, dass eine Behauptung falsch ist.

Während isolationsabhängiger Stufen kann ein Worker eine neue Quelle oder einen neuen Beweishinweis aufdecken, aber er darf nicht stillschweigend zweigprivate Retrieval-Ergebnisse in die gemeinsame Faktenbasis einbringen. Leite alle wesentlichen neuen Beweise durch einen Beweis-Checkpoint, klassifiziere ihre Herkunft/Quellenrolle, aktualisiere die gemeinsame Zusammenfassung und führe nur betroffene Operationen erneut aus. Dies hält kausale Zweige auf den Beweisen vergleichbar, die tatsächlich Entscheidungsgewicht tragen.

Gib allen unabhängigen Sucharbeitern dieselbe sachliche Zusammenfassung. Bestehende Pläne, TODOs, vorherige Empfehlungen und die aktuelle Architektur sind Kontext, kein Beweis dafür, dass das aktuelle Framing korrekt ist.

A2. Entscheidungsvertrag

Definiere:

1. Entscheidungsfrage – Was muss ausgewählt, erklärt, priorisiert oder ausgeschlossen werden?
2. Umfang – Was darf umformuliert werden und was ist festgelegt?
3. Erfolgskriterium – Welches beobachtbare Ergebnis macht eine Handlung besser?
4. Verbotene Ersetzungen – In was darf die Analyse nicht stillschweigend verwandelt werden?
5. Verlust / Kosten eines Fehlers – Was wird beschädigt, wenn die Wahl falsch ist?
6. Umkehrbarkeit – Wie schwierig ist es, sich zu erholen oder den Kurs zu ändern?
7. Analysebudget – Endliche Grenzen für Zeit oder Aufrufe und Korrekturzyklen, gewählt innerhalb der Benutzereinschränkungen vor der Suche. Standardmäßig sind höchstens zwei Korrekturzyklen über den gesamten Lauf erlaubt. Ein Zyklus ist eine gezielte Rückkehr zu Beweisen/Suche/Modellrevision plus deren betroffene nachgelagerte Wiederholungen, nicht jeder Worker-Aufruf. Alle Phasen teilen sich das Budget; Wiederherstellungsversuche verbrauchen das Zeit-/Aufruflimit, und ein Phasenwechsel setzt es nie zurück. Stoppe an jedem Limit oder nach einem Zyklus ohne neue entscheidungsrelevante Beweise, einen praktikablen Mechanismus, gelöste Unsicherheit oder geänderte Entscheidungsauswirkungen. Siehe Checkpoint und Stoppregeln.

A3. Framing und Außensicht-Prüfung

Frage: Lösen wir das richtige Problem? Überprüfe auf vorgelagerte Ursachen, Proxy-Ziele, geerbte Einschränkungen, fehlende Systemgrenzen und alternative Formulierungen, die die Entscheidung wesentlich ändern würden.

Wenn eine aussagekräftige Referenzklasse existiert, zeichne relevante Basisraten oder Außensicht-Beweise auf, bevor tiefe Kandidatenverfeinerung durchgeführt wird. Lass eine generische Basisrate nicht starke fallspezifische Beweise außer Kraft setzen; verwende sie als Kalibrierungseingabe.

Verwende die optionale unabhängige Reframe-Überprüfung oder retrospektive Kau...

... [für die Übersetzung gekürzt]