Run a released multi-stage recipe

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. For the three non-accepted outcomes, see failures, abstentions and disagreements.