Compute
Schemas — TaskSpec, Job and ResultBundle
The three Compute schemas and how they differ, the seven TaskSpec objects, the result bundle layout, and the rule that an unknown field is rejected rather than dropped.
Three schemas, three different jobs
TaskSpec is what you send. It describes the work you want.
Job is what admission creates from your TaskSpec. You never send one. It carries the typed job and stage states you poll.
ResultBundle is what comes back. It is immutable, and you read it rather than edit it.
The seven TaskSpec objects
LithiComputeTaskSpecV1 has exactly seven objects.
| Object | What it carries |
|---|---|
workflow | id and version, such as eval.semantic_grade.v1 or current-compatible |
input | kind, adapter, location, credential_ref, snapshot (version_id, content_sha256), format, item_id_field |
parameters | the workflow's declared typed knobs |
quality | preset |
policy | a profile_id reference |
output | the format, destination and result-partition declaration |
limits | deadline as an ISO 8601 duration, and maximum_price as a currency and a decimal amount |
profile is not an eighth object. A profile= convenience string in a client resolves into policy, quality, output and limits before the request goes out. Do not treat it as a wire field.
Narrowing only removes freedom
A release narrows the general shape; it never widens it.
Your parameters are validated against the generated parameters_schema for that exact workflow version. A profile narrows policy, quality, output and limits to your team's defaults.
So a field accepted by one workflow version may be refused by the next. Validate against the version you pin, not against the shape you used last quarter.
An unknown field is rejected, never dropped
Compute refuses rather than guesses. An unknown or unsupported field is rejected at submission. It is never silently ignored, and it never reaches execution.
The refusal names the field path so you can correct it directly. It never repeats the value you sent, because a value can carry a secret.
This matters when you upgrade. A field that quietly disappeared would leave you believing a setting applied. A refusal tells you the truth at the moment you can still fix it.
ResultBundle layout
data/part-* accepted tabular or media outputs
failures/part-* typed failures and refusals
abstentions/part-* items that produced no answer
disagreements/part-* preserved differences between independent checks
metrics.json aggregate and slice metrics
verification.json rubric, grader and independent-check evidence
provenance.json input, workflow, model, schema and envelope digests
receipt.json signed receipt projection
result-manifest.json written last; binds every file, count, schema, release and retention
result-manifest.json is written last and is the only complete-bundle marker. Part files appearing in storage never mean the job reached a terminal success.
Tabular output gains namespaced result columns: lithi_status, lithi_result, lithi_error_code, lithi_confidence, lithi_evidence, lithi_verification and lithi_usage.
Where each schema release is published
Only registered, customer-safe schema releases are published. Nothing internal is exposed as a schema you could accidentally depend on.
Download the API description from developer settings in the portal for request and response schemas. Each workflow's parameters_schema and output schema sit on its descriptor. See how a bundle is read once a job succeeds.