// TRACE LOOKUP EXAMPLE
// How It Works
Execution Receipts and Independent Verification
Execution receipts are self-contained proof of what TrigGuard evaluated and decided. With cached public keys, verification is local and independent: teams can validate integrity without calling TrigGuard during audits or incident review.
1. Fetch Keys Once
Load public keys from /.well-known/trigguard-keys.json. Cache locally.
2. Parse Receipt
Extract the signature and key_id from the receipt JSON.
3. Verify Receipt
Use Ed25519 to verify the signature against the canonical payload.
4. Check Expiry
Ensure the receipt hasn't expired (check expires_at field).
// Key Discovery
Signature Verification and Integrity
TrigGuard publishes signing keys at a well-known URL so signatures on receipts can be validated cryptographically. Keys rotate periodically while prior keys remain available long enough to verify historical receipts.
GET https://api.trigguardai.com/.well-known/trigguard-keys.jsonKey Rotation
Keys are rotated quarterly. Deprecated keys remain available for 90 days after rotation to allow verification of older receipts.
// Trust Model
Why Verification Matters for Automated Decisions
Verification does not require TrigGuard to be online. Your audit trail is cryptographic proof of policy outcome, not a live query to a control plane. This makes execution decisions independently verifiable across CI, runtime, and compliance workflows.
DEMO MODE — This page demonstrates the verification flow using example keys. Production verification requires fetching your organization's actual public keys from /.well-known/trigguard-keys.json.
// Related Verification Paths
Receipt model · Verification docs · Gate authorization · Verify product