Wissen bleibt exportierbar

Diesen Beitrag anhören (10 Min.)

Ein Datenbankdump bildet den internen Zustand eines Systems ab. Für Menschen, Git oder ein anderes Wissenswerkzeug ist er jedoch kein brauchbares Übergabeformat. Dafür braucht es eine lesbare Projektion, in der Claims, Zitate, Beziehungen, Quellen und Entscheidungen erhalten bleiben.

Stand August 2026 zieht WikiKit im geprüften Repository hier eine klare Architekturgrenze. PostgreSQL bleibt die Quelle der Wahrheit für den laufenden Zustand. Der Markdown-Baum und das OKF-Bundle sind lesbare Projektionen, aber nicht die Quelle der Wahrheit. Beide Exporte werden deterministisch erzeugt. Ein Import wird im Ziel als Änderungsvorschlag behandelt und durchläuft denselben menschlichen Review wie andere Wissensänderungen.

Für Menschen bietet das Cockpit einen Zugang zum Export. Diese Architektur hängt nicht von einer bestimmten Klickfolge oder Oberfläche ab.

Der Markdown-Baum bleibt ohne WikiKit lesbar

WikiKit exportiert einen Space als deterministisches ZIP mit einem Obsidian-freundlichen Markdown-Baum. Die Dateien lassen sich mit üblichen Text- und Markdown-Werkzeugen öffnen, in Git vergleichen oder in Obsidian verwenden. Dafür muss keine laufende WikiKit-Instanz verfügbar sein.

Ein Space wird als ZIP mit einer festen Verzeichnisstruktur ausgegeben. Konzepte, Entscheidungen und Quellen liegen als Markdown vor. Index und Log erleichtern die Orientierung:

index.md
log.md
concepts/<slug>.md
decisions/<slug>.md
sources/<content-hash>.md

Der Export transportiert nicht nur Seitentext. Claims, Zitate, Beziehungen, Quellen und Entscheidungen bleiben Teil der Markdown-Projektion. Ein rein darstellender Export würde diese Zusammenhänge auf sichtbaren Text reduzieren und damit einen wesentlichen Teil des Wissensmodells ausblenden.

flowchart LR
    P["PostgreSQL<br/>freigegebener Space"] --> E["deterministischer Export"]
    E --> M["Markdown-Baum<br/>für Mensch und Git"]
    E --> O["OKF-Bundle<br/>für offenen Austausch"]
    M --> I["Import<br/>neuer Änderungsvorschlag"]
    O --> I

Struktur bleibt Teil der Projektion

Lesbarer Fließtext allein reicht für einen portablen Wissensbestand nicht aus. Ein Claim muss weiterhin mit seinen Belegen und Quellen verbunden sein. Beziehungen zwischen Konzepten und die dokumentierte Entscheidungsgeschichte dürfen beim Export nicht zu unverbundenen Textabschnitten werden.

Der Markdown-Baum hält diese Elemente lesbar und für einen späteren Import auswertbar. Er ersetzt weder das interne Datenmodell noch PostgreSQL, sondern bildet den freigegebenen fachlichen Stand für Übergabe, Prüfung und Weiterverarbeitung ab.

Der Markdown-Export legt die strukturierten Angaben zu Claims, Belegen und Beziehungen in YAML-Frontmatter ab. Dort bleiben Claim, zugehörige Citation und Relation miteinander verbunden, während der eigentliche Inhalt weiterhin als lesbares Markdown vorliegt.

Ein Markdown-Werkzeug kann die Dokumente lesen und versionieren, ohne das vollständige WikiKit-Modell implementieren zu müssen. Ein WikiKit-Import kann die enthaltenen Wissenselemente wieder als Änderungsvorschlag aufnehmen.

Determinismus macht Exporte vergleichbar

