01

Die Trennfrage vor dem Ordnernamen

Eine gute Struktur beginnt nicht mit Nummern oder Icons, sondern mit einer Zuständigkeitsfrage: Ist dieser Inhalt unternehmensweit verbindlich, gehört er zum Agenturbetrieb, zu einem Produkt, zu einer technischen Implementierung oder nur zu einer zeitlich begrenzten Initiative?

Wenn diese Ebenen vermischt werden, entstehen typische Konflikte. Eine Produktentscheidung landet in der Codebase, ein Betriebszustand in einer Präsentation und eine temporäre Checkliste wird unbemerkt zur dauerhaften Regel. Das System wächst, aber niemand kann mehr sicher sagen, welche Datei eine Änderung auslösen darf.

Ein einfacher Test hilft bei der Zuordnung: Würde dieselbe Aussage noch gelten, wenn die aktuelle Implementierung morgen ersetzt wird? Wenn ja, gehört sie wahrscheinlich nicht ausschließlich in die Codebase. Beschreibt sie dagegen ein konkretes Modul, einen Build oder einen technischen Rückfallweg, ist der Implementierungsort richtig. Diese Frage trennt Fachlichkeit und Technik zuverlässiger als eine Diskussion über perfekte Ordnernamen.

Eine zweite Trennlinie verläuft zwischen dauerhaft und vorläufig. Research, Varianten und lokale Stages dürfen widersprüchlich sein, solange ihr Status sichtbar bleibt. Verbindliche Quellen dürfen das nicht. Der Initiativenbereich ist deshalb kein chaotischer Ablageplatz, sondern eine kontrollierte Werkstatt: Hier wird gearbeitet, ohne jede Idee sofort zur Firmenregel zu erklären.

02

Sechs Ebenen mit unterschiedlichen Aufgaben

Das hier beschriebene Modell unterscheidet sechs fachliche Bereiche. Der Unternehmens-Core hält Architektur, Entscheidungen und Registries. Das Business-System enthält wiederverwendbares Agenturwissen. Produktbereiche beschreiben Nutzen, Betrieb und fachliche Regeln. Das Agentic-System ordnet Agenten, Skills, Workflows und Evals. Datenbereiche definieren Verträge und Zugriffsgrenzen. Zur Codebase gehören Implementierung, Tests und technische Dokumentation. Bei der sem.-Website ist dafür das registrierte private Git-Repository zuständig; Unternehmenswissen und Produktregeln bleiben im CompanyOS.

Temporäre Initiativen liegen separat. Dort dürfen Entwürfe, Research und lokale Stages entstehen, ohne sofort kanonische Wahrheit zu werden. Sobald ein Ergebnis dauerhaft gilt, wird es bewusst an seinen fachlichen Hauptort überführt.

Die Ebenen sind keine unabhängigen Silos. Ein Produkt kann einen Agenten verwenden, der wiederum auf einen Datenvertrag zugreift und eine registrierte Codebase ausführt. Getrennt werden die Verantwortungen, nicht die Beziehungen. Genau deshalb braucht das System neben der physischen Ordnung eine kleine strukturierte Landkarte.

Gemeinsame Marken- und Medienassets bilden eine weitere bewusste Ausnahme: Sie werden zentral verwaltet, weil mehrere Produkte und Initiativen dieselben Grundregeln verwenden. Eine konkrete Website kopiert daraus nur die benötigte Projektion. Änderungen an der Marke entstehen am gemeinsamen Hauptort; der Build bleibt Verbrauchsschicht.

  • Core: Architektur, Routing und verbindliche Entscheidungen
  • Business: wiederverwendbares Wissen der Agentur
  • Product: fachliche Produktwahrheit und Betrieb
  • Agentic: Agenten, Skills, Workflows und Evals
  • Data: Verträge, Klassifikation und Zugriffsregeln
  • Code: genau eine registrierte technische Implementierung

03

Registries verbinden, ohne Inhalte zu kopieren

Eine Registry beantwortet: Welche Entität ist das, wo liegt ihre kanonische Quelle und in welcher Beziehung steht sie zu anderen Entitäten? Sie sollte keine komplette Produktbeschreibung duplizieren. Sonst entsteht genau die Parallelwahrheit, die sie verhindern soll.

