What might a case schema and tool interface look like for a simulated environment?

A single case can be delivered as one JSON object per line in a `cases.jsonl` file, with the same content normalised into Parquet tables for analysis.

A case object might contain:

- `case_id`, `domain`, `policy_version` - `approval`: `{approval_id, decision, decided_by_role, decided_at, expires_at}` - `conditions`: a list of `{condition_id, owner_role, evidence_required, due_at, status, mandatory}` - `evidence`: a list of `{evidence_id, condition_id, received_at, summary, assessment}` - `dependents`: a list of `{work_item_id, kind, gate_state}` - `timeline`: ordered events, each with `event_ts`, `actor_role`, `action` and `ref` - `label`: `{gate_should_open, open_condition_ids, expected_action}`

For the simulated environment, each action is a tool with a JSON schema: `read_register(approval_id)`, `log_evidence(condition_id, summary)`, `assess_evidence(evidence_id, outcome)`, `release_gate(work_item_id)` and `write_handover(case_id, text)`. Every call returns structured output and appends to `timeline`.

`reset(case_id, seed)` restores the generated starting state, so the same case can be run repeatedly across model versions. Hidden fields such as `label` are kept out of tool output and only read by the grader.

Treat these names as a proposal to refine in a pilot.