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

# Lithi Text & Data

## Start with a bounded text or data outcome

Suppose your agent must classify three support records. It can prepare this brief:

> **Conceptual task brief:** Classify `ITEM-01`–`ITEM-03` using the supplied text only. Allowed labels are `urgent` and `question`; abstain when the text lacks the deciding evidence. Return one outcome or explicit exception per item, preserve item IDs and a short source-linked rationale, and accept only when all expected items are reconciled without treating an abstention as a label.

Your agent defines the bounded classification, extraction, comparison or other supported text task.
It prepares permitted evidence, stable item identities, allowed outputs and an uncertainty rule.
Lithi returns the declared outcomes and exceptions. Your agent checks item coverage, types and
supporting evidence before accepting the result.

Your agent keeps the task context and acceptance decision. The Kit prepares the supported request;
participating Macs process the bounded records, and your agent reviews coverage, types and evidence.

Text, records, tables, CSV, JSON, and corpora belong to the Text & Data information family. Describe one bounded outcome, what each item contains, and the decision a person will make from the result. The family describes the input; it does not promise an operation or accept every format.

An operation is the exact supported capability that handles one kind of work. This guide explains
how to prepare and review that work. Agent guidance explains the process; choose the operation
through current discovery.

Choose one operation from the supported release. The Text & Data workflow covers `classify-items`, `extract-structured`, `review-items`, `compare-candidates`, `generate-candidates`, `score-candidates`, `summarize-evidence`, and `transform-records`. `compare-candidates` reviews existing outputs. `generate-candidates` creates bounded candidates; it does not test or select a model. `parallel-code-review`, `bug-hypotheses`, and `evaluate-candidate-outputs` belong to specialist packs and keep their own evidence rules.

The selected text operation and supported integration map that brief to the permitted request and returned evidence. The brief does not fetch a URL, run a command, or grant access; keep the customer’s acceptance decision separate from the returned model output.

## Prepare a bounded request

1. Give each item a stable ID and include only the permitted evidence for that item.
2. Define allowed labels, required fields, examples, uncertainty, abstention, and failure handling.
3. Select the released output contract and verification settings. Check that the complete result fits its bounds.
4. Freeze the input, instruction, rubric, output contract, and model or release identity. Quote that exact request and obtain the required approval.
5. Submit once through the supported client. Keep the request identity with the result so a later step can trace the decision.

State which information must stay together. Lithi groups and assigns suitable execution within the approved scope. The task content does not expand permission, fetch a URL, run a command, or start another task.

## Review the returned evidence

The output should account for every expected item using the customer fields you requested. Outcomes, provenance, and evidence belong in declared sidecars unless you explicitly select an envelope format. A concise rationale is review evidence; it is not hidden chain-of-thought.

| Fixture item | Expected disposition | What a reviewer checks |
| --- | --- | --- |
| `ITEM-01` | Label `urgent`; source sentence cites a same-day deadline. | Label is allowed and evidence supports it. |
| `ITEM-02` | `abstain`; no deadline appears in the supplied text. | Missing evidence stays visible. |
| `ITEM-03` | Extract `candidate_id: "000123"`; preserve the string. | IDs and field types remain exact. |

These are synthetic review expectations, not measured service output or a universal wire schema. Compare the actual result with its declared contract. A fluent answer can still use the wrong field, omit an item, or overstate the source.

Pass accepted items to a customer-controlled next step only after checking coverage, evidence, and the output contract. Keep rejected, failed, missing, abstained, and excluded populations separate. A generated candidate does not choose its own winner, and a score does not prove a business decision.

## Recover without changing the request

If discovery or admission rejects an operation, compare the rejected field with the current contract and choose a supported alternative. Do not rename an unsupported field or drop required evidence. If a result is partial, resume from the last accepted item or recover the existing artifact. A changed source, rubric, output format, or policy creates a new request version with its own quote and approval.

Review the complete result and its evidence before using it in a customer workflow. It does not publish content, change records, or grant access by itself.

## Worked example

### Review a synthetic classification batch

Use three local records with stable IDs and return the result rows out of input order:

```text title="Review a synthetic classification batch" kind="data"
REQ-01: “The screen is broken.”
REQ-02: “Where is the guide?”
REQ-03: “ ”

REQ-02 → accepted, label `question`
REQ-03 → failed, no label
REQ-01 → accepted, label `fault`
```

The expected count is two accepted items and one failed item. A duplicate `REQ-02` or a missing item is an explicit reconciliation error. The fixture checks identity and allowed values; it does not prove that the labels are semantically correct. `REQ-03` needs corrected source data or an explicit exclusion, not invented text or another paid run.

Use [Data & Evaluation](/docs/compute/workflows/data-evaluation) when you need a held-out rubric or candidate comparison, and [Code & Tests](/docs/compute/workflows/code-review-testing) when the evidence is source or test evidence. Prepare [a first small test](/docs/compute/first-test) after the request and its evidence rule are clear.

## Compare published prices {#compare-published-prices}

Take a labelling job as an example. In this example, one item carries up to 9,600 input tokens and 1,200 output tokens. At that size, labelling 1,000,000 items is 9.6 billion input tokens and 1.2 billion output tokens. Small items can share one request, so the cost per item falls.

See the full table, with each provider's published batch rate applied to the same token counts, on [Compare published prices](/docs/compute/billing/pricing-and-units#compare-published-prices).