Wissensbasen sichtbar machen

Diesen Beitrag anhören (15 Min.)

Eine Wissensbasis und ihre Darstellung sind zwei verschiedene Dinge. In der Wissensbasis entstehen Aussagen, Zuständigkeiten und Regeln. Dort wird entschieden, welche Version gilt und wer sie ändern darf. Contentkit übernimmt einen späteren Abschnitt: Es macht einen freigegebenen Stand als Website sichtbar – mit Hierarchie, Navigation, Suche, Zugriffsregeln und maschinenlesbaren Ausgaben.

Teil 3 der Serie „Contentkit – Publishing für Maschinen“.

Diese Unterscheidung verhindert eine falsche Erwartung. Contentkit kuratiert keine Wissensbestände. Es ersetzt weder die fachlichen Besitzer noch den Prozess, in dem Rohdaten zu verlässlichem Wissen werden. Ein Agent kann beim Zusammenführen und Formulieren helfen, doch die Herkunft und Gültigkeit bleiben Aufgaben des führenden Systems. Contentkit ist die kontrollierte Veröffentlichungsschicht.

Wissen hat vor der Website eine Heimat

In einem Supportbereich können die verbindlichen Informationen an mehreren Stellen entstehen. Produktgrenzen stehen im Quellcode und in der Spezifikation. Bekannte Fehler kommen aus dem Ticketsystem. Freigegebene Arbeitsanweisungen liegen in einem internen Repository. Verträge und Servicezusagen stammen aus einem weiteren Fachsystem.

Eine Website sollte diese Quellen nicht heimlich zur neuen Wahrheit erklären. Sonst entstehen zwei konkurrierende Stände: die fachliche Quelle und der Text, den jemand zuletzt im CMS-Editor geändert hat. Contentkit vermeidet diesen Rückkanal, weil die Veröffentlichung als expliziter Übergang gestaltet ist.

Fachquellen · Spezifikation, Vorfälle und Betriebsregeln bleiben führend
Wissensprozess · prüft Aussagen und gibt einen gemeinsamen Stand frei
Markdown-Stand · trägt Identität, Sprache, Hierarchie und Zugriffsregeln
ContentKit · validiert, komponiert und veröffentlicht den freigegebenen Stand
Dokumentation · erklärt Aufgaben und Zusammenhänge
Hilfeportal · beantwortet konkrete Anwenderfragen
Maschinenzugriff · stellt JSON, Markdown und LLM-Dateien bereit

Der Markdown-Stand ist dabei kein namenloser Export. Er trägt Identität, Sprache, Hierarchie und bei Bedarf Zugriffsregeln. Contentkit prüft, ob daraus ein konsistenter Website-Stand gebaut werden kann.

Drei Darstellungen für unterschiedliche Fragen

Contentkit kennt kontrollierte Site-Presets. Für Wissensbestände sind besonders product-docs, wiki und knowledge-base interessant. Sie verwenden denselben sicheren Markdown-Renderer und denselben Release-Prozess, ordnen Inhalte aber unterschiedlich an.

Produktdokumentation beantwortet die Frage: Wie benutze oder betreibe ich eine bestimmte Version eines Produkts? Sie kennt aktuelle und archivierte Versionen, hierarchische Seiten, Breadcrumbs und ein Inhaltsverzeichnis aus den Überschriften.

Ein Wiki beantwortet eher: Wie arbeitet dieses Team oder dieses System? Hier zählt die gemeinsame Hierarchie, nicht eine Produktversion. Ein Hilfeportal bündelt hingegen konkrete Anliegen von Anwendern – Fehler beheben, Konto ändern, Release zurücknehmen – und kann Inhalte nach Kategorien ordnen.

{
  "presentation": {
    "preset": "product-docs",
    "docs": {
      "versions": [
        { "id": "v2", "label": "2.x", "status": "current" },
        { "id": "v1", "label": "1.x", "status": "archived" }
      ]
    }
  }
}

Eine archivierte Dokumentationsversion bleibt erreichbar, erhält aber noindex,follow und erscheint nicht in der Sitemap. Damit kann ein Kunde mit einem alten Produktstand weiterhin die passende Anleitung öffnen, während Suchmaschinen bevorzugt die aktuelle Fassung finden.

Hierarchie ist ein geprüfter Inhaltsgraph

Eine Ordnerstruktur allein reicht für eine belastbare Navigation nicht aus. Contentkit verwendet deshalb stabile fachliche Kennungen im Frontmatter. docKey identifiziert eine Seite innerhalb einer Version und Sprache, parent verweist auf die Elternseite, navTitle kann einen kurzen Navigationsnamen tragen und navOrder bestimmt die Reihenfolge.

