Wissenskorrektur

Gespeichertes Wissen über Agent-Tools korrigieren

Lies die gemeinsamen Konventionen und die Publikationsrichtlinien vor dem Schreiben.

Identifiziere den zugehörigen Datensatz

Verwende eine bereitgestellte strukturierte Record/Claim-ID und Revision als primäres Ziel, nicht nur die Anzeigebezeichnung. Lies knowledge_record mit Metadaten und Belegen; bestätige die aktuelle Revision/den Hash. Eine referenzierte Revision, die sich geändert hat, erfordert ein erneutes Lesen und Abgleichen der Anfrage – nicht stillschweigendes Handeln auf einer neuen Behauptung. Ohne exakte Referenz verwende Nachschlage/Suche, überprüfe Kandidaten und frage erst nach, wenn das angeforderte Ziel oder die Korrektur inhaltlich mehrdeutig bleibt.

Unterscheide eine fehlerhafte gespeicherte Behauptung von einer nicht belegten Antwort, widersprüchlichen Quellenangaben und einer Tatsache, die sich im Laufe der Zeit geändert hat. Ein Widerspruch allein berechtigt nicht zur Ersetzung; der einzige Nicht-Benutzer-Fall ist eine dauerhafte Aussage, die von ihrem Inhaber explizit ersetzt wurde, gemäß der Publikationsrichtlinie. Erfinde keine gespeicherte „Sicherheitsangabe“, wenn kein Datensatz existiert, und behandle einen Rückzieher nicht als Beleg für das Gegenteil.

Wende die richtige Operation an

• Korrektur eines Claims oder einer expliziten Beziehung: Rufe knowledge_correct mit der exakten ID, der beobachteten expectedRevision und expectedHash, dem Grund, der beobachteten Vault-UUID und dem Ontologie-Fingerabdruck sowie einem vollständigen replacement desselben kind auf. Ersatzfelder verwenden den Create-Claim/Create-Relationship-Vertrag; es gibt eine äußere Anfrage-ID, keine zweite Ersatzanfrage. Bewahre unterstützenden Kontext, Zuschreibung, präzise Daten und Belege; entferne oder überarbeite, was die Korrektur tatsächlich ändert. Die Operation veröffentlicht den Ersatz und ersetzt die alte Behauptung gemeinsam, mit Verweisen in beide Richtungen.
• Rücknahme ohne Ersatz: Rufe knowledge_withdraw mit der exakten ID, der Revision/ dem Hash, dem Grund und der Vault-UUID auf. Es akzeptiert Seiten, Claims und explizite Beziehungen. Eine Kante wird durch ihre eigene ID identifiziert, nicht durch ihr Endpunktpaar. Es bewahrt die ursprünglichen Belege/den Verlauf und ist keine Dateilöschung.
• Korrektur von Seitentext: Verwende die normale revisonsgeschützte knowledge_save_page, wobei nicht zusammenhängendes verfasstes Material und Quellen erhalten bleiben. Seitenkorrekturen sind Revisionen, keine Ersatzentitätsidentitäten.
• Zwei Seiten für eine Entität: Rufe knowledge_merge mit der überlebenden Seite, dem Duplikat, der aktuellen Revision/ dem Hash beider Seiten und einem Grund auf. Behalte die Seite mit der vollständigeren Identität (echter Name, mehr Verbindungen) als Überlebende; übergib title, um sie umzubenennen, und body, wenn die kombinierte Seite mehr aussagen soll als der aktuelle Text der Überlebenden. Die ID, der Titel, Aliase, Claims, Beziehungen und Links des Duplikats werden dann zur Überlebenden aufgelöst; nichts wird einzeln korrigiert. Mache eine fehlerhafte Zusammenführung mit knowledge_unmerge rückgängig.

Eine explizite Benutzerkorrektur kann Belege liefern: Behalte ihre genaue Aussage mit knowledge_attach, schreibe sie dem Benutzer zu und referenziere ihren verifizierten Locator. Verwende assertion_origin: user_belief, um eine Benutzeraussage von einer unabhängig belegten Aussage zu unterscheiden; behaupte keine dokumentarische Verifizierung. Agenteninferenzen benötigen weiterhin erhaltene Belege der Prämissen, kein erfundenes Zitat.

