Principal
The party whose intent the system enforces — the user signing a budget, the org delegating a procurement decision. Identified by the public key whose signature appears on the intent.
Docs
Vocabulary primer for the mandate stack. Each term links to the source-of-truth doc that defines it — this page exists so a first-time reader can scan the concept space in 5 minutes.
Agent
The party proposing operations on behalf of the principal — typically an LLM-driven agent with access to external systems. Untrusted by construction; every proposal is checked against the principal's policy before it's allowed to settle.
Policy template
A small, declarative document with three blocks: an `intent` schema (fields the principal will sign), an `evidence` schema (fields extracted from the agent's proposal), and a `requires` block of constraints over both. Compiled to bytecode and identified by a base58 SHA-256 hash.
template_id
Base58-encoded SHA-256 hash of the canonical bytecode of a policy template. The same template always produces the same id; an id always identifies one template. Both intents and proofs reference templates by id, not by source.
Intent
The principal's signed commitment: a `template_id` plus the field values that fill the template's `intent` schema. The signature binds the principal to those specific limits, against that specific template.
Proposal
The agent's concrete suggestion — usually a URL or transaction payload pointing at one specific operation. Carries no privileges by itself; gains meaning only when paired with evidence extraction and policy evaluation.
Evidence
The structured data extracted from a proposal that fills the policy template's `evidence` schema — price, brand, delivery date, etc. Extraction is out-of-band; the engine only checks that the values match the schema and satisfy the constraints.
Policy engine
The Rust crate that compiles templates and evaluates them. Two free functions: `compile_source(&str)` and `evaluate_policy(&template, &intent, &evidence)`. Pure evaluator — checks schemas + constraints, doesn't validate signatures.
ELF / elf_id
The compiled SP1 zkVM program that runs the policy-engine evaluator inside the prover. Identified by `elf_id` (its hash); the corresponding verifying key is published when the ELF is registered with the remote prover.
Proof
A four-part bundle: the zero-knowledge proof emitted by SP1, the signed intent, the evidence, and the proposal. Verifiable on its own — any party with the verifying key can confirm the bundle is internally consistent and that the constraints held.
Prover
The agentic-guardrails service that accepts intents and proposals, runs the in-zkVM evaluator, and emits proofs. Streamed via gRPC for downstream consumers; long-running operations are async.
Verifier
The agentic-guardrails service that accepts proofs, checks them with the verifying key, and surfaces the verified stream to whatever needs to act on the result — settlement, audit log, on-chain bridge.
Source docs
- agentic-guardrails — Prover + verifier; proof structure; APIs.
- policy-engine — Compiler + evaluator; template language; CLI.