Verification Reference
Verification
Understand what content_hash means and what --verify guarantees.
What --verify Does
- The CLI sends a simulation request and receives a decision plus a receipt from the ATF API.
- It re-serializes the response payload locally using deterministic, canonical ordering.
- The resulting digest is compared to the
content_hashreturned by the server. A match confirms integrity. - Verification is deterministic and reproducible. The same input and policy result always produce the same hash.
- No client secrets are required. Any tool that follows the same canonical encoding can independently verify a receipt.
What content_hash Represents
content_hash is a deterministic fingerprint of the receipt-relevant content. It captures the fields that define the decision, serialized in a stable, canonical order.
For the same input and policy result, the hash is identical across runs, environments, and machines. This stability is what makes independent verification possible.
The primary purpose is tamper detection. If any field in the receipt is modified after issuance, the recomputed hash will not match the original content_hash, and verification fails.
Verification Flow
Each step is deterministic. The final verify step recomputes the hash locally and compares it to the server-provided value.
What Is Proven vs. Not Proven
Proven
- Receipt integrity matches the deterministic content hash.
- Decision payload is internally consistent.
- Verification can be reproduced by anyone running the CLI.
Not Proven
- Underlying policy is “correct” for your business needs.
- Upstream RPC or provider behavior.
- External market conditions.
Request Tracing (request_id)
Every simulation returns a request_id, a unique correlation handle for that request.
Use it to tie together logs, receipts, and API calls across your pipeline. When debugging or auditing, the request_id is the fastest way to locate the exact decision and its associated receipt.
In production, storing request_id alongside your internal transaction records creates a clear audit trail from intent to enforcement.
How to Use This in Production
Three practical patterns for integrating verification into your workflow:
CI checks for deterministic outputs
Run the CLI in your CI pipeline and assert that verified is true before merging or deploying. Any mismatch fails the build.
Agent pipeline gate
Before your agent executes a transaction, require verified: true in the ATF response. If verification fails, halt execution and alert your operations team.
Receipt archival for audit
Store the full receipt JSON alongside the request_id and content_hash in your own database. Re-verify at any time to confirm nothing has changed.
Don't trust, verify.
Next Steps
Protect an intent, receive a receipt, and verify it end-to-end.
Run your first simulation and verify a receipt locally.
The formal RFC-style contract for receipt structure and hash rules.
See how verification evolves across planned phases.
Review threat model, disclosure policy, and audit status.
A stable, canonical receipt you can inspect and share.