Which evaluation hooks make review runs reproducible and auditable?

An evaluation harness can reset each run to a named snapshot with a recorded scenario seed and controlled clock. The snapshot should include pending events as well as visible records, so repeated runs encounter the same scheduled changes.

Record each tool call with `run_id`, `step_id`, action arguments, returned result and the state revision it affected. An ordered trace lets developers reconstruct whether a failure arose from evidence selection, a rejected action or a later recovery attempt.

Evaluation hooks should operate outside the agent's writable state. They can assert that required follow-ups exist, prohibited changes did not occur and the terminal review state satisfies the task's acceptance criteria. A final message saying the review is complete should not substitute for those checks.

For export, JSONL can hold action events while Parquet can hold tabular run outcomes and assertion results. Shared identifiers allow analysis across both representations.

The buyer should also define how partial runs are scored. Tool interruption, unresolved business work and an incorrect completed decision represent different outcomes and should remain distinguishable in the results.