Compute
Receipts and provenance
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.
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.jsonthat 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 — byte counts and declared integrity before signatures.