What a Tanilo receipt does not prove

This page covers the contract price and spend cap checks. A signed Tanilo receipt records the inputs you supplied (or digests that identify them), the rule version, and each check's result: verified, contradicted or indeterminate. Here's what that shows, and what it doesn't.

What it shows

That the signed bytes verify under the named public key and haven't been altered. To attribute that key to Tanilo, verify against a key set you have authenticated as Tanilo's. The published set is at tanilo.io/.well-known/jwks.json.
What result Tanilo recorded for the supplied inputs under the named rule version. Anyone holding the same inputs can recompute it using the same published rule version. Recompute the check and compare its result and evidence with the signed record, because signature verification alone doesn't establish that the recorded result agrees with the rule.

What it doesn't prove

That the terms or the cap are genuine. You supply them. The check doesn't establish that they're authentic, complete, current or approved, or that a contract was validly signed. The price check also can't detect discounts, rebates, minimum charges or other pricing conditions left out of the structured terms you supply.
That the cap applies. The check doesn't establish that the supplied cap applies to this seller, item or account, or that already_spent is complete or current. The spend cap check records seller, sku and cap_id, but doesn't use them to establish that.
That the offer is still available, or that its supplied timestamp is authentic. Neither check watches for later changes.
That anything happened next. A receipt records a check; it doesn't establish that the check came before any particular action. It doesn't show that the agent relied on the result, that a payment was made, or that the seller delivered.
That the payment matched the offer checked. That comparison belongs in your workflow. See "What if the price changes between the check and the payment?"
That the purchase was a good idea. For these checks, verified means one of two things: the offered unit price equals the unit price of the applicable supplied term, or the offer's total is within the remaining cap calculated from the inputs you supplied. It doesn't judge value, need or fairness, and it doesn't authorize a payment.
Who the buyer or seller is. The checks compare amounts; they don't verify identities.
That any tax amount or tax treatment is correct. The checks calculate no tax.
That every purchase was checked. A set of valid receipts doesn't establish that every purchase was checked or that the set is complete.
That the content is true because it's signed. A valid signature establishes which key the signed bytes verify under and that those bytes haven't been altered. It doesn't by itself identify a person or organization, and it doesn't make the inputs correct.

When there's no receipt

Input that fails a check's schema validation gets HTTP 422 (claim_not_deterministic) and no receipt. If the service has no signing key, it answers HTTP 503 not_signed with unsigned check results, and no receipt is issued. Neither is itself a finding that the price was wrong or the cap exceeded, though unsigned check results can still report a contradicted result.

Handle receipts as commercial records

Receipts are signed, not encrypted, and they contain prices and other commercial details, so share them accordingly. Keep the complete original input, and keep access to the rule version the receipt names, if you want to replay the check later.