> ## 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: Run a released multi-stage recipe
description: >-
  A multi-stage workflow runs stages in dependency order. Learn what each stage
  state means, where intermediate output lands, and how to read and re-run a
  composed run that ends partial.
route: /docs/compute/workflows/multi-stage
page_id: docs-compute-workflows-multi-stage
page_type: howTo
content_layer: guided documentation
surface_profile: guided_docs
audience: Compute customers running work that has more than one step
voice: D
reader_question: How does a multi-stage workflow behave when one stage does not finish?
primary_action: Read the partial result before you re-run
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-workflows-multi-stage-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"
---

## Only released recipes run

A composed run is available when a released workflow declares it. You do not assemble your own stage graph, and no request can introduce a stage that was not declared.

Check the descriptor for the composition you want. If it is not there, run the released workflows separately and join their results in your own system.

That constraint is what makes a composed run readable. Every stage in it was declared, priced and verified before you submitted anything.

## How a stage progresses

Each stage moves through its own states, independently of the job's overall state:

- `BLOCKED` — waiting on a stage it depends on.
- `READY` — its dependencies are satisfied.
- `MATERIALIZING` — its input is being assembled.
- `RUNNING` — the declared work itself.
- `VERIFYING` — the checks your quality preset asked for.
- `AGGREGATING` — accepted results are being collected.
- `SUCCEEDED`, `PARTIAL`, `FAILED`, `SKIPPED`, `CANCELLED` — terminal states.

A stage does not start early and does not overlap its dependency. It waits in `BLOCKED` until the stage before it reaches a state it can consume.

## Where intermediate output lands

A stage's accepted output is the next stage's input. Both are written into your result bundle, in the partitions the recipe and your `output` declaration name.

Do not treat an intermediate file as a finished deliverable while the job is still running. `result-manifest.json` is written last, and it is the only marker that binds every file, count and schema in the bundle.

The presence of part files never means the run reached a terminal success.

## When a stage does not finish

A stage that ends `PARTIAL` accepted some items and not others. It passes on what it accepted, and the run continues.

A stage that ends `FAILED` can leave the stages after it `SKIPPED`. A skipped stage is not a separate fault. It is the declared consequence of its dependency, and it is reported as such.

The job itself reaches `PARTIAL` when work was accepted but the run is not wholly successful. Read the job state and the stage states together, because they answer different questions.

## What success looks like

The job reaches `SUCCEEDED`, every stage reaches `SUCCEEDED`, and `result-manifest.json` is present and binds the files you expected.

Compare the manifest's counts against the item count you submitted. Matching counts are the check worth doing before you use the output.

## If the run ends partial

Read the bundle before you re-run anything. Accepted items are under `data/`, and the rest are separated into `failures/`, `abstentions/` and `disagreements/`.

Every non-success entry carries a safe reason and a concrete next action. Group them, because one cause usually explains many rows.

Then re-run only the items named, against the same input snapshot, so the accepted work is untouched. Quote that re-run like any other request, and read the maximum charge it states before you approve it.

For the semantics of a partial job, see [partial completion](/docs/compute/jobs/partial-completion). For the three non-accepted outcomes, see [failures, abstentions and disagreements](/docs/compute/results/failures-abstentions-disagreements).
