AI Evaluation Gaming: When the Rubric Becomes the Target

We run open challenges where developers compete to build the best enterprise AI skills. After ten of them and more than 1,683 submissions, one pattern keeps showing up, and it is worth being honest about.

Open evaluation works. Trust comes from public tests and public rubrics. A developer can see exactly what a skill will be judged on, which is the whole point of building in the open rather than behind a closed benchmark.

But open evaluation also creates pressure. When the rubric is visible, the rubric becomes the target.

Think of it like a college exam. Hand students the grading criteria and the good ones study the curriculum and put effort where it counts. That is the system working. But hand them the exact exam with the answers ahead of time, and a careful student can study only the questions they know are coming. Both students score well. Swap the exam at the last minute and only one of them still passes.

We watched this happen. The leading skill in one challenge was a masterclass in reverse-engineering. It mapped one to one to every rubric criterion, with lookup tables for the exact scenarios in the test set. It held no pre-written answers, so no simple filter caught it. It scored high because it was engineered to trigger the rubric, not because it was a better skill. The gap between a genuinely good skill and a rubric-optimized one was only about five to ten points of score, and both landed near the top.

That is the bug. If the highest-scoring skill is not the most useful skill, the reward is pointing the wrong way. And with emissions now live on-chain, pointing the wrong way is expensive.

So we stopped hand-authoring test suites and built a pipeline that designs against gaming from the start. A chain of subagents takes an approved skill and builds the challenge. It models the skill's real capabilities, tags which ones are gameable, then writes a scenario set deliberately mixed to resist optimization: mostly judgment calls and procedures, plus a deliberate share of two special kinds.

Trap scenarios, where the obvious rubric-driven move produces a bad answer. A skill that just does what the rubric rewards walks straight into the trap.

Out-of-distribution scenarios, edge cases the skill was never shown, that only a genuine approach handles.

Then the part we care about most. Before any challenge ships, a synthetic red team plays the adversary. It reads the same public files a contestant would and writes skills whose only goal is to game the evaluation: one that encodes the rubric as a checklist, one that forces every answer into a single template, one that memorizes dataset patterns. A calibration judge then scores a good-faith reference skill against all of them, on both a smaller and a larger judge model. The reference has to win by a clear margin on both. If it does not, the suite has not earned the right to ship. It loops back and tightens, up to a couple of times, before a human reviews it.

This is what let us close the gap. In one build, a single rubric-based judge could not tell the gaming skills from the real one. Adding a second grader that checks whether the output was actually shaped by the submitted skill's procedures, rather than by the rubric, opened a fifteen-point gap between the genuine skill and the best gaming attempt. That gap is the whole game. It is the difference between measuring familiarity with the test and measuring the skill.

None of this is a knock on the developers who scored well under the old system. The incentive we built rewarded that behavior, and rational builders responded to it. Fixing the incentive is our job, not theirs.

So here is what to take into a challenge now: build for the brief, not the rubric. The evaluation is designed to reward the skill that holds up on scenarios it has never seen. Skills, not benchmarks. Generalization, not familiarity. That is where this is heading, and now the emissions point the same way.