Reference /Glossary

Glossary

Plain-English definitions for the terms used across these docs. One or two sentences each, in alphabetical order. Where a term has its own page, the definition links to it.

Terms

Action
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 checked against policy and recorded in an Action Receipt. See Actions & verbs.
Action receipt
A signed JSON object recording one action, the policy decision that gated it, who approved it (if anyone), and an action_hash over the content. Anyone can verify it offline with no HESO infrastructure. A receipt proves you authorized an action under your policy; it does not prove the action succeeded downstream. See Action receipts and the receipt schema.
action_hash
A BLAKE3 hash over a receipt’s canonical content, stored as 64-character lowercase hex. The field itself is stripped before hashing. The verifier recomputes it and compares; a mismatch means the content changed after signing.
Action verbs (the seven)
The fixed set of verbs an action can be: llm_call, tool_call, http_request, payment, data_export, account_change, and delete. See Actions & verbs.
Agent
An AI program that takes actions. An agent wrapped with HESO has every action captured, checked against policy, optionally routed for approval, redacted, signed into a receipt, and linked into the audit chain.
Approver
The authorized human who reviews a routed action and signs the decision with their own device-held key. Their verdict is one of approved, rejected, or escalated. The cloud holds no signing key. See Human approval.
Audit chain
The tamper-evident log receipts are appended to. Each receipt’s action_hash is a leaf, and consecutive entries are linked by hashing with BLAKE3. Altering any earlier receipt breaks every downstream link. See The audit chain.
BLAKE3
The hash function HESO uses for the content hash (action_hash) and for linking receipts in the audit chain.
Canonicalization (JCS / RFC-8785)
The deterministic way receipt content is serialized before hashing, following RFC-8785 (JSON Canonicalization Scheme), with action_hash stripped first. Canonical bytes make the hash reproducible across languages.
Co-sign / co-signature
The approver’s Ed25519 signature added alongside the operator’s. A receipt with a valid co-signature is L1. The operator signs the action under heso-action/v1\0 and the approver signs the same bytes under heso-approval/v1\0, so a signature can never be moved between roles. See Trust levels.
Commitment
The hash stored in place of a redacted field. In commit_and_reveal mode it is a 64-character hex BLAKE3 commitment you can later reveal and check; in destructive mode it is an empty string, never omitted. A malformed marker fails verification with MalformedRedaction.
Condition
A single typed test inside a rule, written as a field, an operator, and a value (plus a natural-language display). All conditions on one rule are AND’d; for OR, write two rules. See Conditions & operators.
Consistency proof
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 between two roots an observer pinned. See Transparency log.
Dangerous lane
Any of the four floored verbs: payment, delete, account_change, and data_export. Each carries a built-in floor a policy can tighten but never bypass. See Pinned floors.
Decision
What policy decided to do with an action, one of four: allow, block, redact, or require_approval (route to a human). See Policy & decisions.
Ed25519
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.
First-match-wins
The evaluation rule for a policy: rules are tried by ascending order, and the first one whose subject, verb, scope, and conditions all match decides the action. Nothing after it runs.
Floor / pinned floor
A built-in minimum decision the engine enforces on dangerous lanes. A policy may tighten a floor but can never allow-without-approval a floored lane; one that tries fails at policy load with a [FLOOR_BYPASS] error naming the offending rule and verb. See Pinned floors.
Inclusion proof
A Merkle proof that a specific receipt is present in the transparency log at a given tree size, checkable without the rest of the log. See Transparency log.
Operator
The party that runs the agent and holds the operator signing key. The operator signs every receipt; an L0 receipt is operator-signed only.
Operator (condition operator)
The comparison inside a condition, one of five: gt, lt, eq, contains, and regex. Written as the opfield of a rule’s condition. See Conditions & operators.
Operator 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, so a verifier can check the signature offline.
Policy
Your heso.toml file: an ordered list of [[rule]] blocks that decide what happens to each action. It is first-match-wins, and when no rule matches the default decision is allow. See Policy & decisions.
Quorum (k-of-n)
A human gate that needs k of n approvers (say 2 of 3) instead of one. It is still L1, carried in a multi_approval block with a threshold, a roster of eligible keys, and per-approver records. Fewer than threshold verified legs fails with ThresholdNotMet. See Trust levels.
Redaction
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.
Rule
One [[rule]] block in a policy. It carries an id, an order, an enabled flag, a subject, a verb, a scope, conditions, a decision, and (when it routes to a human) approvers and an SLA. It fires only when its subject, verb, scope, and every condition all match.
Scope
The host a rule applies to, written as a host glob or * for any host. One of the four things a rule matches on, alongside subject, verb, and conditions.
SLA
The sla_minutes field on a rule that routes to a human: how long a routed action may wait for a decision before it is treated as overdue.
Subject
Who an action belongs to, the first thing a rule matches on. Written as { kind = "any" } to match every agent, or pinned to a workflow or account with { kind = "...", value = "..." }.
Suspend / resume
How L1 approval works out of band. A gated action that routes to a human suspends instead of running and raises SuspendedError carrying its action_hash. You resume later with heso.resume(action_hash) and finalize once a decision exists. See Human approval.
Time anchor (trusted time)
An optional RFC-3161 timestamp (time_anchor) that binds when a receipt’s body existed. It is off by default; without it captured_atis the operator’s own clock (informational, not authoritative). A present anchor that does not verify fails with TimeAnchorUnverifiable; when policy marks trusted time required, an absent anchor fails with AnchorRequired.
Transparency log (RFC-6962)
An RFC-6962 Merkle tree over the receipt log. It produces inclusion and consistency proofs without revealing the rest of the log. See Transparency log.
Trust level (L0 / L1)
How strongly a receipt is attested. L0 is operator-signed only; L1adds an authorized human’s co-signature, either a single approver or a k-of-n quorum (both re-derive to L1, not higher). Trust is re-derived on every verify from the signatures that actually pass; a receipt claiming more than its signatures support fails with TrustLevelMismatch. See Trust levels.
Verb
The kind of an action, one of the seven fixed verbs. The verb is part of what a rule matches on. See Actions & verbs.
Verdict
The result of verifying a receipt. The verifier stops at the first gate that fails and returns a tag such as Valid, HashMismatch, InvalidSignature, or TrustLevelMismatch. See Verdicts.