Reproduce a result

Someone sends you a link — in a paper, a README, a chat — and says the result is right there. On most platforms that link is a screenshot, or a recipe you would have to rebuild by hand. On Scellis it is the result: open it, and the run reproduces on your own device. This is the shortest path through the platform's central claim — reproducible by URL — made concrete, in five parts: you receive a link, it reproduces on your device, you inspect exactly what produced it, you fork it, and you commit your own version. Scellis is in development preview, so read this as the flow it is built around.

1. You receive a link#

A Scellis link comes in two kinds, and the difference is load-bearing. A session link points at a live, editable head — the collaborative draft, where things still change — and it asks you to sign in. A snapshot link points at a frozen, content-addressed commit: immutable, citable, and openable without an account. The snapshot is the reproducible-by-URL primitive — the thing a paper or a README should carry.

The same committed snapshot also renders read-only inside a hardened embed, so a write-up can show the living result in place, with an “Open in Studio” and a “Remix (fork)” hatch on it — and a login-free visitor can take either. Recipes and results both travel this way; reproducibility covers the guarantee underneath, while this page walks the doing.

2. It reproduces on your device#

Open the snapshot and Scellis re-resolves its entire committed closure — the exact program, its inputs, the dataset and the train/val/test split by hash, plus the engine version and the determinism tier the run recorded. That closure pins into your local database, and then the run re-executes on your machine: the same IR ladder lowers it to WebGPU and runs on your own GPU, every result checked against the CPU reference within the declared tolerance class. Nothing is uploaded and no server computes — it is the same run you would start in the quickstart, only the recipe arrived from someone else.

Fig. 1 — A snapshot link opens login-free and re-resolves the identical closure — program, data, split, engine, and tier — which re-executes on your own GPU and agrees within the declared tolerance.

Note

Scellis names the guarantee instead of implying a stronger one. “Same bytes, same program, same inputs, recorded engine and tier” is unconditional — it holds on any device. “Same bits out” is conditional: a run is replayable (bit-exact) on the debug tier on the same device or on the CPU-reference path anywhere, and convergent — agreeing within the declared tolerance — across different GPUs, whose floating-point hardware genuinely differs. The reasoning is honest limits.

One more honesty is built into the open. If your engine is too old to satisfy the content the link pins, it refuses loudly — a “needs a newer Scellis” diagnostic — rather than approximate silently. A reproduction that cannot be faithful does not pretend to be.

3. Inspect what produced it#

A reproduced run is not a black box you have to trust. It arrives with its provenance record — the program, BlockIR, and ExecPlan hashes, the dataset and split versions, the checkpoints it loaded and produced, the artifacts it wrote, the engine version, the determinism tier, and the seed. Every entry is a hash, so the record answers questions in both directions: what produced this artifact, and what data trained this model. You can see exactly what you just reproduced, down to the split behind “the test set”.

From the same surface, a “Cite this” anchor projects a canonical citation record — author handle, name, version, content hash, engine version, snapshot URL — rendered to BibTeX, CFF, or CSL. You cite the exact bytes you reproduced, so the citation cannot drift from the thing it points at. The full mechanism, and how a run writes its own provenance, is reproducibility.

4. Fork and make it yours#

Any readable entity can be forked — and forking is the invitation the platform extends on every recipient surface, never a dead-end copy. Your fork records where it came from and inherits the original's license, displayed plainly. From there it is yours: a first-class entity you edit in place through the same validated write path as anything you built from scratch — exactly as authoring extensions describes. A login-free visitor forks too: on your own device you may author and run any computation, unbounded, with no account at all.

Fig. 2 — Every shared result is a starting point: fork it (lineage and license travel along), commit your own version to a new hash — and only then, from that commit, can you propose the change back upstream. You collaborate on a draft; you propose, and cite, a commit.

5. Commit, and pass it on#

When your changes are worth keeping, commit — and your fork gets its own content hash and its own snapshot URL. Share that, and the chain continues: the next person reproduces your version the same way you reproduced the original. If you would rather give your changes back than diverge, you can propose them upstream — the owner reviews a three-way merge and accepts or declines, the loop you already expect from version control.

Where forks and versions live together — curated, pinned, shared — is workspaces and repositories; working on the draft before you commit is live collaboration. Claim your login-free work into an account whenever you want to sync it across devices and share at scale — once, idempotently. Every link you send is now a starting point, not an endpoint.