§ Platform / Catalog
Everything you need, one search away.
Blocks, models, datasets, kernels, viewers, connectors — nothing is baked into the app. Everything arrives on demand and then stays on your device, so what you have answers instantly and keeps working offline. What the rest of the world has published is one search away, and every result shows where it came from, who made it, and whether its numbers were checked.
Content is delivered, never bundled
Every capability you use — a block, a model, a viewer, a connector — arrives as content from a database, not as a file baked into the app. What we build and what people write themselves come in through the same door and pass the same checks; from there, everything syncs into a database inside your browser, and the app runs from that. There is no second copy of anything and no file to fall back on: what you see is exactly what was published.
One path also means the platform grows without releases. A new optimizer, a new viewer, a new connector arrives as data — live in the Studio the moment it lands, with no app update and no reinstall. If you want to see how the delivery path works step by step, the guide walks it: how content reaches your browser.
Yours is resident; the world is on demand
| What | Where it lives | Guarantee |
|---|---|---|
| Working set — everything you use, install, or pin | on your device, hash-verified | Runs offline indefinitely — bounded by what you do, never by how big the world's catalog is. |
| Everything a saved workflow depends on | pinned before it saves | A saved workflow always runs offline; nothing is fetched while it runs. |
| Big things — weights, kernels, code | stored by their content hash | Fetched on demand, verified on arrival, and stored once however many things reference them. |
| Discovering something new | the Registry, on the network | Ranked search over everything published; offline it falls back to a clearly labeled last-known index. |
| Freeing up space | local, and dependency-aware | What you pinned is never collected — only leftovers nothing refers to reclaim space. |
Built to hold millions of published things: your catalog is what you actually use — the rest is one search away, never a download.
A catalog built to hold millions of published things cannot be a download, so it is fetched the way a feed is: on demand. What you actually use, install, or pin — plus the engine and everything a saved workflow depends on — is your working set: guaranteed to be on your device, hash-verified, and running with the network unplugged for as long as you like.
The discipline is strict exactly where it matters. Everything a workflow needs is pinned to your device before it saves, so on-demand fetching is confined to browsing and installing — it never touches a run. And a gap is loud: something you never fetched fails by naming exactly what is missing, never by quietly substituting a “nearest” version.
What you have is not what exists
Scellis keeps three layers apart, because the difference decides what still works when you are offline. Your Catalog is what you *have* — on your device, instant, offline. The Registry is the server's record of everything that *exists* — every published version, by name and by hash. The Marketplace is how you browse the Registry: look, preview, and take what you don't yet have. It holds nothing of its own.
Install is the bridge, and there is exactly one of it: the bytes come down, get checked against their hash before anything activates, and enter your catalog through the same packaging path everything else uses. From that moment the thing is yours — “installed” is a note on one entry, never a duplicate — and it works offline like everything else you have.
Two lanes, one honest stream
Search runs both lanes at once. The local lane answers from your device instantly — offline included, because your catalog goes where you go. The remote lane queries the Registry: ranked, paged, spanning everything published. The results merge into one stream, and every card says which side it came from — installed, available, or paid — so what is yours and what is not is never ambiguous.
Browsing is the same machinery: a subject tree with live counts, filters over kind, source, trust, and difficulty, and a ranking that blends how trusted a thing is, how much real use it gets, and whether it will run on your hardware. Watch something and its new versions come to you. One honest note: finding *new* things in the world needs the network; offline, the global index shows itself for what it is — last known, and labeled that way.
The card is a datasheet
| Signal | Values | Why it matters |
|---|---|---|
| Source | built-in · user · copilot | User work and built-ins are treated identically by design — one path, the same checks, the same way to run. |
| Trust level | unverified → community → verified → official | Earned through review and checking, never bought — work you write yourself can reach verified. |
| Version | training/optimizer/adam@3 | A published version never changes: new versions live alongside old ones, which stay runnable forever. |
| Conformance | passed · partial · untested | Whether the numbers matched the reference — visible before you depend on it, never assumed. |
| License | MIT · Apache-2.0 · CC-BY-4.0 | A license is required before anything is shared at all; a fork inherits it and shows it. |
| Citations & difficulty | beginner → advanced | The method's paper trail goes with it; completeness is required at creation, not hoped for. |
Everything in the catalog carries complete metadata as a condition of existing — name, summary, subject, tags, citations, license, provenance. That is a product rule, not housekeeping: a method you cannot evaluate is a method you cannot responsibly run. The card answers what you would ask before depending on someone else's work — who made it, is it verified, and did its numbers match the reference.
Selecting a card opens a real preview: the method card with its citations, what the thing touches, whether it fits your hardware, and a rehearsal that tells you what a run would need before you start one. Public entries talk back, too — anyone can open a discussion, so the person who hits a bug reports it where the author and every future user can see it.
Published means present
When someone publishes, everyone watching sees it on their next sync — the design target is within a second of arrival — with no app update and no reinstall, because there is no hardcoded list anywhere to amend: a new capability is simply a new entry, live the moment it lands. And what you write yourself comes in through the identical checked path as everything built-in — same checks, same catalog, same card.
Distribution is contractual, not casual. A pack pins the exact version and content of everything it depends on, so the same inputs always resolve to the same result, and every run records the exact set of content it used — which is why what you reproduce is what actually ran. A published version never changes; fixing one in place is forbidden. New versions live alongside it, and anything pinned to the old one keeps working.
Compatibility is declared, never guessed: content states what it needs from the engine, and an engine that cannot provide it refuses out loud with a “needs a newer Scellis” badge — never a crash, never a silent wrong answer. Your catalog can outlive years of releases; that promise has its own page.