Wenn Findings zu Wissen werden

Diesen Beitrag anhören (11 Min.)

Ein WatchKit-Befund hält fest, wie sich ein bestimmter Pfad bei einer bestimmten Quellrevision gegenüber der angewandten Entscheidungsregel verhielt. Wer diese Beobachtung ohne Ziel, Quellrevision und Entscheidungsregel als dauerhaften Claim übernimmt, behauptet mehr, als der Befund hergibt. Ein zeitlos formulierter Satz in der Wissensbasis liest sich dagegen als dauerhafte Eigenschaft des Produkts. Zwischen diesen beiden Aussagen liegt die Produktgrenze zwischen WatchKit und WikiKit – und ein Prozess, der bewusst nicht automatisiert wird.

Stand August 2026 beziehen sich die folgenden Aussagen auf die zitierten Repository-Stände von WatchKit und WikiKit; die öffentliche API beider Produkte kann sich später ändern.

Was ein WatchKit-Befund tatsächlich festhält

Für die hier betrachteten Fähigkeits- und Dokumentationsurteile hält WatchKit fest, wie sich die geprüften Endpunkte gegenüber der Entscheidungsregel verhalten. Es bewahrt dafür die geprüften Pfade, die beobachteten Statuscodes, die Inhaltstypen, die angewandte Entscheidungsregel und begrenzte Antwortbelege auf. Ein Finding ist damit kein freier Prosasatz, sondern eine nachvollziehbare Beobachtung: Man kann später prüfen, welcher Pfad abgefragt wurde, welche Antwort kam und nach welcher Regel daraus ein Urteil wurde.

Genauso wichtig ist, was WatchKit nicht behauptet. Es unterscheidet eine fehlende Beobachtung von einem negativen Prüfergebnis: Wenn ein Ziel nicht geprüft werden konnte, entsteht daraus keine Aussage über sein Verhalten. Beide Zustände bleiben getrennt. Diese Unterscheidung ist fachlich entscheidend: Ein System, das Lücken stillschweigend als Fehlschläge zählt, vermischt fehlende Messungen mit negativen Prüfergebnissen – und eine Wissensbasis, die auf solchen Befunden aufbaut, erbt genau diese Unschärfe.

Wie eine solche Beobachtung strukturiert sein kann, zeigt eine produktunabhängige Illustration – Feldnamen und Werte sind erfunden und geben nicht das WatchKit-Schema wieder:

{
  "target": "docs-endpoint-check",
  "path": "/api/stats",
  "status": "<beobachteter Statuscode>",
  "content_type": "text/html",
  "rule": "documented JSON response expected",
  "evidence_excerpt": "…<html>…",
  "verdict": "mismatch"
}

Der Befund sagt hier nicht, warum die Antwort HTML statt JSON war. Er sagt, was beobachtet wurde, unter welcher Regel das als Abweichung gilt und welcher Beleg das trägt. Eine Ursache – Fehlkonfiguration, veraltete Dokumentation, temporäre Umleitung – müsste erst jemand prüfen.

Die Entscheidung bleibt im Cockpit, die Reparatur außerhalb

WatchKit führt die Entscheidung über einen Befund in einer gemeinsamen Entscheidungswarteschlange und bindet sie an eine genaue Quellrevision. Wer im Cockpit entscheidet, entscheidet über den Stand, den er gesehen hat – nicht über einen abstrakten Dauerzustand. Hat sich die zugrunde liegende Revision inzwischen geändert, wird die veraltete Entscheidung abgelehnt. Das verhindert Freigaben, die nicht mehr zur aktuellen Quellrevision gehören.

Ebenso klar ist die zweite Grenze: WatchKit schreibt vorgeschlagene Reparaturen nie selbst in das beobachtete Ziel. Es kann eine Abweichung belegen. Die Änderung am überwachten System bleibt außerhalb seiner Beobachtungsdomäne.

Für die Wissensfrage folgt daraus etwas Wichtiges: Selbst eine im Cockpit bestätigte Entscheidung ist noch keine dauerhafte Produktaussage. Sie ist eine dokumentierte Entscheidung über genau den revisionsgebundenen Befund, den jemand gesehen hat – nicht über einen Zustand, der ab jetzt allgemein gilt.

Warum Kopieren keine Wissensübernahme ist

Der einzelne Befund bleibt an drei Dinge gebunden: das Ziel, die Messung und den Zeitpunkt. Ein Endpunkt, der zu einem Prüfzeitpunkt kein JSON lieferte, kann eine Stunde später korrekt antworten. Eine Entscheidungsregel, die für einen Pfad passt, kann für einen benachbarten Pfad zu streng sein. Ein Verhalten, das für ein Produkt belegt ist, sagt nichts über andere Produkte derselben Umgebung.

