> ## Documentation Index
>
> Fetch the complete documentation index at: https://lithi.ai/llms.txt
>
> Use this file to discover all available pages before exploring further.

---
title: Schemas — TaskSpec, Job and ResultBundle
description: >-
  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.
route: /docs/compute/reference/schemas
page_id: docs-compute-reference-schemas
page_type: reference
content_layer: technical reference
surface_profile: technical_reference
audience: 'Integrators and AI agents building Compute requests and parsing results'
voice: D
reader_question: 'What exactly do I send, what is created for me, and what comes back?'
primary_action: Validate your request against the workflow's parameters schema
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-reference-schemas-en-us-2026-09-05-v1
last_updated: '2026-09-05'
robots: index
claim_registry_pinned: true
claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write"
---

## 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

```text
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](/docs/compute/results/bundle-layout) once a job succeeds.