> ## 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: Map your data onto workflow parameters
description: >-
  Parameters are the typed knobs a workflow declares. Read the generated schema,
  map your fields locally, ask only where two mappings are equally plausible,
  and let unknown fields be refused.
route: /docs/compute/workflows/parameters
page_id: docs-compute-workflows-parameters
page_type: howTo
content_layer: guided documentation
surface_profile: guided_docs
audience: Compute customers and the AI agents that assemble their requests
voice: D
reader_question: How do I fill in a workflow's parameters and item identifier correctly?
primary_action: Quote the request and read the resolved parameters
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-workflows-parameters-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 the workflow's generated `parameters_schema` and a real sample of your input. The schema is typed, so most mapping questions have one correct answer already in your data.

## Resolve what the data settles

Read the schema and your sample together, on your own machine. Local inspection sends nothing and costs nothing.

Most fields resolve without asking you anything. A column with a matching name and a matching type is a match. A field with one supported value in this workflow has no decision in it.

The goal is a request where every declared parameter is filled from evidence, not from a preference nobody checked.

## Name the item identifier

The `input` object carries `item_id_field`. That field names the column that identifies each item.

Choose one that exists on every row and never repeats. It is how an accepted row, a failure, an abstention and a disagreement all point back to your source record.

Pin the bytes too. The `snapshot` you supply carries `version_id` and `content_sha256`, so the run uses exactly the data you inspected.

## Ask only about genuine ambiguity

Ask a question when two mappings are equally plausible and the data cannot decide between them. Two date columns with the same type is a real question. A single obvious column is not.

When you do ask, ask once and offer the named options. A short choice beats a long form, and it beats a silent guess.

## Never coerce an unknown field

An unknown or unsupported parameter is refused. It is not dropped quietly, and it is not converted into something the schema does accept.

That refusal is the correct behavior. A coerced field changes the work you are about to pay for without telling you, and the result would look successful.

Every refusal carries a safe reason and a concrete next action, so you always know which field to fix.

## What success looks like

Your quote echoes the resolved parameters back to you. Read them against what you intended before you approve anything.

The quote also states the maximum charge and the maximum item count that applies. A quote never authorizes work, so nothing runs until you approve it separately.

## If a parameter is refused

Start from the field the refusal names. Correct it against the current schema rather than against your last successful request.

If the schema itself has moved, admission answers `REPLAN_REQUIRED`. Re-read the descriptor at the version your quote names, rebuild the request, and quote again.

For choosing a stable identifier, see [how item identity works](/docs/compute/inputs/item-identity). To bound what comes back, see [narrowing an output schema](/docs/compute/workflows/output-schemas).