Skip to content
MirrorFirm

What formats and schema do escalation datasets and task packs use?

Records can be delivered as JSONL for tasks and events and as Parquet for larger relational tables, with stable identifiers and a manifest describing versions and links.

Format and schema are agreed per engagement, but a typical layout looks like this.

**JSONL** suits task definitions and event streams, one object per line:

- `tasks.jsonl`: `task_id`, `case_id`, `instruction`, `starting_state_ref`, `expected` (target role, reason codes, handover requirements) - `events.jsonl`: `event_id`, `case_id`, `actor_role`, `action`, `from_status`, `to_status`, `occurred_at`

**Parquet** suits relational tables you may query in bulk:

- `cases`, `parties`, `facilities`, `reviewers` - `authority_rows`: `role`, `product`, `limit_basis`, `limit_value`, `effective_from`, `effective_to` - `escalations`: `escalation_id`, `case_id`, `from_reviewer_id`, `to_role`, `reason_code`, `outcome`

**Documents** can be supplied as text or structured files, referenced by `document_id` from the case.

Identifiers follow a consistent style such as `CASE-0412` or `ESC-0319`, and foreign keys are explicit so joins are reproducible. A `manifest.json` lists files, schema versions, row counts for that delivery, the generation configuration and the foreign-key map.

The data is generated, so a validation script that checks referential integrity and date ordering is a sensible part of any sample. Ask for field names to be aligned to your own schema in a pilot rather than adapting your pipeline to ours.

Stable keys and a manifest let you load the data into your own pipelines and rebuild joins without guesswork.

Audience:
Agent developers
Content type:
Integration
Buyer question:
What can be generated

Content release: r-a220eb6e099b243b

More on Credit escalation