Skip to content
MirrorFirm

What evaluation hooks should an escalation environment expose to graders?

Event logs, tool-call traces, state snapshots, deterministic check functions, a rubric file and a seeded reset give graders what they need to reproduce and score runs.

A grader needs to see what the agent did and what state it left behind. An escalation environment can expose several hooks for that.

- **Event log.** Every state-changing action writes a `case_event` row with actor, action, target, rationale and evidence IDs. - **Tool-call trace.** The ordered calls and arguments, including read-only ones, so a grader can check whether the agent read the authority matrix and exposure links before acting. - **State snapshot.** A JSON dump of case, queue and ownership records at the end of the run, for comparison with `expected_outcome`. - **Deterministic graders.** Functions such as `check_target_tier(case_id)`, `check_trigger_ref(case_id)` and `check_evidence_ids(case_id)` that return pass or fail with a reason code. - **Rubric file.** Weights and descriptions for each check, kept apart from the graders so a team can re-weight without code changes. - **Reset.** A call such as `reset(seed)` that restores all records to a known state, so runs are repeatable and can run in parallel.

Free-text rationale quality cannot be fully scored by deterministic checks. Pair them with a rubric-based reviewer, human or model, and measure agreement on a sample.

Hook names and signatures above are a typical shape; agree them with your harness owner during the pilot.

Deterministic checks cover routing and evidence, while a rubric-based reviewer covers rationale quality; measuring their agreement on a sample keeps scores trustworthy.

Audience:
Evaluation teams
Content type:
Integration
Buyer question:
How to evaluate it

Content release: r-a220eb6e099b243b

More on Credit escalation