What would a JSONL schema for set-up tasks and starting state look like?

One workable layout uses one JSONL file per record type, with Parquet equivalents available if a buyer prefers columnar storage. Exact fields are agreed in a pilot.

- `decisions.jsonl`: `decision_id`, `decision_type`, `approver_role`, `effective_date`, `expiry_date`, `condition_ids` - `parties.jsonl`: `party_id`, `legal_name`, `identifiers`, `address`, `status`, `possible_duplicate_of` - `accounts.jsonl`: `account_id`, `party_id`, `decision_id`, `product_code`, `status`, `config` - `conditions.jsonl`: `condition_id`, `description`, `status`, `evidence_ref` - `policies.jsonl`: `policy_id`, `version`, `text`, `rules` - `tasks.jsonl`: `task_id`, `decision_id`, `policy_ids`, `prompt`, `split`, `difficulty` - `expected_state.jsonl`: `task_id`, `final_records`, `forbidden_actions`

Joins run through the identifiers: `tasks.decision_id` to `decisions`, `accounts.party_id` to `parties`, and so on. Status fields use closed vocabularies such as `draft`, `pending_conditions`, `active` and `closed`, listed in a schema file.

A validation script can check that every foreign key resolves and that each expected state is reachable from the starting state. Ask for that script in the sample so you can run it yourself. As the data is generated, include a grounding and disclosure review alongside the schema check.