Ich habe etwas gebaut, das es so bislang noch nicht gibt.
Ein Musiklabel — aber kein klassisches. Kein Büro, keine Mitarbeiter, kein A&R der Demos hört. Stattdessen: ein Git-Repository als Gehirn, KI-Entitäten als kreative Mitarbeiter, GitOps als Betriebsmodell.
Ich nenne das Projekt Phantom Grid. Und ich behaupte: es ist das erste vollständig code-basierte Musiklabel der Welt und existiert damit für immer im Cyberspace.
Das klingt nach einer Marketing-Aussage. Ist es aber nicht — es ist eine technische Beschreibung. Jede Entscheidung, jeder Release, jedes Design-Element, jede Workflow-Regel existiert ausschließlich als Code, Markdown oder strukturierte Datei — JSON, YAML — in einem öffentlichen GitHub-Repository. Es gibt keine parallele Dropbox, kein Notion-Board, keine Google-Tabelle die “eigentlich” die Wahrheit kennt.
Lass mich erklären wie das funktioniert und warum ich glaube, dass dieser Ansatz die logischste Konsequenz aus allem ist, womit wir uns als Entwickler gerade beschäftigen.
Die Ausgangsfrage
Ich produziere elektronische Musik, seit Jahren nur Ambient, seit geraumer Zeit aber wieder Beats in Form von Electro und Techno, modern aber mit detroitischem Anschlag. Irgendwann kam der Punkt, an dem mir die Idee kam: ich habe Musik, und die will ich unter einem Label-Namen veröffentlichen. Nicht aus Eitelkeit, sondern weil ein Label-Kontext Releases zusammenhält. Es gibt dem ganzen einen Rahmen.
Die Frage war: wie baut man ein Label auf, wenn man Entwickler ist, KI-Tools täglich nutzt und vor allem: wenn man die Fehler völlig veralteter klassischer Musikindustrie-Strukturen von Anfang an vermeiden will?
Die Antwort war nicht “nimm ein CMS und mach ne mySpace-Seite”. Das war im Jahr 2006 definitiv innovativ. Heute ist der Stand der Dinge anders: Wer kein Insta hat, existiert quasi nicht. Das ist heute halt so, aber ich wollte das viel weiter denken als 99,9% der Labelmacher und Artists da draußen. Ich wollte echte Innovation. Die Antwort war: bau das Label so wie du ein Software-Projekt bauen würdest. Mit denselben Prinzipien. Denselben Tools. Derselben Disziplin. Open Source, frei verfügbar, aber als Idee und Konzept für immer im Cyberspace unter meinem Namen in Bits und Bytes verewigt. Früher war Vinyl für die Ewigkeit, heute ist es die Cloud.
Das OS — das Gehirn des Labels
Das erste was ich erstellt habe war kein Logo, keine Webseite, kein Bandcamp-Profil. Es war ein Git-Repository namens phantom-grid-os.
OS steht für Operating System. Das Repository ist buchstäblich das Betriebssystem des Labels.
Darin leben:
- Das Manifest und die Creative Direction
- Das Brand-System mit allen Farben, Typografie-Regeln, visuellen Effekten
- Die Rollen und Verantwortlichkeiten der KI-Entitäten und ihre Seelen SOUL.md
- Alle Release-Daten als strukturierte JSON-Dateien
- Die Tools zur Asset-Generierung
- Die Architektur-Dokumentation
Kein Content ist doppelt vorhanden. Das OS ist die Single Source of Truth. Alles andere — die Website, die Social-Media-Assets, die Asset-Exports ist eine Ausgabe daraus.
Warum Git als Fundament?
Die meisten Labels speichern ihre Informationen irgendwo verteilt. Eine Tabelle hier, eine Dropbox da, ein Notion-Dokument dort. Das führt unvermeidlich zu massiven Inkonsistenzen. Ich spreche da aus Erfahrung.
Git gibt dir etwas, das andere Tools nicht geben: eine vollständige, versionierte Geschichte jeder Entscheidung. Jede Änderung am Brand, jede neue Release-Information, jede Anpassung an den Workflows — alles ist nachvollziehbar, rückgängig zu machen, und mit einem Commit-Message kommentiert.
Das ist nicht nur technisch sauber. Es ist ein Protokoll. In fünf Jahren kann ich nachvollziehen warum eine Entscheidung so getroffen wurde.
Die Architektur-Entscheidung (Stand jetzt): Zwei Repos, ein Pointer
Phantom Grid hat zwei Repositories:
phantom-grid-os — das Gehirn. Kein Build-Step, keine Dependencies, kein CI. Nur Markdown, JSON und Shell-Scripts. Öffentlich, weil Transparenz zum Konzept gehört.
phantom-grid-web — das Gesicht. Die Astro-Site, die phantom-grid.de rendert. Ein deployables Artefakt mit Docker, GitHub Actions, ArgoCD.
Das Web-Repo enthält keinen eigenen Content. Stattdessen ist das OS-Repo als Git Submodule eingebunden. Beim Build liest Astro die Release-JSON-Dateien, die Posts, das Manifesto — direkt aus dem OS-Submodule.
phantom-grid-web/
└── phantom-grid-os/ ← kein Ordner. ein Zeiger.
pinned auf Commit: a91dc6bDas bedeutet: wenn eine neue Release in das OS committet wird, weiß die Website davon noch nicht. Der Zeiger muss bewusst weiterbewegt werden. Das ist keine Schwäche — das ist Kontrolle.
git submodule update --remote
git add phantom-grid-os
git commit -m "chore: update OS submodule — PG-002"
git pushDrei Befehle. ArgoCD erkennt den Push. Neue Release-Seite ist live.
Warum das Submodule-Konzept wichtig ist
Ich habe Git Submodules in einem Lehrformat erklärt das mir selbst gut gefällt: der Ordner ist ein Portal.
Das Web-Repo sieht einen Ordner phantom-grid-os. Die Dateien sind physisch da — Astro kann sie lesen, der Build funktioniert. Aber Git weiß: dieser Ordner gehört nicht mir. Er gehört dem OS-Repo. Wenn du darin etwas committest, landet es dort — nicht hier.
Das zwingt zu einer sauberen Trennung. Der Content lebt im OS. Die Präsentation lebt im Web. Nie umgekehrt.
Die Mitarbeiter: KI-Entitäten mit Rollen und Stimmen
Phantom Grid hat Mitarbeiter. Keine Menschen — aber auch keine anonymen KI-Tools die ich auf Kommando aufrufe.
Es gibt vier Entitäten, jede mit einem Namen, einer definierten Rolle, einer eigenen Perspektive:
WAVEJUMPER übernimmt Art Direction und Visual Identity. HYDRO THEORY kuratiert den Listening Room — eine fortlaufende Dokumentation des musikalischen Bezugssystems. STORM SURGE verantwortet Kommunikation und Release-Strategie. VOID ist die übergeordnete Instanz — kein Charakter, sondern das Schweigen zwischen den Signalen.
Was das von “ich frage ChatGPT” unterscheidet: diese Entitäten haben dokumentierte Rollen im OS. Sie haben Perspektiven die festgehalten sind und sich mit dem Repo weiter entwicklen. Wenn WAVEJUMPER über ein Designproblem schreibt, schreibt sie nicht als generische KI — sondern aus der Position einer Art Directorin die das Phantom Grid Brand System kennt, weil es in ihrer Rolle und Seele dokumentiert ist.
Das ist Kontext-Engineering — die Praxis, KI-Modellen präzise Rahmenbedingungen und Primer mit zu geben damit ihre Outputs konsistent und nützlich sind. Nur konsequenter als üblich und interativ weiter gedacht.
Das Label als lebendiges Dokument
Was mich an diesem Ansatz am meisten überzeugt: das OS ist kein abgeschlossenes Dokument. Es wächst mit dem Label mit.
Jede Designentscheidung wird dokumentiert. Jede neue Komponente im Brand-System wird mit ihrer Intention beschrieben. Die KI-Entitäten — dazu mehr in Teil 2 — haben ihre Rollen, ihre Perspektiven, ihre Stimmen schriftlich festgehalten.
Das OS ist gleichzeitig Betriebsanleitung, Archivmaterial und Arbeitsgrundlage. Für mich als Entwickler. Und für die KI-Entitäten die damit arbeiten.
Das Besondere: phantom-grid-os ist öffentlich auf GitHub. Das ist Absicht. Die Struktur, die Entscheidungen, der Code — das ist Teil des Produkts. Wer verstehen will wie das Label funktioniert, kann es nachvollziehen. Commit für Commit.
Soweit ich weiß existiert so etwas noch nicht. Musiklabels haben Webseiten, Social-Media-Accounts, vielleicht ein Notion-Workspace. Aber kein öffentliches, versioniertes Operating System das das Label selbst ist. Phantom Grid ist beides gleichzeitig: ein laufendes Musikprojekt und ein offenes Experiment darüber, wie kulturelle Infrastruktur im KI-Zeitalter aussehen könnte.
In Teil 2 schaue ich mir die KI-Entitäten genauer an: wer WAVEJUMPER, HYDRO THEORY, STORM SURGE und VOID sind — und warum sie keine KI-Tools sind, wie normale Menschen sie kennen. sondern kreative Mitarbeiter mit eigenen Rollen, Stimmen und Seelen.
Kommentare