Lithi Receipts reference

A Lithi Receipt is a content-free action record. It shows what happened, why it ran, what it used, who allowed it, and where relevant data stayed.

What a receipt can show

A receipt can support a narrow statement about one recorded action. It can show the action summary, time, permitted purpose, and data-not-used summary. It also shows where the relevant data remained.

It can help you compare an outcome with the permission and scope you expected. It can show that a workflow stopped or was limited. It can also show when your decision was needed.

Read the public fields

• Action: Recorded work.

• Time: Creation time.

• Purpose: Allowed reason.

• Data used: Approved class or source.

• Data not used: Explicitly excluded class.

• Boundary: Data location.

• Outcome: Completed, stopped, or awaiting a decision.

The wording is intentionally compact. A receipt describes an event; it does not reproduce the email, draft, prompt, retrieved passage, or provider result.

Know what it cannot prove

A receipt cannot prove that a person agreed with the result. It cannot prove that a draft was sent or that a provider returned a particular answer. It cannot prove that a later permission still applies.

It does not replace the source or current policy. You must still review the exact draft or action.

It also cannot prove a broader security, legal, or compliance conclusion. Treat it as evidence for the recorded scope and time only.

Use it safely with support

When you contact support, share the receipt’s visible action, time, purpose, boundary, and outcome. Explain the question you need answered and remove private content from screenshots or notes.

Do not paste email bodies, draft text, prompts, retrieved passages, credentials, provider responses, or unrelated customer records. Support can use the bounded record to locate the right product path. They do not need the private material itself.

Check the original decision

If the record matters, compare it with the current permission, source owner, purpose, and device state. Revoke or narrow access when the purpose ends. Then check the resulting state in the authoritative control surface.

For the sharing path behind these boundaries, read the data boundaries reference.