A receipt proves which contract the runtime evaluated, at which version and hash, against which observations, and what the verdict was. Ed25519 signs it, so anyone checks it offline without trusting the dashboard.

A receipt carries references to evidence, never raw provider payloads. It names the integration version, the provider API version, the evidence levels used, and the time of verification.

What does a receipt look like?

A VERIFIED receipt for stripe.refund.succeeded. The build signed this document with the public core test key and verified it. Every value comes from the signed integration package that this website renders.
{
  "schema_version": "1.0.0",
  "id": "rc_01ARZ3NDEKTSV4RRFFQ69G5FB1",
  "issued_at": "2026-09-05T14:03:26.006Z",
  "issuer": "provely-runtime",
  "operation_id": "op_01ARZ3NDEKTSV4RRFFQ69G5FAV",
  "intent": {
    "statement": "Refund the charge to the customer."
  },
  "contract": {
    "id": "stripe.refund.succeeded",
    "version": "1.0.0",
    "hash": "71492f92a1aa22d34ac87c685b08f0406364beb23e079da60b09d5ff94a7dff4"
  },
  "skill": {
    "service": "stripe",
    "skill_version": "0.1.0",
    "certification": "official"
  },
  "versions": {
    "provider_api_version": "2026-08-26",
    "runtime_version": "0.1.0"
  },
  "verdict": {
    "verdict": "VERIFIED",
    "terminal": true,
    "reason_code": "all_conditions_satisfied",
    "reason": "The evidence satisfies every condition of the contract.",
    "evidence_levels_used": [
      "E2"
    ]
  },
  "observations": [
    {
      "id": "obs_readback_1",
      "kind": "observation",
      "channel": "provider_readback",
      "evidence_level": "E2",
      "independence": "provider_readback",
      "digest": "723aefd14209efcc53cbc32bc3fa445e141470a1a1855283cd57bf5a40ffdc0e",
      "observed_at": "2026-09-05T14:03:26.004Z"
    }
  ],
  "attempt_count": 3,
  "verified_at": "2026-09-05T14:03:26.005Z",
  "signature": {
    "algorithm": "ed25519",
    "canonicalization": "jcs",
    "key_id": "provely-test-key-1",
    "public_key": "d75a980182b10ab7d54bfed3c964073a0ee172f3daa62325af021a68f707511a",
    "value": "73238e3362d9b11fb89d8c77d33820b9e27c6fee2416ab89fd5a9309930870c9138e0d059cea1182f226a8a9c43af2e19001ff3948d8be0ae9ab00cc8ceb0608",
    "payload_sha256": "6cefacc0d83aaea70c1ce58f24036187e6588e3ce9dfce8a9e87b214df773973"
  }
}

This receipt names the integration stripe at version 0.1.0, certification official, and the contract stripe.refund.succeeded at version 1.0.0. Read the stripe verification page.

Which evidence levels can a receipt name?

A receipt names the level of every observation it carries. A VERIFIED receipt must name at least one level above E0, the word of the agent.

A receipt names the evidence level of every observation it carries.
In words
  • E0 agent assertion: never sufficient.
  • E1 action response: the provider acknowledged the request.
  • E2 provider readback: the runtime read the resource back.
  • E3 provider event: the provider reported the change.
  • E4 independent system: a system outside the action path agrees.
  • E5 external outcome: the result is observable in the world.

Which checks does the validator run?

Six checks, in order. A receipt that fails one is rejected, and the reason code names which check refused it.

  1. The document validates against receipt.schema.json.
  2. The canonical JSON of the document without the signature member hashes to signature.payload_sha256.
  3. The Ed25519 signature verifies against the public key.
  4. The key id maps to that public key in your trusted key map.
  5. A VERIFIED verdict declares one evidence level above E0, and every declared level appears on an observation reference.
  6. A VERIFIED component names the channel that supports it.

Run provely receipt validate <file> against a key map that you control. Read the CLI reference for the steps and the exit codes.

The validator output
$ provely receipt validate rc_01ARZ3NDEKTSV4RRFFQ69G5FB1.json

contract hash    ok
canonical json   ok
signature        ok  key provely-test-key-1
key trusted      ok  from your key map
evidence claim   ok  E2 present on one observation

verdict          VERIFIED
exit 0

The conformance fixtures carry four forgeries. One is signed by a rogue key. One holds a tampered verdict with a repaired digest. One claims VERIFIED and carries no observation. The TypeScript, Python, and Rust validators reject all of them with the same reason codes.

A receipt states the contract hash in contract.hash. The published receipt schema requires a VERIFIED receipt to carry one observation reference with an evidence level of E1 or higher.

Source: Provely core schemas · retrieved 2026-09-05

Does a receipt contain the provider response?

No. It holds a reference to each observation: a digest, a channel, an evidence level, and a time. Raw evidence stays optional, encrypted, and short-lived.

How is the contract hash computed?

The runtime canonicalizes the document as RFC 8785 JSON without the hash member and takes the SHA-256. TypeScript, Python, and Rust produce the same bytes. The cross-language fixtures prove it.

Why is canonical JSON needed?

Three languages must sign and verify identical bytes. RFC 8785 fixes member order, number formatting, and string escaping. The fixtures cover the traps: -0, 1e-7, and UTF-16 code unit order.