Widersprüche dürfen bleiben

Diesen Beitrag anhören (12 Min.)

Ein hypothetisches Beispiel: Im Architekturprotokoll eines Produkts steht „PostgreSQL is the primary database.“ Die Deployment-Dokumentation desselben Produkts sagt: „SQLite is the primary database for edge installations.“ Beide Aussagen sind belegt. Ein maschinell erkennbarer Konflikt entsteht daraus erst, wenn beide Aussagen demselben Subjekt und Prädikat zugeordnet sind und primary_database im Space-Vertrag als funktionales Prädikat konfiguriert ist – also als Beziehung, die für ein Subjekt genau einen aktuellen Wert haben darf.

Eine Wissensbasis darf solche Spannungen nicht mit einer flüssigen Zusammenfassung verdecken. Hinter dem Konflikt können etwa ein unterschiedlicher Geltungsbereich (PostgreSQL allgemein, SQLite nur für Edge-Installationen), eine zeitliche Änderung der Architektur oder ein schlichter Quellenfehler stecken. Eine Zusammenfassung darf den offenen Konflikt nicht zu einer eindeutigen Aussage verdichten. Sind beide Aussagen demselben Subjekt und einem als funktional konfigurierten Prädikat zugeordnet und besitzen sie verschiedene Objekte, markiert WikiKit beide Claims als disputed, verbindet sie über eine contradicts-Beziehung und löscht keinen von beiden, bis eine geprüfte Revision die Frage fachlich klärt.

Wann WikiKit einen Widerspruch erkennen kann

Claims bestehen aus Subjekt, Prädikat und Objekt. Manche Beziehungen dürfen mehrere Objekte gleichzeitig tragen: Ein System kann mehrere Exportformate unterstützen, supports_format=markdown und supports_format=okf ergänzen einander. Andere Beziehungen sollen für ein Subjekt genau einen aktuellen Wert besitzen. Der Space-Vertrag legt diese zweite Gruppe als funktionale Prädikate fest. Ein vereinfachtes Beispiel für diese Konfiguration:

{
  "settings": {
    "functional_predicates": [
      "primary_database",
      "current_owner",
      "default_retention_days"
    ]
  }
}

Stand 18. August 2026 gilt im Repository: Nur bei ausdrücklich als funktional konfigurierten Prädikaten erkennt WikiKit einen Konflikt – genau dann, wenn derselbe Gegenstand und dasselbe Prädikat verschiedene Objekte besitzen. Diese Regel ist absichtlich enger als semantische Ähnlichkeit. WikiKit versucht nicht, jeden inhaltlichen Widerspruch automatisch zu verstehen; ein Modell soll aus zwei ähnlich klingenden Sätzen keinen Konflikt erraten und erst recht keinen wegdiskutieren. Erkannt wird ausschließlich, was der Space-Vertrag als eindeutig deklariert hat. Das macht die Erkennung deterministisch und ihre Fehlermöglichkeiten benennbar: Ein zu breit gewähltes Subjekt erzeugt Scheinkonflikte, ein fehlendes funktionales Prädikat lässt echte Konflikte unentdeckt.

flowchart TD
    A["service<br/>primary_database<br/>PostgreSQL"] --> C{"gleiches Subjekt und Prädikat<br/>anderes Objekt?"}
    B["service<br/>primary_database<br/>SQLite"] --> C
    C -->|funktionales Prädikat| D["beide Claims disputed<br/>contradicts-Beziehung"]
    C -->|mehrwertiges Prädikat| V["kein Konflikt<br/>beide Claims bleiben bestehen"]

`disputed` und `contradicts` erhalten den Konflikt

Trifft bei der atomaren Freigabe ein neuer Claim auf einen bestehenden Wert eines funktionalen Prädikats, werden beide kollidierenden Claims als disputed markiert und durch eine contradicts-Beziehung verbunden. Keine der beiden Aussagen wird gelöscht, keine wird still ersetzt. Ein neuer Beleg darf einen älteren Konflikt nicht einfach überschreiben – auch dann nicht, wenn er später hochgeladen wurde.

{
  "subject": "wikikit-runtime",
  "predicate": "primary_database",
  "object": "PostgreSQL",
  "status": "disputed",
  "relations": [
    {
      "kind": "contradicts",
      "to_claim_id": "claim_sqlite"
    }
  ]
}

Ein umstrittener Claim bleibt sichtbar. Der Status warnt: Es gibt einen belegten Konflikt, der noch nicht aufgelöst ist. Ein nachgelagertes System sollte diesen Claim deshalb nicht wie eine unbestrittene Tatsache verwenden.

Stilles Überschreiben wäre einfacher und gefährlicher. Die aktuelle Seite könnte plötzlich SQLite nennen, während frühere Entscheidungen, Deployments und Runbooks weiter von PostgreSQL ausgehen. Ohne Konfliktstatus würde ein Agent die neue Formulierung mit derselben Sicherheit lesen wie jede andere freigegebene Aussage. disputed schafft stattdessen einen expliziten, abfragbaren Konfliktzustand: Für dasselbe funktionale Prädikat liegen zwei als disputed markierte Werte vor. Diese Information ist für eine Entscheidung wertvoller als eine zufällig gewählte Quelle.

