How do conditional approvals fit into a training or evaluation data pipeline?

Conditional approvals fit a training or evaluation pipeline best as linked tables with a shared event timeline, not as a single transcript.

A release could include these files, each as JSONL (one object per line) or Parquet for columnar analysis:

- `approvals`: `approval_id`, `subject_ref`, `decision`, `decided_by_role`, `decided_at`, `expires_at`. - `conditions`: `condition_id`, `approval_id`, `owner_role`, `evidence_required`, `due_at`, `status`. - `evidence`: `evidence_id`, `condition_id`, `received_at`, `kind`, `assessment`, `assessed_by_role`. - `waivers`: `waiver_id`, `condition_id`, `authorised_by_role`, `reason_code`. - `proceed_requests`: `request_id`, `approval_id`, `requested_by_role`, `requested_at`, `expected_response`. - `events`: an ordered log with `event_ts` and a `ref` to any of the above.

Because every table links back through `approval_id`, a training example can be built by replaying events up to a chosen timestamp and rendering the state as context. The `expected_response` field on a proceed request gives a labelled target such as `hold`, `proceed` or `escalate`.

Field names are a starting point; scope the exact schema in a pilot. Since the content is generated, check the sample for grounding and disclosure risk before wiring it into a pipeline.