Identisches freigegebenes Wissen erzeugt am geprüften Stand für Markdown und OKF bytegleiche ZIP-Dateien. Diese Eigenschaft macht wiederholte Ausgaben vergleichbar.

Die Repository-Tests exportieren denselben Fixture-Stand zweimal und vergleichen die ZIP-Dateien byteweise – für Markdown und OKF. Ohne fachliche Änderung darf sich die erzeugte Projektion nicht ändern.

Determinismus erleichtert damit die Prüfung in Git, in einem Archiv oder vor einem Import. Ändert sich der fachliche Bestand, bleibt die Änderung im Export vergleichbar. Die Aussage betrifft das erzeugte Bundle; sie macht den Export nicht selbst zur Quelle der Wahrheit.

OKF bildet eine zweite Austauschgrenze

Neben dem Markdown-Baum kann WikiKit einen Space als OKF-Bundle exportieren. OKF dient als offener Austauschvertrag für Systeme, die dieses Format unterstützen.

Markdown und OKF sind zwei Projektionen desselben freigegebenen Stands. Sie müssen weder dieselben Dateipfade besitzen noch intern dasselbe Modell voraussetzen. Der Markdown-Export erhält Claims, Zitate, Beziehungen, Quellen und Entscheidungen. OKF bildet davon ab, was sein Formatvertrag vorsieht.

OKF setzt weder gemeinsame Tabellen noch gemeinsame Freigabemechanismen voraus. Das Bundle schafft eine gemeinsame Übergabeform, ohne die beteiligten Systeme an eine gemeinsame Datenbank zu koppeln.

Die Wahl hängt vom Empfänger ab. Für Menschen, Git oder Obsidian liegt der Markdown-Baum nahe. Für den Austausch mit einem System, das OKF verarbeitet, steht das OKF-Bundle zur Verfügung.

Import bleibt ein Reviewvorgang

Ein importiertes Bundle erhält keine Sonderstellung. WikiKit behandelt den Import als normalen Änderungsvorschlag. Damit durchläuft er denselben menschlichen Review wie andere Änderungen am Wissensbestand.

Erst die fachliche Freigabe übernimmt die vorgeschlagenen Inhalte in den kuratierten Zustand. Der Import überschreibt deshalb keine freigegebenen Inhalte ohne Review. Das gilt unabhängig davon, ob das Bundle aus einer anderen Instanz, einem Repository oder einer manuellen Bearbeitung stammt.

Wissen kann das System verlassen und wieder hineingelangen, ohne dass der Rückweg die Verantwortlichkeit des Ziel-Spaces umgeht.

Export ist etwas anderes als Backup

Der Export bildet einen portablen fachlichen Stand ab. PostgreSQL bleibt dagegen die Quelle der Wahrheit für den laufenden Betrieb. Ein Markdown- oder OKF-Bundle allein stellt daher nicht den vollständigen Betriebszustand einer WikiKit-Installation wieder her.

Für einen Anbieterwechsel, eine externe Prüfung oder die Übergabe an ein anderes Wissenswerkzeug ist die lesbare Projektion entscheidend. Für die Wiederherstellung derselben laufenden Installation muss die betriebliche Sicherung an der Quelle der Wahrheit ansetzen. Der genaue Umfang hängt von der jeweiligen Installation ab.

Exporttest und Restore-Test beantworten damit unterschiedliche Fragen. Der Exporttest prüft, ob der fachliche Bestand lesbar und importierbar bleibt. Der Restore-Test betrifft die Wiederherstellung des betriebenen Systems.

Git als Projektion, PostgreSQL als Quelle der Wahrheit

Ein exportierter Markdown-Baum kann in Git versioniert werden. Das ermöglicht zusätzliche Diffs, externe Archivierung oder eine veröffentlichte Projektion. Der laufende WikiKit-Zustand bleibt trotzdem in PostgreSQL.

