Skip to content
MirrorFirm

How do we know a generated mismatch case is solvable from what the agent can see?

Ask for a scripted solvability check and reference trajectories per case, then use agent failures, universal passes and unsolved cases as signals about the pack or the agent.

**Q: How do we know a case is solvable from what the agent can see?**

Ask for a solvability check. For each case, a scripted solver using only the environment's read tools should be able to reach the cause and an acceptable end state. Cases the solver cannot finish are either flawed or deliberately undeterminable, and the release should label which.

**Q: What if the scripted solver passes but real agents fail?**

That is useful information about the agent. Look at the trace to see where it diverged: did it miss a join, misread a policy, or stop at the first plausible cause?

**Q: What if every agent passes?**

The case may be too easy or may leak its answer. Check whether the cause label, a case note or a field name gives the cause away. Ask for cases with the evidence placed at different depths, such as one read, three reads, or a read in a second system.

**Q: Can a case be solvable by more than one route?**

Yes, and the reference solutions should say so. A buyer can ask for several reference trajectories per case where policy allows more than one correct path.

**Q: What should we do with unsolved cases?**

Treat them as defects in the pack until the supplier confirms they are intended undeterminable cases. Keep a log of findings from your own review and bring it into the pilot discussion.

A scripted solver that uses only agent-visible tools separates flawed cases from hard ones and from deliberately undeterminable ones.

Audience:
Environment builders
Content type:
FAQ
Buyer question:
How to evaluate it

Content release: r-a220eb6e099b243b

More on Reconciliation mismatch