Spaces trennen Fachwissen

Diesen Beitrag anhören (10 Min.)

margin kann eine CSS-Eigenschaft sein, eine Handelsspanne oder ein Sicherheitsabstand. Eine gemeinsame Volltextsuche über den gesamten Bestand findet alle drei Bedeutungen. Ein Agent, der an einer Finanzplanung arbeitet, braucht genau eine davon – und sollte die beiden anderen nicht einmal sehen, wenn ihre Quellen vertraulich sind. Das ist kein Ranking-Problem, das ein besseres Scoring löst. Es fehlt eine Grenze.

WikiKit zieht diese Grenze mit Spaces: isolierte Wissensbasen innerhalb desselben Dienstes. Jeder Space besitzt eigene Konzepte, Quellen und Schlüssel, dazu eine Sprachkonfiguration und optional eine versionierte Charter. Der Space-Slug steht in den fachlichen API-Pfaden, die Berechtigung eines Schlüssels ist an ihn gebunden, und jede Space-bezogene Datenbankabfrage filtert nach seiner Identität. Stand 18. August 2026 gilt das im aktuellen Repository; die genannten Verträge stehen in docs/ARCHITECTURE.md und docs/CONTRACTS.md.

Der Space ist der fachliche Container

Der Space-Slug ist Teil der fachlichen API-Pfade, die dem Muster /v1/spaces/{space}/… folgen. Ein Client muss seinen Kontext dadurch ausdrücklich benennen. Ein versteckter globaler Suchmodus könnte sonst Ergebnisse aus mehreren Domänen mischen, ohne dass ein Aufrufer das je entschieden hätte.

flowchart TD
    W["eine WikiKit-Instanz"] --> E["Space engineering<br/>APIs · Architektur · Runbooks"]
    W --> F["Space finance<br/>Kennzahlen · Regeln · Entscheidungen"]
    W --> B["Space blog-de<br/>Schreibregeln · Veröffentlichungen"]
    E -. "keine Quersuche" .- F
    F -. "keine gemeinsamen Schlüssel" .- B

Die Trennung wird im Datenzugriff durchgesetzt, nicht allein durch den Slug im Pfad. HTTP oder MCP löst den Space einmal auf, prüft die Berechtigung des Principals und filtert danach jede Space-bezogene Abfrage nach space_id. Ein Space verhält sich deshalb nicht wie ein Namenspräfix, das eine spätere Query vergessen könnte: Der Filter ist Teil des Datenzugriffsvertrags, nicht eine Konvention im Anwendungscode einzelner Endpunkte.

Schlüssel binden Berechtigung an einen Bestand

Ein fachlicher Schlüssel gehört zu einem Space, nicht zur ganzen Instanz. Erst nachdem HTTP oder MCP den Space aufgelöst und die Berechtigung geprüft hat, laufen die nach space_id gefilterten Abfragen. Ein Schlüssel für engineering liest deshalb keine Finanzquelle und legt keinen Vorschlag in finance an. Schematisch kann so eine Bindung aussehen wie im folgenden Beispiel – die konkreten Feld- und Scope-Namen dienen hier nur der Illustration:

{
  "name": "engineering-coding-agent",
  "space": "engineering",
  "scopes": [
    "knowledge:read",
    "knowledge:propose"
  ]
}

Aktion und Bestand sind zwei verschiedene Fragen: Was darf ein Aufrufer tun, und auf welchen Bestand darf er es anwenden? Beide Prüfungen müssen erfolgreich sein, bevor fachliche Daten ausgegeben werden.

Charter und Sprache gehören zur Grenze

Ein Space trägt mehr als Daten und Schlüssel. Er kann eine menschlich gepflegte, versionierte Charter besitzen: eine Beschreibung dessen, worum es in diesem Bestand geht, was hineingehört und was nicht. Dazu kommt eine Sprachkonfiguration, die festlegt, in welcher Sprache der Space arbeitet.

