Release Verification

Use this checklist to verify an Omnis Helix release from published artifacts or locally produced release assets. The goal is an offline-friendly integrity check: hashes, SBOMs, provenance, and canonical demo outputs should agree before a release is treated as review-safe.

Required Artifacts

• Release archives for the target platforms, such as Linux, Windows, and macOS bundles.
• SHA256SUMS.txt for release archive hashes.
• SBOM-*.spdx.json files when SBOMs are published for the release.
• release-provenance.intoto.json and related build metadata when provenance statements are published.
• Canonical demo bundles and expected reports for release smoke verification.

1) Verify Checksums And Signatures

gpg --verify SHA256SUMS.txt.asc SHA256SUMS.txt
sha256sum -c SHA256SUMS.txt

Expected result: every artifact listed in SHA256SUMS.txt reports OK, and the signature verifies against the expected release-signing key.

If release provenance artifacts are present, verify them with the source checkout tooling:

python tools/verify_release_signatures.py \
  --public-key release-signing-public-key.asc \
  --fingerprint-file release-signing-key-fingerprint.txt \
  --verify-path SHA256SUMS.txt \
  --verify-path BUILD_META.txt \
  --verify-path release-provenance.intoto.json \
  --json

python tools/verify_release_provenance.py \
  --statement release-provenance.intoto.json \
  --assets-dir . \
  --source-digest <git-sha> \
  --json

2) Verify SBOMs

Regenerate an SBOM from the received artifact and compare it against the published SBOM. The exact generator may vary by environment; this example uses syft after it has already been installed locally.

syft packages omnis-helix-linux.zip -o spdx-json > /tmp/helix_sbom_check.json
diff -u SBOM-linux.spdx.json /tmp/helix_sbom_check.json

Expected result: no differences beyond accepted generator metadata.

3) Run Canonical Demo Verification

Use the canonical demo bundle supplied with the release, or the equivalent locally produced demo assets.

unzip -q demo_batch.zip -d /tmp/helix_demo
./OmnisHelix --headless results batch_eval_base_positions \
  /tmp/helix_demo demo_pinned_profile.json /tmp/helix_demo_out.json

Expected result: /tmp/helix_demo_out.json matches the published expected output byte for byte.

If the release includes a prime multiplex demo, run that lane as well and compare against the published expected output:

./OmnisHelix --headless tools/prime_multiplex_leaderboard.py \
  /tmp/helix_demo prime_pinned_profile.json /tmp/prime_lb.json \
  --markdown /tmp/prime_lb.md

diff -u demo_leaderboard.md /tmp/prime_lb.md

Expected result: no diff.

4) Local Verification Without CI Artifacts

When GitHub Actions artifacts are unavailable, generate the release verification bundle locally from existing builds:

tools/release_local.sh \
  out/omnis-helix-linux.zip \
  out/omnis-helix-windows.zip \
  out/omnis-helix-macos.zip

cd out/local-release
sha256sum -c SHA256SUMS.txt

Then run the same release-signature and provenance verification commands from step 1 against out/local-release.

For local calibration and demo reproducibility:

tools/guard_local.sh

Expected result: canonical demo bundles, leaderboards, and determinism checks are regenerated under out/guard/.

5) Inspect Bundle Provenance

Open the exported bundle or release archive and confirm:

• manifest.json exists and lists the expected files.
• Each manifest entry has a digest and size.
• Calibration profiles are present when a release artifact claims to include calibrated simulation outputs.
• Evaluation outputs are present when a release artifact claims to include evaluation results.
• Hashes shown in UI or CLI outputs match the manifest and checksum index.

Failure Handling

If any verification step fails, collect:

• the exact failing command,
• command output,
• operating system and Python version,
• artifact names,
• artifact hashes you computed locally.

Treat failures as release integrity issues until the digest, provenance, or reproducibility mismatch is explained.

Boundary

This release verification flow proves software artifact integrity, provenance, and replay consistency. It does not prove biological truth, clinical suitability, or real-world execution readiness.