What record structure should we expect from a set-up release?

A reseller needs to know what shape the records take before cataloguing them. Set-up material is relational, so a release is best described as a small set of linked tables rather than one flat file.

A typical core set:

- `approvals`: `approval_id`, `decision_type`, `decided_at`, `conditions` (array), `policy_ref` - `parties`: `party_id`, `party_type`, `match_status`, `merged_into` - `accounts`: `account_id`, `party_id`, `approval_id`, `product_code`, `status`, `opened_at` - `services`: `service_id`, `account_id`, `state`, `activation_blocked_by` - `tasks`: `task_id`, `account_id`, `task_type`, `owner_role`, `status` - `events`: `event_id`, `entity_id`, `from_state`, `to_state`, `actor_role`, `at`

Each table can ship as JSONL for inspection or Parquet for scale, with foreign keys documented in a schema file. The `approval_id` on `accounts` and the `events` log are the two links that let a buyer reconstruct how a decision became a live record.

For onward licensing, ask for a manifest that lists tables, keys, row-level generation flags and the schema version, so your customers can validate loads and pin versions. Field names above are a starting point; confirm the exact schema in a pilot.