NVIDIA Nemotron Model Reasoning Challenge · 2026

Teaching a language model
to reason about symbolic equations

Synthetic reasoning trajectories, curriculum SFT,
and a proposal for verifiable process rewards.

The research question

Can a solver teach a model a useful way to search?

A symbolic solver can find an answer by exploring thousands of possibilities. A language model has to produce a useful explanation and an answer within a small token budget. My idea was to bridge that gap: use a solver to obtain a feasible destination, construct a short trajectory leading to it, and teach that trajectory before asking the model to improve through reinforcement learning.

This page explains the design choices, the obstacles behind them, and how I would extend the approach. The solver, synthetic trace generator and curriculum training pipeline were implemented. Semantic rewards extracted from the traces were the proposed next phase. The experiments did not demonstrate a successful symbolic reasoning model.

Find a feasible solutionBuild a teaching trajectoryLearn, then refine

01 · Find the bottleneck

A familiar equation with unfamiliar rules

The competition used a shared Nemotron-3-Nano-30B model and evaluated a submitted LoRA adapter on answer accuracy. Its published evaluation allowed an 8,192-token context and up to 7,680 generated tokens. The model had to end with a boxed answer. Competition overview and metric ↗

The data covered numeral conversion, unit conversion, gravity, ciphers, bit manipulation, numeric equations and symbolic equations. In our competition work, the other categories had become much more reliable. Symbolic equations remained the bottleneck, so we focused our effort there.

Shown equations
AB + CD = DF
AC + BE = CH
BD + CE = EI
New left-hand side
AB + CE = ?

Infer the hidden rules, then encode the result.

Invented example for this explanation. Even “+” is just an operator glyph in the real task: it need not mean addition. Extra examples used in the interactive trajectory below constrain more symbols.

A candidate solution is a small program: a symbol-to-digit mapping, an operator-to-function mapping, and an encoding convention. With A=1, B=2, C=3, D=4, E=5, F=6, G=7, H=8, I=9 and ordinary addition, AB + CE becomes 12 + 35 = 47, encoded as DG. This is one feasible interpretation; a few examples may leave several interpretations possible.

02 · Design the learning pipeline

Two phases: teach a procedure, then reward useful progress

PreparationSymbolic solver → feasible programs → synthetic trajectories

Known solutions provide supervised targets. Short, structured explanations provide a procedure to imitate.

Implemented pipeline

1. Curriculum SFT

Start with fewer equations. Train on attempts, checks, repairs and the answer. Unlock larger problems while retaining replay.

Output: a warmed-up LoRA policy
Proposed semantic rewards

2. Reinforcement learning

Sample the model’s own tagged trajectories. Verify the claims. Reward correct answers and valid progress; penalize false checks and repetition.

Goal: improve beyond imitation
The intended end-to-end method. Generic GRPO code exists in the repository; the richer trace-aware reward system shown here was not completed or validated.

SFT is the warm-up: it gives the model examples of how to organize a candidate, test it and revise it. RL would then expose the model to its own mistakes and optimize the behaviors that an external checker can verify. Neither stage guarantees that the model learns general reasoning; that has to be measured on unseen puzzles.

03 · Obtain supervision

First, build something that can find a solution

We initially lacked reliable teaching solutions ourselves. Through trial and error, the approach became a constrained symbolic search, with a Python driver and a Rust search core. Instead of allowing arbitrary mathematics, we defined a manageable set of operation families, including addition, multiplication, differences, division, remainders, gcd, lcm and concatenation. Small offsets cover variations such as a × b + 1.

Standard encoding

decode(AB) = b·d(A) + d(B)

Base 10, A=1, B=2 → 12

Little-endian encoding

decode(AB) = d(A) + b·d(B)

Base 10, A=1, B=2 → 21

Here b is the numeral base and d maps a symbol to its digit. The research explored base choices; later configurations fixed base 10 for simplicity.

  1. Check simple structure. A demonstrated forward or reverse concatenation pattern can avoid arithmetic search entirely.
  2. Narrow the operation candidates. Inspect signs, repeated operands, result widths and symbol patterns. Operator-glyph statistics suggest a search order, while logical impossibility checks can eliminate candidates.
  3. Assign digits and prune. Enforce distinct digits for distinct symbols. As assignments become available, check constraints and abandon branches that cannot satisfy them. Backtrack and try another candidate or encoding.
  4. Collect feasible programs. Keep solutions consistent with the constraints, optionally collecting several. During data construction the known target answer can be included as a constraint; this makes the solver a supervision oracle, not an unbiased measure of test-time accuracy.

