Evaluation Methodology · LLM Benchmarking

The harness
picks the winner.

One model. 26 equally defensible evaluation setups. A 58-percentage-point range in reported score. A new study finds that config-fragile benchmark items carry 95.7% of the score gap between adjacent models, and that four of twelve models can claim rank one depending entirely on how the harness is configured.

Core concept
Config-fragile items: benchmark questions whose correctness score changes with equally defensible harness choices. These items concentrate nearly all the variance that separates adjacent models on standard leaderboards.
scroll to explore

First surfaced in Tandemly Briefing — 2026-08-21.

A score is a band,
not a number.

What the paper did, and why it matters.

Researchers built a fragility grid: 12 open-weight instruction-tuned models from four families, each answering 3,679 items drawn from ARC, HellaSwag, MMLU, and TruthfulQA, under 26 equally defensible harness configurations. Items, weights, and decoding strategy stayed fixed. Only harness setup changed.

The result collapses the standard interpretation of leaderboard scores. One model (gemma4-31b) spans 31% to 89% accuracy on harness choice alone. Four of the twelve models can claim rank one under some configuration. And the items responsible for this variance are not random. Config-fragile items carry 95.7% of the score gap between adjacent model pairs on average. Benchmark compression, which is supposed to sharpen discrimination, makes the problem worse: it selects for the most fragile items, not the most stable ones.

The per-item records and analysis scripts were released with the paper. Every number reproduces on a CPU in seconds, so this is a claim anyone can verify.

The benchmark assumes
a neutral instrument.

Standard leaderboard practice treats score as capability. This paper tests that assumption.

LLM evaluation has converged on a small set of multiple-choice benchmarks: ARC, HellaSwag, MMLU, TruthfulQA. The Open LLM Leaderboard and similar rankings formalize the practice. A model gets a score. Teams use that score to choose between options. The implicit assumption is that the score measures something stable about the model.

Prior work showed aggregate variance under harness changes, but stopped there. A model's score shifted when you ran the same benchmark under a different harness setup, but which items were responsible? Were they distributed randomly, or concentrated in a small, identifiable subset? Did benchmark compression, the standard practice of distilling thousands of items into a smaller more discriminative set, help or hurt?

These questions stayed open. And they matter more than they might appear. If model-selection decisions rest on rankings that are partly manufactured by harness configuration rather than model capability, teams can be choosing systematically wrong models without any visible signal that something has gone wrong.

The question the paper answers

Which items drive the harness-induced variance, and can we identify them? If fragile items are concentrated and measurable, the problem has a fix. If they are diffuse and unpredictable, the problem is structural.

One grid to find
the fragile items.

The setup was deceptively simple. Every variable held fixed except one.

The paper builds what it calls a fragility grid. Twelve open-weight instruction-tuned models from four families answer 3,679 items from the four standard benchmarks under 26 harness configurations. Every configuration is equally defensible. None is wrong. Items, weights, and greedy decoding stay fixed across all configurations. Only the harness setup varies.

