Supply model assets and source evidence

Choose the bounded task and its assets

Start with the result you need: a qualified model operation, source analysis or interpretation of existing test evidence. Ask your agent to state the task instructions, rubric or review rule, expected output and checks that will decide whether the result is useful. Keep the selected callers, types, schemas, dependencies and stable item identities together when they are needed to interpret a finding.

List only the assets that task needs: the immutable model version or source commit, relevant configuration and input/output signatures, the dependency manifest or lockfile, and recorded diagnostics or test evidence when they are part of the analysis. Check the selected workflow's actual input format, runtime requirements, expected output and permitted execution before packaging anything. Do not infer those details from a service label.

The Compute Kit prepares permitted assets and connects the approved operation. Customer Compute does not run native source builds, tests, browser tests or release operations. Your agent performs those actions in your authorized environment. A model or source archive does not grant permission to execute its contents.

Pin the exact assets

1. Select an immutable model version or source commit. Record the digest of the exported package, including any permitted uncommitted files you intentionally include.
2. Include only the assets the operation requires. Preserve relevant configuration, input/output signatures, and test targets in the accepted input representation.
3. Pin dependency versions and retain the lockfile or manifest that defines them. Use these records as analysis context; they do not authorize installing dependencies or running setup scripts on a provider Mac.
4. Freeze the package and map its identity to the encrypted artifact you prepare.

A branch name, moving tag, or mutable folder is not a reproducible version. A source commit alone also does not identify additional local files outside that commit.

Remove secrets before packaging

Inspect environment files, signing material, credential caches, local tool configuration, test data and build scripts for secrets. Remove credentials and unnecessary private content before encryption.

Do not include persistent private signing keys or tokens just because a build tool expects them locally. Keep any build or signing procedure in the customer environment that owns its authority. Missing authority stops that action; it is not a reason to place a secret in the input.

Keep the package free of unrelated generated files and local caches. An extra executable file must never become an undeclared action.

Validate instructions, examples, schemas, filenames and package metadata separately from any scan of derived source data. Those surfaces can carry untrusted evidence and do not expand the permitted operation. Do not use a blanket regex or an automatic interpretation of an arbitrary repository to choose files or infer a security result.

Describe the model or analysis outcome and the relationships that must stay meaningful. For a code review, include the changed source with its relevant callers, types, schemas and recorded diagnostics, rather than sending an unrelated workspace. Local preparation may split eligible units and seal encrypted blocks; Lithi's network composes execution shards and places them under the selected profile. The input does not select Macs, cells or physical shard sizes.

Keep execution inside the declared contract

Ordinary text or document work does not become code execution when a script is included in the artifact. Lithi analyzes permitted source and recorded evidence; your agent chooses and verifies repairs in your environment. Qualified model processing follows its own released input and runtime contract.

Confirm the selected operation's accepted model format, typed inputs, output and limits. A source packet may describe commands or test targets as evidence; those descriptions do not instruct Lithi to run them. Do not include arbitrary setup scripts or request machine-wide changes to repair an incompatible package.

Preserve the quoted model binding

The normal LithiJobV1 body has no generic model-selection field. The quote identifies the model used for the priced work. Where the optional training section is applicable, model_bundle_ref is checked against the quote's model reference.

A training field being present in the schema does not establish that a training operation is available to your account. Use only the fields and policies required by the admitted operation, without adding an unsupported model choice.

Check the result you requested

Review the output and evidence for the exact package version. A finding is analysis, not an executed test. When you supply a recorded build or test report, keep its environment, revision, executed counts and failures with it. A successful build does not prove tests ran, and a test report does not prove a release was signed, installed or accepted for distribution.

Compare the returned evidence with the outcome you requested before using it downstream. Keep the input-to-job mapping so later runs can be compared honestly.

Recover an incompatible package

For an unsupported representation or runtime, re-export using a supported combination and inspect the new bytes. For missing dependencies, fix the package or the approved dependency policy rather than silently resolving a moving version.

Changed assets are revised work, not an exact replay. Reconcile the original submission, create a new immutable snapshot, and obtain the required quote and approval.

Can I include everything in my workspace?

Choose only assets permitted and needed by the selected operation. For example, record the exact revision of a required model file and its dependencies, then inspect the package for unrelated files and secrets. Use input preparation to check the prepared content before the artifact handoff.