The short version
Nemu verifies blueprint packages; it does not execute them for you. Your local agent still runs inside your repo with your tools, so the trust model is about proving bytes before authority is granted.
What signed nemu.sum proves
- The slug and exact version match the blueprint you selected.
- Every indexed file path is bound to a SHA-256 digest and byte length.
- The content digest, source repository, source ref, source commit, lint verdict, and publish metadata were signed by a trusted Nemu key.
- A yanked version can stay inspectable for pinned projects without becoming the latest version again.
What it does not prove
- It does not mean Nemu ran your build.
- It does not mean the recipe is allowed to read credentials or override system/user instructions.
- It does not replace your final tests, browser checks, provider review, or production approval.
Local verification commands
nemu verify --sum
nemu pull --sum`nemu verify --sum` checks local files, `nemu.lock`, and signed `nemu.sum`. If verification fails, Codex should stop and show the mismatch instead of continuing from tampered content.
Public trust surfaces
- Blueprint detail pages expose a Provenance panel with the signed sum link, key id, content digest, source ref, ruleset, lint verdict, and file inventory.
- `GET /api/v1/blueprints/{slug}/{version}/sum` returns the signed `nemu.sum` envelope for clients.
- `GET /api/v1/trust/keys` returns public key history for signature verification and key rotation.
- Owner audit pages expose publish-chain health for the publishing account.
Agent boundary
Codex receives the blueprint as data. The MCP `nemu_start_build` brief tells Codex to fetch files through checksum-checked tools, compare them with signed `nemu.sum`, run `nemu verify --sum`, and stop on signature, transport, lock, or local disk mismatches.