Compute
Import a cloud model batch request set
Each cloud model batch provider gets its own generated profile, level and evidence. Endpoint and regional differences are documented rather than folded into one cloud claim.
What this connects
Batch request files written for a cloud provider's model service, as an input. Lithi reads the file and maps each entry onto a Compute workflow request.
There is no single cloud compatibility level, because there is no single cloud behavior. Each provider has its own generated profile, its own named level and its own published conformance matrix. Read the profile for the provider you are importing from, and treat it as the authority over this page.
Bind an exact input
Freeze the assembled request file and bind it by identity and digest:
"snapshot": {
"version_id": "<the request set identity you recorded>",
"content_sha256": "<the digest of those exact bytes>"
}
Per-request identity is preserved. Each entry's custom identifier stays attached to its unit and appears on the matching output row, so results join back by identifier rather than by order. Duplicates are refused by value.
Credentials
No provider key is involved and none is accepted. Lithi does not call a cloud model service on your behalf.
Where the file is staged, input.credential_ref names a registered storage credential as a reference, never a secret value. Register it, test it, read it back, and revoke it when the work ends.
Formats and limits
Read the provider profile before you assume anything. Each profile states four things that genuinely vary between providers, and getting them from the wrong profile is the most common failure here:
| What varies | Where to read it |
|---|---|
| Supported request fields and endpoints | The provider's generated profile |
| Lifecycle steps and their order | The provider's conformance matrix |
| Error shapes and typed refusals | The operation's own generated error_schema |
| Regional and data-residency differences | The provider profile, plus your own policy |
Regional differences are documented per provider rather than generalized. A shape that is supported in one region may not be in another, and the profile says which.
An unsupported field is refused by name. It is never defaulted or approximated, because a silently dropped field would change the work you paid for. The maximum item count for a workflow is stated on its descriptor and repeated on your quote.
Commit the output
Outcomes arrive as a Lithi result bundle, not as a provider-shaped output file. Accepted rows land in data/part-*, typed failures and abstentions beside them, and result-manifest.json is written last as the only complete-bundle marker.
The lifecycle is Lithi's for every provider. A quote comes first and never authorizes work; approval is a separate act; a job reaches SUCCEEDED, PARTIAL, FAILED or CANCELLED; and every non-success carries a safe reason and a concrete next action.
Where your policy constrains where work may run, set that in your policy profile rather than inferring it from a provider's region. See how regions and jurisdiction are applied.
What is not supported
There is no blanket cloud compatibility claim, and no provider profile may be read as evidence about another provider.
Outside the adapter:
- Any provider whose profile and conformance matrix have not been published.
- Calling a cloud model service, or holding a cloud provider credential.
- Provider-shaped output files, provider error codes or provider batch identifiers.
- Assuming a field, region or limit carries across providers because the file format looks similar.
If a field or an endpoint is refused, the response names it. Map it against the correct provider profile, rebuild, take a new digest, then quote and approve again.