> ## 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: Read a workflow descriptor before you quote
description: >-
  Workflow descriptors state the input, parameters, bounds and quality presets a
  workflow accepts. Read the current one, inspect your data locally, then check
  it again when you request your quote.
route: /docs/compute/workflows/discovery
page_id: docs-compute-workflows-discovery
page_type: howTo
content_layer: guided documentation
surface_profile: guided_docs
audience: Compute customers and the AI agents that plan work for them
voice: D
reader_question: How do I find out what a workflow accepts before I run it?
primary_action: Request a quote for the workflow you chose
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-workflows-discovery-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"
---

## Before you start

You need one task with a clear outcome and a real sample of its input. Discovery is read-only. Listing or explaining a workflow neither quotes, admits nor runs paid work.

## List and explain the candidates

Start from the outcome you want and narrow to a few workflows.

```bash
lithi workflow list
lithi workflow explain
```

Your own AI agent can do the same through the local helpers `lithi.plan()` and `lithi.recommend()`. Those helpers suggest and shape work. They never quote, admit or run anything.

## Read what the descriptor declares

A descriptor is the authority on what a workflow accepts. Read all of it, not only the name:

- `workflow.id` and `workflow.version` — for example `eval.semantic_grade.v1`, selected by an exact version or by `current-compatible`.
- The generated `parameters_schema` — every typed knob, its type and whether it is required.
- The output schema — the fields the workflow can return.
- The bounds — including the maximum item count for one batch.
- The quality presets it accepts, and the profile its units run under.

Never read a ceiling from another workflow. Bounds differ per workflow, and the descriptor is the only place they are stated.

## Inspect your own input first

Check your data before you send anything anywhere.

```bash
lithi assess
lithi inspect
lithi dataset validate
```

Confirm the field you will use as the item identifier exists on every row and is unique. Confirm your largest item, not your average one.

## Check again at quote time

A cached discovery result is a snapshot of an earlier release. Descriptors are versioned and can be released again, so a plan built last week may no longer match.

Treat your quote as the current authority. It repeats the bounds that apply and states the maximum charge. If the descriptor moved after you planned, admission answers `REPLAN_REQUIRED` rather than running something you did not price.

Re-read the descriptor before every quote you intend to approve. It costs nothing.

## What success looks like

You can state four things without guessing. The workflow id and version, the parameters you will send, the output schema you expect, and the maximum item count on your quote.

If you cannot state all four, you are not ready to quote.

## If discovery and your quote disagree

Read the version your quote names, not the one you planned against. Rebuild the request from that descriptor and quote again.

Never carry an old parameter set forward into a new version. A field that was optional can become required, and a bound can move. Every refusal names the reason and the next action to take, so start from what it named.

When your request matches the current descriptor, [request a quote](/docs/compute/quotes) and read what it commits you to. To map your data onto the declared knobs, see [how parameters are resolved](/docs/compute/workflows/parameters).