Der Geltungsbereich löst viele Scheinkonflikte

Im Eingangsbeispiel beziehen sich die Quellen möglicherweise auf verschiedene Deployments. Dann ist keines der Objekte falsch; das Subjekt ist zu breit. Aus wikikit-runtime werden wikikit-standard-deployment und wikikit-edge-deployment.

[
  {
    "subject": "wikikit-standard-deployment",
    "predicate": "primary_database",
    "object": "PostgreSQL"
  },
  {
    "subject": "wikikit-edge-deployment",
    "predicate": "primary_database",
    "object": "SQLite"
  }
]

Der Review korrigiert damit das Modell, nicht die Quellen. Beide Originalzitate bleiben erhalten. Neue Claims beschreiben ihren tatsächlichen Geltungsbereich; was mit den zu breit geschnittenen alten Claims geschieht, entscheidet die geprüfte Revision – automatisch verschwindet keiner von ihnen.

Andere Konflikte sind zeitlich. Eine Retention betrug früher 30 Tage und heute 90. Auch hier können beide Quellen stimmen: Der aktuelle Claim nennt 90 Tage, die alte Aussage bleibt als frühere Fassung in ihrer Revision erhalten. Kategorisierungen und Beziehungen bleiben revisionsfähige, belegte Aussagen.

Ein echter fachlicher Widerspruch bleibt übrig, wenn Geltungsbereich und Zeitraum identisch sind. Dann muss die prüfende Person eine Quelle als maßgeblich bestimmen, eine neue Entscheidung anlegen oder die Frage bewusst offenhalten.

Review im Cockpit

Die fachliche Auflösung geschieht nicht in der Erkennungslogik, sondern in einer späteren, geprüften Revision. Das Cockpit ist dafür die Les- und Reviewoberfläche für Menschen: Dort liest eine Person die betroffenen Claims mit ihren Belegen und entscheidet, ob Geltungsbereich, Zeit oder Inhalt kollidieren. Ein Änderungsvorschlag, der nur den neueren Claim betrachtet, könnte die Entscheidung zugunsten des jüngeren Belegs verzerren – deshalb gehören beide Seiten des Konflikts in den Review.

Ein praktischer Prüfpfad:

Subjekt und Prädikat auf zu groben Geltungsbereich prüfen.
Quellenzeitpunkt und betroffene Produktversion vergleichen.
Autorität der Quellen einordnen, ohne ältere Belege zu entfernen.
Entscheidung mit kurzer Begründung festhalten und in einer neuen Revision freigeben – oder den Konflikt bewusst disputed lassen.

Die prüfende Person darf einen Konflikt offenlassen. Fehlende Information ist ein legitimer Zustand; eine spätere Quelle oder eine zuständige Person kann die Auflösung nachholen. Wichtig ist die Rollenverteilung: WikiKit legt den Widerspruch offen und hält ihn stabil. Es entscheidet nicht ohne Review, welche Aussage wahr ist – weder über sprachliche Plausibilität noch über Datumsstempel.

Suche und Antworten sollten den Status respektieren

Ein Konflikt, den nur der Reviewprozess kennt, verschwindet für alle anderen Leser. Deshalb geben Such- und MCP-Lesezugriffe auch disputed Claims zurück. Für nachgelagerte Systeme folgt daraus eine redaktionelle Soll-Regel, keine bereits implementierte WikiKit-Funktion: Eine natürlich formulierte Antwort sollte den Widerspruch benennen und beide Belege angeben, statt eine Seite auszuwählen. Ein hypothetisches Antwortformat eines solchen Systems könnte so aussehen:

{
  "answer": "The knowledge base contains conflicting primary-database claims for the runtime.",
  "citations": ["claim_postgresql", "claim_sqlite"],
  "status": "conflict"
}

Findet ein nachgelagerter Agent keine freigegebene Auflösung, sollte er keine eindeutige Antwort geben und den internen Konflikt nicht mit allgemeinem Vorwissen scheinbar lösen. Er sieht die disputed Claims und darf daraus keinen eindeutigen Wert ableiten: Diese Frage ist gerade offen, und die weitere Planung muss das berücksichtigen.

Drei Revisionen zeigen den Unterschied

Bei default_retention_days unterscheiden sich Ablösung und Widerspruch so: Revision 1 enthält den freigegebenen Claim default_retention_days=30. Eine spätere Entscheidung erhöht den Wert auf 90; die geprüfte Revision 2 übernimmt den neuen Wert als aktuelle Aussage und behält die alte als Geschichte. Es gibt keinen offenen Konflikt, weil Quelle und Entscheidung die zeitliche Ablösung erklären.