Direkte Änderungen an einer Git-Kopie werden deshalb nicht automatisch zum freigegebenen Wissensstand. Sollen sie zurück nach WikiKit gelangen, führt der Weg über Import und Review. So bleibt nachvollziehbar, welche Änderung vorgeschlagen und fachlich freigegeben wurde.

Git hält in diesem Modell einen transportierten Stand. Änderungen aus Git können den laufenden PostgreSQL-Zustand erst nach Import und fachlicher Freigabe ändern.

Eine Migration prüft die Übergabegrenze

Für eine Migration genügt es nicht, nur die Existenz eines ZIP-Downloads festzustellen.

ZIP öffnen und die erwarteten Pfade für Index, Log, Konzepte, Entscheidungen und Quellen prüfen.
Bundle in das Ziel importieren und den dabei erzeugten Vorschlag prüfen.
Erst nach fachlicher Freigabe die vorgeschlagenen Wissenselemente übernehmen.

Der Vergleich richtet sich auf die exportierten Wissenselemente. Interne Tabellen oder abgeleitete Funktionen des laufenden Systems sind nicht Teil dieser Projektion und deshalb kein geeigneter Maßstab für die Gleichheit der Bundles.

Der Import als Vorschlag verhindert zugleich, dass eine Migration ungeprüfte Inhalte sichtbar macht. Auch bei einem Systemwechsel bleibt die Freigabe eine Verantwortung des Ziel-Spaces.

Die Exportgrenze ist der Space

WikiKit exportiert jeweils einen Space. Damit bleibt die Projektion an dieselbe fachliche Grenze gebunden, innerhalb derer Claims, Quellen, Beziehungen und Entscheidungen verwaltet werden.

Wer mehrere Wissensdomänen übertragen will, muss diese Grenzen bewusst behandeln. Ein Export ist keine pauschale Abbildung der gesamten PostgreSQL-Instanz, sondern die portable Projektion eines ausgewählten Spaces.

Bezug zu früheren Artikeln

Markdown Reports statt Dashboard-Zwang beschreibt Markdown als diffbares und archivierbares Artefakt, das unabhängig von einer veränderlichen Live-Ansicht geprüft werden kann.

WikiKit überträgt diese Idee vom einzelnen Report auf eine Wissensdomäne. Konzepte, Claims, Zitate, Beziehungen, Quellen und Entscheidungen werden als deterministische Projektion exportiert. Übliche Markdown-Werkzeuge erhalten den lesbaren Zugang zum fachlichen Bestand.

Bei WikiKit kommt der reviewpflichtige Rückweg hinzu. Ein Wissensbundle kann in eine andere Instanz importiert werden, erzeugt dort aber erneut einen prüfbaren Änderungsvorschlag.

Werkzeuge, die zusammenspielen betont offene Formate statt gemeinsamer Datenbanken. Markdown, ZIP und OKF setzen diese Austauschgrenze um, ohne dass ein beteiligtes System die internen Tabellen des anderen kennen muss.

Den Ausgang durch einen Prüfimport absichern

Ein erfolgreicher Download belegt weder Lesbarkeit noch Importierbarkeit. Ein Prüfimport öffnet den Markdown-Export mit üblichen Werkzeugen und importiert das Bundle in einen temporären Ziel-Space. Dort muss der importierte Stand als Vorschlag sichtbar bleiben, bis der fachliche Review abgeschlossen ist.

Die Repository-Tests trennen zwei Nachweise. Der Markdown-Roundtrip serialisiert, parst und serialisiert einen Fixture-Stand erneut; das Ergebnis muss bytegleich sein und umfasst dabei strukturierte Claims, Zitate, Beziehungen, Entscheidungen und Quellen. Der Importtest prüft getrennt, dass Quellen übernommen, Zitate auf die neuen Quellen abgebildet und die Wissensänderungen als genau ein Vorschlag ins Review gestellt werden.

Weiterführende Quellen

Wie fandest du diesen Beitrag?

Kommentare