What is Reasoning Data?
Worked reasoning for problems with verifiable answers: step-by-step derivations in mathematics, the sciences, and logic, where the final answer can be checked independently and the intermediate steps can be inspected by a reviewer.
Reasoning data is worked solutions to problems whose answers can be checked: mathematics, the sciences and logic, where a final answer exists and the steps between the question and the answer can be inspected. It is what reasoning models are fine-tuned on and what process reward models are trained against.
The distinguishing concern is that the derivation, not the answer, is the product. A dataset of final answers trains a model to guess outcomes; a dataset of verified derivations trains the search behaviour that produces them. The two look similar in a file listing and behave completely differently in training.
The second concern is verification depth. Checking the final answer is mechanical, and checking each step requires people who can actually solve the problem at the level being collected. The cost of this category is dominated by that second check, and suppliers who quote without it are quoting for a different product.
What buyers get wrong
The failure mode is plausible-looking wrong reasoning. A solution whose steps do not follow from each other teaches a model to imitate the shape of reasoning without the substance, and the defect is invisible without step-level review by people who can actually solve the problems.
The specification detail that decides everything
Whether the delivery separates the derivation from the final answer and records how each was verified. Answer-only records train outcome prediction; step-verified derivations are what process supervision and reasoning distillation consume.
This is the line item that most often separates a dataset that works from one that gets re-ordered. It belongs in the specification before production starts, not in the delivery review.
How we source it
We do not hold inventory in this category. A requirement comes in, we match it to a producer who can meet the specification, and we agree the quality bar with both sides before recording begins. A pilot batch goes first so misalignments surface early.
Scenarios this covers
Buyers rarely ask for a category by name. They describe a situation, and the situation is what tells us whether this category is the right one. If yours is in the list, name it in the brief and it goes straight into the specification. If it is not, describe it anyway, because it usually means the requirement sits in a neighbouring category.
What good Reasoning Data looks like
Reasoning data is judged on step correctness and answer verification, both of which are documented properties rather than a matter of how fluent the solution reads.
-
Steps that follow from each other
Each step derived from the previous one, reviewed by someone who can solve the problem, because plausible-looking wrong steps teach the shape of reasoning without the substance.
-
Verifiable final answers
An answer that can be checked mechanically or by a short independent computation, so the correctness of the set does not rest on trust.
-
Derivation separated from answer
The two delivered as distinct fields, because outcome training and process training consume different parts of the same record.
-
Error and correction pairs
Wrong attempts paired with their corrections, which is what teaches models to detect and repair their own mistakes rather than to never make them.
-
Difficulty and topic labels
Problems labelled by topic and difficulty band, because a reasoning set that cannot be stratified cannot be used to measure what it improved.
Public datasets in this category
These are openly documented resources, not products we sell. Each one covers part of the category, and knowing where each stops is usually what decides whether a project needs a collection of its own.
-
GSM8K
Grade-school mathematics word problems with step-by-step solutions, the set that made small reasoning benchmarks practical. It covers arithmetic reasoning at one level; what it does not cover is the difficulty range that frontier training now consumes.
-
MATH
Competition-style problems across algebra, geometry and number theory with full solutions, organised by difficulty. It reaches much further than grade-school sets, and it still samples one style: contest problems, not the applied problem shapes of professional work.
-
NuminaMath
A large open collection of competition problems with solutions, assembled from multiple sources with deduplication. It is the volume answer to the earlier benchmarks; the open question it leaves is verification depth across such a wide assembly.
-
OpenMathInstruct
A synthetically generated instruction set of mathematics problems and solutions with verified answers, published to make the generation recipe reproducible. It shows how far synthesis goes and where it stops: answer verification is mechanical, step quality still needs people.
Questions to ask a supplier
Questions that decide whether the solutions can support process training, or only outcome training.
- Who reviews the derivations, and what is their qualification at the level being collected?
- How is each final answer verified, mechanically or by independent computation?
- Are wrong attempts and corrections included, or only correct solutions?
- How are problems labelled by topic and difficulty?
- What share of the set was rejected in review, and against what criteria?
The vague answer here is a claim of expert review without names or criteria. Ask who reviews, at what level, against what criteria, and what share of submissions was rejected. Rejection rate is the number that separates a reviewed set from a collected one.
A verifiable answer can show a rejected item with the reviewer's reasoning, and can describe how answers are checked independently of the author. Both details are hard to fake and cheap to verify, which is what makes them useful questions.
Technical attributes
The items below are the ones a specification can hold a producer to, and the ones that decide whether a delivery is usable for training rather than only present.
| Step verification | Derivations reviewed by qualified solvers, criteria recorded |
|---|---|
| Answer verification | Mechanical or independent check per problem |
| Record structure | Question, derivation and answer as separate fields |
| Error coverage | Wrong attempts with corrections included |
| Labeling | Topic and difficulty band per problem |
| Delivery format | Structured records with verification metadata per item |
The step verification column is the price of this category. Mechanical checks can verify answers and formal proofs; everything short of that needs people who can solve at the collected level, and the cost structure of a reasoning set is essentially the cost of that review.
The record structure column decides the training uses. Answer-only records train outcome models; derivation and answer as separate fields support process supervision, distillation and error analysis from one delivery.
A mistake here is measured as confident wrongness. A model trained on unverified derivations learns to produce authoritative-looking steps that do not hold, and the failure surfaces in production as wrong answers with no signal that anything was wrong.
How Reasoning Data is collected
Reasoning collection is authoring and review rather than recording: the work is producing correct derivations and proving they are correct.
- Problem sourcing and answer verification. Problems are selected with known or independently computable answers, because a set without checkable answers cannot be verified at all.
- Derivation authoring. Solutions are written step by step by people who can solve at that level, in the register the target model should learn, from terse competition style to explanatory tutoring style.
- Step-level review. A second qualified reviewer checks that each step follows, and the criteria for rejection are recorded, because review without recorded criteria drifts across a long project.
- Error pairing. Common wrong approaches are captured with their corrections, so the set contains the failure modes the model will meet rather than only the path through.
- Labeling and packaging. Problems are labelled by topic and difficulty, verification status is recorded per item, and the set is packaged with the review criteria and rejection statistics.
After review, each record is re-verified at the answer level, derivation and answer are split into separate fields, verification status and reviewer criteria are attached per item, and rejected items are summarised with reasons. The re-verification pass is what catches the errors that review itself introduces.
The pilot for reasoning data is a small set across the intended topics and difficulty bands, authored, reviewed and answer-verified end to end. Its purpose is to calibrate the review: the rejection rate and the kinds of defects found decide whether the criteria are set right before volume work begins.
Acceptance is checked by re-verifying a sample of answers mechanically and re-reviewing a sample of derivations independently. The specification should fix the register, the label scheme and the verification method before authoring starts, because all three shape every item that follows.
How a delivery goes wrong
The defects below are the ones that recur across this category. Each is decided at collection or annotation time, which is why none of them can be repaired in delivery review.
-
Steps that do not follow
A derivation that jumps or asserts teaches a model to imitate the appearance of reasoning. The defect is invisible in spot checks and systematic in effect, which is why step-level review by solvers is the core cost of this category.
-
Answers that were never verified
Collected solutions occasionally contain wrong answers, and a wrong answer key teaches the model to be confidently wrong at scale. Mechanical re-verification of answers is the cheap defence and the one most often skipped.
-
One style of reasoning only
A set drawn entirely from competition problems produces a model that reasons in competition register: terse, formal and unhelpful outside the genre. Register has to be a collection parameter, not an accident of sourcing.
Why this matters to buyers
Reasoning is the capability that compounds: a model that can work through an unfamiliar problem is useful on problems nobody collected. Outcome-only data teaches it to sound right on familiar ones, and the gap between those two shows up exactly when it matters, on inputs outside the training distribution.
The second driver is measurability. Verified derivations make it possible to train against process, to detect reward hacking early, and to see whether an improvement came from better reasoning or better guessing. None of that is available from answer keys alone.
The cost of unverified reasoning data is a model that fails expensively: it is deployed because it sounds right, and it is wrong on exactly the problems that matter, with no way to tell from the output. Verification is what makes the difference between a model that reasons and one that performs reasoning.
The second cost is the ability to improve. Process supervision, error analysis and difficulty-stratified evaluation all need step-level, verified structure. A team that bought answers buys another dataset when it needs to iterate.
Verified derivations give a reasoning programme both the training signal and the measurement: process supervision works, wrong answers are visible, and difficulty bands let improvement be attributed. The dataset compounds because every verified step is reusable across models.
The second gain is coverage control. A set collected by topic and difficulty can be extended where the model is weak rather than where collection is cheap, and the next batch is comparable with the last. Iteration is what reasoning programmes actually run on.
Specification at a glance
| Category | Reasoning Data |
|---|---|
| Group | Non-speech data |
| Critical spec | Whether the delivery separates the derivation from the final answer and records how each was verified. Answer-only records train outcome prediction; step-verified derivations are what process supervision and reasoning distillation consume. |
| Included by default | Pilot batch, metadata schema, source and consent documentation |
| Pricing | Quoted from specification. No published rates |
Related categories
-
LLM Training Data
Text corpora for LLM pretraining and fine-tuning: instruction data, preference data, and multi-turn dialogue data.
-
Computer Vision Data
Annotated image and video data, with annotation types including classification, bounding boxes, segmentation masks, and keypoints.
-
NLP Data
Annotated text for NLP tasks: named entities, dependency syntax, sentiment polarity, and relation extraction.
-
Multilingual Language Data
Parallel or non-parallel text corpora spanning multiple languages, used for multilingual models and low-resource language research.
-
Translation Data
Parallel corpora pairing source and target language, used for machine translation training and evaluation.
-
Dictionary Data
Structured dictionary entries with definitions, parts of speech, pronunciation, and example sentences, used for dictionary products and lexical understanding tasks.
Questions about Reasoning Data
Why not collect answers only?
Because the answer does not contain the behaviour. Training on outcomes rewards the model for arriving anywhere near the result, including by shortcuts that fail on harder variants. The derivation is the part that generalises.
How are derivations verified?
A second qualified solver reviews each step against recorded criteria, and final answers are checked mechanically where possible. The review criteria and the rejection statistics are part of the delivery, so the level of checking is auditable rather than asserted.
Do you cover formal proofs as well as informal solutions?
Yes. Formal settings such as proof assistants have the advantage that correctness is machine-checked; informal solutions carry more of the explanatory style that production models need. The mix is set by the specification.
Can problems be collected in languages other than English?
Yes, including parallel sets where the same problem exists in several languages. Reasoning is a demanding place for translation, so parallel items are reviewed as solutions in each language rather than translated and assumed.
Do you have Reasoning Data available now?
No. We do not hold inventory. Everything is produced against a specification. That means the timeline starts when the spec is agreed rather than immediately, and it also means the data matches your requirement instead of approximately matching something already built.
Can this be combined with other categories in one delivery?
Yes, and it is common. A single specification can cover several categories across several languages, with one pilot batch and one quality bar. It usually reduces total cost because contributor recruitment and project setup are shared.
What does the consent documentation cover?
Signed contributor consent stating the intended use, the collection methodology, and the annotation guideline the data was produced under. For projects involving EU data subjects the chain is built to satisfy GDPR, including the transfer mechanism. The terms for moving the data across a border.
Request Reasoning Data
Tell us the language, the hours, and what the data needs to look like. You will get a real number and a real timeline, not a range. If we cannot source it well, we will tell you that instead.
- Pilot batch before the full run, so problems surface early.
- Consent documentation delivered with the data.
- No medical or clinical data. No recorded telephone calls.
- You send the spec Language, hours, recording conditions, and the deadline.
- We reply within two business days A real number and a real timeline, not a range.
- You approve a pilot batch A small run first, so problems surface before the full order.
- Full run, then delivery with documents Audio, transcripts, and the consent record for every speaker.