Beide steuern spätere Synthesevorschläge, ohne deren Review zu umgehen. Ein Modell, das aus neuen Quellen Konzepte verdichtet, erhält Charter und Sprache als Rahmen – der Vorschlag bleibt trotzdem ein Vorschlag und wird erst durch eine menschliche Freigabe sichtbares Wissen. Die Charter ersetzt keine Prüfung. Sie sorgt dafür, dass Vorschläge von Anfang an im richtigen fachlichen Register formuliert sind, statt dass ein Reviewer denselben Stilhinweis in jeder Freigabe wiederholen muss.

Auch das Fachvokabular bleibt lokal. Ein universelles Vokabular über alle Domänen würde entweder sehr abstrakt oder voller Ausnahmen. Der owner eines Softwaredienstes kann eine Teamrolle sein; der owner eines Kontos eine andere Art von Subjekt. Spaces erlauben dieselben Wörter in ihrem jeweiligen Kontext, ohne beide in ein gemeinsames Schema zu pressen. Die Isolation löst dabei nicht jede Mehrdeutigkeit innerhalb eines Space – Konzepte brauchen weiterhin präzise Slugs, Subjekte und Quellen. Sie hält aber fachfremde Bedeutungen aus Suche und Synthese heraus.

Cockpit, HTTP und MCP müssen dieselbe Grenze durchsetzen

Eine Grenze, die nur ein Zugangsweg kennt, ist keine. Für HTTP und MCP ist der Vertrag belegt: Der Space wird einmal aufgelöst, die Berechtigung des Principals geprüft, danach filtert jede Abfrage nach space_id. Der Schlüssel ist dabei das Credential; der Principal ist die Identität, für die daraus die Autorisierungsentscheidung fällt. Ein Schlüssel, der auf engineering begrenzt ist, erreicht finance weder über einen REST-Pfad noch über ein MCP-Werkzeug. Das eingebaute Cockpit zeigt Spaces, Konzepte, Quellen und Reviews über dieselbe Produktdomäne und muss für denselben Principal dieselbe Space-Isolation durchsetzen wie die beiden APIs.

Abweichende Berechtigungsregeln würden einen Umgehungspfad schaffen. Sobald ein Zugangsweg eigene Nebenregeln bekäme, würde er zum bevorzugten Schlupfloch: Ein Agent, dem die MCP-Suche keinen Finance-Treffer liefert, dürfte ihn dann über eine Cockpit-Session doch bekommen – und die Berechtigungsprüfung des Schlüssels wäre nur noch eine Empfehlung.

Für Agenten hat das eine praktische Folge bei der Abstention. Findet die Suche im autorisierten Space nichts zu einer Finanzdefinition, liefert WikiKit keine Treffer aus einem anderen Bestand – die entsprechenden Abfragen laufen dort gar nicht. Der Agent kann dann sagen, dass der Begriff im verfügbaren Space nicht belegt ist. Ob er die Lücke trotzdem aus seinem Modellwissen füllt, entscheidet die Werkzeugantwort nicht; das bleibt eine Frage der Agentendisziplin außerhalb von WikiKit. Keine Promptformulierung muss ihn aber bitten, Finance-Treffer zu ignorieren: Sie erreichen ihn schlicht nicht. Ein Benutzer mit mehreren Berechtigungen kann mehrere gezielte Suchen ausführen und die Ergebnisse ausdrücklich zusammenführen – die Quersicht entsteht dann im autorisierten Client, nicht in einer globalen Datenbankabfrage.

Umgebung und Wissensdomäne sind verschiedene Achsen

development, staging und production beschreiben Betriebsumgebungen. engineering, finance und blog-de beschreiben Wissensdomänen. Eine Deployment-Umgebung ist eine Betriebsgrenze: Sie kann Datenbanken, Credentials und Ausfallrisiken trennen. Sie ist damit nicht automatisch ein eigener Wissensbereich, und ein Space sollte diese beiden Achsen nicht koppeln. Ein Space trennt Zugriffe logisch; er behauptet keine getrennte Datenbank, Hardware oder Operatorrolle.

