How should evaluation hooks avoid leaking the expected correction to the agent?

An evaluation harness can maintain two interfaces: an observation surface used by the agent and a privileged evaluator surface used after or during the run. The agent sees business records and permitted tools. The evaluator can access expected outcomes, hidden fault settings and assertions about acceptable behaviour.

A generated task may carry `case_family`, `expected_disposition` and `injected_fault` in evaluator metadata. These fields should not appear in task prompts, searchable attachments or ordinary tool responses. File names and error messages also need review; a descriptive fixture name can reveal the intended answer even when the main label is hidden.

Evaluation hooks can emit `tool_called`, `record_read`, `mutation_attempted` and `run_completed` events with timestamps and run identifiers. Assertions can then inspect the trace alongside the final state, without requiring the agent to narrate every internal decision.

MirrorFirm could provide separate schemas and access controls for these surfaces. Buyers can test the boundary by querying the environment through the same credentials as the agent. They should also keep related case variants within a controlled dataset split, so memorising a training case's outcome does not masquerade as successful investigation on its evaluation counterpart.