Helix StudioGenome IDE
← Docs
Helix CLI docs
Browse Helix CLI docs

Enterprise Proof (procurement-friendly index)

This folder is a dry, auditable index of Helix’s trust posture: security posture, threat model, signing/verification model, and what receipts do (and do not) guarantee.

Security posture

  • Security policy: policies/security.md
  • Repository security disclosures: ../SECURITY.md
  • Release provenance + SBOMs: policies/release_provenance.md

Threat model

  • Threat model: threat_model.md

Signing + verification model

  • Plugin signing model: policies/plugin_governance.md
  • Validation verdict signing:
    • Algorithm: Ed25519
    • Signed bytes: canonical JSON of the verdict payload with signature=null (whitespace/key-order proof)
    • Verifier enforces the declared canonicalization (helix.canonical_json_bytes.v1)
    • Verifier rejects unknown canonicalization identifiers
  • Verification commands:
    • Single receipt: helix verify verdict path/to/verdict.json --pubkey publisher.pub
    • Bundle receipts: helix verify bundle helix-reference-validation-bundle-<TAG>-linux.tar.gz --json-out verify_bundle.json

Receipts (what they guarantee)

If helix verify bundle … succeeds, then (at minimum):

  • Every verdict.json is signed by the publisher key (or the explicitly pinned --pubkey).
  • Every receipt’s bytes match the release inventory (bundle.index.json SHA-256).
  • Every receipt’s semantics match the release inventory (expectedStatus).

Receipts do not claim biological truth; they prove computational provenance + integrity of the recorded verdicts and their declared expectations.

Deployment acceptance gates (Teams/Enterprise)

For any Teams/Enterprise deployment, treat the published reference validation bundle as a platform contract:

  • Public validation packs must run through the remote lane
  • Receipts/artifacts must land in the artifact store + run registry
  • The deployment is “healthy” only if helix verify bundle … passes against the published reference bundle