What formats and keys can a generated intake release use?

A release can be delivered as files, as an environment, or both. The file form is straightforward.

- **JSONL** for cases, submissions and notes, one object per line, each with a stable `case_id` or `note_id`. - **Parquet** for larger tabular sets such as parties and documents, which suit analysis and filtering. - **JSON or YAML** for policies, with `policy_id`, `applies_to`, `conditions` and `outcome`. - **Task files** in JSONL, each with `task_id`, `start_state_ref`, the instruction given to the agent and an `expected` block.

A typical `expected` block lists `final_status`, `final_queue`, `reason_codes`, `linked_case_ids` and `message_type`. Optional fields mark actions that must not occur, such as `forbidden_actions: ["close_case"]`.

Foreign keys connect the files: `party_id` links cases to parties, `case_id` links documents and notes, and `supersedes_case_id` links amendments to earlier cases. Keep these consistent, and a loader can reconstruct the whole case graph.

For a simulated environment, tool actions are exposed with typed arguments, for instance `set_status(case_id, status, reason_code)` or `assign_queue(case_id, queue)`. Reset loads a named snapshot, and an export call returns final state for grading.

The schema is agreed in scoping, because most buyers need field names that match their own agent's tool definitions.