What might the JSONL or Parquet schema look like for sufficiency cases?

A common layout separates entities into linked files so they can be joined by key.

- `cases`: `case_id`, `case_type`, `policy_version`, `opened_at`, `status`, `channel`. - `documents`: `document_id`, `case_id`, `doc_type`, `issuer`, `issued_on`, `received_at`, `page_count`, `legible`, `content_ref`. - `requirements`: `requirement_id`, `case_type`, `policy_version`, `doc_type`, `max_age_days`, `substitutes[]`, `condition`. - `gaps`: `gap_id`, `case_id`, `requirement_id`, `kind` (`missing`, `stale`, `mismatch`, `illegible`), `document_ids[]`. - `requests`: `request_id`, `case_id`, `gap_ids[]`, `message`, `sent_at`, `reply_id`. - `events`: `event_id`, `case_id`, `ts`, `actor_role`, `action`, `payload`.

The `events` table is the natural JSONL stream, because each line is one dated action and replay is simple. Reference tables such as `requirements` suit Parquet, which keeps types explicit and loads quickly into analysis tools.

Two design points matter. First, keep `status` history in `events` rather than overwriting it, so you can train on intermediate states. Second, record the expected outcome in a separate label file, so the agent's inputs and the answer key never share a table.

Field names are a starting point. Agree the schema in a pilot so it maps cleanly to your own agent's tool outputs.