The harness configurations differed on choices like: how the question is formatted before the model sees it, how answer choices are presented, and most importantly, how the answer is scored. Should the harness record what text the model generates, or which answer option received the higher log-likelihood (the log of the model's probability for each choice)? Both methods appear in the wild. Neither is wrong. And the difference between them turns out to carry most of the variance.

The result is one correctness bit per model-item-config cell: a three-dimensional grid. An item is config-fragile if its correctness score changes across configs for a given model. This is the key diagnostic unit, and it turns out to be concentrated. Most items are stable across configs. A small fraction are not, and that fraction does almost all the work of separating adjacent models.

12
Models evaluated
Open-weight instruction-tuned models from four families, including Gemma 4. Each model answering each item under each config produces one correctness bit.
3,679
Benchmark items
Drawn from ARC, HellaSwag, MMLU, and TruthfulQA: the four benchmarks that most standard leaderboards use. Items, weights, and decoding strategy are fixed across all configurations.
26
Harness configurations
All 26 configurations are equally defensible. The load-bearing variable, identified in the results, is scoring mode: generated text versus per-option log-likelihood. Not option ordering, which most protocols standardize.

Four models can
claim rank one.

The numbers are large enough that none of them read as measurement noise.

Score range, one model
58pp
gemma4-31b: 31% to 89% on harness choice alone
Models reaching rank one
4 / 12
Under some configuration, four models can claim first place
Gap carried by fragile items
95.7%
Of adjacent-model score gaps, on average, come from config-fragile items
Standard leaderboard assumption
A score is a point. Models run against a standardized harness and get a number. That number reflects model capability. Adjacent rankings reflect real capability differences.
What the fragility grid shows
A score is a band. The number depends heavily on which scoring mode and harness configuration is used. Adjacent rankings are mostly determined by config-fragile items, not capability differences that survive configuration change.
Finding 1: Score is a band, not a point

Gemma4-31b scores between 31% and 89% depending solely on harness configuration. The model is the same. The benchmark items are the same. Decoding is greedy throughout. The 58-point range is entirely attributable to config choice. This is not an outlier: several other models in the study show comparable ranges. A single reported score on any of these benchmarks is a single draw from a wide distribution.

Finding 2: Four models can claim rank one

Of the twelve models in the study, four can achieve the top leaderboard ranking under some configuration. The harness is not a neutral instrument. It selects the winner. Teams relying on a published ranking to choose between models may be relying on a ranking whose top position changes with config choice rather than reflecting stable capability ordering.

Finding 3: Fragile items carry the gap

On items where two adjacent models both answer consistently across configs, the pair scores essentially the same. The entire observed ranking difference between neighboring models comes from config-fragile items: the small fraction of benchmark questions whose correctness score changes with harness configuration. Config-fragile items carry 95.7% of the adjacent-model score gap on average. Remove those items, and adjacent models converge.

Finding 4: Compression makes it worse

Benchmark compression is a standard practice: start with thousands of items, keep the most discriminative ones, end up with a smaller benchmark that still separates models. Item discrimination correlates with fragility at r = 0.28 (95% CI: 0.25-0.30). Selecting for discrimination is, on average, selecting for fragility. A compressed benchmark is more likely to be fragility-weighted than the full benchmark it was derived from. The discriminative property that compression maximizes and the config-fragile property that creates unstable rankings track together.

Finding 5: Scoring mode is the load-bearing variable

Of all the harness choices that vary across the 26 configurations, scoring mode drives the most variance. Whether the harness scores by what text the model generates, or by which answer option received the higher log-likelihood, is the choice that matters most. Option ordering, which is what most evaluation protocol standardization focuses on, turned out to matter much less. Evaluation protocols may be standardizing the wrong variable.

Scope and limitations

The study covers 12 models from 4 families, 3,679 items from 4 benchmarks, and 26 configurations. The findings describe these models and benchmarks under these configurations. Generalization to other model families, other benchmarks, or other configuration spaces requires further work. The paper's released code lets teams run the same analysis on their own setup, which is the appropriate way to check whether these findings apply to a specific use case.

What changes about
model selection.

The findings affect anyone who uses published leaderboard scores to choose or rank models.

1
For teams using published leaderboard scores to select models
A published score on ARC, HellaSwag, MMLU, or TruthfulQA is a single draw from a distribution. The practical floor here is: know the scoring mode the leaderboard used. Generated text or per-option likelihood? If the page doesn't say, treat the score as provisional. For decisions between closely-ranked models, a score gap that looks meaningful may be entirely attributable to which items are fragile under that configuration.
2
For teams running internal evaluations
Standardize scoring mode first. Most evaluation protocols spend effort standardizing option ordering. This paper shows scoring mode (generated text versus per-option log-likelihood) is the variable that carries most of the harness-induced variance. Decide which scoring mode your internal benchmark uses, record it, and apply it consistently. Changing scoring mode between runs produces score bands that cannot be compared.
3
For teams using benchmark compression
Benchmark compression by item discrimination selects for fragility. If your compressed benchmark was assembled by keeping the most discriminative items, it is more likely to be fragility-weighted than the full benchmark. Before trusting a compressed benchmark for model selection, measure its fragility profile: run two configurations that differ in scoring mode and check whether rankings change. A benchmark that reverses rankings on scoring-mode change is not safe for selection decisions regardless of its discrimination profile.
4
For researchers publishing benchmark results
The paper's fragility analysis is cheap to run: one correctness bit per model-item-config, no LLM calls, reproducible on a CPU in seconds using released code. Including a fragility score alongside benchmark results gives readers a way to interpret the score's stability. A score accompanied by "fragile items contribute X% of adjacent-model gaps under these configs" is more informative than a score alone.

Concrete next
steps.

What you can actually do with these findings.

1
Check the scoring mode on any leaderboard you use for model selection
The benchmark page or harness documentation should say whether it scores on generated text or per-option log-likelihood. If it does not specify, that is the first thing to find out before relying on the ranking for a production decision.
2
Report a score band, not a score point, for important comparisons
The minimum intervention is two runs on your evaluation set: one with generated-text scoring and one with per-option-likelihood scoring. Report both. If they agree on ranking, the finding is more robust. If they disagree, the gap between candidate models may be fragility-driven.
3
Run the paper's fragility analysis on your existing internal benchmark
The method requires no new LLM calls: one correctness bit per model-item-config combination is enough. Run it on your current item set to identify which items are driving gaps between candidate models. The released code and data from the paper provide a working implementation.
4
Before compressing a benchmark, measure fragility first
If the highest-discrimination items in your benchmark are also the most config-fragile, compression is moving in the wrong direction. Identify stable high-discrimination items, if they exist, and prefer them for compressed subsets.
5
Read the paper
Parupudi, V.S. Raghu (2026). "There Is No Neutral Harness: Modern LLM Leaderboards Are Manufactured by Config-Fragile Items." arXiv:2608.21382. Per-item records and analysis scripts are released with the paper and run on a CPU in seconds.