How HELM Works
How HELM turns proposed actions into governed execution, receipts, and organizational proof.
How HELM Works
Key idea: HELM is an execution authority layer. In OSS form it starts as a kernel that sits between a proposed action and a side effect. In platform form it becomes the shared control plane around that same kernel for organizations that need approvals, packs, evidence operations, and jurisdiction-aware control.
The kernel pipeline
Every governed action passes through four stages:
| Stage | Component | Output |
|---|---|---|
| 1 | Intent Capture | Proposed action, identity, scope, context |
| 2 | Policy Check (PEP) | Deterministic verdict under policy and constraints |
| 3 | Verdict | ALLOW or DENY + reason code |
| 4 | Receipt | Signed receipt → ProofGraph → EvidencePack |
1. Intent Capture
HELM captures the proposed action before it becomes a side effect:
- tool or action identifier
- arguments and hashes
- caller identity
- optional organizational context such as
organization_id,scope_id, or principal scope
2. Policy Check (PEP)
The Policy Enforcement Point evaluates the request against deterministic rules:
Request → Schema validation (CPI) → Policy rules (PEP) → Verdict
If no rule matches, the default is DENY. HELM does not fall back to permissive behavior.
3. Verdict
The Guardian produces a signed decision record:
| Field | Meaning |
|---|---|
| Action | ALLOW or DENY |
| Reason code | Machine-readable explanation |
| Evidence | Canonicalized inputs and context |
| Signature | Ed25519 proof of decision integrity |
4. Receipt
Execution, or denial, becomes a receipt in the ProofGraph:
| Receipt field | Meaning |
|---|---|
EffectHash |
Hash of the effect or effect result |
ArgsHash |
Hash of canonicalized input |
PrevReceiptHash |
Causal link to prior receipt |
LamportClock |
Monotonic causal order |
ReasonCode |
Why the verdict was produced |
Signature |
Cryptographic proof |
Three guarantees
Fail-closed
If policy is missing, scope is invalid, schemas drift, or verification fails, HELM denies execution.
Deterministic
Same policy + same input + same context = same verdict.
Offline-verifiable
Anyone with the EvidencePack can verify the receipt chain, signatures, and replay surface without trusting a running server.
OSS, Platform, and the long thesis
HELM OSS
HELM OSS is the open execution kernel:
- fail-closed policy enforcement
- receipts and ProofGraph
- replay and verification
- adapters and integrations
HELM Platform
HELM Platform adds the shared organizational surfaces around the same kernel:
- approvals and operator workflows
- workspaces and packs
- Mission Control
- evidence operations
- jurisdiction-aware deployment controls
Long-horizon thesis
The long-term destination is broader than enterprise tooling. HELM is being designed as an organizational execution substrate for organizations where humans, agents, software, and policies become co-executors.
Next steps
| Goal | Guide |
|---|---|
| Understand OSS vs Platform | Platform Boundary |
| Deep technical reference | Architecture |
| Review trust assumptions | Trust Model |
| See a non-enterprise use case | Research Lab Operations |