Packs, publishing, and trust

Sooner or later your work has to leave your machine — a workflow a collaborator should run, a block strangers will build on, a model your future self must reproduce. Scellis ships work as a Pack: a signed, versioned bundle of entities whose dependency graph is closed — everything the contents reference either travels inside the envelope or is pinned by exact version and content hash. This page walks the shipping path step by step: the envelope, the lockfile, the publication gate, the signature, the trust ladder, and the guarantees that keep dependents from breaking. One distinction before anything else: a Pack ships; a Repository curates; a Listing sells. Three axes, never blurred.

One envelope for everything that ships#

Not every export is a whole pack. Five portable single-file formats exist — .scellis-workflow, .scellis-pack, .scellis-block-pack, .scellis-model, .scellis-dataset — and all five share one envelope. The manifest inside declares the type; the bytes are byte-for-byte reproducible, so exporting the same content twice yields the identical file; and every import verifies the content hash before anything lands in your Catalog. A file that fails verification is refused — loudly, in the same canonical diagnostic every refusal on the platform speaks. There is no probational import and no partial landing: verified bytes, or nothing.

The closure travels with the work#

The hardest promise a pack makes is completeness, and Scellis refuses to leave it to the author's memory. When authored code calls other catalog entities — an op, a helper function, a tokenizer — every such use resolves through a lockfile: an automatically derived closure of everything the work depends on, pinned by identity, exact version, and content hash, and checked for cycles. The same closure is what makes a saved workflow run offline: every pinned hash is resident on the device before a run starts, so fetching lives at authoring and install time, never on the run path.

{
  "entity": "user/ada/robust-scaler",
  "version": 3,
  "content_hash": "sha256:9f2c41ac…",
  "uses": {
    "tensor/matmul@2": "sha256:41ac88d0…",
    "user/kim/winsorize@1": "sha256:b7e03f5e…",
    "text/tokenizer/bpe@4": "sha256:0d66c2a1…"
  },
  "effects": [],
  "min_engine": "1.4.0",
  "capabilities": ["webgpu.f16"]
}

Two consequences deserve emphasis. First, effects are transitive through the closure: if a dependency three levels down declares network egress, the pack wears that declaration on its face — a “pure” wrapper cannot smuggle a call in through its imports (how effects are declared at all is covered in authoring extensions). Second, installation re-resolves the same closure on the receiving device. A pack is never almost-installed: either every pin resolves and verifies, or the install refuses and names the pin that failed.

Publication is a preflight, not an upload#

You publish a committed version, never a live draft. Drafts are where things change; a commit is the immutable, content-addressed artifact worth putting your name on — the same draft-versus-commit discipline that runs through reproducibility. On top of the commit sits a gate that checks the bundle before anything goes out — and the checks themselves are delivered as content, so the bar can rise without an app release. The gate demands:

• A resolvable lockfile: every dependency pinned, every pin resolvable.
• Conformance evidence: anything that computes carries its record of agreement with the reference implementation — for a GPU kernel, the hash-bound ConformanceReceipt that gated its trusted activation.
• A method card: the human-readable account of what this is and how it behaves. Models add a model card; datasets, a datasheet.
• Declared effects: everything the contents touch beyond pure compute — closure included.
• Profile compatibility: declared, so a device knows before installing whether it can run this.
• Complete metadata and a license: no blank fields where a catalog entry should be — and nothing goes public without an explicit SPDX license.

Miss a piece and publication is refused with every missing item named — never silently, never with a generic error. You fix exactly what the gate lists and publish again; there is no guessing.

Signed on your device, trusted by evidence#

Signing happens where your work lives: in the browser. A signing key is itself a catalog entity; the private half is generated locally and never leaves the device — not synced, not uploaded, not recoverable by Scellis. Publishing signs the content hash, and every install verifies signature and hash together, so what arrives on another machine is provably what you published.

Trust is a separate axis from authorship and from popularity. A published version carries an earned level — unverified, community, verified, official — and user work climbs to verified on the same evidence bar as anything the platform team ships, because user content is structurally identical to builtins. Official merely marks Scellis-maintained content; everything else moves up on evidence, never favoritism.

Published versions never move under you#

A published version is immutable — “fixing” one in place is forbidden by construction. When meaning changes, the version bumps, and the old version stays runnable forever, because dependents pin exact versions in lockfiles. Updating is therefore a decision you make, not something that happens to you: you re-resolve to the new version deliberately, run your checks, and move. The same rule follows content into commerce: a buyer keeps v2 when v3 ships.

Dependents are defended structurally, too. Purging a published entity is refused while any dependent's lockfile pins it. Erasing an account tombstones its published entities — the author is anonymized, the pinned bytes stay resolvable — so nobody's work breaks because someone else left. And when upstream evolves somewhere you would rather not follow, forking is first-class: fork anything you can read and you own a full copy — editable, publishable, and checked exactly like everything else. Permanence of this kind is a platform commitment, not a courtesy.

Consent at install; policy from the Workspace#

Install time is where safety is decided, and it is decided on declarations. A pack states the effects its closure needs, and consent is computed from that statement:

A Workspace can hold a tighter line for everyone inside it: require signed packs only, forbid network effects, or demand deterministic execution. No local setting overrides workspace policy — the interface cannot be talked past a rule the workspace set.

Delivery at the speed of sync — honest to the last mile#

Publish, and delivery stops being your problem. There is no release train because there is nothing to release: the compiled app ships only the engine, and every capability arrives from the database — so a newly published pack is live for other clients within seconds of their next sync. No app rebuild, no reinstall, no waiting for a version window.

Fast shipping still ships mistakes, so every published hash has an advisory channel. An advisory alerts every pinned dependent — a notification, a catalog badge on the flagged version, and a one-step re-resolve to move off it — and new installs of a flagged version can be blocked at the byte-serving chokepoint every install flows through.

That is the whole path from your device to everyone else's: one envelope, a closure that travels, a gate that names its demands, a signature minted locally, versions that never move, consent computed from declarations — and delivery at the speed of a sync.