Cryptographic verification runs locally against published keys. Multi-key rotation schema for gateway-issued receipts is in private beta.
PROBLEM
Authorization without independent confirmation is not trustworthy
TrigGuard authorizes irreversible actions before they execute and emits a signed receipt at the moment of decision. Verify is the public confirmation surface for that decision: any system, anywhere, can prove the action carried a valid TrigGuard authorization.
Logs can be edited, policy state can drift, audit trails can fragment across tools. The signed receipt and its independent verification path are how TrigGuard remains accountable to the systems it controls.
WHAT VERIFY DOES
Independent confirmation of TrigGuard authorization
Verify confirms that receipts issued by TrigGuard are intact, signed by the expected key material, and bound to the decision context that authorized execution. It does not authorize, dispatch, or enforce; authorization happens upstream at the decision boundary.
Capabilities
- Receipt shape conformance
- Ed25519 signature validation over canonicalized payload
- Public-key resolution via
/.well-known/trigguard - Offline verification once keys are cached
HOW IT WORKS
Receipt and signature validation pipeline
Verify is the product surface for independent confirmation. Operational verification workflow is canonical at /verify; receipt schema semantics are canonical at /protocol/receipts and /protocol/spec.
EXAMPLE
Verify a receipt offline
Use the canonical verification workflow on /verify for browser-based checks and /docs/verification for CLI and key-discovery procedure details.
INTEGRATION
Receipt Verification Infrastructure Integration
RELATED LINKS