Architecture
HELM's execution kernel, platform boundary, and organizational control model.
Architecture
One thing to remember: HELM keeps the trusted execution boundary small and deterministic, then layers shared organizational control around it.
HELM is a fail-closed execution authority. The OSS kernel governs proposed actions at the moment they become side effects. HELM Platform adds the control-plane surfaces that let organizations operate that kernel at scale.
Design invariants
| Invariant | Mechanism |
|---|---|
| Fail-closed | Unknown tools, invalid scopes, drifted outputs, or missing proof → DENY |
| Deterministic | JCS, SHA-256, Ed25519, Lamport clocks |
| Auditable | Every decision → ProofGraph node → EvidencePack |
| Boundary first | Shared UI and operations may change; the kernel contract must not |
Four layers
1. Proposal layer
Models, workflows, humans, and external systems propose actions.
2. Kernel layer
The HELM OSS kernel enforces:
- policy evaluation
- authority scope checks
- causal receipts
- replayable evidence
3. Platform layer
HELM Platform adds:
- approvals and operator inboxes
- workspaces, packs, and federation
- Mission Control / Studio surfaces
- evidence operations and public verification routes
4. Organizational layer
Longer-term HELM compiles organizational structure itself:
- OrgDNA / OrgGenome
- authority graphs
- jurisdiction matrices
- human+AI operating models
Kernel execution loop
The canonical execution protocol for a governed action:
Request → Guardian (PEP) →
DENYwith receipt
or
Request → Guardian (PEP) → SafeExecutor → Receipt → ProofGraph → EvidencePack
Step by step
- A model, human, workflow, or service proposes an action.
- CPI validates the structure and policy inputs.
- PEP evaluates policy and scope.
DENYproduces a signed denial receipt.ALLOWpasses the action to the executor.- The effect is canonicalized and hashed.
- The receipt is linked into the ProofGraph.
- Optional condensation and export create EvidencePacks.
Policy precedence
Policies compose in strict priority order:
| Priority | Layer | Role |
|---|---|---|
| P0 | Ceilings | Hard platform or safety limits |
| P1 | Policy bundles | Organizational governance |
| P2 | Overlays | Runtime, per-session, or delegated scope limits |
| CPI | Validator | Deterministic validation of the stack |
| PEP | Enforcer | Final allow / deny verdict |
Trusted Computing Base
The kernel TCB remains intentionally small.
| Package | Purpose |
|---|---|
contracts/ |
Canonical data structures |
crypto/ |
Signing and canonicalization |
guardian/ |
Policy Enforcement Point |
executor/ |
Safe execution |
proofgraph/ |
Causal receipt graph |
trust/registry/ |
Trust and key state |
runtime/sandbox/ |
Bounded execution sandbox |
receipts/ |
Receipt policy enforcement |
The control plane must depend on this boundary, not the other way around.
Public interfaces
| Interface | Purpose |
|---|---|
POST /v1/chat/completions |
Drop-in governed proxy |
GET /api/v1/proofgraph/* |
Sessions and receipts |
POST /api/org/genesis/* |
Organization bootstrap and activation |
GET /api/org/status |
Runtime status of organizational control surfaces |
POST /api/bootstrap/workspace |
Workspace provisioning |
GET /api/packs |
Pack and policy distribution |
Architectural truth
HELM starts as a kernel, but its strategic direction is not “tool-call proxy plus dashboard.” It is a stack with a strict foundation:
- Kernel proves governed execution
- Platform proves shared organizational control
- Reference systems prove the thesis under real load
Next steps
| Goal | Guide |
|---|---|
| Understand trust boundaries | Trust Model |
| Understand OSS vs Platform | Platform Boundary |
| Install the kernel | Quickstart |