Die falsche Behauptung, die hier vermieden werden muss, lautet: „Das Produkt liefert keine Nutzungsdaten.“ Die belegbare Aussage lautet enger: „Dieser Pfad lieferte zu diesem Zeitpunkt unter dieser Regel keinen verwertbaren Inhalt, und hier ist der Antwortauszug.“ Wer aus dieser engen Beobachtung die weite Produktaussage macht, verallgemeinert über den Beleg hinaus. Der so erzeugte Claim hält einer Quellenprüfung nicht stand.

Deshalb ist die Grenze zwischen den beiden Produkten keine organisatorische Bequemlichkeit, sondern eine fachliche Notwendigkeit. WatchKit entscheidet nicht, welche Aussage dauerhaft in eine Wissensbasis gehört. Es kann diese Entscheidung gar nicht treffen, weil sie Informationen verlangt, die außerhalb der Beobachtung liegen: Ist die Einschränkung beabsichtigt? Gibt es eine Entscheidung, die sie erklärt? Widerspricht der Befund einer bereits freigegebenen Aussage? Umgekehrt ersetzt WikiKit keine laufende Beobachtung. Ein freigegebener Claim kann unbemerkt veralten, wenn niemand mehr prüft, ob er noch stimmt.

Bedingungen einer Wissensübernahme

Wenn ein Befund den Weg in die Wissensbasis antreten soll, sind vier Punkte zu prüfen.

Erstens die Quelle. Bei einer Übergabe wird der Befund mit seinen Belegen – Pfad, Statuscode, Inhaltstyp, Regel, Antwortauszug – als unverändertes Dokument übergeben, nicht als bereits interpretierte Zusammenfassung. Nur so kann eine spätere Prüfung gegen genau das Material laufen, das die Beobachtung getragen hat.

Zweitens ist zu prüfen, ob der Befund einmalig war oder wiederkehrt. Diese Information hilft bei der Einordnung, ist aber keine zwingende Voraussetzung für jede Wissensübernahme. Für die Übergabe sollte jede erneute Beobachtung als eigene Quelle mit eigener Revision erhalten bleiben. Der hier vorgeschlagene Ablauf setzt keine feste Schwelle, ab wie vielen Wiederholungen ein Befund „zählt“; das ist eine fachliche Entscheidung pro Ziel und Kontext, keine Konstante des Werkzeugs.

Drittens die Einordnung. Zwischen Beobachtung und dauerhafter Aussage steht die Frage nach dem Geltungsbereich: welches Produkt, welcher Pfad, für welchen beobachteten Zeitpunkt, mit welcher Erklärung. Diese Einordnung kann ein Befund auslösen, aber nicht selbst liefern. Häufig braucht sie eine zweite Quelle – etwa die Produktdokumentation oder eine dokumentierte Entscheidung –, die die Ursache trägt, während der Befund das Auftreten belegt.

Viertens die bewusste menschliche Freigabe. Sie ist kein Abnicken am Ende, sondern der Punkt, an dem jemand Verantwortung für die verallgemeinerte Aussage übernimmt. Sichtbar wird die Änderung erst nach menschlicher Freigabe des ChangeProposal.

WikiKit: von der unveränderten Quelle zum ChangeProposal

Auf der anderen Seite der Grenze übernimmt WikiKit das übergebene Material zunächst als unveränderte Quelle. Es normalisiert den Inhalt nicht nachträglich und ersetzt ihn nicht durch eine Zusammenfassung. Aus der Quelle können anschließend einzelne Claims entstehen – und hier greift die zweite Sicherung: WikiKit behält nur Claims, deren Beleg wörtlich in der archivierten Quelle auffindbar ist. Ein vermeintliches Zitat, das im übergebenen Befund nicht vorkommt, scheitert an dieser Prüfung.

Die mögliche Wissensänderung selbst liegt als ChangeProposal getrennt vom sichtbaren Wissen. Für normale Leser bleibt der Vorschlag unsichtbar. Erst wenn ein Mensch das ChangeProposal freigibt, wird die Änderung sichtbares Wissen. Es gibt keinen Pfad, auf dem ein Befund diese Prüfung umgeht – keine automatische Promotion, keine Sichtbarkeit ohne Review.