Für Revision 3 trifft ein Runbook ein, das weiterhin 30 Tage als aktuellen Default bezeichnet. Damit kollidiert der vorgeschlagene Anspruch mit dem aktuellen 90-Tage-Claim. Wird der Vorschlag als Revision 3 atomar freigegeben, werden beide aktuellen Behauptungen disputed und über contradicts verbunden, bis geklärt ist, ob das Runbook veraltet ist oder die Entscheidung nie umgesetzt wurde. Der vorgeschlagene Claim wird nicht allein wegen seines späteren Uploadzeitpunkts bevorzugt.

revision 1:
  aktueller Wert: 30 Tage

revision 2:
  aktueller Wert: 90 Tage
  alte Aussage bleibt als Geschichte erhalten

revision 3 (Vorschlag):
  Runbook nennt 30 Tage als aktuellen Default
  bei atomarer Freigabe:
    -> beide aktuellen Werte werden disputed
    -> contradicts verbindet die kollidierenden Claims

Diese Sequenz trennt Ablösung von Widerspruch. Eine begründete zeitliche Änderung erzeugt eine neue aktuelle Aussage und bewahrt die alte als Geschichte. Ein Beleg, der gleichzeitig einen anderen aktuellen Wert beansprucht, öffnet bei der atomaren Freigabe einen Konflikt. Die prüfende Person kann die Produktionskonfiguration als zusätzliche Quelle heranziehen: Zeigt sie 90 Tage, wird der Runbook-Claim abgelehnt und eine Dokumentationskorrektur angestoßen. Zeigt sie 30, muss geklärt werden, ob die Entscheidung falsch umgesetzt oder zurückgenommen wurde. Die Wissensbasis soll diese Betriebsentscheidung nicht aus Zeitstempeln erraten.

Veraltet ist nicht automatisch widersprüchlich

Ein Claim kann jahrelang unverändert und trotzdem korrekt sein; ein anderer ist nach zwei Tagen überholt. Staleness ist deshalb eine eigene Qualitätsdimension und kein Beweis für einen Konflikt. Eine Preisangabe kann einen kurzen Prüfzyklus verlangen, während eine mathematische Definition oft seltener geprüft werden kann. Welche Wissensarten wann erneut betrachtet werden, ist eine Festlegung des Teams für seinen Space.

Als Reviewpolicy formuliert: Alter sollte zu einer erneuten Prüfung führen, nicht automatisch zu einer Abwertung des Claims; erst eine neue Quelle oder eine Entscheidung sollte den Status verändern. Umgekehrt kann ein sehr junger Claim sofort umstritten sein, wenn eine gleich aktuelle Quelle widerspricht. Diese Trennung verhindert eine mechanische Aktualitätsgläubigkeit: „Neuer“ ist ein wichtiges Signal, aber keine fachliche Autorität. Herkunft, Geltungsbereich und Entscheidung bleiben nötig.

Einordnung gegenüber früheren Beiträgen

Zwei frühere Beiträge dieser Seite behandeln benachbarte Fragen: ADR: Entscheidungen, die man versteht und Wissen, das die Session überlebt. Neu ist hier die Verbindung zwischen Entscheidung, einzelnen Claims und ihren Quellen: Ein Dokument kann in einem Ordner veralten, ohne dass eine neuere Produktdokumentation den Gegensatz bemerkt. Bei gleichem Subjekt und funktionalem Prädikat markiert WikiKit die kollidierenden Claims und verbindet sie. Der Review im Cockpit kann den Konflikt klären oder bewusst offenhalten. Alt und Neu dürfen in der Historie bleiben, aber ihr Status und ihre Beziehung müssen klar sein – Aufbewahren ist etwas anderes, als beide gleichzeitig für gültig zu erklären.

Sichtbare Konflikte machen die Wissensbasis prüfbar

Eine Wissensbasis ohne sichtbare Widersprüche kann besonders sauber oder besonders blind sein. Entscheidend ist, ob sie überhaupt einen Mechanismus besitzt, Konflikte zu erkennen und offen zu halten. WikiKit konzentriert sich dafür auf explizite, kontrollierte Prädikate und belegte Claims. Diese Begrenzung macht das Ergebnis vorhersehbar; die fachlichen Nuancen bleiben beim Review und werden in einer geprüften Revision festgeschrieben.

Für Teams ändert sich damit die Gesprächsgrundlage. Statt „Im Wiki steht aber …“ liegen zwei konkrete, verbundene Claims mit Quelle und Status im Cockpit vor. Der Review kann nun Geltungsbereich, Zeitraum oder Quelle gezielt prüfen, eine neue Entscheidung anstoßen oder das Nichtwissen ausdrücklich stehen lassen.

Für den ersten Einsatz spricht viel dafür, nur wenige fachlich eindeutige Prädikate zu konfigurieren: aktueller Owner, primäre Produktionsdatenbank, freigegebener Retention-Default. An den ersten realen Konflikten lässt sich dann prüfen, ob die Subjekte präzise genug geschnitten sind und welche Reviewinformationen fehlen. Erst danach sollte das kontrollierte Vokabular wachsen. So bleibt die Widerspruchserkennung ein verständliches Fachmodell – und wird nicht zu einem Schema, das jede neue Quelle erst passend machen muss.

Weiterführende Quellen

Wie fandest du diesen Beitrag?

Kommentare