Claims: klein, belegt, prüfbar

„Unser Publishing ist sicher, schnell und zuverlässig.“ Der Satz klingt gut und taugt kaum als Claim. Drei Bewertungen stecken darin, keine besitzt ein Kriterium, und eine Quelle könnte höchstens Teile davon belegen. Eine prüfende Person müsste den ganzen Satz annehmen oder ablehnen, obwohl sie vielleicht nur einen belegten Rollback-Mechanismus als Teil der Zuverlässigkeit bestätigen kann.

Eine Wissensbasis sollte deshalb kleine Aussagen als subject / predicate / object speichern. Der Seitentext bleibt für Menschen lesbar. Claims bilden darunter jene Einheiten, die einzeln zitiert, geprüft, bestritten und stillgelegt werden können. Confidence und Status beantworten dabei verschiedene Fragen.

Ein Claim sagt genau eine Sache#

Das Subjekt benennt den Gegenstand, das Prädikat die Beziehung oder Eigenschaft und das Objekt den konkreten Wert. Ein guter Claim lässt sich ohne den restlichen Seitenabsatz verstehen.

{
  "subject": "content-release",
  "predicate": "rollback_mechanism",
  "object": "switch the active pointer to an immutable revision"
}

Die Form ähnelt einem einfachen RDF-Triple, ist aber kein Zwang, die gesamte Fachlichkeit als universellen Graphen zu modellieren. Innerhalb eines Space entsteht ein kontrolliertes Vokabular, das zu dessen Fragen passt. rollback_mechanism kann dort sinnvoll sein, wo Releases verglichen werden; in einem HR-Space wäre es ohne Bedeutung.

Zu große Claims verbinden mehrere prüfbare Aussagen. Zu kleine Claims verlieren ihren Sinn. content-release / uses / pointer wäre zwar atomar, erklärt aber nicht, wofür der Pointer verwendet wird. Die Formulierung sollte eng genug für einen Widerspruch und vollständig genug für einen Leser sein.

flowchart TD
    A["Aussage aus Quelle"] --> Q{"eine fachliche<br/>Behauptung?"}
    Q -->|mehrere| S["in mehrere Claims teilen"]
    Q -->|eine| C{"ohne Absatz<br/>verständlich?"}
    C -->|nein| E["Objekt präzisieren"]
    C -->|ja| V["Zitat und Status ergänzen"]

Das Zitat trägt die Aussage#

Jeder Claim verweist über Citations auf eine oder mehrere Quellen. Die Citation enthält einen wörtlichen Ausschnitt und optional einen Locator. Eine Zitatprüfung kann sicherstellen, dass das Zitat wörtlich im archivierten Quelltext vorkommt. Ein Claim, dessen Beleg nur paraphrasiert oder erfunden ist, sollte verworfen werden, bevor er den Review erreicht.

{
  "subject": "content-release",
  "predicate": "rollback_mechanism",
  "object": "switch the active pointer to an immutable revision",
  "confidence": 0.94,
  "citations": [
    {
      "source_id": "source_release_docs",
      "quote": "Rollback changes the active release pointer to a previous immutable revision.",
      "locator": "Rollback"
    }
  ]
}

Ein Zitat muss die Aussage in ihrem Geltungsbereich stützen. Wenn die Quelle nur von einer Preview-Umgebung spricht, darf der Claim daraus keine allgemeine Produktionsregel machen. Diese Prüfung kann nicht allein über Zeichenketten erfolgen. Die prüfende Person liest den Kontext.

Mehrere Citations sind nützlich, wenn eine Aussage aus Vertrag und beobachtetem Verhalten gemeinsam gestützt wird. Die API-Dokumentation kann den vorgesehenen Mechanismus beschreiben, ein Produktionsreport seine tatsächliche Nutzung belegen. Viele schwache Quellen machen einen Claim jedoch nicht automatisch stärker.

Confidence ist keine Wahrheitsskala#

