Data formats Compute reads and writes

Eight format families

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

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 before you write the reader.