Core concepts

Scellis is carried by a small set of load-bearing ideas: blocks and the workflows that compose them, models with their own editor, a lowering ladder, guarantees you declare rather than inherit, identity by hash, and a database that acts as the runtime. This page is the map — the shape of each idea and how they fit together. If you have already run the quickstart, you have touched all of them; here they get names, and the rest of the guide goes deep on each.

Blocks and workflows#

The block is the canonical, versioned unit of computation. It is not a snippet of code; it is a contract — declared inputs and outputs, semantics (determinism, tolerance, differentiability), a streaming contract, and the effects it performs. You reference a block as block_id@version, and that pairing is immutable: published versions coexist, a semantic change is a new version rather than an edit of an old one, so shared work never shifts underneath you. Identities carry structure, too — block_id uses slashes for global identity (training/optimizer/adam), while a dotted taxonomy classifies it for browsing, and the two never mix.

A workflow is a typed graph of blocks. Control flow is first-class in the graph — loops, conditionals, and scans are graph constructs, not escape hatches — and workflows close the loop: a workflow can be packaged as a block and nested inside another. Composition is the whole point. Big work is small work, composed, and the compiler rejects an ambiguous graph early with a precise diagnostic rather than guessing.

Models and Model View#

A model is its own entity, with its own editor. You open it in Model View and edit it layer by layer through three synchronized views — a graph you draw on, a form you fill in, and code you type — all projections of one underlying model. Change it in one and the others follow; validation runs live, so an inconsistent architecture is caught as you build it, not at run time.

Crucially, the training pipeline is configured on the model and travels with it. Optimizer, scheduler, loss, mixed precision, and even the federation setup live in one place. Share the model, and its training setup arrives with it — not as a separate artifact somebody forgets to send.

The IR ladder#

A drawn graph does not run as drawn. It lowers through a ladder of inspectable, versioned rungs — from the workflow graph, through a tensor-level representation carrying autograd and memory planning, down to GPU dispatches and, when work is distributed, a plan across peers. Every rung is inspectable: when you want to know what will actually execute, you can look, at any level. That is what makes a run reproducible, budgetable, and debuggable rather than a leap of faith — the mechanics are WebGPU and the IR.

One consequence deserves its own sentence: the UI state is never the program. The program is canonical and content-addressed; the canvas is a view of it. What runs is the program, not the picture — which is exactly why a link can carry a result and not a screenshot.

Declared, never defaulted#

Two guarantees run through every block, and neither is assumed. First, effects: blocks are pure by default. A block that reaches outside its own computation — network, filesystem, secrets, a peer — must declare that effect. Unknown effects are denied by default; declared ones are consent-gated and recorded in provenance, and effects are transitive across a call closure, so a “pure” function cannot quietly call a network-effecting one. Note precisely what is restricted: never expressiveness — only effects.

Second, determinism — declared, never defaulted. Every computation names one of three tiers:

• debug — bitwise-identical results with the same seed on the same device.
• prod — agreement within a declared tolerance class.
• fast — nondeterminism exactly where it is declared safe.

The tier is plumbed end to end and recorded in provenance. A missing tier does not get a quiet default; it fails compile, loudly. You always know which guarantee you are getting — and never lose one by accident.

Identity is a hash; the database is the runtime#

Content is addressed by SHA-256: committed versions are immutable, and caches verify what they return on read. A live collaborative session is never hashed — only a committed version is citable. So “reproducible by URL” means exactly what it says: the link re-resolves the identical committed artifacts, the engine version that executed them, and the determinism tier they ran under. That is the backbone of reproducibility across the whole platform.

And the database is the runtime. There are no static catalog files: every block, model, and viewer arrives from the database, is cached locally, and the in-memory registries are caches rebuilt from it — the Catalog you browse is exactly what was published, one path with no stale copies. At scale, content is fetched on demand and pinned by use, so you never download a universe to use a corner of it. The flip side of local-first is the promise that closes the loop: a workflow's dependency closure is pinned before you save it, so what you saved always runs offline, and an offline miss fails loudly by name rather than silently substituting.

Five ways to group work#

The moment work is shared, five grouping concepts appear — and each answers exactly one question. They are deliberately not interchangeable, and the platform never lets one drift into a neighbour's job.

One axis each — none of them takes over a neighbour's question. When you know which question you are asking — ship, sell, govern, curate, or compute — you know which concept you need. Two of them, Workspace and Repository, are where solo work becomes shared work; that transition is workspaces and repositories. That is the whole map; the rest of this guide walks it.