confidence beschreibt, wie sicher die erzeugende Synthese bei ihrer Zuordnung war. Sie kann der prüfenden Person helfen, unsichere Vorschläge zuerst anzusehen. Sie ist kein Ersatz für Status und keine Wahrscheinlichkeit, dass eine Aussage in der Welt wahr ist.

type ClaimStatus = "proposed" | "verified" | "disputed" | "deprecated";

type Claim = {
  subject: string;
  predicate: string;
  object: string;
  confidence: number;
  status: ClaimStatus;
};

Ein Claim mit confidence: 0.99 bleibt vor der Freigabe proposed. Ein freigegebener Claim mit confidence: 0.78 kann verified sein, weil ein Mensch Quelle und Formulierung geprüft hat. Später kann ein neuer Beleg ihn disputed machen, ohne den alten Confidence-Wert umzudeuten.

Diese Trennung verhindert eine bequeme Abkürzung. Eine Grenze wie „ab 0.9 automatisch freigeben“ würde Modellselbstsicherheit mit fachlicher Verbindlichkeit verwechseln. Sinnvoller ist es, aus jeder Wissensänderung einen Änderungsvorschlag zu machen, unabhängig vom Wert in confidence. Er wird erst nach menschlicher Freigabe übernommen.

Status bildet den Lebenszyklus ab#

proposed ist Staging und für normale Leser unsichtbar. verified bezeichnet eine freigegebene Aussage. disputed macht einen nachvollziehbaren Konflikt sichtbar. deprecated hält eine überholte Aussage in der Geschichte, ohne sie als aktuellen Stand zu behandeln.

Der Lebenszyklus erlaubt präzisere Antworten als Löschen. Wenn ein Dienst bis Version 2 einen statischen Retry-Wert verwendete und seit Version 3 ein Budget teilt, sind beide Aussagen historisch relevant. Die alte wird nicht aus allen Revisionen entfernt. Sie erhält einen Status und bleibt mit ihrer Quelle verbunden.

stateDiagram-v2
    [*] --> proposed
    proposed --> verified: human approval
    proposed --> [*]: rejection
    verified --> disputed: conflicting evidence
    disputed --> verified: conflict resolved
    verified --> deprecated: superseded
    disputed --> deprecated: superseded

Der Übergang von proposed zu verified geschieht nicht automatisch, sondern erst nach einer menschlichen Entscheidung. Der sichtbare Seitentext kann den aktuellen Stand anschließend flüssig erklären. Die Claims darunter bewahren, welche Einzelaussagen diese Erklärung tragen und welche Konflikte noch offen sind.

Funktionale Prädikate machen Konflikte exakt#

Manche Beziehungen dürfen gleichzeitig mehrere Objekte haben. Ein System kann mehrere Exportformate unterstützen. supports_format=markdown widerspricht supports_format=okf nicht. Andere Beziehungen sollen für ein Subjekt nur einen aktuellen Wert besitzen, etwa primary_database.

Ein Space kann solche funktionalen Prädikate deklarieren. Treffen dort zwei unterschiedliche Objekte für dasselbe Subjekt und Prädikat aufeinander, kann die Wissensbasis beide Claims als disputed markieren und über contradicts verbinden.

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

Diese Regel bleibt deterministisch. Ein Modell muss nicht entscheiden, ob zwei frei formulierte Absätze semantisch kollidieren. Das kontrollierte Prädikat benennt vorher, wo genau ein einzelner aktueller Wert erwartet wird.

Zu viele funktionale Prädikate wären schädlich. supports_format als funktional zu markieren würde ergänzende Fakten fälschlich in Konflikt setzen. Das Vokabular ist deshalb eine fachliche Entscheidung des Space und gehört ins Review.

Einen Absatz in Claims zerlegen#

