Every accepted Agent Network task leaves a receipt.

A receipt records the allowed task state, checks, timing, and safe evidence tied to an outcome, without publishing private task content.

The proof follows the work

Every accepted Agent Network task leaves a receipt. It is a plain, timestamped record of what Lithi did, why it ran, what it used, who allowed it, and where the relevant data stayed.

The record follows the work from an accepted request through its recorded outcome. It can show the task status, the policy and release evidence that applied, the checks that ran, and the time those events occurred. It can also carry safe digests: cryptographic fingerprints that tie evidence together without publishing the underlying content.

What a receipt can show

A Lithi Receipt shows evidence for that task and outcome:

• the recorded status and the allowed capability;
• policy, release, and verification evidence;
• a result digest and delivery evidence, where the outcome includes them;
• measured usage and charge evidence, where the applicable record includes them;
• signatures and timestamps required for that record.

These details help you inspect how an accepted task moved through its checks. They do not expose private prompts, customer message bodies, API keys, provider identity, exact provider location, private result bytes, or internal storage links.

Batches keep outcomes separate

Bulk describes the amount of work. A batch describes compatible, independent items submitted together. Lithi keeps those items separately identifiable, routes them to eligible capacity, and checks each outcome on its own.

That separation matters when results differ. One item failing validation must not appear successful because other items finished. A batch can therefore contain accepted, refused, or follow-up outcomes, with receipt evidence for each item rather than one blanket claim that everything passed.

A refusal is also an outcome

Work may not run when it does not fit the approved capability, cannot run safely, or fails a required check. In those cases, Lithi records a non-success state instead of presenting the task as complete.

The receipt can carry a typed reason and a next action. That may tell you to inspect the issue, notify the owner, close the work, or allow another permitted attempt. A refusal record explains what happened; it does not turn an unavailable result into a successful one.

Protected in transit. Honest about the endpoint.

Lithi uses encrypted transport on approved network paths and signed envelopes where the current protocol requires them. A signature helps protect integrity; it is not the same as encrypting stored results. A receipt digest binds evidence without revealing the private content it represents.

The Mac doing the work still has to process the task. A participating provider Mac is not a confidential-computing enclave. Provider-facing Lithi surfaces are designed to stay blind to customer content. A privileged owner with physical or root-level access may still inspect ordinary unified memory during execution. See Compute security for the fuller executor boundary.

What a receipt does not prove

A receipt supports a narrow conclusion about recorded work and its evidence. It does not prove that a model answer is objectively true. It does not prove a fixed provider payout or that work ran in the closest city.

It does not publish private task content. It does not guarantee settlement or payment, and it does not mean everything is on-chain. Usage, charge, earnings, and payment questions still need their own authoritative records; see quotes, limits and billing and provider allocation and settlement.

Primary action

Review compliance and assurance for how receipt evidence fits a broader review, or contact the Trust Center with the task reference you are reviewing.