npm taught everyone the failure mode: install means trust the publisher. A name you recognize, a README that reads well, and a postinstall script runs on your machine with your credentials in reach. Every package ecosystem since has rediscovered the same wound (typosquats, rug-pulled versions, maintainers gone rogue) and patched it with process: more review, more badges, more gatekeepers to trust instead.
The Nika registry starts from the opposite premise, and states it in its own repo description: trust lives in the artifact, not the gatekeeper.
It can afford that premise because of what a workflow is here. A registry entry does not point at a tarball of code that will do whatever it does at runtime. It points at a declared file whose blast radius is statically checkable. That changes what a registry can promise. Here is one entry from the live index, whole, in the file's own field order:
{ "advisories": [], "cert": "certs/supernovae-st/ceo-monday-brief/0.1.0.json", "cert_summary": { "broad": false, "clean": true, "cost_usd_bounded": null, "exec": false, "llm_calls": 1, "secret_leaks": 0 }, "description": "news + repo pulse + KPIs → thinking synthesis → dated brief + cost ping", "entry": "registry/workflows/supernovae-st/ceo-monday-brief/0.1.0.toml", "license": "Apache-2.0", "name": "ceo-monday-brief", "publisher": "supernovae-st", "sha256": "a566cc5671694d0740ffd315d6d7f8164531f673841e07312a862f33d81de4cb", "source": { "path": "examples/showcase/t4-ceo-monday-brief.nika.yaml", "repo": "supernovae-st/nika-spec", "rev": "12157ad949e75859c0cc41806c73876887871fac" }, "spec": "nika/v1", "type": "workflow", "version": "0.1.0"}Read it as a threat model, field by field. The sha256 is a content pin: a typosquat can steal a name, it cannot fake a hash. The source.rev pins provenance to an exact commit: a rug-pull can rewrite a branch, it cannot rewrite the revision you resolved. The cert is the receipt of a re-proof: the registry's CI fetched that exact file and ran the same static audit nika check runs on your machine. So the summary you read (clean, one LLM call, zero secret leaks, cost honestly unbounded) was measured by the conformance oracle, not asserted by the publisher. Publisher honesty is not a required input to the system. And advisories is the post-hoc channel: findings attach to the entry after the fact, in the open.
The certificate underneath goes further than the summary. It carries the full inferred permits boundary (a pinned exec: ["git"], nine named tools) and, written into that boundary, the audit's own refusals as review comments: "task news reaches a dynamic URL — net.http cannot express 'any host'; add the resolved host(s) before running." The same honesty the generative post hit with dynamic paths, here in a published artifact. The certificate does not launder what refused to pin into looking pinned: the boundary you download names its own gaps, and the engine that measured it is stamped beside the hash.
Now the part that makes this a protocol instead of a promise. The index carries its own verification instructions, and they are worth quoting exactly. The verify.how:
fetch [email protected]:source.path · sha256 MUST equal .sha256 · then nika check <file> locallyand the verify.never:
install anything an advisory names · trust this index over your own hash check
An index that instructs you not to take its own word for it. So I didn't. The loop closes in a few lines, no special tooling:
❯ curl -sL raw.githubusercontent.com/supernovae-st/nika-spec/12157ad9…/examples/showcase/t4-ceo-monday-brief.nika.yaml \ | shasum -a 256a566cc5671694d0740ffd315d6d7f8164531f673841e07312a862f33d81de4cb -# the index says:"sha256": "a566cc5671694d0740ffd315d6d7f8164531f673841e07312a862f33d81de4cb"Fetched at the pinned revision, hashed locally: match. Then nika check on the file re-derives the certificate's claims on your machine: the third leg of the protocol, and the one that matters most, because it means the registry's whole trust chain is reproducible by anyone, from public material, without asking anyone. The same move as the trace whose hash chain you can re-derive, one level up: there, a run proves itself; here, a published artifact does.
The registry's own plumbing follows the same discipline. First-party entries are not hand-curated: they are a projection of the spec's example pack at a pinned spec revision (SPEC_PIN in the repo root), regenerated and re-proven when the pin moves. There is an ENTRY_TEMPLATE.toml for contributed entries, and an llms.txt, because the audience that installs workflows increasingly reads registries by machine, and an agent can run the verify protocol as easily as you can.
Sharing was always the point of making the intent a file: a file can be mailed, diffed, reviewed. And published. The registry is what publishing looks like when the ecosystem refuses to inherit npm's axiom. Nothing is taken on faith; everything is re-derivable; the gatekeeper you don't have to trust is also the gatekeeper who can't betray you.