Reproduzierbarkeit

Ein Ergebnis, das du nicht rekonstruieren kannst, ist eine Anekdote. Scellis behandelt Reproduzierbarkeit als Eigenschaft der Architektur, nicht als persönliche Gewohnheit: Identität ist ein Hash, ein Run ist ein Provenienzprotokoll, Determinismus ist eine Stufe, die du deklarierst, und Historie wird nie zerstört. Genauso bewusst ist die Plattform präzise darin, was jede Garantie bedeutet — sie benennt die, die du bekommst, statt eine stärkere anzudeuten. Diese Seite geht die Maschinerie von unten nach oben durch: von der Inhaltsadressierung bis zum exakten Versprechen hinter „reproduzierbar per URL“ — und was du Schritt für Schritt tust, damit ein Ergebnis zitierbar wird.

Identität ist ein Hash#

Workflows, Modelle, Datensätze und Runs sind inhaltsadressiert: Die Identität einer committeten Version ist der SHA-256-Hash ihrer Bytes, und diese Bytes können sich nie ändern — nicht per Richtlinie, sondern per Arithmetik, denn andere Bytes sind ein anderer Hash. Caches folgen derselben Regel: Wird ein Artefakt aus einem lokalen Speicher gelesen, werden seine Bytes gegen den Hash verifiziert, den sie zu tragen behaupten. Eine fehlgeschlagene Verifikation wird nicht als Drift abgetan; sie ist Korruption, und das Artefakt wird neu geholt. Was ein Hash benennt, ist exakt das, was du bekommst.

Daten, eine Ebene tiefer#

Dieselbe Disziplin gilt für Daten — eine Ebene unterhalb dessen, wo die meisten Werkzeuge aufhören. Dataset-Versionen sind inhaltsadressiert: Gleiche Daten ergeben denselben Hash. Und Train/Val/Test-Splits sind selbst versionierte, inhaltsadressierte Artefakte: Die exakte Aufteilung hinter einem Ergebnis ist per Hash aufgezeichnet und wieder auflösbar — ein Artefakt, das du zitierst, keine Konvention, an die du dich halb erinnerst. Wurde ein Modell „auf dem Testset“ evaluiert, sagt das Protokoll präzise, welche Bytes dieses Set waren.

Ein Run schreibt seine eigene Provenienz#

Jeder Run zeichnet die volle Identität dessen auf, was geschehen ist — das Programm, das lief, die Pläne, zu denen die Engine es abgesenkt hat, die gelesenen Daten, die geladenen und erzeugten Checkpoints, die geschriebenen Artefakte, die ausführende Engine und die Determinismus-Stufe darunter. Ausgeschrieben sieht das Protokoll so aus:

run 812 — committed
  program      sha256:9f2c41ac…   the exact graph that ran
  block_ir     sha256:52aa07c1…   the lowered program
  exec_plan    sha256:cc90e4b2…   dispatches + memory plan
  dataset      sha256:d41c66f8…   a version, never a path
  split        sha256:5a01d9e3…   train/val/test partition
  checkpoint   sha256:8be29a44…   weights · optimizer · RNG state
  artifacts    sha256:77aa1b0d…   metrics table, figures
  engine       1.4.2              the engine that produced it
  tier         prod               determinism, declared
  seed         42                 counter-based RNG

Weil jeder Eintrag ein Hash ist, beantwortet das Protokoll Fragen in beide Richtungen. „Was hat dieses Artefakt erzeugt?“ läuft rückwärts von einer Ausgabe zum exakten Programm, zu den Daten und zur Engine dahinter. „Welche Daten haben dieses Modell trainiert?“ läuft vorwärts von Dataset-Versionen zu Checkpoints. Experiment-Tracking fällt gratis ab: Ein Experiment ist einfach Provenienz — Runs plus unveränderliche Programme plus Dataset-Versionen plus Checkpoints — und Vergleiche sind abgeleitete Sichten über diese Protokolle, dauerhaft über Sessions hinweg. Wie Checkpoints selbst entstehen, zeigt Training im Browser.

Determinismus wird deklariert, nie defaultet#

Bitweiser Determinismus kostet Durchsatz, also wählt Scellis ihn nie still für dich — und nimmt ihn dir nie still weg. Jede Berechnung deklariert ihre Determinismus-Stufe, und eine fehlende Stufe lässt die Kompilierung laut scheitern, statt still auf einen Default zu fallen.