Stabile IDs sind dabei wichtiger als schöne Namen. Ein Produkt kann umbenannt oder verschoben werden, ohne dass jede Beziehung ihre Identität verliert. Beziehungen werden an einem Ort gepflegt, statt in fünf Dateien gegenseitige „nutzt“- und „wird genutzt von“-Listen zu synchronisieren.

Eine gute Registry bleibt absichtlich langweilig. Sie enthält Identität, Typ, Speicherort, Klassifikation und wenige maschinenlesbare Zustände. Häufig wechselnde Betriebsdaten oder ausführliche fachliche Regeln gehören dort nicht hinein. Je mehr eine Registry selbst erklären will, desto wahrscheinlicher konkurriert sie bald mit der eigentlichen Quelle.

Beziehungen benötigen dieselbe Disziplin. „Nutzt“, „liefert Daten an“ und „wird bereitgestellt durch“ sind unterschiedliche Aussagen. Werden sie nur als Freitext notiert, kann später niemand sicher prüfen, welche Änderung welche Verbraucher betrifft. Ein gemeinsamer Relationship-Bestand macht Auswirkungen sichtbar, ohne die verbundenen Systeme physisch zusammenzukopieren.

04

Routing als Arbeitsabkürzung

Ein Agent oder Mensch liest nicht pauschal den gesamten Workspace. Er startet beim zentralen Router, findet über Systemkarte und Registry den zuständigen Einstieg und liest erst dann die lokalen Regeln. Das reduziert Kontext, schützt eingeschränkte Bereiche und verhindert, dass historische Dateien zufällig handlungsleitend werden.

Dieser Mechanismus macht das System erweiterbar. Ein neues Produkt benötigt nicht sofort eine globale Zusammenfassung. Es braucht einen fachlichen Hauptort, einen Einstieg, eine Registry-ID und die tatsächlich relevanten Beziehungen.

Routing ist dabei mehr als Navigation. Ein Einstieg legt auch eine Lesereihenfolge fest: zuerst die allgemeine Sicherheitsgrenze, danach der aktuelle Zustand, anschließend die lokale Spezifikation und zuletzt die konkrete Implementierung. So trifft ein Agent technische Entscheidungen nicht auf Basis einer veralteten Roadmap und fachliche Entscheidungen nicht aus einem Buildartefakt.

Der Router darf trotzdem klein bleiben. Wenn er jede Ausnahme erklärt, wird er selbst zum zweiten Handbuch. Seine Aufgabe ist, die nächste richtige Quelle zu benennen und klar zu sagen, welche Bereiche ohne konkreten Auftrag nicht geöffnet werden. Fachliche Tiefe bleibt lokal bei dem System, das sie verantwortet.

05

Eine praktische Prüfliste

Vor einer neuen Datei oder einem neuen Ordner helfen diese Fragen: Gibt es bereits eine Quelle für diese Information? Ist der Inhalt dauerhaft oder temporär? Wer darf ihn ändern? Welche Systeme hängen davon ab? Enthält er sensible Daten? Und wie wird eine spätere Migration dokumentiert?

Wenn diese Fragen nicht beantwortet sind, ist ein neuer Ordner selten die Lösung. Dann braucht es zuerst eine Einordnungsentscheidung. So lässt sich vorab entscheiden, ob eine bestehende Quelle ergänzt werden sollte oder tatsächlich ein neuer Bereich nötig ist.

Bei einer Änderung an einem gemeinsamen Modul kommt eine Auswirkungsprüfung hinzu. Welche Produkte oder Workflows verwenden es? Welche Tests schützen das bisherige Verhalten? Gibt es einen sicheren Rückfallweg? Welche Dokumentation muss zusammen mit der Implementierung angepasst werden? Diese Fragen gehören vor den Patch und nicht erst in die Fehleranalyse danach.

Nach einer Migration wird deshalb nicht nur geprüft, ob die neue Datei existiert. Alte Referenzen, Einstiegspfade und Registries müssen auf den neuen Hauptort zeigen. Ein alter Bestand wird kontrolliert archiviert, wenn er noch historischen Wert besitzt. Ziel ist nicht maximale Sauberkeit im Dateibaum, sondern eine eindeutige aktive Wahrheit mit nachvollziehbarer Geschichte.