Die Produktgrenzen bestimmen damit den möglichen Integrationsweg: WatchKit hält die Beobachtung mit Belegen und der revisionsgebundenen Cockpit-Entscheidung fest. Für eine Übergabe müssten Quelle und Wiederholungen erhalten bleiben; Einordnung und Freigabe erfolgen anschließend in WikiKit. Ein direkter Übergabevertrag zwischen beiden Produkten wird hier nicht vorausgesetzt.

Review prüft Geltungsbereich, nicht nur Wahrheit

Die prüfende Person beantwortet im Review andere Fragen als die Entscheidungsregel in WatchKit. Dort ging es um die Entscheidung über einen konkreten, revisionsgebundenen Befund. Hier geht es um die Frage, was genau daraus dauerhaft behauptet werden darf. Der Claim muss Subjekt, beobachtetes Verhalten und Zeitraum auf den Beleg begrenzen, statt eine Produkteigenschaft zu verkünden.

Ein neuer Befund kann einer bereits freigegebenen Aussage widersprechen. Auch dieser Widerspruch erreicht die Wissensbasis nur auf dem belegten Weg: als ChangeProposal, das erst nach menschlicher Freigabe sichtbar wird. Ob eine neue Aussage die alte ablöst, ob die Subjekte enger gefasst werden oder ob der Konflikt offen bleibt, ist damit eine Review-Entscheidung und kein Automatismus. Als Anforderung an diesen Review formuliert: Die abgelöste Aussage sollte nachvollziehbar bleiben, weil sie erklärt, unter welchen Annahmen frühere Entscheidungen fielen.

Auch hier liefert die Beobachtung den Anstoß, aber nicht das Urteil. Ein neuer Befund kann belegen, dass ein Verhalten nicht mehr dem entspricht, was ein freigegebener Claim beschreibt. Ob der Claim deshalb überholt ist oder ob die neue Beobachtung ein Sonderfall war, entscheidet der Review anhand der Quellen.

Die Grenze wirkt in beide Richtungen

Eine freigegebene Aussage in WikiKit beendet die Beobachtung nicht. Der Claim beschreibt einen geprüften Stand; ob das beobachtete Laufzeitverhalten noch gilt, zeigt eine erneute Messung. Ein späterer Befund kann der Anlass sein, den Claim erneut zu prüfen. Claims über beobachtbares Laufzeitverhalten können ohne erneute Messung unbemerkt veralten.

Umgekehrt bleibt das Befund-Archiv ohne Kuration ein wachsender Bestand zeitgebundener Einzelaussagen. Man kann darin suchen, aber jede wiederkehrende Frage müsste erneut aus Rohbeobachtungen beantwortet werden. Erst der kuratierte Claim mit Quelle, Beleg und Freigabe macht die Antwort wiederverwendbar: Wer sie später liest, kann den Weg zurückgehen – von der Aussage über das Zitat bis zum ursprünglichen Befund mit Pfad, Statuscode und Antwortauszug.

Beide Produkte lösen also je ein Problem, das das andere bewusst nicht löst. Das ist kein Mangel an Integration, sondern ihre Voraussetzung. Eine Integration, die die Grenze einebnet, würde unbelegte Claims sichtbar machen oder veraltete Claims an die Stelle erneuter Messungen setzen.

Die Konsequenz: Befunde dürfen abgelehnt werden

Die praktischen Folgen dieser Architektur sind unterschiedliche Aufnahmebedingungen: Das Befund-Archiv kann mit jeder archivierten Prüfung wachsen; sichtbares Wissen in WikiKit entsteht dagegen nur nach einer Freigabe. Ohne auffälligen Befund endet der Lauf bei der Beobachtung. Ohne fachliche Einordnung bleibt ein Änderungsvorschlag offen oder wird begründet abgelehnt. Erst ein belegter, eingeordneter und bewusst freigegebener Sachverhalt wird zur dauerhaften Aussage. Die Möglichkeit zum Nicht-Übernehmen ist dabei kein Reibungsverlust, sondern der Mechanismus, der die Wissensbasis vor einem Bestand ungeprüfter Behauptungen schützt.

Dieses Ungleichgewicht ist beabsichtigt: Es hält die Menge dessen klein, wofür jemand Verantwortung übernommen hat – und macht genau diese Menge verlässlich. Wer die Grenze zwischen WatchKit und WikiKit ziehen will, zieht sie am besten dort, wo aus „das haben wir beobachtet“ ein „das gilt“ werden soll. Diesen Schritt macht kein Werkzeug. Ihn macht ein Mensch, mit Quelle, Wiederholung und Einordnung vor Augen.

Weiterführende Quellen

Wie fandest du diesen Beitrag?

Kommentare