Behandle einen Handle oder eine Fehlidentität

Verwende knowledge-entities, um das Handle-Profil, die etablierte Person und ihre verbundenen Datensätze zu finden und zu lesen. Behalte die genaue Identifikation des Benutzers als Beleg bei. Aktualisiere unterstützte Aliase und Identitätskontext auf den vorhandenen Seiten; bewahre nicht zusammenhängende Inhalte und beschreibe die Verbindung zur etablierten Person. Verwende die vorhandene ID dieser Person für zukünftige Anreicherungen. Wenn der Handle bereits eine eigene Seite hat, führe sie mit knowledge_merge in die Seite der etablierten Person zusammen, statt eine Verweisseite zu schreiben, sie zurückzuziehen oder ihre Claims einzeln zu korrigieren. Führe Zusammenführungen nur auf Basis von Identitätsbelegen durch (die Aussage des Benutzers, eine Selbstvorstellung, eine gemeinsame stabile Konto-ID), niemals aufgrund von Namensähnlichkeit; knowledge_diagnostics mergeCandidates listet zu überprüfende Seiten auf, nicht zu verschmelzende Seiten. Behalte den Identitätsbeleg mit knowledge_attach und übergib ihn als evidence.

Überprüfe betroffene Prosa, Claims, Zeitlinien und Beziehungen innerhalb des Korrekturbereichs. Korrigiere falsche Zuschreibungen und ungeklärte Identität, wo die neuen Belege dies unterstützen, unter Verwendung der oben genannten Seiten-/Behauptungsoperationen; bewahre Quellenbezeichnungen, wörtliche Zitate, Ereignisdaten und Korrekturprovenienz. Eine bestätigte Autorenidentität verifiziert nicht unabhängig die sachlichen Behauptungen dieses Autors.

Änderungen erfolgen über diese Tools, nicht durch manuelle Markdown-Bearbeitungen, Browser-Formulare, SQL oder separate „Erstellen dann Zurückziehen“-Aufrufe. Es gilt kein zusätzliches Genehmigungsritual für eine eindeutige benutzerautorisierte Korrektur. Befolge die Publikations-Wiederholungs-/Konflikthandhabung; eine Quittung im Status „akzeptiert“/„Konflikt“ ist keine abgeschlossene Reparatur.

Untersuche die Ausbreitung und berichte ehrlich

Die impact.items der Quittung identifiziert bekannte direkte/transitiv abhängige Elemente zum Zeitpunkt der Annahme. Es aktualisiert sie nicht. Lies betroffene Datensätze per exakter ID und untersuche ihre Belege. Repariere nur unterstützte Änderungen innerhalb des Anfragebereichs; ersetze keine Abhängigkeits-IDs oder Quellzitate blind mit dem neuen Claim. Datensätze, die von einer inaktiven Behauptung abhängen, werden bis zur Reparatur von der aktuellen Suche zurückgehalten; die genaue Datensatz-/Verlaufsprüfung bleibt verfügbar.

Suche als ergänzende Prüfung nach plausiblen Textkopien. Suchfehler, unverlinkte Prosa, verborgene Bereiche und unvollständige Indizes verhindern ein universelles „Alle Kopien behoben“-Versprechen. Verändere nicht automatisch als Folge einer Wissenskorrektur unzusammenhängende Gedächtnis- oder Identitätssysteme.

Lies das Original und den Ersatz (oder das zurückgezogene Ziel) zurück, überprüfe Lebenszyklus und Belege und überprüfe, ob die aktuelle Suche die alte Behauptung ausschließt. Antworte mit der Quittungs-/Anfrage-ID, den betroffenen Datensatz-IDs, dem Korrektur-/Rücknahmegrund und reparierten versus ungelösten Abhängigkeiten. Erwähne den erhaltenen Verlauf nur, wenn relevant; versprich niemals Löschung aus Originalen, Exporten oder Backups.