Glossary

One thing an agent does that HESO captures and gates — an LLM call, a tool call, an HTTP request, a payment, a data export, an account change, or a delete. Every action is evaluated against policy and recorded in an Action Receipt. See Actions & verbs.

The kind of an action, drawn from a fixed set: llm_call, tool_call, http_request, payment, data_export, account_change, and delete. The verb is part of what a rule matches on.

What policy decided to do with an action: allow, block, redact, or require_approval — in plain language, allow, block, redact, or route-to-human. See Policy & decisions.

Your heso.toml file: an ordered list of [[rule]] blocks that decide what happens to each action. It is first-match-wins, and an unmatched dangerous lane defaults to require_approval. See Policy files.

One [[rule]] block in a policy. It carries an id, an order, an enabled flag, a subject, a verb, a scope, a list of conditions, a decision path, and — when it routes to a human — optional approver labels and an SLA. A rule fires only when its subject, verb, scope, and every condition all match.

A single typed test inside a rule, written as a field, an operator, and a value (plus a natural-language display). The engine evaluates gt, lt, gte, lte, eq, neq, in, not_in, exists, and matches. See Conditions & operators.

The evaluation rule for a policy: rules are tried in order, and the first one whose subject, verb, scope, and conditions all match decides the action. Nothing after it runs.

A built-in minimum the engine enforces on dangerous lanes — payments, deletes, account changes, and large data exports. A policy may tighten a floor but can never allow-without-approval a dangerous lane; one that tries is rejected at load with a [FLOOR_BYPASS] error naming the offending rule and verb. See Pinned floors.

The unit of HESO: a signed JSON object recording exactly one action, the policy outcome that gated it, who approved it (if anyone), and an action_hash that pins the bytes. It is offline-verifiable — anyone can check it with no HESO infrastructure. See Action receipts and the receipt schema.

A BLAKE3 hash over a receipt’s canonical bytes, stored as lowercase 64-character hex. The field itself is stripped before hashing. The verifier recomputes it and compares it to the embedded value; a mismatch means the content changed after it was signed.

The deterministic way receipt content is serialized before hashing, following RFC-8785 (JSON Canonicalization Scheme), with action_hash stripped first. Canonical bytes are what make the hash reproducible across languages.

The hash function HESO uses for the content hash (action_hash) and for linking receipts in the audit chain.

The signature scheme HESO uses. The operator signs every receipt; at L1 the approver adds a second Ed25519 signature with their own device-held key.

The Ed25519 key the operator signs receipts with. Its public half appears as the receipt’s agent identity and in the operator signature entry. Verifying the operator signature against the content is gate four of the verify order.

The authorized human who reviews an action routed to them and signs the decision with their own device-held key. The cloud holds no signing key. See Human approval.

The Ed25519-signed artifact an approver returns when they decide on a routed action. It ties the decision to the approver’s key and folds back into the receipt as a co-signature.

The approver’s Ed25519 signature added alongside the operator’s. A receipt with a valid co-signature is L1. If the co-signature is present but does not check out, verification fails at gate five with invalid_approver.

How strongly a receipt is attested. L0 is operator-signed; L1adds an authorized human’s co-signature. Trust is re-derived on every verify from which signatures actually pass — a receipt claiming more than its signatures support fails with trust_mismatch. There is no L2 or L3 yet. See Trust levels.

The tamper-evident log receipts are appended to. Each receipt’saction_hash is a leaf, and consecutive entries are linked by hashing. Altering any earlier receipt breaks every downstream link. See The audit chain.

The link between consecutive audit entries: chainHash = BLAKE3(prevChainHash ++ actionHash). The first entry (sequence zero) uses the literal genesis as its previous chain hash.

An append-only Merkle tree over the receipt log, built with SHA-256 per RFC-6962. It produces inclusion and consistency proofs without revealing the rest of the log. See Transparency log.

A Merkle proof that a specific receipt is present in the transparency log at a given tree size, checkable without the whole log.

A Merkle proof that a later state of the transparency log is an append-only extension of an earlier one — nothing already logged was removed or rewritten.

Keeping sensitive fields off HESO’s servers by removing or committing to them before the receipt is signed. Two modes: destructive drops the value entirely; commit_and_reveal replaces it with a commitment you can later reveal and check. See Redaction.

The hash stored in place of a redacted field. In commit_and_reveal it is a 64-character hex BLAKE3 commitment; in destructive mode the commitment is an empty string, never omitted. A malformed marker fails verification at gate six with redaction_malformed.

The local file next to an action that holds redacted values or reveal data. It keeps secrets with you instead of on the control plane (HESO’s servers), and the receipt still verifies.

The queue of receipts waiting to be pushed to the cloud. Pushing to the API returns an outbox result that says whether each receipt was accepted; the server re-verifies before it accepts.

The result of verifying a receipt. The verifier stops at the first gate that fails and returns a state such as valid, hash_mismatch, invalid_signature, or trust_mismatch. See Verdicts.

An agent wrapped with HESO. Every action it takes is captured, checked against policy, optionally routed for approval, redacted, signed into a receipt, and chained into the audit log.

An Ed25519 keypair that signs receipts — the operator’s key, or an approver’s device-held key at L1. Its public half is embedded so a verifier can check the signature offline.

A label on an action naming the broader process it belongs to (for example a vendor-payout run). A rule’s subject can target a specific workflow.

A label on an action identifying the account it touched. Like workflow, a rule’s subject can target a specific account.

The host a rule applies to, written as a host glob or * for any host. It is one of the four things a rule matches on, alongside subject, verb, and conditions.