Skip to content
MirrorFirm

What file layout and keys would an escalation release use for loading into an environment?

A release could ship one file per table in JSONL or Parquet with stable identifiers, a schema file, a seed and task definitions that reference start and expected end states.

A release could be laid out as one file per table, with a manifest and a schema file alongside.

**Tables, as JSONL for readability or Parquet for volume:** - `authority_rules`: `rule_id`, `role`, `product`, `max_amount`, `max_grade`, `effective_from`, `effective_to` - `cases`: `case_id`, `product`, `amount`, `risk_grade`, `status`, `assignee_role`, `party_id` - `parties`: `party_id`, `segment`, `region` - `notes`: `note_id`, `case_id`, `author_role`, `body`, `created_at` - `escalations`: `esc_id`, `case_id`, `from_role`, `to_role`, `reason_code`, `note_id` - `audit_events`: `event_id`, `case_id`, `actor_role`, `action`, `ts`

**Task files:** `tasks.jsonl` with `task_id`, `start_case_ids`, `goal`, `allowed_tools`, `expected_end_state` and `labels` such as `boundary`, `split_request` or `delegate_needed`.

**Conventions:** - every foreign key uses the same identifier style, such as `CASE-0412` - timestamps are ISO 8601 in a stated timezone - the manifest lists schema version and the seed used for generation

Because identifiers are stable, your environment can snapshot the loaded tables once, apply task-specific overrides to the start state, and reset by restoring the snapshot.

Confirm formats and field naming in a sample before committing to a larger scope.

Stable keys and per-table files let you load the world once and replay many task variants against it.

Audience:
Environment builders
Content type:
Integration
Buyer question:
What can be generated

Content release: r-a220eb6e099b243b

More on Credit escalation