What evaluation hooks should a harness expose for a conditional approval environment?

Evaluation hooks are easiest to build when the environment exposes state, not only text.

A typical harness has four parts:

- **Reset:** `reset(case_id, seed)` loads the generated starting state, including approval, conditions, evidence and dependent work items. - **Agent loop:** the model calls tools such as `read_register`, `assess_evidence`, `release_gate`, `request_information` and `write_handover`. Each call and result is appended to a `trace.jsonl` file. - **State diff:** after the run, the harness compares the final register against `expected_state`, field by field, for example `gate_state`, `condition.status` and `notifications`. - **Graders:** one function per failure mode, each returning `{check_id, passed, evidence_refs}`. A rubric-based grader can score the handover text against `open_condition_ids`.

Results can be written as one JSONL row per run with `case_id`, `model_id`, `seed`, `checks` and `final_state_hash`, then loaded into Parquet for comparison across model versions.

Keep the hidden `label` and `expected_state` out of tool responses. Run each case with several seeds if the environment includes variation in evidence wording.

Hook names and output shapes are open to adjustment; confirm them against your own harness in a pilot, and review a sample for grounding before you rely on scores.