Architecture

Base informatique Trusted en 8 packages de HELM, protocole d'exécution et priorité des politiques.

Architecture : référence technique de cette page.

Architecture

One thing to remember: HELM's entire trusted core is 8 Go packages. CI enforces that nothing else touches the governance boundary.

HELM is a fail-closed execution authority for AI agents. It sits between intent and effect — every tool call, sandbox execution, and self-extension passes through a governance boundary that produces signed, causal, deterministic proof.

Design invariants

Invariant	Mechanism
Fail-closed	Unknown tools, invalid args, drifted outputs → `DENY`
Deterministic	JCS (RFC 8785), SHA-256, Ed25519, Lamport clocks
Auditable	Every decision → ProofGraph node. EvidencePacks verifiable offline

Verified Planning Loop (VPL)

The canonical execution protocol for every tool call:

Request → Guardian (PEP)

If DENY → DenialReceipt → ProofGraph → 403

If ALLOW → SafeExecutor → Tool Driver → Canonicalize → Receipt → ProofGraph → Checkpoint (Proof Condensation)

Step by step

Model generates a tool call proposal
CPI (Canonical Policy Index) validates the proposal schema
PEP evaluates policy rules
DENY → signed DenialReceipt appended to ProofGraph → 403
ALLOW → SafeExecutor runs the tool driver
Effect is JCS-canonicalized and hashed into a Receipt
Receipt linked to the ProofGraph (causal DAG, Lamport-ordered)
Periodic Proof Condensation creates Merkle root checkpoints

Policy precedence

Policies compose in strict priority order. Lower layers cannot override higher ones:

Priority	Layer	Role
P0	Ceilings	Hard limits — cannot be overridden
P1	Policy Bundles	Organizational governance (signed)
P2	Overlays	Runtime, per-session, per-agent
CPI	Validator	Deterministic policy stack validation
PEP	Executor	Guardian enforces, Executor runs

P0 — absolute ceilings (budget maximums, forbidden effect types)
P1 — signed policy bundles (organizational governance)
P2 — runtime overlays (session-scoped, can only narrow P1)
CPI — validates composed policy stack for internal consistency
PEP — Guardian applies resolved policy, produces signed DecisionRecord

Trusted Computing Base (TCB)

The kernel TCB is 8 packages — the minimal trusted core. CI enforces forbidden-import gates to prevent scope creep.

Package	Purpose
`contracts/`	Canonical data structures (Decision, Effect, Receipt, Intent)
`crypto/`	Ed25519 signing, JCS canonicalization
`guardian/`	Policy Enforcement Point (PEP), PRG enforcement
`executor/`	SafeExecutor with receipt generation
`proofgraph/`	Cryptographic ProofGraph DAG
`trust/registry/`	Event-sourced trust registry
`runtime/sandbox/`	WASI sandbox (wazero, deny-by-default)
`receipts/`	Receipt policy enforcement (fail-closed)

Data contracts

Contract	Fields
DecisionRecord	Verdict, ReasonCode, PolicyDecisionHash, Ed25519 signature, LamportClock
Effect	ToolName, EffectType, InputHash, OutputHash
AuthorizedExecutionIntent	DecisionID, Guardian signature, TTL
Receipt	EffectHash, OutputHash, ArgsHash, PrevReceiptHash, LamportClock, Ed25519 signature
EvidencePack	Receipts, MerkleRoot, ProofGraphHash, Ed25519 signature

External interfaces

Interface	Endpoint
Standalone proxy	`POST /v1/chat/completions`, `GET /helm/receipts`, `GET /helm/proofgraph`
Kernel API	`POST /v1/chat/completions`, `GET /api/v1/proofgraph/sessions`, `GET /api/v1/proofgraph/sessions/{session_id}/receipts`
MCP gateway	`GET /mcp/v1/capabilities`, `POST /mcp/v1/execute`
Health check	`GET /healthz`

Deployment patterns

Pattern	Description
Sidecar proxy	`helm proxy` on `:9090` — single `base_url` change in your app
MCP server	`helm mcp serve` for MCP-native clients
Gateway	Full kernel/API surface on `:8080` for multiple agents/services
In-process	Embedded as a Go library

Next steps

Goal	Guide
Get running in 5 minutes	Quickstart
Understand conformance levels	Conformance
Review the threat model	Trust Model