Erste Schritte
Ein Ergebnis reproduzieren
Jemand schickt dir einen Link — in einem Paper, einem README, einem Chat — und sagt, das Ergebnis sei genau da. Auf den meisten Plattformen ist dieser Link ein Screenshot oder ein Rezept, das du von Hand nachbauen müsstest. Auf Scellis ist er das Ergebnis: Öffne ihn, und der Run reproduziert auf deinem eigenen Gerät. Das ist der kürzeste Weg durch den zentralen Anspruch der Plattform — reproduzierbar per URL —, konkret gemacht, in fünf Teilen: Du bekommst einen Link, er reproduziert auf deinem Gerät, du inspizierst genau, was ihn erzeugt hat, du forkst ihn und du committest deine eigene Version. Scellis ist eine Development Preview — lies das als den Ablauf, um den es gebaut ist.
1. Du bekommst einen Link#
Ein Scellis-Link kommt in zwei Arten, und der Unterschied ist tragend. Ein Session-Link zeigt auf einen live editierbaren Head — den kollaborativen Entwurf, wo sich Dinge noch ändern — und verlangt eine Anmeldung. Ein Snapshot-Link zeigt auf einen eingefrorenen, inhaltsadressierten Commit: unveränderlich, zitierbar und ohne Konto zu öffnen. Der Snapshot ist das Reproduzierbar-per-URL-Primitiv — das, was ein Paper oder ein README tragen sollte.
Derselbe committete Snapshot rendert außerdem schreibgeschützt in einem gehärteten Embed, sodass ein Beitrag das lebende Ergebnis an Ort und Stelle zeigt — mit einer „Open in Studio“- und einer „Remix (fork)“-Luke darauf —, und ein Besucher ohne Login kann beides nehmen. Rezepte und Ergebnisse reisen so; Reproduzierbarkeit deckt die Garantie darunter ab, während diese Seite das Tun durchgeht.
2. Er reproduziert auf deinem Gerät#
Öffne den Snapshot, und Scellis löst seine gesamte committete Closure wieder auf — das exakte Programm, seine Eingaben, den Datensatz und den Train/Val/Test-Split per Hash, dazu die Engine-Version und die Determinismus-Stufe, die der Run aufgezeichnet hat. Diese Closure pinnt in deine lokale Datenbank, und dann führt der Run auf deiner Maschine neu aus: Dieselbe IR-Leiter senkt ihn zu WebGPU ab und läuft auf deiner eigenen GPU — jedes Ergebnis gegen die CPU-Referenz innerhalb der deklarierten Toleranzklasse geprüft. Nichts wird hochgeladen und kein Server rechnet — es ist derselbe Run, den du im Schnellstart startest, nur kam das Rezept von jemand anderem.
Hinweis
Scellis benennt die Garantie, statt eine stärkere anzudeuten. „Gleiche Bytes, gleiches Programm, gleiche Eingaben, aufgezeichnete Engine und Stufe“ gilt bedingungslos — auf jedem Gerät. „Gleiche Bits heraus“ ist bedingt: Ein Run ist replayable (bit-exakt) auf der debug-Stufe auf demselben Gerät oder auf dem CPU-Referenzpfad überall, und convergent — innerhalb der deklarierten Toleranz übereinstimmend — über verschiedene GPUs hinweg, deren Fließkomma-Hardware sich real unterscheidet. Die Begründung sind die ehrlichen Grenzen.
Noch eine Ehrlichkeit steckt im Öffnen. Ist deine Engine zu alt, um den Content zu erfüllen, den der Link pinnt, lehnt sie laut ab — eine „braucht ein neueres Scellis“-Diagnose — statt still zu approximieren. Eine Reproduktion, die nicht treu sein kann, tut nicht so, als wäre sie es.
3. Inspiziere, was es erzeugt hat#
Ein reproduzierter Run ist keine Blackbox, der du vertrauen musst. Er kommt mit seinem Provenienzprotokoll — den Programm-, BlockIR- und ExecPlan-Hashes, den Datensatz- und Split-Versionen, den geladenen und erzeugten Checkpoints, den geschriebenen Artefakten, der Engine-Version, der Determinismus-Stufe und dem Seed. Jeder Eintrag ist ein Hash, das Protokoll beantwortet Fragen also in beide Richtungen: Was hat dieses Artefakt erzeugt, und welche Daten haben dieses Modell trainiert. Du siehst exakt, was du gerade reproduziert hast — bis hinunter zum Split hinter „dem Testset“.
Von derselben Oberfläche projiziert ein „Cite this“-Anker einen kanonischen Zitationsdatensatz — Autoren-Handle, Name, Version, Content-Hash, Engine-Version, Snapshot-URL —, gerendert als BibTeX, CFF oder CSL. Du zitierst die exakten Bytes, die du reproduziert hast — die Zitation kann also nicht von dem wegdriften, worauf sie zeigt. Die volle Mechanik, und wie ein Lauf seine eigene Provenienz schreibt, ist Reproduzierbarkeit.
4. Forke es und mach es zu deinem#
Jede lesbare Entität lässt sich forken — und Forken ist die Einladung, die die Plattform auf jeder Empfängerseite ausspricht, nie eine Sackgassen-Kopie. Dein Fork hält fest, woher er stammt, und erbt die Lizenz des Originals, deutlich angezeigt. Ab da gehört er dir: eine erstklassige Entität, die du direkt über denselben validierten Schreibpfad bearbeitest wie alles, was du selbst gebaut hast — genau wie Erweiterungen erstellen es beschreibt. Ein Besucher ohne Login forkt ebenfalls: Auf deinem eigenen Gerät darfst du jede Berechnung erstellen und ausführen — unbegrenzt, ganz ohne Konto.
5. Committe und gib es weiter#
Sind deine Änderungen es wert, behalten zu werden, committe — und dein Fork bekommt seinen eigenen Content-Hash und seine eigene Snapshot-URL. Teil sie, und die Kette geht weiter: Der Nächste reproduziert deine Version so, wie du das Original reproduziert hast. Willst du deine Änderungen lieber zurückgeben statt abzuzweigen, kannst du sie nach upstream vorschlagen — der Owner reviewt einen 3-Wege-Merge und akzeptiert oder lehnt ab, die Schleife, die du aus der Versionsverwaltung kennst.
Wo Forks und Versionen zusammen leben — kuratiert, gepinnt, geteilt —, sind Workspaces und Repositories; am Entwurf zu arbeiten, bevor du committest, ist Live-Kollaboration. Übernimm deine Login-freie Arbeit in ein Konto, wann immer du sie über Geräte synchronisieren und im großen Maßstab teilen willst — einmalig und idempotent. Jeder Link, den du schickst, ist jetzt ein Startpunkt, kein Endpunkt.