§ Plattform / Workspaces
Governance, die wirklich bindet.
Ein Workspace regelt die Arbeit eines Teams: Mitgliedschaft und Rollen von owner bis viewer, Richtlinien, die die Oberfläche nicht aushebeln kann, und revisionssichere Protokolle, wer wann was getan hat. Durchgesetzt wird alles am Server und in der Datenbank — nie im Client, wo eine Regel nur ein Vorschlag wäre. Regeln ist die eine Aufgabe des Workspace; vier Geschwisterkonzepte tragen die übrigen.
Eine Aufgabe pro Konzept — sauber getrennt
| Konzept | Achse | Was es ist |
|---|---|---|
| Pack | liefert aus | Ein signiertes, versioniertes Bündel, das alles mitbringt, wovon es abhängt — das, was ausgeliefert wird. |
| Listing | verkauft | Ein Handelseintrag, der genau ein Release bepreist; die Arbeit selbst weiß nichts vom Verkauf. |
| Workspace | regelt | Rollen, durchsetzbare Richtlinien und Audit-Bereich eines Teams. |
| Repository | kuratiert | Ein benanntes, versionsgepinntes Regal für alles, was du als Ganzes weitergeben willst. |
| Pool | rechnet | Eine Kohorte von Geräten, die gemeinsam einen Job ausführt — unter einem expliziten Vertrauensregime. |
Eine Achse pro Konzept, mit Absicht: ein Workspace liefert nie aus, ein Pack verkauft nie, ein Pool regelt nie.
Sobald Arbeit geteilt wird, tauchen fünf Arten auf, sie zu gruppieren — und jede beantwortet genau eine Frage. Ein Pack liefert aus, ein Listing verkauft auf dem Marketplace, ein Workspace regelt, ein Repository kuratiert, ein Pool rechnet. Sie sind bewusst nicht austauschbar: keines ist ein Modus eines anderen, und keines macht je zwei Jobs. Wenn du weißt, welche Frage du stellst — ausliefern, verkaufen, regeln, kuratieren oder rechnen —, weißt du, welches du brauchst.
Das Repository verdient den Satz, der ihm sonst fehlt: eine benannte, versionsgepinnte Sammlung von allem — Workflows, Modelle, Datasets, Blocks — geteilt wie ein Regal. Gepinnte Versionen halten das Regal stabil: Was eine Kollegin öffnet, ist exakt das, was du hineingestellt hast. Es trägt keine Rollen und keine Richtlinien; ein Repository kuratiert, ein Workspace regelt. Deine eigenen Regale stehen in deiner Startansicht, und der Guide führt durch beide.
Wer genau was darf
| Rolle | Reichweite | Was sie hinzufügt |
|---|---|---|
| owner | der Workspace selbst | Volle Kontrolle — Lebenszyklus, Richtlinien, Mitgliedschaft und jede Rolle darunter. |
| admin | Mitgliedschaft, Rollen & Richtlinien | Fügt Mitglieder hinzu, setzt Rollen und Richtlinien, fragt das Audit-Log ab und exportiert es. |
| editor | die Arbeit selbst | Erstellt, bearbeitet und führt aus, was der Workspace teilt. |
| viewer | Nur-Lese-Zugriff | Sieht geteilte Arbeit und ihre Historie; ändert nichts. |
Mitglieds- und Rollenänderungen werden serverseitig durchgesetzt und ins Audit-Log geschrieben — wie jede andere Änderung der Plattform.
Mitgliedschaft ist die Grenze. Vier Rollen, strikt geordnet — owner, admin, editor, viewer —, jede fügt der darunter Fähigkeiten hinzu, und der Server hält die Linie: Ein Mitglied hinzufügen, eine Rolle ändern, eine Richtlinie setzen ist eine gewöhnliche Aktion auf derselben API, die jeder Client nutzt — serverseitig geprüft und ins Audit-Log geschrieben. Eine Rolle ist eine Zugriffsentscheidung, nie ein Abzeichen, das die Oberfläche malt.
Dieselbe Grammatik erreicht Einzelpersonen. Ein Dokument mit einer Kollegin zu teilen ist ein Grant — eine Kante pro Empfänger, mit eigener Rolle, eigenem Ablauf und eigenem Widerruf. „Mit mir geteilt“ ist damit eine Frage, die du stellst, kein Stapel Kopien, der sich ansammelt. Workspace-Rollen und Grants pro Dokument komponieren sauber; keins gibt sich als das andere aus.
Eine Durchsetzungsgrenze, kein Schalter
Eine Workspace-Richtlinie kann ausschließlich signierte Inhalte zulassen, Netzzugriff komplett verbieten, deterministische Läufe verlangen oder unveränderliche Logs mit vollem Audit-Trail führen. Eine hier gesetzte Richtlinie wird durchgesetzt, nicht vorgeschlagen: Die Oberfläche kann sie nicht aushebeln, der Copilot auch nicht — jeder Aufrufer passiert dieselbe serverseitig geprüfte Oberfläche. Sie steht bewusst über der persönlichen Zustimmung: Einen Effekt, den du allein erlauben darfst, kann eine Team-Richtlinie für alle verweigern.
Der Audit-Trail ist abfragbar, nicht bloß vorhanden: Admins fragen als Daten ab, wer wann was getan hat — im Studio oder exportiert für die Akte. Rechenschaft ist damit selbst erreichbar, nicht in einer Logdatei vergraben. Regulierte Arbeit bekommt eine Grenze, die sie einem Auditor zeigen kann — in einer Form, die ein Auditor wirklich lesen kann.
Wer es findet — und wem du es gibst
Jede Arbeit trägt eine Sichtbarkeit — private, workspace oder public — und sie bewegt sich in eine Richtung: Öffnen ist ein bewusster Schritt, Zurücknehmen ein eigener, auditierter, und nichts verlässt private ohne angeheftete Lizenz. Sichtbarkeit beantwortet, wer etwas *finden* darf. „Teile das mit genau einer Kollegin“ kann sie bewusst nicht ausdrücken — eine Einstellung fasst keine Personenliste.
Diese Aufgabe gehört dem Teilen: Grants für benannte Personen, Einladungen, die beim Annehmen zu einem Grant werden, und Links in zwei ehrlichen Sorten. Ein Snapshot-Link friert eine committete Version ein — unveränderlich, ohne Login, allein aus der URL reproduzierbar. Ein Session-Link öffnet den lebenden Entwurf zum Co-Editing in Echtzeit. Und ein reguliertes Dokument kann Links komplett verbieten und nur benannte Personen zulassen.
Drei Entscheidungen kollabieren nie zu einem Schalter: Sichtbarkeit entscheidet, wer es findet, eine Co-Edit-Rolle entscheidet, wer es ändert, und ein Gerät beisteuern entscheidet, wer Rechenleistung gibt. Einem Dokument zum Bearbeiten beizutreten heißt nicht, deine GPU zu verleihen — die Plattform hält die drei sichtbar getrennt; du weißt immer, welche du gerade triffst.
Die Trennung wohnt in der Datenbank
Die Trennung zwischen Teams ist kein Versprechen der Anwendungsschicht. Row-Level-Security-Richtlinien in der Datenbank entscheiden, wer was sieht — unterhalb jedes API-Aufrufs und jedes Clients. Und diese Richtlinien werden aus einer Quelle generiert: Sichtbarkeit, Workspace-Mitgliedschaft, Grants und Link-Zugriff in einem Zug. Eine Sharing-Regel existiert genau einmal, und die Datenbank setzt sie vollständig durch.
Die Konsequenzen sind konkret. Ein Bug in einer Oberflächenkomponente kann Zugriff nicht ausweiten, denn die Datenbank selbst verweigert. Ein widerrufener oder abgelaufener Grant lässt Zeilen schon in der Speicherschicht nicht mehr durch — nicht erst in einem Client-Check, der übersprungen werden könnte. Das ist eine Schicht eines tieferen Stapels — Anmeldung, Isolation, Sandboxing, Integrität, Rechenschaft — ausgeführt unter Sicherheit und im Guide.
Eine Teamlizenz ist Daten, kein Anbau
Was eine Person beziehen darf — welchen Plan sie hat, welche bezahlten Inhalte sie installieren darf — ist ein Modell für die ganze Plattform, und wer einen Plan hält, kann eine Person sein oder ein Workspace. Eine Workspace-Lizenz ist sitz-gepoolt: Mitglieder erben sie, solange sie Mitglied sind, aufgelöst beim Anmelden über denselben Mitgliedschafts-Lookup, der alles andere regelt. Team-, Kurs- und Campus-Lizenzen sind damit Daten auf einer Kante, die es schon gibt — und dasselbe Modell drückt eine teamweite Lizenz für Marketplace-Inhalte so natürlich aus wie einen Plan.
Sitze werden gemessen wie jede Quote: Der Server verweigert Überschreitung laut und mit klarem Upgrade-Pfad — nie stillschweigend. Und unter allem: Rechnen ist nie an einen Tarif gebunden. Eine Workspace-Lizenz kauft gehostete Dienste — Speicher, Sharing-Skala, Kollaborationskapazität — und sonst nichts.