---
kind: page
layout: docs
title: Verify the installation
locale: en
slug: verify-installation
translationKey: atlas-verify-installation-v2
docKey: installation-check
docsVersion: v2
parent: getting-started
navTitle: Verify installation
navOrder: 30
summary: Verify services, database and storage after installation.
---

Vor dem Release löst Contentkit diese Angaben als Inhaltsgraph auf. Eine fehlende Elternseite, ein Zyklus, eine unbekannte Version, eine doppelte Kennung oder eine doppelt erzeugte URL stoppt den Build. Der aktive Website-Stand bleibt unverändert.

Diese Prüfung ist für Agenten wesentlich. Ein Sprachmodell kann bei einer großen Umstrukturierung sehr schnell zwanzig Seiten verschieben. Es kann dabei ebenso schnell einen Elternverweis übersehen. Statt eine beschädigte Navigation zu veröffentlichen, erhält der Agent einen konkreten Fehler und kann die betroffene Revision korrigieren.

Praxisbeispiel: Hilfe nach einem Produktupdate

Ein Hersteller liefert eine neue Version eines Geräts samt Verwaltungssoftware aus. Nach dem Update häufen sich drei Fragen: Wie wird die neue Verbindung eingerichtet? Wo findet man die geänderte Statusanzeige? Wie setzt man bei einem fehlgeschlagenen Update auf den letzten Stand zurück?

Die Antworten entstehen nicht in Contentkit. Die Verbindungsparameter kommen aus der Produktspezifikation, die Anzeige aus dem ausgelieferten Frontend und der Rücksetzvorgang aus dem freigegebenen Runbook. Ein Agent sammelt die bestätigten Ausschnitte, erzeugt daraus drei Markdown-Seiten und versieht sie mit der richtigen Hierarchie. Contentkit baut ein Hilfeportal daraus.

Für den Anwender entsteht ein zusammenhängender Weg statt einer Sammlung interner Dokumente. Die Seite zur Einrichtung verlinkt auf die Statusanzeige, die Fehlersuche führt zum Rücksetzvorgang, Breadcrumbs zeigen den fachlichen Zusammenhang. Dieselben Inhalte sind über die statische Suche auffindbar. Auf Wunsch kann die Betriebsanleitung nur für angemeldete Kunden sichtbar sein.

Der Nutzen liegt nicht allein in schönerem HTML. Die veröffentlichte Struktur ist reproduzierbar. Wird die Version später archiviert, bleibt genau der damalige Stand unter seiner Versionsroute erreichbar. Ein neuer Agent kann die freigegebenen Seiten über Markdown oder JSON lesen, ohne das Ticketsystem und die interne Spezifikation erneut zusammenführen zu müssen.

Visualisierung heißt mehr als Seitenlayout

Contentkit leitet aus dem freigegebenen Bestand mehrere Darstellungen ab. Aus der Hierarchie entstehen Seitennavigation, Breadcrumbs und Inhaltsverzeichnisse. Aus Tags entstehen Übersichten und verwandte Artikel. Aus Sprachvarianten entstehen alternative Links. Aus Sichtbarkeitsregeln entstehen öffentliche und geschützte Such- sowie Navigationsbestände.

Mit semantischer visueller Komposition kommt eine weitere Projektion hinzu. Ein Wissensbaustein kann ausdrücklich als Prozess, Vergleich, Timeline, Hierarchie, Beziehung, Kennzahl oder Datentabelle beschrieben werden. Der Inhalt behauptet damit eine Bedeutung, aber noch keine Pixel. Eine Narrative hält fest, welche Frage der Leser beantworten soll, welche Aussage zentral ist und welche Belege danach folgen. Contentkit wählt erst anschließend ein kompatibles Information Pattern und löst es für den tatsächlichen Container auf.

Ein gerichteter Prozess bleibt im SVG frei von Review-Metadaten; die Beispielseite erklärt außerhalb, welche Frage und Semantik das Pattern trägt

Das ist für Wissensseiten mehr als grafischer Schmuck. Eine Installationsfolge muss eine eindeutige Reihenfolge behalten. Ein Architekturüberblick muss Zentrum, Ebenen oder Abhängigkeiten ehrlich benennen. Eine Timeline darf nicht so aussehen, als sei sie ein wiederkehrender Zyklus. Die Registry beschreibt diese Aussagen samt Ausschlussregeln, Inhaltsbudgets und responsiven Fallbacks. Ein Agent kann dadurch begründen, weshalb eine Darstellung geeignet ist, statt nur ein hübsches Muster auszuwählen.

Damit wird eine Wissensbasis für unterschiedliche Abnehmer sichtbar:

