Helix Principles (decision trust infrastructure)
These principles are the product. The GUI, runners, and registries are implementations.
1) Decision authority, not compute
Helix exists to be a verifiable authority for in‑silico design decisions: “what was decided, under which policy, with which semantics, on which backend, and can it be replayed offline?”
2) Fail closed, always
If provenance, policy pinning, determinism claims, signatures, or schema validity are missing or ambiguous, verification must fail. No “best effort” green paths.
3) Offline verification is sacred
Any reviewer must be able to verify a bundle/proof without trusting Helix servers. Online services can distribute artifacts and policies; they must not be required to establish trust.
4) No artifact without a contract identity
Every emitted unit of value must carry a verifiable contract identity:
- Prefer an embedded, schema‑stamped header.
- If embedding is impossible, emit a cryptographically linked sidecar and make verification fail if separated.
No lingering exemptions.
5) Determinism is a product feature
Determinism is not implied. It is declared, labeled, and tested:
- Stable ordering and formatting
- Fixed seeds (when applicable)
- Backend fingerprints
- Explicit determinism classes and failure semantics
6) Policy is code (pinned, hashed, reviewable)
Policies gate what may be claimed or exported. They must be:
- Versioned and content‑addressed
- Reviewable like code
- Bound to artifacts via the contract identity
7) Receipts are products
Signed receipts and reference validation bundles are first‑class outputs. Downstream systems should be able to treat “verifier‑clean + receipt‑present” as a programmable acceptance gate.
8) Drift is not a bug; it’s a proof object
When outputs change, Helix should produce a minimal, reviewable explanation:
- One‑screen summary (terminal / single Studio pane)
- Causal frontier (run graph)
- Shareable proof bundle that verifies offline
If a reviewer must open raw logs to answer “what changed and why?”, the UX is failing.
9) Stay inside the positioning boundary
Helix is pre‑clinical, in‑silico simulation and exploration only. Language and feature scope must stay consistent with docs/positioning.md and docs/non_goals.md.
10) Prove it in CI
Every major change should have explicit gates and artifacts:
- Determinism/trust checks
- Offline bundle verification
- Drift proof generation + verification
- Schema contract tests (and visual/CUDA smokes where applicable)