Why not teach the brute-force log? Exhaustive search is lengthy, contains many unhelpful dead ends and easily overwhelms the competition’s token budget. A successful search log also does not automatically provide a concise, learnable explanation. I wanted to retain the valid destination while controlling the teaching path.

04 · Work backward to teach forward

Synthetic trajectories from a fixed feasible solution

Choose one feasible target program. Starting from its digit mapping, make a small change—swap two assignments or reassign a symbol to an unused digit. Repeat for up to N perturbations. Then reverse the sequence: the teaching trajectory begins with a flawed hypothesis and reaches the fixed target through one repair at a time.

Construction · known target first
M*Feasible target
M₂One perturbation
M₁Two perturbations
M₀Three perturbations
Reverse the order; describe checks and candidate repairs.
Teaching · read as forward attempts
M₀Try & check
M₁Repair & check
M₂Repair & check
M*Verify & answer
Three perturbations are an example, not a requirement. The generator can produce fewer depending on puzzle structure and the text budget.

The intermediate hypotheses deliberately fail; what must be sound is the arithmetic used to check them and the final solution. The generator uses a forward check to describe a mismatch, then frames a repair as a hypothesis to test. Several trajectories can lead to the same target. These are constructed teaching explanations, not a claim about the actual search history or a model’s internal reasoning.

Interactive illustration · no model inference

Follow a synthetic repair trajectory

3 repairs

For this toy example, addition and standard base-10 encoding are fixed. Move from the perturbed mapping toward the selected target.

M₀ · perturbedM* · selected target
ExampleDecoded checkResult
Query AB + CE
What changes between attempts?

The target assigns A… I to 1…9. Construct backward by swapping A/B, then C/D, then E/F. Read forward, undo E/F, C/D, then A/B. The example equations are independently recomputed at each attempt. A repair may fix one equation and disturb another; only the final mapping must pass every check. The selected endpoint is known during construction.

Keep the text useful and short. Describe the mismatch rather than every searched branch. Reuse a concise operation vocabulary, skip unchanged checks where appropriate, and cap the number of repair attempts. The implementation estimates text length and reduces perturbations; exact tokenizer checks would be needed to guarantee the final response fits.

Do not disguise privileged information as deduction. The known endpoint helps construct the path, but a narrated claim should be justified by the visible examples. “Try this swap” is a proposal; “this digit must be 4” needs evidence. The project’s later revisions addressed this distinction and visibility of symbols absent from the prompt.

05 · Make the learning task progressive

Start small, retain useful experience, increase complexity

Long systems require more candidate checks, more cross-equation consistency and longer explanations. My curriculum starts with one shown equation plus one query—two equations in total—and progresses toward problems with three, four or five shown equations. Earlier examples remain in the mix while harder buckets are introduced.

1 example
+ query
2 examples
+ query
3 examples
+ query
4–5 examples
+ query

The implemented scheduler adapts competence-based curriculum learning. A square-root schedule unlocks buckets according to their cumulative dataset share. Before full difficulty, the sampler balances the unlocked buckets. The last phase focuses on the three–five-example distribution. A separate replay stream from the other puzzle categories stays active throughout.

Illustration of the recorded schedule configuration: 250 updates, full competence at update 175, 25% replay. Band widths are expected sampling proportions, not measured learning progress.
Explore the sampling rule

What goes into a training batch?

Start smallTarget distribution

Batch size 32: 8 replay slots and 24 symbolic slots. Shares are expected values; actual samples use seeded shuffled cycling. At step 175, one- and two-example buckets drop out of the symbolic mix.

The loss teaches the assistant’s trajectory and final answer while masking the prompt. To test the curriculum fairly, I would compare it with flat sampling under the same token budget, starting adapter and puzzle-level split. Augmentations of the same original puzzle must stay in the same split.

06 · Proposed next phase

Make reasoning steps inspectable—and reward what can be checked

After SFT, the model would generate its own trajectories in the learned format. Tags give a fixed reward function places to look: the proposed digit mapping, the equations checked, the detected failure, the suggested repair and the conclusion. The important step is independent verification, rather than trusting a model’s claim that it passed a check.

  1. 1Sample a group

    Warmed-up policy generates several tagged attempts for one puzzle.

  2. 2Parse & verify

    Recompute equations and compare states using a deterministic checker.

  3. 3Assign rewards

    Combine answer accuracy, valid progress and bounded penalties.

  4. 4Update the policy

    Use group-relative advantages in GRPO; sample again.

