§ Platform / Extensibility
Everything we can compute, you can write.
New ops, GPU kernels, gradient rules, optimizers, losses, viewers, connectors — written from inside the Studio, checked exactly like the built-ins, and indistinguishable from them when they run: the engine cannot tell your work from ours at the moment it executes. We keep three grammars, one checker, and a reference implementation to check against. Everything else is yours.
Your work and ours are the same kind of thing
Most platforms ship two kinds of code: theirs, compiled into the product, and yours, held at arm's length behind a plug-in interface. Scellis ships one kind. Everything the engine can run — including everything we build in — is content in one catalog: one way in, one set of checks, one way to run. An op you write executes through exactly the path a built-in op does; nothing in the engine asks where it came from.
The identity is structural, not cosmetic — it reaches all the way down to execution, and giving a built-in special treatment is treated as a bug and caught automatically, like any other regression. The visible differences are cosmetic: a user/ prefix in the name, a source chip on the card. When we add an op ourselves, we add it as content, under the same rules.
Three grammars, a checker, a reference — nothing else
| What we keep | What it governs | What it unlocks for you |
|---|---|---|
| The shape & signature language | What an operator promises — shapes, axes, reductions, number types | Declare any operator; the engine reads the promise generically |
| The memory layout for GPU kernels | How a kernel reaches its data — buffers, shared scratch space, constants | Tiled matrix multiplies, reductions, stencils — yours to write, not reserved |
| The way gradients are written | Derivative rules as ordinary composed graphs | Any gradient you can express by composition is yours to write |
| The checker | Every authored thing — when it is created and at every edit | The same checker gates every built-in too |
| The reference implementation | How compute earns trust — a reference to check against, tolerances, gradient checks | Your kernel earns exactly the evidence ours does |
Everything outside this table is content you can write. An op we add ourselves comes in as content too, checked by the same rules.
Everything we hold back fits in three grammars the engine reads generically. A shape-and-signature language states what an operator promises: the shapes it takes, the axes it reduces, the number types it accepts. A memory layout for GPU kernels describes how a kernel reaches its data, so a tiled matrix multiply, a reduction, or a stencil is something you can write rather than something reserved for us. And a way of writing gradients makes a derivative rule an ordinary composed graph, as expressive as any forward pass. Anything written in those three is yours.
The floor beneath them is disclosed just as precisely. A small set of things is deliberately closed — the number types, the shape rules, the precision tiers and their tolerances, the handful of control-flow forms. You write any op, kernel, or gradient on top of those; and if a genuinely new one is needed — a complex number type, an eighth kind of loop — it arrives as an additive, versioned release of the engine, never as built-in content, and never as a privilege we did not tell you about.
The test we hold ourselves to is deliberately not machine learning. A finite-difference stencil, a novel statistic, a simulation step must ride the identical path — ops, kernels, blocks, control flow, types — with none of the training machinery involved. The rule is blunt: if you cannot write a Laplacian without us, the substrate is ours, not yours.
The built-ins are just the starting set
| Name | Kind | Origin | The bar it passed |
|---|---|---|---|
| matmul | op + its GPU kernel | built-in | checked · matched the reference within tolerance |
| user/mira/rms-norm | op + its GPU kernel | user | checked · matched the reference within tolerance |
| training/optimizer/adam | optimizer | built-in | checked · every dependency pinned to an exact version |
| user/kav/adam-cautious | optimizer | user | checked · every dependency pinned to an exact version |
| training/loss/focal | loss | built-in | checked · differentiable by composition |
| user/ada/quantile-huber | loss | user | checked · differentiable by composition |
Built-in and user rows read identically because they are identical — one catalog, the same checks, one way to run. Origin is presentation; the engine never branches on it.
The built-in catalog is a starting set, never a ceiling: the optimizers, losses, and schedulers the product ships with came in through the same door yours will — written, checked, published, delivered. And writing is a full surface of the Studio, not a code-only hatch: creating or editing something exposes every attribute it supports, from its signature and how it streams to its citations and its license.
Read the list below in both directions. A built-in row and a user row of the same kind carry the same promise, pass the same checks, and run the same way; the origin column is the only cell that differs, and the engine never reads it. That is what “first-class” means mechanically — the catalog does not have a service entrance.
Written means checked — in both directions
Everything you write — every kind of thing, not only blocks — passes one shared check when it is created and again at every edit. The same check gates every built-in, so the guarantee runs both ways: your work is validated like ours, and ours is provably complete under exactly the rules imposed on you. Missing metadata, an effect you didn't declare, an incomplete signature — rejected clearly, whoever wrote it.
Compute earns trust instead of asserting it. A kernel you write is paired with a plain reference implementation, and the evidence that the GPU version matches that reference — within a tolerance you declared — is what lets other people trust it; on your own device you can always run your own unchecked kernel. Gradients are checked numerically against your own forward pass, and even the algebra you declare for a reduction is tested before anything relies on it.
Editing is the sibling of writing. Built-ins never change — “editing” one forks a copy that is yours — while your own things are edited in place through the same checked path that created them. And trust is earned separately from who wrote it: things climb from unverified to community to verified to official on evidence, so work written by a user can wear exactly the badge ours does.
Import and use, like a library
Inside anything you write — an op, a block, a kernel's reference, a connector's input — you call other things from the catalog the way you would use an imported library, and the imports write themselves: the checker reads your call sites and records what you depend on, and a visual dependencies panel *is* the import statement — drag something in and the link is made. The call-by-call detail is in the guide: writing your own extensions.
Every call resolves to an exact version and an exact content hash — never “whatever happens to be newest” — so what you compose is reproducible by construction and runs offline, and a link re-runs precisely that set. Effects carry through: a “pure” helper cannot smuggle in a network call through something it depends on, because consent is asked for the whole set at once. And names cannot be spoofed — an op called relu that someone else wrote never shadows the built-in relu.
A pack installed from the Marketplace is live immediately, and the things inside it become available to call on the spot — install, then call, the way you would pull a library into a notebook. Whatever depends on it stays pinned to the exact version it resolved: an edit upstream never changes what you already built, and updating is a choice you make, never something that happens to you.
Publish without anyone rebuilding anything
Publishing runs a rehearsal first: are the versions all pinned, is the evidence there, are the effects declared, is the metadata complete, is there a license on anything you are making public. What ships is a signed, versioned pack; whoever installs it checks its hash first, and it is live for them without an app rebuild — for you, and for everyone else.
This is why a missing integration is never something you wait for us to build. The built-in connector set is deliberately small: the next connector, format, or training method is an afternoon of work away, published and findable the same day. More people writing means more the platform can do; we maintain three grammars, a checker, and a reference. The loop — write, check, publish, discover, run — is where you start, not a roadmap.
Publishing is not fire-and-forget, either. A security notice or a deprecation filed against a published version reaches everyone pinned to it, and forks carry their lineage and their license with them, so anything you take from the catalog is an invitation to build on rather than a dead-end copy.