A row count is the least informative number you can publish about a dataset. Here is what a buyer or reviewer actually needs, in rough order of how often it is missing.
1. Register and dialect distribution
For Arabic this is the first question and it is almost never answered. "50,000 Arabic conversations" could mean anything from uniformly MSA to 90% one regional dialect.
State the breakdown:
Najdi 34%
Hejazi 27%
Sharqiyah 18%
General / white 21%
Someone building for Riyadh needs to know whether Najdi is a third of the corpus or a twentieth of it, and no aggregate number answers that.
2. Duplicate and near-duplicate rate
Two numbers, with the method:
- Exact duplicates removed
- Near-duplicates removed, with the similarity metric and threshold
"1,240 rows removed at MinHash ≥ 0.85 over word-level 4-shingles" is checkable. "Deduplicated" is not.
A stated zero is suspicious rather than impressive, and saying so in the card is more credible than omitting the field.
3. Drop rate, and what failed
If the corpus passed through a quality gate, publish how much did not pass, broken down by which check rejected it. A rejection histogram tells a reader where the data is weakest, which is exactly what they want to know and exactly what most cards hide.
It also tells them the gate runs. A corpus with 22 checks and a 0% rejection rate is describing a gate that is not gating.
4. How the splits were made
Not the ratio — the method. Specifically, whether near-duplicate clusters were kept on the same side of the split.
| Weak | Strong |
|---|---|
| "90/10 train/validation" | "90/10, split by near-duplicate cluster so no pair above 0.85 similarity spans the boundary" |
Anyone who has been burned by leakage looks for this sentence first.
5. The row schema, with types
Every field, its type, whether it is always present, and what it means. Including the ones you think are obvious.
For annotated data, two extra things matter:
- The closed label space, listed in full
- Whether labels were model output or generation input — these produce materially different corpora and a reader cannot tell from the rows
6. Provenance
What the generator was conditioned on. For synthetic data this is the sentence that carries the compliance claim, so make it explicit rather than implied: whether real records were used as seeds or few-shot examples, how identifiers were produced, and whether named entities are invented.
7. Known weaknesses
The section that builds the most trust and appears the least.
Every corpus has classes that are thin, registers that are under-represented, phenomena the generator handles badly. Write them down. A reader who finds a weakness you documented concludes you measured carefully. A reader who finds one you did not concludes the opposite about everything else in the card.
A minimal template
Rows / conversations / labelled units
Register distribution
Label distribution, vs target if one was set
Duplicate policy: metric, threshold, rows removed
Quality gate: number of checks, rejection rate, top rejection reasons
Splits: ratio and grouping method
Schema: field, type, presence, meaning
Label space: full list, and whether labels were input or output
Provenance: what the generator saw
Known weaknesses
License
Ten headings. It takes an afternoon, and it is the difference between a dataset someone can evaluate and one they have to take on trust.