Erste Schritte
Kernkonzepte
Eine kleine Zahl tragender Ideen hält Scellis zusammen: Blöcke und die Workflows, die sie komponieren; Modelle mit eigenem Editor; eine Absenkungsleiter; Garantien, die du deklarierst statt erbst; Identität per Hash; und eine Datenbank, die als Runtime arbeitet. Diese Seite ist die Karte — die Form jeder Idee und wie sie zusammenpassen. Hast du den Schnellstart schon gemacht, hast du sie alle berührt; hier bekommen sie Namen, und der Rest des Guides geht in jede in die Tiefe.
Blöcke und Workflows#
Der Block ist die kanonische, versionierte Einheit der Berechnung. Er ist kein Code-Schnipsel, sondern ein Vertrag — deklarierte Inputs und Outputs, Semantik (Determinismus, Toleranz, Differenzierbarkeit), ein Streaming-Vertrag und die Effekte, die er ausführt. Referenziert wird ein Block als block_id@version, und diese Paarung ist unveränderlich: Veröffentlichte Versionen koexistieren, eine semantische Änderung ist eine neue Version statt eines Edits an einer alten — geteilte Arbeit verschiebt sich dir also nie unter den Händen. Auch Identitäten tragen Struktur: block_id nutzt Slashes für globale Identität (training/optimizer/adam), während eine punktierte Taxonomie zum Stöbern klassifiziert — und die beiden vermischen sich nie.
Ein Workflow ist ein typisierter Graph aus Blöcken. Kontrollfluss ist im Graphen erstklassig — Schleifen, Bedingungen und Scans sind Konstrukte des Graphen, keine Notausgänge — und Workflows schließen den Kreis: Ein Workflow lässt sich als Block verpacken und in einem anderen verschachteln. Komposition ist der ganze Punkt. Große Arbeit ist kleine Arbeit, komponiert; und der Compiler lehnt einen mehrdeutigen Graphen früh mit einer präzisen Diagnose ab, statt zu raten.
Hinweis
Alles, was du erstellst, nimmt denselben Weg wie die Built-ins: Derselbe Author-Check validiert es, und zur Laufzeit sind beide strukturell ununterscheidbar — die Engine kann beim Dispatch einen Built-in nicht von einer Nutzer-Entität unterscheiden. Built-ins sind unveränderlich; einen zu „editieren“ heißt, deine eigene erstklassige Kopie zu forken. Dieser Anspruch — und was Erstellen erfordert — ist Erweiterungen erstellen.
Modelle und die Model View#
Ein Modell ist eine eigene Entität mit eigenem Editor. Du öffnest es im Model View und bearbeitest es Schicht für Schicht — durch drei synchronisierte Ansichten: einen Graphen, auf dem du zeichnest, ein Formular, das du ausfüllst, und Code, den du tippst — alle Projektionen eines zugrunde liegenden Modells. Änderst du es in einer, ziehen die anderen nach; die Validierung läuft live, sodass eine inkonsistente Architektur beim Bauen auffällt, nicht erst zur Laufzeit.
Entscheidend: Die Trainings-Pipeline wird am Modell konfiguriert und reist mit ihm. Optimizer, Scheduler, Loss, Mixed Precision und sogar das Federation-Setup leben an einem Ort. Teilst du das Modell, kommt sein Trainings-Setup mit — nicht als separates Artefakt, das jemand zu schicken vergisst.
Die IR-Leiter#
Ein gezeichneter Graph läuft nicht so, wie er gezeichnet ist. Er senkt sich über eine Leiter inspizierbarer, versionierter Sprossen ab — vom Workflow-Graphen über eine Tensor-Repräsentation mit Autograd und Speicherplanung hinunter zu GPU-Dispatches und, wenn verteilt gerechnet wird, zu einem Plan über Peers. Jede Sprosse ist inspizierbar: Willst du wissen, was tatsächlich läuft, kannst du nachsehen — auf jeder Ebene. Genau das macht einen Lauf reproduzierbar, budgetierbar und debugbar statt zum Vertrauenssprung — die Mechanik ist WebGPU und die IR.
Eine Konsequenz verdient ihren eigenen Satz: Der UI-Zustand ist nie das Programm. Das Programm ist kanonisch und inhaltsadressiert; die Canvas ist eine Ansicht davon. Was läuft, ist das Programm — nicht das Bild. Genau deshalb kann ein Link ein Ergebnis tragen und keinen Screenshot.
Deklariert, nie stillschweigend gesetzt#
Zwei Garantien ziehen sich durch jeden Block, und keine wird angenommen. Erstens Effekte: Blöcke sind standardmäßig pur. Ein Block, der über seine eigene Berechnung hinausgreift — Netzwerk, Dateisystem, Secrets, ein Peer —, muss diesen Effekt deklarieren. Unbekannte Effekte werden standardmäßig verweigert; deklarierte sind zustimmungspflichtig und werden in der Provenienz festgehalten, und Effekte sind transitiv über eine Aufruf-Closure — eine „pure“ Funktion kann also nicht leise eine mit Netzwerk-Effekt aufrufen. Beachte genau, was eingeschränkt wird: nie die Ausdruckskraft — nur Effekte.
Zweitens Determinismus — deklariert, nie stillschweigend gesetzt. Jede Berechnung benennt eine von drei Stufen:
debug— bitweise identische Ergebnisse mit gleichem Seed auf demselben Gerät.prod— Übereinstimmung innerhalb einer deklarierten Toleranzklasse.fast— Nichtdeterminismus genau dort, wo er als sicher deklariert ist.
Die Stufe wird Ende-zu-Ende durchgereicht und in der Provenienz festgehalten. Eine fehlende Stufe bekommt keinen stillen Default; sie schlägt beim Kompilieren fehl — laut. Du weißt immer, welche Garantie du bekommst — und verlierst nie eine aus Versehen.
Identität ist ein Hash; die Datenbank ist die Runtime#
Content ist über SHA-256 adressiert: Committete Versionen sind unveränderlich, und Caches verifizieren beim Lesen, was sie zurückgeben. Eine live geteilte Session wird nie gehasht — zitierbar ist nur eine committete Version. „Reproduzierbar per URL“ heißt deshalb genau das: Der Link löst wieder zu den identischen committeten Artefakten auf, zur Engine-Version, die sie ausgeführt hat, und zur Determinismus-Stufe, unter der sie liefen. Das ist das Rückgrat der Reproduzierbarkeit über die ganze Plattform.
Und die Datenbank ist die Runtime. Es gibt keine statischen Katalogdateien: Jeder Block, jedes Modell und jeder Viewer kommt aus der Datenbank, wird lokal gecacht, und die In-Memory-Registries sind daraus neu aufgebaute Caches — der Katalog, den du durchstöberst, ist exakt das, was veröffentlicht wurde, ein Pfad ohne stale Kopien. Im großen Maßstab wird Content bei Bedarf geholt und durch Nutzung gepinnt — du lädst kein Universum herunter, um eine Ecke zu benutzen. Die Kehrseite von Local-first ist das Versprechen, das den Kreis schließt: Die Abhängigkeits-Closure eines Workflows wird vor dem Speichern gepinnt, sodass Gespeichertes immer offline läuft — und ein Offline-Miss laut mit Namen scheitert, statt still zu ersetzen.
Fünf Arten, Arbeit zu gruppieren#
Sobald Arbeit geteilt wird, tauchen fünf Gruppierungskonzepte auf — und jedes beantwortet genau eine Frage. Sie sind bewusst nicht austauschbar, und die Plattform lässt keines in die Aufgabe eines Nachbarn driften.
| Konzept | Achse | Was es ist |
|---|---|---|
| Pack | liefert aus | ein signiertes, versioniertes Bundle mit geschlossenem Abhängigkeitsgraphen |
| Listing | verkauft | ein Commerce-Datensatz, der ein Release bepreist (das Artefakt bleibt commerce-blind) |
| Workspace | regelt | Rollen, Richtlinien und Audit-Scope eines Teams |
| Repository | kuratiert | ein benanntes, versionsgepinntes Regal aus Entitäten |
| Pool | rechnet | eine Kohorte von Peers, die einen Job ausführt |
Eine Achse pro Konzept — keines übernimmt die Frage seines Nachbarn. Weißt du, welche Frage du stellst — ausliefern, verkaufen, verwalten, kuratieren oder rechnen —, weißt du auch, welches Konzept du brauchst. Zwei davon, Workspace und Repository, sind der Ort, an dem aus Solo-Arbeit geteilte Arbeit wird; dieser Übergang ist Workspaces und Repositories. Das ist die ganze Karte; der Rest dieses Guides läuft sie ab.