Lithi Receipts
What a Lithi Receipt tells you about your work and its outcome, and what it cannot tell you about quality, payment or privacy.
A Lithi Receipt records an action or outcome and the evidence tied to it. Use it to check what happened to the work you requested. For example, a receipt can show that a result was accepted after named checks; it does not tell you whether that answer is useful without the review your task requires. It is not the result file or an invoice.
Match the receipt to the work
Start with the receipt reference associated with your account and result. Check the recorded outcome and time. Compare the work and result references with the ones you intended to review, rather than relying on a screenshot from another run.
A receipt can bind the recorded state to policy, release, verification, or result evidence. The fields depend on the receipt's purpose. A digest is a fingerprint of particular bytes; it is not a copy of the full content, an encryption key, or proof of every surrounding event.
Customer-facing evidence should not require you to disclose private prompts, message bodies, keys, signed transfer links, provider identities, or exact Mac locations. Share only the safe reference needed for your question.
Read the outcome before using the result
| Recorded outcome | What to do |
|---|---|
| Success | Match the accepted result and review the checks actually covered. |
| Refusal or rejection | Read the reason and the permitted next action. It is not successful execution. |
| Failure, cancellation, or expiry | Check what ended and whether any earlier accepted work remains. Do not assume a refund or complete erasure. |
| Missing or mismatched evidence | Stop relying on the record and ask for clarification using its safe reference. |
For batches, inspect item outcomes and exceptions separately. A receipt covering a batch is not a blanket success verdict for every item. Failed, abstained, disputed, and missing items do not become accepted simply because other items completed.
Know the limits of the evidence
A valid signature supports the signer and bytes covered by its verification rules. It does not prove truthful usage counts, complete observation, or objective answer quality by itself. Use the result's actual verification and human-review requirements for consequential decisions.
The descriptor check confirms that the service names a delivered result for the submitted job; it reads no artifact bytes. It is separate from transfer, byte, decryption, schema, coverage, and destination checks, and task-quality evaluation remains outside the Kit. See result file verification for the checks and limits.
A provider's participating Mac is not a confidential-computing enclave. Receipt integrity does not prevent a privileged owner from inspecting ordinary execution memory. Encryption, runtime admission, and host confidentiality are separate questions.
Receipt evidence also does not prove that work ran in the closest town, that an environmental benefit occurred, or that a payment settled. Customer charges, provider earnings, and bank payment confirmation have their own records. A receipt alone does not mean the work is recorded on a blockchain.
Completeness and confidentiality are separate from integrity
A receipt records the checks performed over the population it names. It does not establish that nothing else happened, that everything was inspected, or that an omitted item is a zero. "Not inspected" and "nothing found" are different results, and a receipt should let you tell them apart.
Confidentiality is a separate question from integrity. Receipt evidence says a stated check passed over stated bytes; it says nothing about who could read those bytes while they were processed.
These records answer different questions:
| Question | Record to read |
|---|---|
| How many times was work tried? | Attempt history. |
| Which outputs passed the required checks? | Accepted-work evidence and recorded exceptions. |
| What counts toward the customer bill? | Accepted usage under the signed quote. |
| Which input groups could an owner read? | Recorded access grants, counted across that owner's Macs and attempts. |
A failed attempt can still disclose input. A retry does not erase that access or create a second charge for the same accepted logical work. Read how your job is split across Macs for the owner limits checked before key release.
Resolve a mismatch without repeating work
Keep the existing job, result, and receipt references. Describe the mismatched state or missing evidence without attaching the payload. A missing permission to download may need renewal, not another inference run. An expired access link is not proof the stored result was deleted.
Review receipt and provenance guidance for the evidence accompanying your result and the safe way to raise a mismatch.