ENGINEERING CASE STUDY
A release should remain checkable after it leaves the runtime.
The detached-release path binds a declared payload universe, manifest state and receipt snapshots so a recipient can detect modification, unexpected entries and signature or chain failures outside the originating runtime — and reports an unsigned release as an attention state rather than upgrading it to verified.
Engineering problem
Copying a ZIP or an export does not preserve the technical meaning of what was actually issued. The bytes travel; the guarantees do not. A recipient holding a loose archive cannot tell whether an item was added, whether one is missing, whether the contents were altered, or whether anything about it was ever signed. To be verifiable after it leaves the runtime, a release needs four things it does not get for free: a declared universe of what it contains, content commitments over that universe, signature state, and defined failure semantics for when any of those do not hold.
The declared payload universe
The core idea is to freeze an explicitly declared set of what the release is — its payload universe — rather than leaving it as whatever happens to be in the archive. Once the universe is declared and bound, anything outside it is an anomaly by definition: an extra file is not a harmless addition, it is an entry the release never claimed, and the verifier can say so. Binding the universe is what converts a bag of files into a release with an edge.
Implementation
The current release verifier freezes an explicitly declared ZIP payload universe and binds both the payload and the detached release manifests to it. It supports detached Ed25519 signing — the signature travels alongside rather than embedded in the content — and it can verify embedded signed or unsigned V2 receipt snapshots carried within the release. Each of these is a separate commitment with its own pass or fail, so a verifier learns not just that something is wrong but which thing.
Adversarial checks — what it is built to reject
The current tests exercise the release against the ways a recipient could be deceived: a modified export is rejected because the content commitments break; a rewritten release manifest is rejected because it no longer binds the declared universe; duplicate ZIP names are rejected because name collisions are a classic way to smuggle a substitute entry; and invalid signature binding is rejected rather than ignored. Critically, an unsigned release is reported as an attention state, not upgraded to verified — absence of a signature is surfaced honestly, never rounded up to trust.
Why unsigned-as-attention matters
The tempting shortcut in release tooling is to treat a well-formed but unsigned package as good enough. That is exactly the laundering the verifier refuses: unsigned is a distinct, named state a recipient must see and decide about, not a quiet pass. The verifier's job is to report the true state of the release, including the uncomfortable one, so the decision to accept it rests with a human who can see exactly what the release establishes and what it leaves open.
Boundary
Detached release verification is implemented and tested, but current product authority places default packet compilation activation under operator control. Complete end-to-end packet and release readiness is therefore not claimed here — what is claimed is the specific, tested behavior of the verifier against modified, rewritten, duplicated and unsigned releases. Activation remains a separately governed, operator-controlled state.