> ## 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: How a Compute request is built
description: >-
  A Compute request has seven objects and no more. This page builds one up from
  the smallest useful form, and explains why a saved profile narrows your
  defaults but never widens what you may do.
route: /docs/compute/concepts/task-spec
page_id: docs-compute-concepts-task-spec
page_type: concept
content_layer: guided documentation
surface_profile: guided_docs
audience: Integrators and AI agents assembling a Compute request
voice: D
reader_question: What goes into a Compute request, and what is optional?
primary_action: Request a quote for your task
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-concepts-task-spec-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"
---

## The seven objects

A request carries seven objects. There is no eighth.

| Object | What it carries |
| --- | --- |
| `workflow` | `id` and `version` — which work, at which version. |
| `input` | Where the data is, and the frozen snapshot that identifies it. |
| `parameters` | The typed knobs the workflow declares. |
| `quality` | One `preset`. |
| `policy` | A `profile_id` reference. |
| `output` | Format, destination, and result partitioning. |
| `limits` | `deadline` and `maximum_price`. |

They sit on top of the four ideas in [workflow, profile, job, and result](/docs/compute/concepts/workflow-profile-job-result).

## The minimum request

Two objects are enough to describe work: `workflow` and `input`.

```json
{
  "workflow": { "id": "eval.semantic_grade.v1", "version": "current-compatible" },
  "input": {
    "kind": "<the input kind the workflow declares>",
    "adapter": "<your registered adapter>",
    "location": "<your registered source reference>",
    "credential_ref": "<a secret reference, never a secret>",
    "snapshot": { "version_id": "<version id>", "content_sha256": "<digest>" },
    "format": "<the input format>",
    "item_id_field": "<the field that identifies one item>"
  }
}
```

`credential_ref` is a reference. A request never carries the credential itself.

## A normal request

Add the four objects that shape the outcome and its cost.

`parameters` are validated against the workflow's generated `parameters_schema`, so an unknown key is refused rather than quietly ignored. `quality.preset` selects how much verification runs. `output` says what you want back and where it goes.

`limits` bounds the run. Write `deadline` as an ISO 8601 duration, and `maximum_price` as a currency with a decimal amount. Set it even for a small job — it is your stated ceiling, and your quote is read against it.

## Advanced invocation

`policy` carries a `profile_id`. That one reference pulls in your team's agreed defaults for quality, output, and limits, so the request you write stays short and consistent across callers.

Some clients also accept a `profile=` convenience string. It resolves locally into `policy`, `quality`, `output`, and `limits` before anything is sent.

It never travels as an eighth object, and nothing on the receiving side reads it. If you are reading a request off the wire, expect the seven.

## Compiling is local; a job is not

`lithi workflow compile` runs on your own machine, as do the `lithi.plan()` and `lithi.recommend()` helpers. They validate a spec and suggest a shape. They do not quote, do not admit, and do not run paid work.

Nothing durable exists until you approve a quote and admission returns a job. A compiled spec on your disk is an input to that step, never a record of it.

## What a saved profile can and cannot do

A profile narrows. It cannot widen.

It can pin a stricter quality preset, a shorter deadline, a lower maximum price, or a fixed destination. It cannot grant a scope your key does not hold, raise a spend ceiling, or add a destination nobody registered.

Where a profile and your key disagree, the narrower of the two applies. So a profile is a good place to encode team policy, and never a way around an approval.

## Get it priced

A finished spec is ready to price, and pricing commits you to nothing: [what a quote states and what it does not](/docs/compute/quotes).