Execution authorization flow

// PIPELINE

REQUEST - EVALUATION - DECISION - SIGNED RECEIPT - OFFLINE VERIFICATION

An automation system submits an execution request; TrigGuard evaluates policy deterministically; the outcome is exactly PERMIT, DENY, or SILENCE; a signed receipt binds the decision; verification uses the issuer public key and never phones home to TrigGuard.

POST /execute
  -> deterministic evaluation (PERMIT | DENY | SILENCE)
  -> signed receipt (Ed25519)
  -> offline verification (issuer public key)

1. Execution request

Production path: POST /execute with surface, action, and binding context (hash) the authority evaluates.

{
  "surface": "deploy.release",
  "action": "promote",
  "context_hash": "sha256:..."
}

2. Deterministic evaluation

Evaluation yields only PERMIT, DENY, or SILENCE. Fail-closed: anything else or transport failure withholds execution.

3. Signed receipt issuance

Expect fields such as receipt_id, decision, timestamp, surface, context_hash, signature / receiptSignature, key_id, payload_hash on issued receipts (exact wire shape: receipt schema).

4. Offline verification

Load keys from /.well-known/trigguard-keys.json, run the same canonical JSON + Ed25519 path as the CLI, or use the Receipt Explorer. This receipt can be verified independently using the issuer's public key. Verification requires no callback to TrigGuard.