Reasoning Core builds better procedural reasoning data

Reasoning Core shows that broad procedural data can improve completion-supervised reasoning training.

• Research org: Unspecified in arXiv abstract
• Core data: 50 generators
• Breakthrough: Broad procedural collection with semantic scorers and difficulty controls

If you train models on reasoning tasks, you already know the bottleneck: good data is hard to scale, and synthetic data can look valid without actually teaching the model anything useful. This paper is about that gap.

The authors propose Reasoning Core, a procedural data library designed specifically for completion-supervised reasoning training. Instead of relying on one narrow task family, it spans mathematics, logic, planning, state tracking, formal languages, structured data, games, causality, and code.

What problem this paper is trying to fix

Procedural generators can produce verifiable reasoning problems at scale, which makes them attractive for supervised training. But the abstract makes a clear point: this space has received less attention than it deserves as a source of completion-supervised fine-tuning data.

That matters because completion-supervised training depends on the model learning from the target completion itself, not just from a prompt-response pattern. If the generated examples are too easy, too noisy, or too loosely tied to the intended skill, the training signal can be weak even when the examples are technically “valid.”

Reasoning Core is built around that problem. The paper argues that procedural generation alone is not enough; the design of the generators, targets, and scoring matters just as much as the fact that the data is synthetic.

How the method works in plain English

Reasoning Core is a collection of 50 generators. Each generator produces verifiable reasoning problems in one of several domains, including math, logic, planning, state tracking, formal languages, structured data, games, causality, and code.

What makes the library more than a random pile of synthetic tasks is the extra machinery around the generators. The abstract mentions semantic scorers, difficulty controls, and task evaluators. In practical terms, that means the system is not only generating examples, but also checking whether they are meaningful, controlling how hard they are, and evaluating whether the task is being rendered and scored correctly.

The authors also ran audits that combine model-assisted review, human adjudication, and regression testing. Those audits were applied while developing Reasoning Core and also to the comparison collections, which suggests the paper is as much about data quality control as it is about raw data volume.

What the paper actually shows

The evaluation uses a matched completion-supervised protocol, and the authors compare Reasoning Core against Procedural Warmup, Reasoning Gym, and SynLogic across four base-model settings and multiple training durations.

In the primary 3B comparison, Reasoning Core achieves the highest mean scores on DROP, LogiQA, and ARC-Challenge. The abstract says it exceeds both the baseline without procedural data and all three alternative procedural collections.

Important caveat: the abstract does not provide the actual benchmark numbers, so we can’t say by how much it wins from the source text alone. What we can say is that the result is not limited to one dataset or one model size; the authors claim it holds across the primary 3B setting and that they tested multiple base-model settings and training durations.

The task-level analysis is also a key result. The paper says semantic validity alone does not ensure training utility, which is a useful warning for anyone building synthetic data pipelines. In other words, a generator can produce examples that look correct on paper but still fail to train the model effectively.

Why this matters for developers

If you work on LLM training, evals, or data generation, this paper is a reminder that “synthetic” is not a quality guarantee. A procedural dataset needs more than coverage: it needs calibrated difficulty, compact targets, and checks that the rendered task still matches the intended solution space.

That is especially relevant for completion-supervised setups, where the target completion is the training signal. If the target is bloated, ambiguous, or mismatched to the generator, you can end up optimizing the wrong thing.

The paper also suggests a practical workflow for teams building their own synthetic data: use semantic scoring, add difficulty controls, and audit the pipeline for mismatches between generation, rendering, targets, and scoring. The authors explicitly report finding subtle mismatches through those audits, which is a good reminder that these bugs can hide in plain sight.

Limitations and open questions

The abstract gives strong directional results, but it leaves out several details developers would want before treating this as a drop-in recipe. We do not get benchmark numbers, per-task deltas, or a full breakdown of how each generator contributes to the gains.

We also do not know from the abstract how expensive the audits are, how hard the generators are to maintain, or how sensitive the results are to specific model choices beyond the four base-model settings mentioned. Those are the kinds of details that determine whether a data recipe is reusable in real training pipelines.

Another open question is transferability. The paper shows gains on DROP, LogiQA, and ARC-Challenge in the primary 3B comparison, but the abstract does not tell us whether the same procedural design principles hold equally well for other model sizes, other reasoning benchmarks, or non-reasoning tasks.

The bottom line

Reasoning Core is not just another synthetic dataset dump. It is an attempt to make procedural reasoning data more trainable by shaping the examples, scoring, and difficulty around completion-supervised learning.

For practitioners, the big takeaway is simple: if you are generating reasoning data, validity is only the starting point. The paper argues that compact targets, calibrated difficulty, and careful auditing are what turn synthetic problems into useful training signal.

• Broad procedural data can beat narrower synthetic collections in completion-supervised reasoning training.
• Data quality depends on more than semantic validity; target design and difficulty calibration matter.
• Audits can catch generation-rendering-scoring mismatches that synthetic pipelines otherwise miss.