What makes a mismatch task worth including in an evaluation?
Lists the properties that separate a mismatch task that discriminates between systems from one that is trivially solved or impossible to score.
Use this list to screen a candidate mismatch task before adding it to a benchmark.
- A single recorded root cause that a reviewer can verify from the evidence in the case. - At least one plausible but wrong explanation, such as a timing difference that does not account for the full gap. - Evidence spread across two or more related records, so one query does not settle it. - A stated policy that governs who may correct which record and by how much. - A defined correct action, plus any acceptable alternatives, including escalation where that is right. - A final state that can be compared with a reference, so a wrong fix is detectable. - A realistic handover note or case history that the agent must read rather than skip. - No leakage of the answer in field names, case titles or comments.
Tasks that meet most of these tend to separate careful investigation from guessing. Tasks that meet few of them tend to become either trivial or unscoreable, and are better revised than kept.
Use these traits to screen candidate tasks before they enter a benchmark, so each one measures something specific.
- Audience:
- Evaluation teams
- Content type:
- Checklist
- Buyer question:
- What it is and why it matters
Content release: r-a220eb6e099b243b
Related questions
- How does a mismatch appear in the systems an agent connects to?
- How do I tell if a process is a good fit for mismatch training?
- What does a billing mismatch caused by a transposed meter read look like?
- Why is a mismatch harder for an agent than a normal lookup task?
- What is a record mismatch in a business, and why does it matter for agent evaluation?
- What does a settlement-versus-ledger break look like as an environment task?