Interactive examples
Check an AI agent’s claim before your business acts on it.
A support reply can promise a refund the policy excludes. A workflow can send the wrong attachment. Explore the policy case, then run a file check yourself.
Historical illustration · Moffatt v. Air Canada
Could the passenger request the fare difference after flying?
Scripted reconstruction of the 2024 decision. Tanilo had no role in the case. The findings shown here are preset.
The airline excluded requests made after travel was complete.
Case and sources
In 2024, the British Columbia Civil Resolution Tribunal awarded the passenger C$650.88 in damages, plus interest and fees. This scripted Tanilo reconstruction paraphrases the historical advice and policy. Tanilo had no role in the incident.
Tribunal decision · Case summary“I attached the approved version.”
!Different file. The example workflow holds the send.
Simplified browser check using sample inputs. The file example hashes the two text samples. No API call or receipt.
Claim to check
“I’m sending the approved file.”
What else can an agent get wrong?
The record
Verify a signed receipt.
Check the signature on a real Tanilo receipt. Then change one byte and check it again.
A valid signature shows that the signed record has not changed and verifies against the selected key. It does not establish that the result is correct, that an action was authorized, or that the receipt conforms to every rule of its profile.
Check it on your own machine
Install tanilo-receipt-verify 0.2.4 or later and follow the verification guide. Expected output: valid sha256-baac7b81…. Earlier instructions are kept in the history of this check.
Historical signature demo · On 2 October 2026, /evaluate assessed the claim “Paris is the capital of France” under the gate rules then in use. This receipt belongs to that model assessment.
Runs in this page against the key set published at tanilo.io. If the key set can’t be fetched, the terminal says so and nothing is marked valid.
For engineers
When the amount matches but the network differs
Tanilo’s x402 guard added checks for the asset and network named in the payment terms. Version 0.2.0 checks these before payment creation.
The rate matches. One condition disappeared.
At fifty cents a message, the agent prepares a $400 order for 800 messages. The supplier agreement requires at least 1,000. The extracted term leaves out that condition.
Source clause structured from the full text below
- Price
- USD 0.50 per message
- Minimum order
- 1,000 messages per order
Extracted term what the extraction returned
- Price
- USD 0.50 per message
- Minimum order
- Minimum order missing
“Each order must cover at least 1,000 messages.”
Complete synthetic clause
“Supplier charges USD 0.50 per message. Each order must cover at least 1,000 messages.”
Condition omitted
The order falls 200 messages short. A reviewer can trace the difference to the sentence in the agreement.
Proposed total · $400.00
Requires review
About the prototype
This illustration uses a fictional agreement. Results from the local prototype are unpublished. It runs locally; it is not a public endpoint and is separate from /evaluate. Its findings are unsigned assessments that require review; they don’t establish that a term is correct and never approve an action.
States it reports: verified, contradicted, indeterminate, not_evaluated. It is not offered for sale.
What do you need checked?
Tell us what your workflow produces, what it should match, and what happens when it gets something wrong.