Zovda
Ask a model to solve a problem and it often can. Ask a corpus to state the answer consistently and it often cannot. The failure is notation, not arithmetic.
Math data looks rigorous and is frequently inconsistent in ways a validator never notices.
One symbol, one meaning
The same expression can mean multiplication in one file and a wildcard in another. A minus sign may be a hyphen. A decimal comma may sit next to a decimal point in the same collection.
A normalisation table is the only thing that makes two files comparable.
Units belong to the answer
"12" is not an answer. "12 cm", "12%", and "12 items" are different problems with different checks.
We require units on numeric answers and a field stating the expected answer type, so verification can run without a human.
Difficulty is a label, not a length
A long problem can be easy; a short one can require a proof. Store a difficulty band and the required technique, and stop using character count as a proxy.
That change alone makes a corpus usable for curriculum work.
The checklist we run
- Is there a single normalisation table across the collection?
- Do numeric answers carry units and an expected type?
- Are difficulty and technique recorded per row?
- Can answers be parsed by one deterministic rule?
- Are duplicates detected after normalisation, not before?
If a supplier cannot answer these, the corpus is a typesetting exercise. Zovda normalises before annotating, and the Datuva catalogue exposes the answer types buyers need to verify.
Where to start
Start from the answer format your product must produce: number, expression, interval, or proof. The question bank collection covers the structured end, and the corpus catalogue maps stages.
Tell us the subject range and volume. We reply within one business day.