Leser bewegen sich über Dokumentationsstruktur, Suche und direkte Links.
Support-Mitarbeiter finden ein freigegebenes Verfahren statt eines zufälligen Ticket-Kommentars.
Agenten lesen Markdown-Zwillinge, llms.txt, llms-full.txt oder die geschützte JSON-API.
Nachgelagerte Systeme reagieren auf signierte Veröffentlichungsereignisse.

Wichtig ist die gemeinsame Herkunft. HTML, Suchindex und Maschinenformat werden nicht getrennt gepflegt. Sie entstehen im selben Release aus denselben Revisionen. Das verringert die Gefahr, dass der sichtbare Hilfetext etwas anderes behauptet als der maschinenlesbare Stand.

Preset und Layout sind nicht dasselbe

Das Preset legt die grundlegende Informationsarchitektur der Website fest. Eine einzelne Seite kann zusätzlich ein kontrolliertes Layout wählen: standard, docs, wiki, knowledge, landing, changelog oder composition; report bleibt als kompatibler Name für Report-Kompositionen erhalten. Eine Dokumentationswebsite kann daher eine gewöhnliche Impressumsseite enthalten, ohne dafür ein zweites System zu benötigen.

---
kind: page
layout: standard
title: Legal notice
locale: en
slug: legal-notice
translationKey: legal-notice
summary: Legal information for the product documentation.
---

Diese Auswahl verweist nicht auf eine hochgeladene Template-Datei. Contentkit besitzt die erlaubten Layouts und erzeugt daraus einen bekannten DOM-Aufbau. Autoren und Agenten wählen eine Variante, führen aber keinen eigenen Code aus. Dadurch bleiben Vorschau, Content Security Policy, Barrierefreiheit und Release-Verhalten über alle Darstellungen gleich.

Warum das für LLM-Agenten nützlich ist

Ein Agent braucht zwei Dinge, die in gewachsenen Wikis oft fehlen: eine erkennbare Struktur und einen vertrauenswürdigen Stand. Contentkit liefert beides auf der Veröffentlichungsseite. Der Inhaltsgraph macht Beziehungen ausdrücklich. Der Release benennt, welche Revisionen gemeinsam gelten.

Für visuelle Inhalte kommt ein dritter Punkt hinzu: der Agent braucht einen Vertrag für die passende Erzählform. Über die öffentlichen Pattern- und Publishing-Guide-Endpunkte kann er Fragen, Story Arc, benötigte Evidenz, Ablehnungsgründe und positive Beispiele lesen. Die Kompositions-API empfiehlt passende Muster, validiert Inhaltslängen, Einheiten und Zeitangaben und meldet eine responsive Ersetzung ausdrücklich zurück. Ein still abgeschnittenes Label ist kein Erfolg.

Das vereinfacht zum Beispiel die Beantwortung einer Supportfrage. Ein Agent kann zuerst im veröffentlichten deutschen Hilfeportal suchen, die gefundene Seite als Markdown abrufen und ihre Version sowie Metadaten prüfen. Er muss nicht aus zehn bearbeitbaren Wiki-Ständen erraten, welche Anleitung freigegeben wurde. Geschützte Seiten bleiben nur mit einem passenden Leseschlüssel oder einer Lesersitzung erreichbar.

Der Agent wird dadurch nicht zum fachlichen Besitzer. Er erhält lediglich eine bessere, kontrollierte Projektion. Wenn die Quellregeln falsch sind, veröffentlicht Contentkit sie zuverlässig falsch. Die Qualität beginnt weiterhin beim Wissensprozess vor dem CMS. Contentkit sorgt dafür, dass der freigegebene Stand vollständig, auffindbar und für verschiedene Abnehmer gleich dargestellt wird.

Wo die Grenze bewusst verläuft

Contentkit enthält keinen Schema-Builder für beliebige Wissensobjekte und keine Oberfläche für kollaborative Rohnotizen. Es besitzt auch keine Logik, die aus widersprüchlichen Quellen selbstständig Wahrheit erzeugt. Wer eine Produktregel freigibt, bleibt eine organisatorische Entscheidung.

Diese Begrenzung hält das System überschaubar. Eine spezielle Sammlung kann als kind: post mit eigenem Tag und strukturierten Zusatzfeldern erscheinen. Einmalige Inhalte werden Seiten. Für komplizierte fachliche Modelle bleibt das führende System zuständig; Contentkit übernimmt die verständliche, statische Darstellung des freigegebenen Ausschnitts.

Das ist gerade bei KI sinnvoll. Modelle verführen dazu, jeden Schritt in einen großen Agenten zu legen. Sauberer ist die Teilung: Fachsysteme und verantwortliche Prozesse entscheiden, was gilt. Agenten übersetzen den freigegebenen Stand in portable Dokumente. Contentkit prüft und veröffentlicht die Darstellung. Jede Stufe hat einen klaren Auftrag.

