What might the record schema look like for generated set-up state?

Generated state can be delivered as JSONL, one entity per line, with a shared envelope so a loader can route records by type.

An envelope could look like `{"type":"approval","id":"APP-2187","version":1,"data":{}}`.

Suggested entity fields:

- **approval:** `id`, `party_ref`, `product_code`, `conditions[]`, `approved_by_role`, `approved_on`, `expires_on`, `status` - **party:** `id`, `legal_name`, `kind`, `identifiers[]`, `addresses[]`, `status`, `duplicate_group` - **account:** `id`, `party_ref`, `approval_ref`, `product_code`, `opened_on`, `status`, `terms` - **obligation:** `id`, `account_ref`, `kind`, `status`, `evidence_ref` - **task:** `id`, `assigned_role`, `instruction`, `input_refs[]`, `due`

Links are plain identifier references such as `party_ref` and `approval_ref`, so a referential integrity check is a join. A `duplicate_group` label lets the grader see which parties were seeded as near-matches; it can be withheld from the agent's tool results.

Policies ship as a separate file, for example `policies.jsonl`, with `rule_id`, `applies_to`, `condition` and `severity`. Expected outcomes ship as `expected_state.jsonl`, keyed by task id.

For analytical use, the same tables can be supplied as Parquet with identical column names. Confirm the format and field list in a pilot; this schema is a starting point for discussion, not a fixed specification.