Ein praktisches Beispiel zeigt die Größenentscheidung. Angenommen, eine Quelle sagt: „The service runs as a single binary, migrates PostgreSQL on startup, and exposes health and readiness endpoints.“ Daraus sollte kein Claim mit dem Objekt single binary with migrations and probes entstehen. Drei Eigenschaften ändern sich unabhängig voneinander.

[
  {
    "subject": "service-runtime",
    "predicate": "distribution",
    "object": "single self-contained binary"
  },
  {
    "subject": "service-runtime",
    "predicate": "database_migration",
    "object": "runs automatically on startup"
  },
  {
    "subject": "service-runtime",
    "predicate": "exposes_probe",
    "object": "/health and /ready"
  }
]

Wenn später ein Sidecar hinzukommt, betrifft das den Distribution-Claim. Die Migration und die Probes können unverändert bleiben. Eine prüfende Person sieht genau den kleinen Diff. Ein Agent kann weiterhin die beiden bestätigten Aussagen verwenden, während die erste geprüft wird.

Die Gegenprobe hilft: Würde eine Änderung des Objekts automatisch die anderen Teile der Aussage ändern? Falls nein, sind mehrere Claims angemessen. Würde ein Claim ohne Nachbarsatz missverständlich, braucht er ein genaueres Subjekt oder Objekt.

Auch Zeit und Geltungsbereich gehören in die Formulierung. uses PostgreSQL passt zu einer aktuellen Architektur, wenn die Quelle den gesamten Dienst beschreibt. Bezieht sie sich nur auf die Produktionsbereitstellung, sollte das Subjekt service-production-deployment lauten. Präzision entsteht oft besser über ein engeres Subjekt als über einen langen Objekttext.

Ein Claim ist kein vollständiger Satz für die Blogprosa. Er darf maschinenlesbar und knapp bleiben. Die Konzept-Seite erklärt anschließend, wie die drei Eigenschaften zusammenwirken.

Ein Konzept ist mehr als seine Claims#

Claims allein ergeben keine gut lesbare Erklärung. Ein Konzept besitzt weiterhin Titel, Zusammenfassung, Markdown und Beziehungen zu anderen Konzepten. Die Seite kann ein Beispiel, Einschränkungen und den historischen Zusammenhang erklären.

Die Claims erfüllen eine andere Aufgabe. Sie erlauben:

• eine einzelne Aussage bis zum Originalzitat zurückzuverfolgen;
• einen Widerspruch ohne Ablehnung der ganzen Seite zu markieren;
• bei einer neuen Revision nur die tatsächlich veränderten Behauptungen zu prüfen;
• Suchtreffer und Agentenantworten auf sichtbare, freigegebene Einheiten zu begrenzen.

Seitentext und strukturierte Ebene sollten gemeinsam revisioniert werden. Ein Vorschlag darf nicht bereits neuen Text zeigen, während seine Claims für Leser unsichtbar oder unvollständig sind. Die atomare Freigabe macht die neue Revision als Einheit aktuell.

Beziehungen verbinden, Claims belegen#

Neben Claims kann eine Wissensbasis gerichtete Beziehungen zwischen Konzepten kennen: related, part_of, depends_on, contradicts und supersedes. Eine Relation beantwortet, wie zwei Seiten zusammenhängen. Sie ersetzt keinen Claim und keine Citation.

{
  "from_slug": "content-release",
  "kind": "depends_on",
  "to_slug": "immutable-revision"
}

Die Relation macht Navigation und Kontext möglich. Der belegte Sachverhalt bleibt als Claim auf einer der Seiten. Sonst würde ein bloßer Link eine fachliche Aussage tragen, ohne ihren Wortlaut oder ihre Quelle zu nennen.

contradicts kann als Folge der funktionalen Prädikatlogik entstehen. supersedes eignet sich für eine nachvollziehbare Ablösung, bei der der neue Begriff oder die neue Regel den alten Stand ersetzt. Beziehungen selbst werden mit der Konzept-Revision geprüft und veröffentlicht.

Revisionen beantworten die Zeitfrage#