↶ Repeat with the updated policy and fresh trajectories
Proposed RL loop. A scalar reward can aggregate checked process signals. Assigning different rewards directly to individual tokens would require additional training logic.
Tags as a contract between the model and a verifier
Trace fieldWhat to extract or verifyStatus
<digit_mapping_N>A candidate assignment. Check valid digits and one-to-one symbol mapping.Existing tag
<digit_mapping_analysis_N>Decoded operands, chosen operations and example checks. Recompute them.Existing tag
<digit_mapping_analysis_follow_up_N>A repair hypothesis. Compare the before/after mappings and checks.Existing tag
<conclusion>Final encoded answer and consistency with the selected program.Existing tag
<check eq="2">
<repair>
Machine-readable operands, computed result, expected result and changed assignments.Proposed extension
<reject reason="…">
<assumption>
A verifiable reason to discard a candidate; an explicit choice when the examples do not determine a unique rule.Proposed extension
<check eq="1">
  mapping: A=2, B=1, C=3, D=4, F=6
  operation: add; encoding: standard
  computed: 21 + 34 = 55; expected: 46
  verdict: fail
</check>
<repair>
  hypothesis: swap A and B, then recheck all examples
</repair>

Proposed structured extension, illustrated on the toy equation AB + CD = DF. The arithmetic is checkable; the verifier must still test whether the proposed swap improves the full constraint set.

Candidate reward components—not implemented or tuned
SignalReward or penaltyHow to avoid a shortcut
Final answerReward matching the reference answer.Keep this separate from merely finding a program consistent with the demonstrations.
Constraint consistencyReward the fraction of all shown equations satisfied by a valid candidate.Use one shared mapping and operation choice across checks; recompute every equation.
Useful repairReward net improvement in verified constraints.Count novel states, cap the bonus and do not reward undo/redo cycles.
False verificationPenalize claiming that an incorrect computation passed.A failed hypothesis honestly reported is allowed; fabricated success is not.
Repeated states & excess lengthPenalize unproductive loops and budget overruns.Do not pay for the number of tags; retain enough space for useful exploration and the answer.
Illustrative reward design · untrained coefficients

Credit an honest partial attempt

R = answer + 0.2·consistency + 0.1·progress − 0.2·false-check − 0.1·loop − 0.05·overrun

+1.30

A design sketch: all components are bounded and recomputed by a verifier. It illustrates how two wrong answers can receive different feedback. These weights are not experimental results or a recommended optimum.

Even dense rewards can be uninformative if every rollout earns the same score. I would mix problem difficulty to keep both successes and failures in the group, keep a small SFT/replay stream during refinement, and monitor final-answer accuracy separately from process scores. A higher process reward is useful only if it transfers to better answers on unseen problems.

What I learned

A useful research direction, an unsuccessful model so far

The central lesson was that finding a feasible solution and teaching a language model to find one are different problems. A symbolic oracle supplied targets. Synthetic trajectories made them shorter and structured. A curriculum made the training distribution controllable. None of that was enough to demonstrate strong symbolic performance in the saved runs.

29 / 823 3.52%

Best saved symbolic-equation diagnostic. These are public training puzzles, not a held-out benchmark. The saved evaluations predate the last generator revision; there is no verified final score for that revision or the proposed semantic RL phase.

View the saved diagnostic results and their limits
Saved run labelCorrect / 823Accuracy
Zero-example · unmasked basic30.36%
Zero-example · masked analysis30.36%
Zero-example · masked basic70.85%
Merged · unspecified configuration50.61%
Merged · mask-prefix · 250 steps10.12%
Merged · mask-prefix-initial · 400 steps293.52%

Labels summarize saved filenames, not controlled comparisons. The best run included boxed answers in only 81 of 823 outputs, pointing to completion/format problems; missing token counts and finish reasons prevent assigning a single cause. The ~86% starting competition adapter documented in the repo is a different result and is not the outcome of this method.

Evidence and methodology · Aggregate results with source hashes

How I would continue

  1. Improve the SFT foundation. Audit each claim for visible evidence, preserve honest uncertainty, measure exact token lengths and train until the model reliably completes a checkable trajectory.
  2. Test transfer, not memorization. Hold out whole source puzzles and novel symbol mappings. Compare curriculum with flat sampling, and compare short synthetic repairs with answer-only or direct explanations under the same budget.
  3. Implement the process verifier. Start with mapping validity and arithmetic checks; add repair progress only after testing against false claims, repeated states and reward manipulation.
  4. Spend more effort on RL after a usable warm-up. Compare answer-only and process-aware rewards, track each category to detect forgetting, and retain changes only if final-answer generalization improves.

My hypothesis is that stronger SFT followed by carefully verified RL feedback could make better use of these trajectories. That remains an experiment to run. I am sharing the design because the route from a difficult problem to a testable training strategy is worth documenting, including where it failed.

Code & references

Research developed during the 2026 competition. This explainer presents the method and proposed extensions; simulations are illustrative and run locally in your browser.

← Back to Demos