Hosted build evidence
A trusted hosted workflow must produce provenance identifying its source revision, builder, inputs and output artifact digests.

Inspect the Numina 2.0 application inventory, discover its detached build statements, and review the separate rc22 runtime evidence.
Numina 2.0.0 brings the website, operations workspace and installable mobile web app together. Your service workflows and private Treasury records remain available in the same design.
Loading deployed release…
Loading…This build identity is calculated from the packaged application files. Detached build provenance is checked separately using the exact inventory fingerprint below. The rc22 control-plane dependency retains its own identity and signed records.
A detached signed statement can identify the builder and the exact release file. The statement stays separate so the original file remains unchanged.
Signature verification has not been performed.
Loading…No manifest response is currently loaded.
The lookup opens GitHub’s public records for this fingerprint. A listed statement is evidence to verify; its presence alone does not establish a valid signature, SLSA level or deployment match. An empty or unavailable lookup does not verify the release.
Save the exact manifest above as application-release-v2.json. Use GitHub CLI to check its digest, the designated repository and the pinned builder identity.
Load the current manifest to prepare verification.
Review the verified source revision and workflow run against the intended release. A signature check does not by itself prove that these bytes were deployed or that all SLSA Build L3 controls are established.
The Numina 2.0 application uses control-plane runtime v1.9.0-rc22. Its signed declaration and control-state receipts can be checked against the public key pinned in this website.
A runtime signature authenticates the service’s declaration. It does not independently establish a build-platform security level or verify the bytes of the referenced SBOM and provenance artifacts.
https://slsa.dev/provenance/v1The predicate URL identifies the official provenance format and remains the same in production. This page is the production documentation location; it is not itself a builder-signed provenance statement.
A trusted hosted workflow must produce provenance identifying its source revision, builder, inputs and output artifact digests.
Build L3 requires evidence of isolated builds and protection against user-controlled provenance tampering, alongside the applicable builder controls.
The published application must be linked to the exact artifact authenticated by the trusted builder’s provenance.
Application build statements are discovered by the inventory fingerprint above. The separate rc22 runtime’s full provenance and builder controls have not been verified here. Neither a file hash nor a listed statement alone closes these verification gaps.
Assessment recorded September 12, 2026. Official SLSA levels · Build requirements.
The earlier rc20 records remain available as historical artifacts. They do not establish the rc22 build’s provenance.