Claims: klein, belegt, prüfbar

Diesen Beitrag anhören (12 Min.)

„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. Ein prüfende Person müsste den ganzen Satz annehmen oder ablehnen, obwohl er vielleicht nur die Aussage über Rollback bestätigen kann.

WikiKit speichert deshalb kleine Aussagen als subject / predicate / object. Der Seitentext bleibt für Menschen lesbar. Claims bilden darunter jene Einheiten, die einzeln zitiert, geprüft, bestritten und stillgelegt werden können. Diese Folge zeigt, wie man ihre Größe wählt und weshalb Confidence und Status verschiedene Fragen beantworten.

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. Der Grounding Guard prüft, ob das Zitat im archivierten Quelltext vorhanden ist.

{
  "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. Der 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. WikiKit macht aus jeder Änderung einen Änderungsvorschlag, unabhängig vom Wert in confidence.

Status erzählt den Lebenszyklus

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 sichtbare Seitentext kann den aktuellen Stand 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, markiert WikiKit beide Claims als disputed und verbindet sie über contradicts.

{
  "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. Eine Quelle sagt: „WikiKit 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": "wikikit-runtime",
    "predicate": "distribution",
    "object": "single self-contained binary"
  },
  {
    "subject": "wikikit-runtime",
    "predicate": "database_migration",
    "object": "runs automatically on startup"
  },
  {
    "subject": "wikikit-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. Ein 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 ist für eine aktuelle Architektur okay, wenn die Quelle den gesamten Dienst beschreibt. Bezieht sie sich nur auf die Produktionsbereitstellung, sollte das Subjekt wikikit-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 Konzepte. 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.

Der Seitentext und die strukturierte Ebene werden gemeinsam revisioniert. 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

WikiKit kennt neben Claims gerichtete Beziehungen zwischen Konzepte: 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.

Beim Export erscheinen sie als Wiki-Links und Frontmatter. Ein anderer Markdown-Leser kann die Verbindungen darstellen, auch wenn er WikiKits Datenmodell nicht vollständig kennt. Der strukturierte Roundtrip erhält Claims, Citations und Relations verlustfrei.

Revisionen beantworten die Zeitfrage

Ein aktueller Claim erklärt nicht allein, wann er eingeführt wurde. Die Konzept-History führt freigegebene, abgelehnte und vorgeschlagene Revisionen mit Agent-Metadaten. Dazu gehören Modell, Promptversion und verwendete Quellen.

{
  "revision": 4,
  "status": "current",
  "agent_meta": {
    "model": "configured-provider-model",
    "prompt_version": "synthesize.v1",
    "source_ids": ["source_release_docs"]
  }
}

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 Freigabe.

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. Die Herkunft reicht damit über die fachliche Quelle hinaus bis zum technischen Entstehungsprozess.

Was sich seit damals geändert hat

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.

WikiKit ergänzt eine kleinere, dauerhafte Einheit zwischen Dokument und Kontext: den 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 für Anfänger 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.

Der Trick liegt in der Bescheidenheit des Modells. WikiKit versucht nicht, jeden Satz als universelle Ontologie abzubilden. Es hält jene Behauptungen strukturiert, die für Suche, Review, Konflikte und Herkunft relevant sind. Der Rest darf verständliche Prosa bleiben.

Weiterführende Quellen

Wie fandest du diesen Beitrag?

Kommentare