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

# Export format

> The export file in full — the JSON array a run's export produces, the fields on each item entry, the six status values, and the per-node metrics block.

A run's export is a JSON array with one entry per item in the run. Each entry records how one item was labeled. Its shape depends on how far the item got when you started the export. To produce and download the file, see [Export your labeled results](/docs/data/guides/export-results.md).

A completed item carries its inputs and outputs, plus per-node metrics. Here is one from a support-ticket run:

```json theme={null}
{
  "index": 4,
  "status": "completed",
  "input": { "ticket_text": "My invoice is double the usual amount this month." },
  "output": { "intent": "billing" },
  "metrics": [
    {
      "nodeName": "classify_intent",
      "nodeType": "generation_sft",
      "ahtMs": 42318,
      "avgLlmQaMs": 8125,
      "attempts": 1,
      "annotatorId": "a3f9c1e08b"
    }
  ]
}
```

An item that had not started when you exported carries only its `index` and `status`:

```json theme={null}
{
  "index": 12,
  "status": "idle"
}
```

A canceled item has no `output`. If a node wrote at least one field selected by End before cancellation, `partialOutput` contains the selected fields that had values when the item was canceled:

```json theme={null}
{
  "index": 9,
  "status": "cancelled",
  "input": { "ticket_text": "Can I change the email address on my account?" },
  "partialOutput": { "intent": "question" }
}
```

## Entry fields

Every entry is a JSON object. `index` and `status` are always present. The rest appear as the item makes progress.

| Field | Type | Present when |
| - | - | - |
| `index` | number | Always |
| `status` | string | Always |
| `input` | object | The item has started |
| `output` | object | The item has completed |
| `partialOutput` | object | The item was canceled after a node wrote a field the End node returns |
| `metrics` | array | A Generation or Quorum node has finished |

`index` is the item's index in the source dataset (counting from 1). A run that launches a filtered subset carries just those items' indexes, so the numbers can be sparse. `status` is one of the [status values](#status-values) below.

`input` holds the item's input fields. `output` holds the fields the End node returns. `partialOutput` holds the fields the End node returns that had a value when the item was canceled: the fields its nodes wrote, plus the fields the End node takes straight from the input. It appears only when a node wrote at least one of these fields before the cancel, for example the answer of an item accepted without review. It uses the same field names as `output`, but fields can be missing. See [Fields and data](/docs/data/concepts/fields-and-data.md) for what these fields hold and how a Quorum node's output comes back as a per-expert list. `metrics` carries per-node timing and labeling details. See [The `metrics` array](#the-metrics-array). Each of these is omitted until the item reaches the state in the table.

## Status values

| Value | Meaning |
| - | - |
| `completed` | The item ran through the pipeline and produced its output. |
| `failed` | The item stopped at a node it could not complete, or on entry when a required input was missing. |
| `cancelled` | The run was canceled while the item was still unfinished, or the item reached the 14-day node timeout. |
| `paused` | The run was paused while the item was still unfinished. |
| `in_progress` | The item is still being labeled. |
| `idle` | The item had not started when you exported. |

> [!NOTE]
>
> The file spells the canceled state `cancelled`, with two Ls. The Items tab in the app shows the same state as a **Canceled** chip, with one L. When you search your downloaded file, use the file's spelling: `cancelled`.

## The `metrics` array

The `metrics` array has one entry for each Generation or Quorum node the item ran. Each entry records how that node handled the item. Code and Match nodes never produce an entry. Each entry names the node (`nodeName`, the node's name as shown in the pipeline graph) and its kind (`nodeType`). A Generation entry describes single-expert labeling. A Quorum entry describes several experts, so it drops `attempts` and `annotatorId` and carries `annotatorIds` instead:

```json theme={null}
{
  "nodeName": "rate_helpfulness",
  "nodeType": "quorum_sft",
  "ahtMs": 51044,
  "avgLlmQaMs": 10233,
  "annotatorIds": ["a3f9c1e08b", "b7e2d4f19c", "c1a8f3e05d"]
}
```

| Field | Type | Appears on |
| - | - | - |
| `nodeName` | string — the node's name in the pipeline graph | Every entry |
| `nodeType` | `"generation_sft"` or `"quorum_sft"` | Every entry |
| `ahtMs` | number | Every entry |
| `avgLlmQaMs` | number or `null` | Every entry |
| `attempts` | number | Generation entries |
| `annotatorId` | string or `null` | Generation entries |
| `annotatorIds` | array of strings | Quorum entries |

### How the metrics are computed

* `ahtMs` — milliseconds from the item's first task starting to the node first finishing.
* `avgLlmQaMs` — the rounded mean of the node's review durations, in milliseconds; `null` when review never ran.
* `attempts` — how many times the task was submitted or expired (Generation entries; under synthetic labeling the submissions are the model's).
* `annotatorId` — the expert behind the last submission or expiry; `null` when the node labeled synthetically (Generation entries).
* `annotatorIds` — the experts who labeled the item on this node (Quorum entries), in answer order when the node's annotator IDs field is available. The first ID then belongs to the first answer in every answer array, and one expert can occupy multiple positions. If that field is unavailable, the list falls back to IDs from submitted-task metrics, which need not align with the answer arrays. The list can be longer than the node's configured overlap when [review rejections bring in extra experts](/docs/data/reference/nodes/quorum.md#when-review-rejects-every-answer). To read the pairs next to the answers, add the node's annotator ids field to the End node's outputs and read it in `output`, or in `partialOutput` for a canceled item (see [Matching answers to experts](/docs/data/reference/nodes/quorum.md#matching-answers-to-experts)).

### When a node is missing from `metrics`

* A node appears only once a task on it started and the node then finished for the item — a node that failed before any task began is left out. A node the item never reached, one still running when you exported, or one that was canceled is left out.
* Code and Match nodes never appear, even when the item ran them. Only Generation and Quorum nodes produce metrics.
* Every entry reflects the item's state at the moment you started the export, like the rest of the file (see [Export your labeled results](/docs/data/guides/export-results.md)).

## Related

* [Prepare training data from labels](/docs/train/guides/prepare-training-data.md) — use completed entries’ `input` and `output` objects as the source for training examples
* [Label, train, and evaluate](/docs/workflows/label-train-evaluate.md) — carry a completed export into the cross-product workflow
* [Export your labeled results](/docs/data/guides/export-results.md) — how to produce and download the file
* [Fields and data](/docs/data/concepts/fields-and-data.md) — what the `input` and `output` fields hold
* [Quorum node](/docs/data/reference/nodes/quorum.md) — why `annotatorIds` can outnumber the configured overlap


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.