Skip to main content

delta / mandate

delta mandate is a cryptographic verification system for agentic commerce. It ensures that proposed agent purchases respect the user's cryptographically signed intent.

The user signs an intent. An agent proposes a candidate solution. delta mandate extracts evidence from the proposal, evaluates it against the intent in a zero-knowledge proving environment, and produces a proof — without revealing the intent's private details.

Throughout these docs, "operator" refers to the company integrating delta mandate — typically a platform offering agentic commerce as a service.

This page walks through the lifecycle of an intent. For the API surface and CLI setup, see the API Guide; for the system as a whole, see the Architecture.

Concepts at a glance​

A delta mandate flow involves five primitives:

  • Template — a reusable policy definition: an intent schema, an evidence schema, and constraints, written in the Policy Engine DSL. The operator registers templates once. (more)
  • Intent — a signed declaration of what the user accepts; references a template. (more)
  • Proposal — an agent's candidate solution for an open intent. (more)
  • Evidence — structured data extracted from a proposal, matching the template's evidence schema. (more)
  • Proof — the composite artifact attesting that a proposal satisfied an intent. (more)

Intent Lifecycle​

1. Submit a signed intent​

An intent is a signed JSON document specifying what the user wants. Either the user signs the intent themselves using their own key, or the operator signs it on their behalf.

The intent payload has three fields:

  • id — a UUID assigned by the caller
  • template_id — identifies the template that defines the rules for this intent
  • attrs — the input values that parameterize the template (the fields are defined by the template)
{
  "payload": {
    "id": "550e8400-e29b-41d4-a716-446655440000",
    "template_id": "3mJr7AoLXfFj...",
    "attrs": {
      "fields": {
        "max_price_cents": 5000,
        "category": "pullover"
      }
    }
  },
  "signature": { "..." }
}

Once signed, the intent is submitted to the prover — either directly by the user, or forwarded by the operator:

guardrail-prover intents submit --json-body signed_intent.json

2. Submit a proposal​

The agent proposes a solution to an open intent. It discovers open intents either by receiving them from the operator's platform or by querying the prover directly (GET /intents/<intent_id>), then submits a proposal — either directly or via the operator:

guardrail-prover proposals submit \
  --intent-id <intent_id> \
  --url <proposal_url>

Once received, the prover calls the operator's evidence extraction server — which must implement the Evidence Extraction API (evidence-openapi.json) — to extract structured evidence from the proposal URL. It then evaluates that evidence against the template and intent, and generates a ZK proof.

3. Query the outcome​

The operator polls the verifier until the intent reaches a terminal state:

guardrail-verifier intents get --intent-id <intent_id>

The response carries a status field of success, failure, or expired — see the OpenAPI spec for the full shape of each variant.

On success, the operator retrieves the proof:

guardrail-verifier proofs get --intent-id <intent_id>

The proof contains the signed intent, the proposal, the extracted evidence, and the ZK proof data — sufficient to independently verify that the proposal satisfied the intent:

{
  "sp1_proof": [/* binary proof bytes */],
  "evidence": { "fields": { "category": "pullover", "price_cents": 4200, "size": "XL" } },
  "signed_intent": { "payload": { "..." }, "signature": { "..." } },
  "proposal": { "intent_id": "550e8400-...", "url": "https://..." }
}