How could a generated release be laid out in files, and what does a task record contain?

A release for this workflow can be organised as a folder of files with a manifest that ties them together.

- `manifest.json` lists files, schema versions, the random seed used for generation and the generation date. - `decisions.jsonl`, `conditions.jsonl`, `evidence.jsonl`, `amendments.jsonl` and `work_items.jsonl` hold one record per line. - `policies/` holds rule files and plain-text policy documents, each with a `policy_id` that records cite. - `tasks.jsonl` holds the task pack.

A condition line might carry `condition_id`, `decision_id`, `type`, `owner_role`, `state`, `opened_at`, `due_at` and `closed_at`. Timestamps use ISO 8601 with an explicit offset, so Australian time zones and daylight saving can be tested.

A task line carries `task_id`, `initial_state_ref`, `instruction`, `allowed_tools`, `expected_actions`, `forbidden_actions` and `grading_notes`. Keeping expected and forbidden actions separate lets a grader penalise unsafe steps even if the final state looks acceptable.

Parquet versions of the same tables can be supplied for analytical work. Free-text fields stay in the JSONL.

Schema versions are explicit so a later release can add fields without breaking your loaders. Agree the field list in a pilot and test the loaders against a small sample before requesting more volume.