> ## 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: Workflow, profile, job, and result
description: >-
  Four words carry the whole model: workflow, profile, job, and result. This page
  defines each one, walks a small run from input to result, and shows what never
  belongs in a request.
route: /docs/compute/concepts/workflow-profile-job-result
page_id: docs-compute-concepts-workflow-profile-job-result
page_type: concept
content_layer: guided documentation
surface_profile: guided_docs
audience: Anyone about to send their first real work to Compute
voice: D
reader_question: What are the four things Compute asks me to think about?
primary_action: Build your first task spec
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-concepts-workflow-profile-job-result-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 four words

Compute asks you to think about four things and nothing else.

**Workflow** is what Lithi does. It is a named, versioned unit of work that you pick per task.

**Profile** is your team's reusable defaults for how that work is done.

**Job** is the admitted current run. It is the only one of the four with a live state.

**Result** is the immutable bundle and receipt you keep afterwards.

## Why the split matters

Each of the four changes on a different schedule. A workflow is chosen per task. A profile is agreed once and reused. A job lasts as long as the run. A result outlives all three.

Keeping them apart is what lets you change team defaults without rewriting every request. It is also what lets you audit a finished run without depending on the settings that produced it.

## One small run, end to end

1. Freeze the input. A snapshot records a `version_id` and a `content_sha256`, so the run is about exactly those bytes.
2. Name the workflow and version you want, for example `eval.semantic_grade.v1` at `current-compatible`.
3. Let your profile fill in the defaults: quality preset, where output goes, the deadline, the maximum price.
4. Request a quote. It states the maximum charge, carries an expiry, and authorizes nothing.
5. Approve separately. Admission then returns a job, which moves through `ADMITTED` and `RUNNING` to `SUCCEEDED`, `PARTIAL`, or `FAILED`.
6. Read the result. `result-manifest.json` is written last and is the only marker of a complete bundle.

If facts move between the quote and admission, admission answers `REPLAN_REQUIRED`. Quote again rather than resubmitting the old one.

## What never appears in a request

Nothing in a request describes where the work runs or how it is spread out. There is no placement field, and no way to ask for one.

You express urgency and cost instead. The `deadline` and `maximum_price` values inside `limits` are the whole of your control over how hard a job is pushed.

That is deliberate. It keeps your request portable across contract releases, because no field you submit depends on how the work happens to be arranged.

## Limits worth knowing early

A quality preset states what was checked, never that an answer is correct. Standard covers schema and deterministic validation. Verified adds independent sample verification. High assurance raises the verification rate or the number of independent checks. Custom evaluation runs your own rubric or reference set.

The maximum item count for a workflow sits on its descriptor and is repeated on your quote. Do not code to a number you saw in an example.

Part files appearing in a bundle are not terminal success. Wait for the manifest.

## Build the request

Once these four are clear, the request itself is small: [the seven objects in a task spec](/docs/compute/concepts/task-spec).