How does a conditional decision appear in the records a reseller ingests?

A conditional decision usually arrives as several linked tables rather than one flat file. A release could carry the following, as JSONL or Parquet.

- **decisions**: `decision_id`, `case_id`, `decided_at`, `decider_role`, `status` (such as approved_with_conditions), `policy_ref`. - **conditions**: `condition_id`, `decision_id`, `text`, `owner_role`, `due_at`, `state` (open, satisfied, waived, lapsed). - **evidence**: `evidence_id`, `condition_id`, `submitted_at`, `submitter_role`, `document_type`, `review_outcome`. - **holds**: `hold_id`, `case_id`, `condition_id`, `raised_at`, `cleared_at`. - **releases**: `release_id`, `case_id`, `released_at`, `released_by_role`, `blocking_conditions_at_release`.

The key links are `decision_id` to `condition_id`, and `condition_id` to `evidence_id` and `hold_id`. A reseller's ingestion job can check that every condition has a parent decision and that every release references the conditions in force at that moment.

State changes are best carried as an events table with `event_id`, `entity_id`, `from_state`, `to_state` and `occurred_at`, so ordering questions can be tested. Schemas and field names are agreed per release, so ask for a schema file alongside the data.

All records are generated. Plan a review of the sample for grounding and disclosure risk before onward licensing.