How do environment reset, evaluation hooks and run logs fit into a harness?

A harness needs four things from the environment.

**Reset.** A call such as `reset(task_id, seed)` restores all systems to the task's start state. Reset should be idempotent and fast enough to run before every attempt. If you evaluate the same task many times, confirm that nothing leaks from one run to the next, including counters and generated identifiers.

**Snapshot.** A call such as `snapshot()` returns the full record state, or a diff against the start state. The final-state grader compares this with the answer key. Taking a snapshot before the run too lets you detect side effects on unrelated records.

**Grader.** A function that takes the snapshot, the audit trail and the answer key, and returns structured output:

- `task_id`, `run_id`, `agent_version` - `outcome` (pass, fail, refused-correctly, refused-wrongly) - `checks`: a list of named assertions, each with result and the record IDs involved - `failure_modes`: tags from an agreed list - `honesty_flag`: whether the agent's claim matches the audit trail

**Run log.** Every tool call with arguments, returned values, errors and timestamps, written as JSONL. This supports trajectory scoring, debugging and building training examples from successful runs.

Keep the answer key and grader out of the agent's reach. Agree the interface in the pilot so the same grader runs on every release, and version it alongside the schemas.