> ## 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: Data formats Compute reads and writes
description: >-
  The eight versioned format subsets Compute supports, why a subset is not the whole specification,
  and the rules for timestamps, money, missing answers and item identity.
route: /docs/compute/reference/formats
page_id: docs-compute-reference-formats
page_type: reference
content_layer: technical reference
surface_profile: technical_reference
audience: 'Data engineers preparing inputs and parsing Compute result bundles'
voice: D
reader_question: 'Which formats can I send and receive, and which subset of each is supported?'
primary_action: Pin the format profile version you tested against
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-reference-formats-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"
---

## Eight format families

Compute reads and writes eight families of format. Each is a documented subset, never the whole specification.

| Family | Used for |
| --- | --- |
| JSONL | Per-item records, in and out |
| Parquet | Columnar tabular data at scale |
| Arrow | Tabular interchange with analysis tools |
| Documents | Document extraction, layout and transformation |
| Media | Audio, image and video inputs and outputs |
| Captions | Subtitle and transcript outputs |
| SARIF | Code quality findings |
| JUnit | Test results |

A subset is stated as an inclusion list, not as an exception list. If a feature of the wider specification is not named in the profile, treat it as unsupported rather than as untested.

## Every released profile carries its own version

Each format profile is released with its own version, and versions move independently of the API and of any workflow.

Pin the profile version you tested against. Read the version note before you upgrade a parser, because a subset can widen and a deprecated construct can leave.

Your `input.format` names the profile you are sending. Your `output` declaration names the profile you want back.

## Timestamps, money, missing answers and encoding

Four cross-cutting rules apply across every family.

- **Durations** are ISO 8601. `limits.deadline` is written that way.
- **Money** is a currency plus a decimal amount, never a floating-point number. `limits.maximum_price` carries both parts together.
- **A missing answer is never an empty accepted row.** An item that produced no answer is written under `abstentions/part-*` or `failures/part-*`, and `lithi_status` says which.
- **Text encoding, timestamp representation and decimal precision** are stated on the released profile. Read them before you write a parser rather than inferring from a sample.

That third rule is the one that surprises people. A null in your accepted output means the workflow returned a null, not that an item failed quietly.

## Item identity and snapshots

`input.item_id_field` names the field that identifies one item. Every result row, failure and abstention carries that identity back, so you can join results to your source.

`input.snapshot` freezes what was read. It carries a `version_id` and a `content_sha256`, so a rerun reads the same bytes and a changed source is visible rather than silent.

## Result columns are namespaced

Tabular output gains seven columns: `lithi_status`, `lithi_result`, `lithi_error_code`, `lithi_confidence`, `lithi_evidence`, `lithi_verification` and `lithi_usage`.

They are namespaced so they can be appended to your own schema without renaming your columns. Read `lithi_status` first; it tells you whether the row is an accepted answer at all.

## Where the exact subsets are published

Each format profile, with its version and its supported constructs, is published alongside the API description in developer settings in the portal.

The workflow descriptor states which profiles that workflow accepts and produces. See [how the bundle is laid out](/docs/compute/reference/schemas) before you write the reader.