Ein aktueller Claim erklärt nicht allein, wann er eingeführt wurde. Eine Konzept-History sollte freigegebene, abgelehnte und vorgeschlagene Revisionen mit ihrer Herkunft führen: Welches Modell und welche Prompt-Version haben den Vorschlag erzeugt, welche Quellen wurden verwendet und welche Person hat freigegeben.

Diese Angaben machen ein Modell nicht zum Autor im rechtlichen oder fachlichen Sinn. Sie dokumentieren, welcher technische Syntheseweg den Vorschlag erzeugte. Prüfende Person, Notiz und Zeitstempel erklären die menschliche Entscheidung. Freigabe, Status und Revision zusammen machen sichtbar, wie eine Aussage in den gültigen Wissensstand gelangt ist – und wie sie ihn wieder verlassen kann.

Die History erlaubt eine zeitbezogene Frage: Welche Aussage war im März sichtbar, bevor die Retention-Regel geändert wurde? Ein Wissensdienst, der immer nur den aktuellen Absatz zurückgibt, kann sie nicht zuverlässig beantworten. Revisionen erhalten den damaligen Stand, ohne alte Claims als heute gültig auszugeben.

Für Teams wird diese Spur besonders nach Modell- oder Promptwechseln nützlich. Wenn eine neue Syntheseversion auffällig andere Claims vorschlägt, lassen sich betroffene Revisionen identifizieren und gezielt prüfen. Damit lässt sich neben der Quelle auch nachvollziehen, welches Modell und welche Prompt-Version den Vorschlag erzeugt haben.

Ein Schritt über „Sauberes Grounding II“ hinaus#

Sauberes Grounding II sortierte Grounding in Konventionen, Dokumente und Schnittstellenbeschreibungen. Die zentrale Frage lautete, welches Material für eine konkrete Aufgabe in den knappen Kontext gehört und wie teuer seine Wiederbeschaffung wäre. Das war ein Arbeitsmodell für einzelne Sessions.

Hinzu kommt eine kleinere, dauerhafte Einheit zwischen Dokument und Kontext: der Claim. Ein Agent muss nicht jedes Mal eine ganze Seite als gleichmäßig verbindlich behandeln. Er kann die aktuelle Konzept-Revision lesen, sichtbare Claims samt Status prüfen und bei Bedarf ihre Citations öffnen. Aus „passendes Dokument in den Kontext“ wird „passende, freigegebene Aussage mit Rückweg zur Quelle“.

Der ältere Artikel Fuzzy Matching mit expliziten Grenzen trennte eine Behauptung mit Confidence von einem Fakt. Dieselbe Vorsicht gilt hier. Confidence hilft beim Sortieren eines Vorschlags. Erst Beleg, Review und Status bestimmen, wie die Aussage in der Wissensbasis erscheint.

Claims im Review prüfen#

Bei einem neuen Vorschlag genügen vier Fragen. Behauptet der Claim genau eine Sache? Ist er ohne den umgebenden Absatz verständlich? Trägt das Zitat genau diesen Geltungsbereich? Würde ein abweichender neuer Wert als klarer Widerspruch erkennbar?

Wenn eine Antwort nein lautet, wird der Claim geteilt, enger formuliert oder abgelehnt. Das ist keine formale Wortübung. Kleine Claims senken später den Aufwand. Eine geänderte Retention-Regel erfordert dann keine komplette Neufassung der Seite über Storage. Nur die betroffene Aussage und ihre Erklärung werden angepasst.

Strukturiert werden nur Behauptungen, die für Suche, Review, Konflikte oder Herkunft relevant sind. Es geht nicht darum, jeden Satz als universelle Ontologie abzubilden. Alles andere bleibt Prosa; dafür entsteht kein Claim.

Weiterführende Quellen#

• W3C RDF 1.1 Concepts
• W3C PROV-O
• Sauberes Grounding II
• Fuzzy Matching mit expliziten Grenzen