Eine Quelle, die gilt: Warum jedes Projekt eine Single Source of Truth braucht

In einem früheren Beitrag habe ich beschrieben, warum dieselbe Information an zwei Orten fast zwangsläufig auseinanderläuft. Die naheliegende Gegenfrage lautet: Wie baut man ein Wissenssystem, in dem Menschen und KI-Agenten tatsächlich mit dem gültigen Stand arbeiten?

Die kurze Antwort heißt Single Source of Truth, kurz SSoT: Für jede relevante Information ist eindeutig festgelegt, welche Quelle gilt. Alle anderen Dokumente verweisen darauf, verdichten sie für einen bestimmten Zweck oder werden daraus erzeugt.

Das klingt zunächst nach sauberer Ablage. Für die Arbeit mit KI ist es aber mehr: Es entscheidet darüber, ob ein Agent belastbar weiterarbeiten kann oder nur die erstbeste plausible Datei verwendet.

Eine SSoT ist keine Superdatei

Das häufigste Missverständnis ist die Vorstellung einer riesigen Masterdatei, in der alles über ein Projekt stehen muss. Eine solche Datei wird schnell unlesbar, veraltet und vermischt Dinge, die unterschiedliche Lebenszyklen haben.

Sinnvoller ist eine klar begrenzte Zuständigkeit je Wahrheitstyp. Ein Projekt kann zum Beispiel mehrere gültige Quellen besitzen:

• eine Einstiegsdatei erklärt Zweck, Struktur und verbindliche Verweise,
• eine Statusdatei beschreibt den aktuellen Stand,
• ein Entscheidungsregister hält fest, was warum beschlossen wurde,
• ein Aufgabenbestand enthält offene und abgeschlossene Arbeit,
• Research-Dateien sichern Quellen, Belege und offene Unsicherheiten.

Keine dieser Dateien ist die Wahrheit über alles. Jede ist aber die einzige gültige Quelle für ihre eigene Aufgabe. Genau diese Grenze macht das System verständlich.

Was sich für KI-Agenten dadurch ändert

Menschen können widersprüchliche Ordner manchmal noch aus Erfahrung deuten. Ein Agent sieht zunächst nur Dateien. Findet er Strategie.md, Strategie-neu.md und Strategie-final-v3.md, kann er nicht zuverlässig wissen, welche davon gilt. Das Änderungsdatum hilft nur bedingt: Die zuletzt bearbeitete Datei muss nicht die fachlich gültige sein.

Eine gute SSoT-Architektur beantwortet deshalb vor der eigentlichen Arbeit vier Fragen:

1. Wo beginnt der Agent?
2. Welche Quelle gilt für den gesuchten Sachverhalt?
3. Wie aktuell muss sie sein?
4. Wohin darf ein Ergebnis geschrieben werden?

Damit sinkt nicht nur die Fehlerquote. Auch der Kontext wird kleiner. Ein Agent muss nicht jedes Mal den gesamten Wissensbestand durchsuchen, sondern kann über eine kompakte Einstiegsdatei oder einen Index gezielt zu den relevanten Quellen navigieren. Das spart Rechenaufwand und verhindert, dass nebensächliche oder alte Dokumente die aktuelle Aufgabe überlagern.

Versionierung ohne final-v7

Eine SSoT ersetzt keine Versionsgeschichte. Sie trennt nur zwei Dinge, die oft vermischt werden:

• Der aktuelle Stand lebt an genau einem benannten Ort.
• Seine Entwicklung wird über eine Versionshistorie und dokumentierte Entscheidungen nachvollziehbar.

Wer einen früheren Zustand prüfen möchte, kann ihn in der Historie finden. Wer heute arbeiten möchte, braucht dafür keine Sammlung alter Dateikopien im aktiven Projekt. Archive bleiben als Beleg erhalten, sind aber keine gültigen Einstiegspunkte mehr.

Das reduziert Konflikte deutlich: Zwei Personen oder Agenten können weiterhin gleichzeitig Änderungen vorschlagen. Sie verhandeln diese Änderungen aber an derselben zuständigen Quelle, statt unbemerkt zwei konkurrierende Wahrheiten fortzuschreiben.

Widersprüche verschwinden nicht – sie werden prüfbar

Auch ein sauber aufgebautes System verhindert nicht jeden fachlichen Widerspruch. Neue Erkenntnisse können alte Annahmen widerlegen. Zwei Quellen können zu unterschiedlichen Schlüssen kommen. Ein Status kann hinter der Realität zurückliegen.

Die SSoT liefert dafür den notwendigen Bezugspunkt. Erst wenn feststeht, welche Quelle welchen Anspruch besitzt, lassen sich Abweichungen systematisch erkennen:

• Ein Dashboard kann gegen die zugrunde liegenden Daten geprüft werden.
• Eine Zusammenfassung kann auf veraltete Aussagen untersucht werden.
• Ein Agent kann melden, dass ein neuer Beleg dem gültigen Modell widerspricht.
• Ein Validator kann feststellen, dass eine erzeugte Übersicht nicht mehr mit ihrer Quelle übereinstimmt.

