> ## Documentation Index > > Fetch the complete documentation index at: https://lithi.ai/llms.txt > > Use this file to discover all available pages before exploring further. --- title: Receipts and provenance description: >- The usage receipt, the delivery proof and the invoice are three separate objects. Verify each signature and contract release with released tooling, and read the lineage the bundle exposes. route: /docs/compute/results/receipts-and-provenance page_id: docs-compute-results-receipts-and-provenance page_type: reference content_layer: technical reference surface_profile: technical_reference audience: Integrators and finance owners reconciling Compute evidence voice: D reader_question: Which object proves what, and how do I verify it? primary_action: Verify the receipt signature with your released client source_locale: en-US source_status: APPROVED source_version: docs-compute-results-receipts-and-provenance-en-us-2026-09-05-v1 last_updated: '2026-09-05' robots: index claim_registry_pinned: true claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write" --- ## Three objects, three claims | Object | Where it lives | What it proves | What it does not prove | | --- | --- | --- | --- | | Usage receipt | `receipt.json` in the bundle | The job ran under your approved quote and account, at the approved price | That any business judgment inside the result is correct | | Delivery proof | The delivery record for a destination write | Bytes reached a named destination and the provider committed them | That the compute run was sound, or that anyone read the file | | Invoice | Your commercial records | What was billed, under which commercial state | That payment settled | They are produced by different events and can move independently. A signed receipt with no delivery proof is a completed run that was never written out. ## Verifying a signature Verification runs through the released client you already use, not through a separate tool. Each released client carries the verification path for its language, and the exact package name and version is listed on the client page. Check three things together. - The signature over the receipt projection. - The contract release the receipt was written against. - The digests in `provenance.json` that the receipt references. A signature that verifies against an unexpected contract release is not a pass. Read the release before you accept the signature, because the meaning of the fields is bound to it. ## Version and release fields Every response envelope carries `request_id`, the operation, the contract release, a typed state, an evidence class, `observed_at`, `valid_until` and a structured `next_action`. Pin your reader to the release you tested against. When the release changes, read the change before your reader treats an unknown field as absent. Every mutable current row carries a non-decreasing version. A lower version never supersedes a higher one, so a late reply cannot rewrite what you already hold. ## What provenance exposes `provenance.json` carries digests of the input, the workflow, the model, the schema and the envelope. Digests identify; they do not reveal. That is the whole lineage you get, deliberately. The bundle exposes customer-safe lineage only, and never internal execution detail — you never manage or see how the work was carried out. Your input snapshot is identified by its `version_id` and `content_sha256`. That is what lets you prove which bytes the run actually read. ## Reconciling a receipt against an invoice Match on the job reference and the usage recorded in `lithi_usage`, not on wall-clock time. Runs and billing periods do not share boundaries. Commercial state is tracked separately from job state and moves through its own milestones: `INVOICE_FINALIZED`, `ERP_CREATED`, `ERP_APPROVED`, `PAYMENT_INITIATED`, `MERCURY_FUNDS_CONFIRMED`. Only a current Mercury read-back advances the Lithi payment projection to paid. A `Paid` label in your own finance system is an annotation, never settlement. ## What a receipt cannot be asked to do A receipt proves its declared evidence and nothing beyond it. It is not a quality opinion, and it does not certify the content of the result. It also carries no task content. That is what makes it safe to keep in your own records and safe to quote to support. When you contact support, the receipt reference and the job reference are enough. Never send a payload dump, a key, a signed link or bank details. ## Next, verify the bytes A signature proves the receipt. It does not prove you downloaded the whole bundle intact. - [Download and verify a result](/docs/compute/results/download-and-verify) — byte counts and declared integrity before signatures.