Skip to content
MirrorFirm

Which file formats and schema conventions suit an escalation dataset?

JSONL for cases and traces, Parquet for large tables and JSON Schema for validation, with identifier, money, timestamp and enumeration conventions fixed before generation.

Choose formats by how the data will be read, and fix the conventions before generation so every table joins cleanly.

- **JSONL** for cases, events and tool traces. One object per line streams well and diffs cleanly in review. - **Parquet** for large tables such as exposure links or balances, where columnar reads help bulk analysis. - **JSON Schema** files for each table, so a loader can validate a release before ingesting it.

Conventions worth agreeing up front:

- Stable identifiers with a type prefix, such as `APP-2187`, `FAC-5530` and `CASE-0412`, used as join keys across files. - Money as integer minor units plus a currency code, which avoids rounding disputes in aggregate calculations. - Timestamps in ISO 8601 with a timezone, so event ordering is unambiguous. - Enumerations for status and event types, listed in the schema rather than free text. - A `manifest.json` listing files, schema versions, row counts, the generation seed and the train, dev and test split assignment.

Keep expected outcomes in their own file, separate from the case files, so a team can withhold them from an agent's context and from any training split.

Formats are negotiable. If your harness expects a different layout, such as a single nested JSON per case, raise it during scoping and test it on a sample first.

Agreeing conventions up front means every table joins cleanly and a loader can validate a release before ingesting it.

Audience:
Evaluation teams
Content type:
Integration
Buyer question:
What can be generated

Content release: r-a220eb6e099b243b

More on Credit escalation