Auch der Zufall ist für Wiederholung gebaut: Ziehungen kommen aus einem zählerbasierten RNG, ein Seed reproduziert seine Sequenz also exakt — mit benannten Teilströmen für Dropout, Shuffling und Augmentation. Der RNG-Zustand reist in jedem Checkpoint mit; ein Training, das aus einem Checkpoint fortgesetzt wird, setzt genau die Zufallssequenz fort, die es ohne Unterbrechung erzeugt hätte.

Was „reproduzierbar per URL“ verspricht#

Die Formulierung hat eine präzise Bedeutung — und die Präzision ist der Punkt. Ein committeter Scellis-Link löst die identischen committeten Artefakte wieder auf — dieselben Bytes, dasselbe Programm, dieselben Eingaben — zusammen mit der aufgezeichneten Engine-Version und Determinismus-Stufe. Dieser Teil gilt bedingungslos: auf jedem Gerät, und du kannst ihn in Minuten selbst durchspielen.

Erneute Ausführung ist eine stärkere Behauptung, und sie ist bedingt — die Plattform benennt sie deshalb in zwei Stufen. Ein Run ist replayable, wenn er sich bit-exakt erneut ausführen lässt: die debug-Stufe auf demselben Gerät oder der CPU-Referenzpfad überall. Er ist convergent, wenn die erneute Ausführung innerhalb der deklarierten Toleranzklasse übereinstimmt — der Normalfall über verschiedene GPUs hinweg, deren Fließkomma-Hardware sich real unterscheidet. Eine Plattform, die Bit-Gleichheit über beliebige GPUs verspräche, verspräche etwas, das sie nicht prüfen kann; Scellis deklariert stattdessen die Klasse.

Entwürfe ändern sich; Commits zertifizieren#

Eine live geteilte Session wird nie gehasht — sie ist ein Ort, an dem sich Dinge ändern, und der Hash eines bewegten Ziels wäre ein falsches Zertifikat. Der Commit ist der Akt, der das zitierbare Artefakt prägt: Ab diesem Moment ist die Version unveränderlich, adressierbar und verlinkbar. Kollaboriere live; zitiere den Commit. Die Trennung ist Absicht — und sie zieht sich durch die ganze Plattform.

Teilen gilt für Ergebnisse, nicht nur für Rezepte. Die Ausgaben eines abgeschlossenen Runs — Metriken, Abbildungen — lassen sich als dauerhafte, ohne Login abrufbare, zitierbare Snapshot-URL teilen: Wer sie öffnet, löst die identischen committeten Artefakte wieder auf, Provenienzprotokoll inklusive. Derselbe committete Snapshot rendert schreibgeschützt in einem gehärteten Embed — ein Paper-Anhang oder ein README trägt so das lebende Ergebnis statt eines Screenshots.

Zitiere es wie Literatur#

Zitation ist erstklassig — in beide Richtungen: Entitäten tragen Zitate hinein, und jede committete Entität und jeder Run projiziert einen kanonischen Zitationsdatensatz heraus — Autoren-Handle, Name, Version, Content-Hash, Engine-Version, Snapshot-URL — gerendert als BibTeX, CFF oder CSL über einen „Cite this“-Anker:

@misc{ada_2026_robust_scaler,
  author       = {ada},
  title        = {robust-scaler (version 3)},
  year         = {2026},
  note         = {content hash sha256:9f2c41ac… · engine 1.4.2 · tier prod},
  howpublished = {Scellis snapshot URL — resolves the committed bytes}
}

Der Datensatz zitiert die committeten Bytes — die Zitation kann also nicht von dem wegdriften, was sie zitiert.

Historie — und die Engine — schließen den Kreis#

Jedes Dokument trägt eine Commit-Historie, durch die du blättern kannst, und je zwei Commits lassen sich diffen — auch Modellarchitekturen, denn Modellgraphen sind inhaltsadressiert und diffen wie alles andere. Wiederherstellen schreibt die Vergangenheit nie um: Das Auschecken einer früheren Version landet als neuer Commit oben auf der Historie. Nichts wird je zerstört.

Die Engine schließt den Kreis. Runs pinnen die engine_version, die sie erzeugt hat; Content deklariert die Engine-Features, die er braucht; und eine Engine, die ein Stück Content nicht erfüllen kann, lehnt laut ab — eine „braucht ein neueres Scellis“-Diagnose, nie eine stille Annäherung. Bei jeder Engine-Änderung wird ein eingefrorener Korpus älterer Arbeit erneut ausgeführt, damit ein Update alte Zahlen nicht still verändern kann — dieselbe Disziplin, mit der deine Arbeit unsere Releases überlebt. Das Ergebnis von gestern bleibt das Ergebnis von gestern.