Compute request and response schemas

Choose the operation and direction first, then select its request and response schemas. An operation's request and response have different schemas. A job submission is not a status response, and a result reference is not the result file itself.

The schema checks shape, fields, enums and declared bounds. It does not decide whether a result is semantically correct or accepted for your work. Your existing agent keeps that acceptance decision.

Select the operation and direction

These names identify components in the canonical API description. The response column names the object inside the REST success envelope's data field.

LiveBoundedLithiJobV1 combines LithiJobV1 with the public route's tighter ciphertext bound. Its request carries contract_id: "LithiJobV1" and schema_version: "lithi-job.v1". The wrapper's schema name does not replace either field.

A workflow description or local task specification is not automatically the body accepted by POST /v1/jobs. A customer agent can use a task brief to organize the full instructions, context, output schema and evidence requirements for review. Convert that brief to the operation's request schema; it does not grant access or approve execution.

Quote request fields

All fields in this table are required. The only additional top-level fields declared by QuoteRequest are optional UUIDs job_id and batch_id; neither accepts null.

A QuoteResponse requires status: "signed" and quote. Its quote schema is LithiQuoteV1. Do not substitute another quote contract merely because its name has a higher version suffix. A signed quote is not approval to execute.

Job request fields

LithiJobV1 has 18 required top-level fields and five optional fields: training, sealed_binding, sealed_block_manifest, stage_partition and completion_policy. The table groups the required fields for reading; it does not introduce nested groups into the request. sealed_binding carries the preparation decision, preparation commitment, sealed manifest root and quote digest for sealed admission. sealed_block_manifest carries the content-free sealed block manifest; stage_partition carries the measured stage and partition terms; and completion_policy carries the approved verification and partial-completion policy. A batch sends the last three run-level objects on its first item only. Use the schema and selected client contract for the exact admission state; do not invent a binding or treat a quote as approval.

input.source contains kind: "encrypted_artifact" and artifact_id. The public bounds contain the declared file count, ciphertext bytes and estimated input tokens. They do not contain plaintext file contents, credentials or a local filesystem path.

contract.verification contains mode and rate. Its modes are none, sampled and full; rate is a number from 0 through 1. The hard_gates array has unique members drawn from schema_valid, label_allowed, evidence_bound, typed_output_contract and verification_passed.

The optional training object, when supplied for an admitted operation, requires all six fields: model_bundle_ref, dataset_ref, training_profile, evaluation_policy_ref, batch_completion_policy and result_destination_id. A field's presence in the schema does not authorize an operation or establish model-training availability.

Batches and artifact metadata

BatchRequest requires exactly quote_id, completion_policy_digest and items. Each item uses LiveBoundedLithiJobV1; it is not an arbitrary object. A batch is one run over one sealed input: its first item carries the run-level sealed_block_manifest, stage_partition and completion_policy, later items carry none of those run-level objects, and every item carries its own sealed_binding. Array bounds and the serialized request's byte limit both apply.

ArtifactPrepareRequest requires account_id, artifact_id, data_profile, ciphertext_bytes, chunk_count, chunk_root_digest and destination_id.

ArtifactCompleteRequest requires account_id, artifact_id, upload_id, ciphertext_manifest_digest, chunk_root_digest and capability_digest. Preserve the identifiers and digests associated with the same upload. Preparation does not prove that the bytes arrived or that completion succeeded.

Decode the response, not the request

REST JSON success envelopes require exactly ok: true and data. Validate data against the specific response schema. SDK methods may unwrap that envelope; follow the client guide rather than unwrapping it a second time.

This synthetic job-status response illustrates the projection shape; it is not evidence of a real job:

{
  "ok": true,
  "data": {
    "job_id": "11111111-1111-4111-8111-111111111111",
    "state": "accepted",
    "state_version": 1,
    "digest": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
    "p_next_action": "none"
  }
}

JobProjection does not echo the input. ResultProjection requires job_id, encrypted_artifact_id, result_digest, evidence_digest and delivery_state. Those are bounded references and evidence fields, not an inline transcript, arbitrary JSON result or a promised directory layout.

Paginated event and result responses use items with an optional next_cursor. An absent cursor and next_cursor: null are not interchangeable. MCP responses use JSON-RPC and tool-result projections instead of the REST envelope.

Reject invalid fields deliberately

The request and projection objects above declare additionalProperties: false. Preserve required fields and nested strictness. Do not drop an unrecognized setting silently, add an undeclared convenience field or convert null into a missing value.

The REST error envelope declares ok: false, an error object containing code, and p_next_action: "none". A schema refusal can return INVALID_REQUEST; do not assume every REST failure includes field paths, submitted values or a human-readable message.

Use the canonical Compute OpenAPI document for complete enum membership, patterns, nested bounds and operation-specific error responses. Keep that document as the machine-readable authority rather than creating a separate schema from these reading tables.