Execution trace walkthrough

// TRACE

Stages

1. Request / intent - Caller submits POST /execute with surface, action, context, idempotency_key (see reference spec).
2. Runtime evaluation - Policy engine evaluates the frame against the active policy version on the hot path (runtime authorization, pre-execution).
3. Deterministic decision - Outcome is exactly one of PERMIT, DENY, or SILENCE for the same inputs and policy snapshot (deterministic authorization, decision model).
4. Receipt generation - A signed receipt binds the decision (PERMIT, DENY, or SILENCE) to request context hash and policy/evaluator references (receipts). Enforcement (EXECUTED / BLOCKED) is recorded separately by the runtime.

{
  "decision": "DENY",
  "decision_code": "TG_RISK_THRESHOLD_EXCEEDED",
  "surface": "spendCommit",
  "policy_hash": "4d2f7a9b1e...",
  "engine_version": "tg-engine@1.3.0",
  "protocol_fingerprint": "TG-01",
  "request_hash": "c38fa1c9ab...",
  "receipt_id": "9f0c1a7e2b...",
  "latency_ms": 42,
  "timestamp": "2026-04-17T15:32:10Z"
}

5. Verification - Verifiers check signatures and key material via key discovery; use Verify or verification docs for operational flows.
6. Execution or withhold - Runtimes record enforcement (EXECUTED / BLOCKED) separately from the receipt decision. Decisions DENY; enforcement is BLOCKED when execution does not proceed. Fail-closed integrations withhold on non-PERMIT.

// CONTRACT

What to read next

TG-01 reference specification · Decision vs enforcement · Receipt structure · Verify center · Architecture · Pricing