Die Architektur macht Widersprüche also nicht unmöglich. Sie macht sie sichtbar, zuordenbar und korrigierbar.

Dauerhaftes Wissen gehört nicht in den Chatverlauf

Die großen KI-Anbieter bauen eigene Erinnerungs- und Kontextfunktionen auf. Diese sind bequem: Ein Werkzeug kann Vorlieben wiedererkennen, frühere Gespräche heranziehen oder selbst Kontext sammeln. Für einen dauerhaft belastbaren Wissensbestand reichen sie trotzdem nicht aus.

Solche Erinnerungen sind meist an einen Anbieter gebunden. Welche Information gespeichert, verdichtet oder beim nächsten Auftrag tatsächlich geladen wird, ist nur begrenzt sichtbar. Eine fachliche Entscheidung lässt sich dort schwer versionieren, prüfen oder gezielt für ein anderes Werkzeug freigeben.

Deshalb behandle ich Werkzeug-Erinnerung als nützliche Unterstützung, nicht als Quelle der Wahrheit. Das dauerhafte Wissen liegt in eigenen, lesbaren und versionierten Dateien. Der Chat ist Arbeitsraum. Der eigene Wissensbestand ist Gedächtnis.

Diese Trennung reduziert die Abhängigkeit von einzelnen Modell- und Toolanbietern. Wenn ein Werkzeug wechselt, bleibt das Wissen bestehen. Nur der Zugang muss neu angeschlossen werden.

Werkzeuge austauschen, Wissen behalten

Ein gut strukturierter Wissensbestand kann von unterschiedlichen KI-Systemen genutzt werden: lokal arbeitenden Agenten, cloudbasierten Assistenten, Suchsystemen oder später einer eigenen Anwendung. Voraussetzung ist nicht, dass alle Werkzeuge gleich funktionieren. Sie brauchen aber denselben klaren Vertrag:

• offene, maschinenlesbare Formate,
• benannte Einstiegspunkte,
• eindeutige Zuständigkeiten,
• nachvollziehbare Verweise,
• Regeln für Aktualität und Schreibrechte.

Manche Werkzeuge lesen diese Struktur direkt, andere benötigen einen kleinen Adapter. Entscheidend ist: Der Adapter übersetzt den Zugang, er besitzt nicht das Wissen. So bleibt das Wissenssystem stabil, während Modelle, Oberflächen und Anbieter austauschbar werden.

Was nicht als SSoT funktioniert

Ein paar Muster sehen geordnet aus, lösen das Problem aber nicht:

• Eine riesige Masterdatei: Sie bündelt zu viele Zuständigkeiten und wird selbst zum Engpass.
• Mehrere gleichberechtigte Zusammenfassungen: Ohne klare Hierarchie ist weiterhin unklar, welche Aussage gilt.
• Ein manuell gepflegtes Dashboard: Es ist nur eine weitere Kopie, wenn es nicht aus den gültigen Quellen erzeugt wird.
• Nur eine Such- oder Vektordatenbank: Sie kann Inhalte auffindbar machen, ersetzt aber keine fachliche Autorität und keine lesbare Originalquelle.
• Ein Archiv im aktiven Suchraum: Alte Dokumente bleiben wichtig, dürfen aber nicht wie aktuelle Anweisungen behandelt werden.
• SSoT als bloße Beschriftung: Eine Datei wird nicht dadurch verlässlich, dass „Master“ im Namen steht. Zuständigkeit, Pflege und Prüfmechanismen müssen tatsächlich gelebt werden.

Ein einfacher Startpunkt

Für jeden Bereich, Wissensbestand oder jedes Projekt sollten fünf Fragen eindeutig beantwortet sein:

1. Welche Datei ist der Einstieg?
2. Wo steht der aktuelle Zustand?
3. Wo werden Entscheidungen mit ihrer Begründung festgehalten?
4. Wo liegen Belege und ursprüngliche Quellen?
5. Wo wird offene Arbeit gesteuert?

Wenn zwei Dateien dieselbe Frage gleichberechtigt beantworten, gibt es wahrscheinlich noch keine echte SSoT. Dann sollte nicht eine dritte Übersicht entstehen. Stattdessen braucht es eine Entscheidung: Welche Quelle gilt – und werden die anderen künftig daraus erzeugt, verweisen sie nur darauf oder gehören sie ins Archiv?

Eine belastbare Wissensarchitektur beginnt nicht mit mehr Dokumentation, sondern mit klarer Zuständigkeit. Für Menschen schafft das Orientierung. Für KI-Agenten schafft es einen Arbeitsvertrag. Und für wechselnde Werkzeuge schafft es Unabhängigkeit, weil das Wissen dort bleibt, wo es hingehört: im eigenen System.

Mehr zur praktischen Umsetzung steht auf der Seite zu KnowledgeOS. Der Beitrag „Zweimal aufgeschrieben ist einmal gelogen“ zeigt anhand zweier konkreter Fehler, was ohne diese Trennung passiert.