Lithi glossary: receipts, states, workflows, and APIs
Plain definitions of the Compute Kit, participating Macs, receipts, states, workflows and APIs, with links to the page that owns each exact value.
Use this glossary for the meaning of each Lithi term, then use the owning product or API reference for its current value. A definition explains a word; it does not prove that a job ran, a payment settled, or an account has permission.
In the practical Compute flow, your existing agent keeps the goal, project context, model, local edits, native builds and tests, and final decisions. The Compute Kit prepares permitted work and the approved MCP or API connection; participating people's Macs perform supported work. A compatible agent still needs approved access and a supported integration.
Agent, Kit, and participation
The Compute Kit is the local harness that helps an existing agent prepare permitted work and connect an approved interface. The Kit does not replace the agent's model, context, edits, native tests, or final acceptance decision.
The Lithi Agent Network is the participating-Mac network used for supported work under current Compute policy. A Mac can perform assigned work, but a recorded Mac is not the same population as a provider account or a verified person.
The five Work tools are lithi.quote, lithi.run, lithi.batch, lithi.status, and lithi.result. Monthly reporting uses a separate reporting:read API or an approved report file. It is not a sixth Work tool. Its accepted_work_macs, physical_activity_macs, and provider_accounts fields describe different populations; they are not additive and do not count individual people, payments, or savings.
Lithi Receipt
A Lithi Receipt is a timestamped evidence record for one accepted Agent Network task or outcome. It contains content-minimized identifiers, policy, and provenance instead of private message bodies.
A receipt records evidence for its declared scope. It does not prove model truth, guarantee settlement, mean data is on-chain, explain every token's reasoning, or expose the private content behind the action. Use the Lithi Receipt ID to find a receipt; its exact format comes from the current receipt contract.
When you contact support about a receipt, share the receipt reference and visible problem. Do not include a bearer key, password, private message body, or customer file.
State
A state is the current recognized condition of an item or workflow. Technical state values come from a versioned lifecycle contract, so keep their exact spelling and case.
Each object has its own state contract. A job, artifact, delivery, and payment system can use different values. Use Compute states and reason codes for the API object you are handling.
A state read is evidence of that observation only. It does not automatically prove execution, delivery, or payment.
Workflow
A workflow is a defined series of steps that moves work toward an outcome. In technical use, it has versioned inputs, states, commands, actors, policies, retries, events, and terminal outcomes.
Keep a workflow separate from a job. A workflow describes how work proceeds; a job is one unit scheduled for execution. A workflow definition does not authorize an account to run it.
API
An application programming interface (API) is a defined way for software systems to request data or actions from one another. Lithi API documentation includes operations, authentication, authorization, schemas, errors, and limits.
Use the Compute API and client reference for exact methods, paths, fields, and limits. Do not infer a route from a contract type name or assume every language client exposes the same constructor and methods.
Evidence and proof
Use evidence for information that supports or challenges a statement, decision, or outcome. A signature can establish its declared signer and bytes. A test can establish the behavior it exercised. Neither automatically proves semantic correctness outside that scope.
Keep source, build, test, runtime, delivery, and payment evidence separate when you read receipts, logs, and test results. Do not compress them into one word such as verified.
Choose the exact reference
The definitions on this page carry each term's public meaning. Use Lithi Receipts for receipt evidence and verification boundaries. Use roles and states when the actor or authority matters.
If a term's definition and a current product screen appear to conflict, keep the current observation and check the owning product or API contract. Do not change an action or replay work just to make labels agree.