First test

Choose one small test

Ask your existing AI agent to assess a small task against your permitted data, desired output and acceptance rule. The assessment needs no Lithi installation and incurs no Lithi Compute charge; your agent provider may charge for its own work. If it fits, apply for access and follow the setup guide after approval. Confirm that the connected account is the one you intend to use and, for an MCP connection, that it exposes the five Work tools: lithi.quote, lithi.run, lithi.batch, lithi.status and lithi.result. Tool registration or a connection check alone does not prove a network test has run.

Give this test one outcome to judge. Keep the wider goal and context in your existing agent, use input you have permission to process, keep each item’s ID and write the acceptance rule before you submit. A small test limits the scope of a mistake; it does not make paid work free.

An estimate is useful before this checklist, but it is not a quote, access grant or execution authority. Copying an estimate prompt does not upload data, request a key or start work. Transfer of a prepared, sealed input needs its own explicit permission. Paid admission then needs a signed quote and approval for that exact work.

Use this eight-review fixture to practice the review step. It is complete, fictional and fixed. It is not a live measurement or a prediction.

Give the fixture instructions as well as its text. A suitable task brief says: classify each review as positive or negative when it clearly expresses an opinion about the product; return invalid when the text is missing; and return abstained when the text is present but the opinion is missing or ambiguous. Keep the supplied ID, explain the evidence for the label, and do not guess when the context does not support a label. The acceptance check is eight IDs accounted for, with six accepted labels, one invalid item and one abstention.

“It is light.” remains ambiguous: the sentence does not say whether the writer liked the product. Do not force a positive or negative label just to make the table complete. The missing-text case and the ambiguous-text case exercise different instructions; keep both outcomes visible in the review.

If you use the optional offline replay, its fresh in-memory session clears the practice outcomes and review flag. It does not erase a saved script, terminal output, or copied notes.

Check the acceptance rule

First, inspect every input and expected outcome. Match outputs to IDs, count six accepted, one invalid and one abstained, and record what evidence is still missing. These practice outcomes are teaching fixtures. They do not prove account access, capacity, model quality, execution, a charge or delivery.

Keep three actions separate. A public read-only assessment explains whether a task looks suitable. Authorized Kit setup or a no-spend diagnostic can inspect your agent host and show a connection plan. Approved live work is the step that can transfer prepared input or consume Compute. None of the assessment, setup or diagnostic steps is a quote or execution approval.

For a real test, carry over the question and review rule, then create a fresh live input. Confirm the supported operation and format through the Compute client guide. The practice table is a planning aid, not a wire request, quote or receipt.

Review the quote and submit once

Prepare the bounded task before paying. If the selected account needs funding, complete the paid $25 credit purchase yourself through the secure human payment step. Preserve the prepared input, account and original request identity while you pay, then read back confirmed credit before continuing. Use credit and payment recovery if the purchase is pending or unknown; do not pay again to resolve a missing response.

1. Validate every item against the chosen operation. Resolve missing IDs, unsupported values and unclear rules before requesting a quote. Keep the reviewed input unchanged afterward.
2. Request a final signed quote for that exact input, output, policy and deadline. Check the scope, maximum charge, expiry and verification terms.
3. Approve the matching paid work separately, or confirm that an existing bounded policy covers it. Quote creation is not approval.
4. Submit once through the supported run or batch path. Admission holds the approved maximum from available credit before dispatch. Keep the returned job reference and request identity. Accepted submission is not completed work.
5. Read the job status and result with the supported tools. Result metadata identifies the authorized artifact; retrieve the file and verify its digest. Check coverage and evidence against the acceptance rule before deciding whether to scale.

The Kit prepares eligible input and seals blocks locally. Lithi owns execution-shard composition and placement. State what must stay together and what the output must contain. Do not choose Macs, physical shard sizes or a replacement request to steer execution.

For an organization request, an authorized reviewer can inspect the amount and expiry in Team → Approvals, then choose Approve or Deny and confirm the recorded decision. An expired or already decided request is read-only.

Check the result and reconcile every exception

Read rejected, failed, invalid, abstained, disputed and missing items before sampling accepted output. Match each output to its input ID, check its integrity and verification evidence, and compare actual usage with the approved quote. Verify result files explains how to check the artifact and its evidence.

The live counts may differ from the fixture. Record what actually happened. Retain the receipt reference with its stated evidence. A receipt does not guarantee business correctness, confirm delivery to another system, or mark an invoice paid.

Keep usage, invoices, and payments separate. Usage records accepted work. An invoice requests payment. Payment is a separate action with its own confirmed status.

With reporting permission, the monthly Compute impact report can show Macs recorded with accepted work, broader physical activity and qualified energy or Community records. These are separate populations, and the report does not confirm payment or claim savings.

Name the outcome before acting

Retry safely and keep the result

An unknown submission outcome requires a read of the existing request or job before retrying. An expired quote or changed input needs renewed review and approval. Never create a second job to discover what happened to the first.

If accepted output exists but delivery fails, recover delivery of that output rather than rerunning the computation. Expand the workload only after the small test passes your checks and every exception has a clear owner. When you are ready, choose a worked example that matches the outcome you want to scale to next.