Mehrsprachigkeit ist eine weitere Projektion

Eine Übersetzung ist nicht nur derselbe Text mit anderen Wörtern. Produktbegriffe, Links und verfügbare Versionen können sich je Sprache unterscheiden. Contentkit identifiziert zusammengehörige Varianten über translationKey, erzeugt locale-spezifische Routen und setzt alternative Sprachlinks. Der Release prüft den gesamten Stand, statt Sprachvarianten unabhängig voneinander auszuliefern.

Ein Übersetzungsagent kann die freigegebene deutsche Seite als Quelle verwenden, eine englische Revision vorschlagen und technische Begriffe gegen das Produktglossar prüfen. Die englische Seite bleibt ein eigener Inhalt mit eigener Revisions-ID. Wird nur die deutsche Fassung korrigiert, behauptet Contentkit nicht, die englische sei automatisch ebenfalls aktuell.

---
kind: page
layout: knowledge
title: How do I roll back a release?
locale: en
slug: rollback
translationKey: kb-rollback
docKey: rollback
category: Publishing
summary: Activate a known release without running another build.
---

Für Anwender entsteht eine klare Sprachwahl mit kanonischen URLs. Für Agenten bleibt sichtbar, welche Sprachfassung tatsächlich veröffentlicht ist. Das ist zuverlässiger als eine Laufzeitübersetzung, deren Wortlaut sich bei jedem Aufruf ändern kann.

Wissen sichtbar zu halten ist ein Prozess

Eine gute Visualisierung kann veraltetes Wissen sehr überzeugend aussehen lassen. Deshalb sollte der vorgelagerte Wissensprozess Gültigkeit und Prüfdatum liefern. Contentkit zeigt bei Posts standardmäßig einen Hinweis, wenn sie älter als drei Jahre sind; für fachliche Anleitungen kann ein strukturierter Prüfzeitpunkt unter extra einen engeren Rhythmus unterstützen.

Ein Prüfagent kann regelmäßig die Headless-Liste lesen, nach Metadaten sortieren und einen Bericht über überfällige Bestätigungen erzeugen. Er ändert die Seiten nicht selbstständig, sondern gibt den fachlichen Besitzern eine konkrete Liste. Nach der Prüfung entsteht eine neue Revision – auch dann, wenn der Text unverändert bleibt, aber die Quellen erneut bestätigt wurden.

So wird Contentkit nicht zum Kurator, unterstützt aber den Nachweis der Kuration. Es veröffentlicht den Stand, auf den sich Menschen und Maschinen beziehen, und liefert die Kennungen für einen späteren Abgleich mit dem führenden Wissensprozess.

Die Darstellung vom Anwender her wählen

Die Preset-Wahl sollte nicht vom Namen des internen Quellsystems abhängen. Ein Confluence-Bereich wird nicht automatisch zum Wiki, und ein Ticketbestand nicht automatisch zur Knowledge Base. Entscheidend ist die Aufgabe auf der veröffentlichten Seite.

Wer ein Produkt in einer konkreten Version installiert, braucht eine geführte Dokumentationshierarchie. Wer eine einzelne Störung beheben möchte, profitiert von einer kurzen Hilfeportal-Seite mit Kategorie und klarer Antwort. Wer den gemeinsamen Release-Prozess eines Teams nachschlägt, findet ihn in einer Wiki-Struktur. Derselbe bestätigte Wissensbaustein kann in mehreren Ausgaben vorkommen, sollte aber nicht durch Copy-and-paste auseinanderlaufen. Ein vorgelagerter Generator kann aus einer gemeinsamen Quelle passende Markdown-Dokumente erzeugen und ihre Herkunft unter extra festhalten.

Ein Agent kann bei der Zuordnung helfen, indem er Suchanlässe und Zielgruppen analysiert. Die Entscheidung bleibt fachlich: Welche Frage soll ein Anwender an dieser Stelle beantworten können? Contentkit setzt die gewählte Struktur anschließend konsequent in Route, Navigation und Suche um.

Fazit

Contentkit ist keine kuratierte Wissensbasis. Es ist die Visualisierung und Veröffentlichungsschicht für Wissensstände, die an anderer Stelle geführt und freigegeben werden. Produktdokumentation, Wiki und Hilfeportal sind verschiedene Sichten auf diese Aufgabe, nicht verschiedene Wahrheiten.

Für Anwender entstehen auffindbare, versionierte und bei Bedarf geschützte Wege durch das Wissen. Für Agenten entstehen klare Hierarchien und maschinenlesbare Ausgaben. Weil alle Darstellungen aus demselben Release stammen, bleiben menschliche und maschinelle Sicht auf demselben Stand.

Weiterführende Quellen

Wie fandest du diesen Beitrag?

Kommentare