Für lokale Tests kann eine eigene WikiKit-Instanz mit temporärer Datenbank laufen. Sie enthält einen engineering-Space mit Fixtures. Die Produktion enthält ebenfalls engineering, aber mit echten Quellen und Schlüsseln. Der gleiche Slug drückt denselben fachlichen Kontext in einer anderen Umgebung aus.

development:
  database: wikikit_dev
  spaces: [engineering]

production:
  database: wikikit_prod
  spaces: [engineering, finance, blog-de]

Ein Space engineering-prod würde beide Dimensionen verschweißen: Der Slug koppelt Betriebs- und Fachdimension und trägt die Betriebsdimension unnötig in Pfade und Schlüsselbindungen. Besser trennt das Deployment die Datenbanken und Credentials, während Space-Slugs die Fachlichkeit benennen.

Eine Ausnahme sind bewusst getrennte Mandanten innerhalb derselben Instanz. Dann kann ein Space auch eine organisatorische Isolation ausdrücken. Wichtig ist, dass diese Bedeutung dokumentiert ist und nicht derselbe Mechanismus einmal als Umgebung, einmal als Team und einmal als Projekt verwendet wird.

Quellen und Vorschläge bleiben im Space

Eine Quelle wird in einem konkreten Space aufgenommen und gehört zu ihm; auch der Synthesevorschlag, der aus ihr entsteht, liegt in diesem Bestand und wird erst durch eine Freigabe sichtbares Wissen. Weil jede Space-bezogene Abfrage nach space_id filtert, taucht eine vertrauliche Finanzquelle in keiner Engineering-Suche auf – unabhängig davon, wie ähnlich die Begriffe sind.

Landet eine Quelle im falschen Space, führt der saubere Weg über eine erneute Einreichung mit dem passenden Schlüssel im richtigen Kontext und die Ablehnung des falschen Vorschlags. So bleibt die Einreichung an den richtigen Space und den dafür berechtigten Schlüssel gebunden, statt dass eine stille Verschiebung die Herkunfts- und Berechtigungsgrenze verwischt.

Wann ein neuer Space sinnvoll ist

Nicht jedes Projekt braucht einen eigenen Space. Zu viele kleine Bestände erschweren das gemeinsame Finden und erzeugen doppelte Begriffe an Stellen, an denen dasselbe Fachwissen gemeint ist. Die Grenze soll echte Wissens- und Verantwortungsgrenzen abbilden – nicht die Ordnerstruktur eines Laufwerks und nicht das Organigramm allein.

Eine Trennung lohnt sich, wenn mindestens eine dieser Fragen klar mit Ja beantwortet wird: Sind die Leser oder prüfenden Personen verschieden? Sind Quellen vertraulich gegeneinander abzugrenzen? Besitzt der Bereich ein eigenes Vokabular, eine eigene Sprache oder eine eigene Charter? Braucht er Schlüssel mit eigener, engerer Reichweite?

Für zwei eng verbundene Engineering-Teams kann ein gemeinsamer Space mit präzisen Konzepten die bessere Wahl sein. Finance und öffentliche Blogregeln gehören eher auseinander, wenn Leser, Vertraulichkeit oder Sprache abweichen. Ein Space braucht außerdem benannte Personen, die offene Vorschläge und die Schlüsselpflege übernehmen – ohne diese Verantwortung wird die technische Isolation zu einem vergessenen Bestand, den niemand mehr prüft.

Die Entscheidung für einen benannten Space fällt bei der ersten echten Trennungsanforderung: eigene Leser, eigene Vertraulichkeit, eigenes Vokabular oder eigene Schlüssel. Ab diesem Moment gehört die Grenze in Slug, Schlüssel und Charter – und Cockpit, HTTP und MCP müssen sie für denselben Principal gleich durchsetzen. Promptregeln und Namenskonventionen erzwingen weder Berechtigungen noch space_id-Filter.

Weiterführende Quellen

Wie fandest du diesen Beitrag?

Kommentare