What checks should I run on a pack before using it for evaluation?
A checklist of integrity, fairness and leakage checks to run on a sample pack, each aimed at a different way an evaluation set can quietly mislead you.
Run these checks on a sample before you trust it as an evaluation set; each one catches a different way a pack can mislead you.
- Every record and policy ID referenced in cases and labels resolves to an actual record or policy. - The stated variance equals the difference you recompute from the two records. - A person can reach the labelled cause using only the tools and data the agent is given. - Held-out labels do not appear in any field, note or tool response the agent can read. - Each forbidden action is actually possible in the environment, so avoiding it is a real test. - Matched, fault-free cases are present, so false alarms are measured. - Escalation-correct cases are present, with a defined passing outcome. - Environment reset returns identical state on repeated runs of the same case.
Record which checks fail and why. A failure is more often a data fault to report back than an agent fault to fix, and sorting the two early saves wasted runs.
Each check catches a distinct way a pack can mislead, so running all of them keeps scores meaningful before you compare agent versions.
- Audience:
- Agent developers
- Content type:
- Checklist
- Buyer question:
- How to evaluate it
Content release: r-a220eb6e099b243b
Related questions
- How does path-level scoring separate two agents that both match the totals?
- How can a buyer inspect the quality of generated mismatch cases?
- How should I score an agent that reaches the right fix for the wrong reason?
- Where do reset, trace and grading hooks fit around an agent run?
- How do we know a generated mismatch case is solvable from what the agent can see?
- What evaluation hooks should a mismatch environment expose for reset, traces and scoring?