MathConstructOptimize-Envs

3,577 RL tasks in 142 families where the model must construct a mathematical object, graded by a deterministic checker. There is no answer matching and no LLM judge in the reward path.

Most math RL data asks for a final number. Here the model has to produce the object itself: a colouring, a design, a counterexample, a point configuration, a polynomial. The checker accepts any valid object, not a stored answer. The collection has two subsets:

subset	what the model does	reward	families	tasks
construct	produce any object satisfying stated conditions (a witness)	1 if valid, else 0	80	3,464
optimize	produce a valid object with the best objective it can (extremal constructions, bound improvement)	0 if invalid; otherwise 0.1 + 0.9 × progress from a trivial baseline to the best known value	62	113

The runnable sandboxed version (one Harbor task directory per row) is in amphora/MathConstructOptimize-Envs-harbor.

Sources

Tasks are converted from existing generator suites and research-problem repositories. Each checker was re-implemented and hardened; see the list of upstream verifier bugs below.

source	subset	tier	families	tasks
RLVE-Gym	construct	competition	30	1,800
MathConstraint	construct	competition	33	875
NPPC	construct	competition	8	480
Reasoning Gym	construct	competition	3	180
AlphaEvolve repository of problems	construct + optimize	research (mostly)	27	187
EinsteinArena	optimize	research	26	28
FunSearch	optimize	research	3	15
Finch / Evolution Fine-Tuning (erdos_* tasks)	optimize	research / competition	12	12

Construct generators have 4–6 difficulty levels × 10 seeds. Optimize tasks are single research problems, some at several sizes n. families.csv lists every family with its source, license, domain, problem_key and tags.

Row schema

column	meaning
task_id	unique id
subset, family, problem_key	task contract, generator family, canonical math problem id (for cross-source dedupe)
domain, tier, level	math area, competition or research, difficulty level
source, license	upstream task and its license
tags	see below
prompt	full, self-contained task statement including the required JSON answer schema
instance	JSON string with the instance data the checker needs
direction, baseline, best_known	optimize only: objective direction, trivial-baseline score, best known score
reference_answer, reference_reward	a known valid answer (planted witness or published construction) and its reward; for SFT/debugging, not needed for grading

Grading

from datasets import load_dataset
from huggingface_hub import snapshot_download
import sys, json

repo = snapshot_download("amphora/MathConstructOptimize-Envs", repo_type="dataset", allow_patterns=["grade.py", "graders/*"])
sys.path.insert(0, repo)
from grade import grade

ds = load_dataset("amphora/MathConstructOptimize-Envs", "construct", split="train")
row = ds[0]
reward, details = grade(row, json.loads(row["reference_answer"]))   # -> 1.0, {"valid": True}

Graders need Python ≥ 3.10 with numpy, scipy, sympy and networkx. Every check runs in under 60 s. Feasibility checks use exact integer or rational arithmetic wherever the problem allows.

The optimize reward is 0 for an invalid answer, else 0.1 + 0.9 · clip(progress, 0, 1). Progress is linear between baseline (a deliberately weak valid construction) and best_known. The kissing-number tasks use a log scale of the overlap loss instead. The 0.1 floor for validity keeps GRPO groups from being all-zero, because without it research-level tasks gave no signal in our pilot.

Tags

tag	meaning
agentic_trivial	a solver (CP-SAT, z3, brute force) cracks the top level within seconds, so the task is useful single-turn but weak for sandboxed agents (2,368 tasks)
np_search	the task is essentially combinatorial search
best_known_uncertain	best_known comes from our own search or an uncited value
ea_under_review	EinsteinArena marks the problem as under review. We audited each one and included it only when we could make the check sound
unique_answer	the answer is unique, but it is still verified as a witness (e.g. by expanding a factorization)
float_objective, exact_integer, exact_rational, ...	how the objective is computed

Reference pass rates (pilot, 66 tasks)

Pilot with 8 single-turn samples and 4 agentic attempts per task (Harbor terminus-2, no network):

model / mode	trivial (≥0.9)	trainable	too hard (≤0.1)
gpt-oss-120b, single-turn	23	23	20
gpt-oss-120b, agentic	33	19	13
Qwen3-8B, single-turn	13	15	38
Qwen3-8B, agentic	8	10	47

Pass rates vary a lot by model and mode, so filter for your policy. Difficulty levels are monotone within every generator family.

Upstream verifier bugs found and fixed

Re-implementing the checkers surfaced problems in the source verifiers that an RL policy could exploit:

• Model output executed as code. RLVE integral (sympify) and Reasoning Gym integration (parse_expr) evaluate the model's answer as Python, and they also accept an unevaluated Integral(f, x). Our checkers parse through a whitelist syntax tree.
• Empty answers accepted. MathConstraint verify() lets the solver fill in any variable the answer omits, so {} passes.
• Missing range, length or type checks.
  • NPPC 3-colouring accepts an all-distinct colouring.
  • Clique and independent set accept a vertex repeated k times.
  • Quadratic congruence accepts x = 0.
  • Several verifiers accept floats or bools.
• Floating-point feasibility checks.
  • EinsteinArena circle packing and circles-in-rectangle (the AlphaEvolve seed overlaps by about 1e-16).
  • Heilbronn triangle containment (uses a rounded √3).
  • Finch tolerances that allowed beating the proven 10/3 bound.
  • AlphaEvolve p58 (Erdős–Szekeres): the published 33- and 65-point sets reported as having no convex 7- or 8-gon do contain one under exact arithmetic.
• Checks that are wrong or too weak.
  • AlphaEvolve spherical designs: the pass test compares a negated error, so it always passes.
  • AlphaEvolve 3D Kakeya ignores tubes that leave its Monte Carlo box.
  • Arithmetic Kakeya "repairs" the submitted distribution before scoring it.
  • The prime-number-theorem constraint was checked on random samples.
  • The uncertainty-principle root scan could miss roots.
• Wrong or unreachable targets. Several Finch targets are above a provable maximum, below a known optimum, or infeasible.

Excluded

• AlphaEvolve problem 6: the notebook's functional differs from the one a construction-checker can certify.
• Problems with no checkable objective (proof-only or meta problems), or no recoverable construction or verifier.
• FunSearch corner-free sets (checker not released).
• Sources without a license.
• Duplicate problem and size pairs across sources (deduplicated by problem_key).

License

Each row carries the license of its source (license column): MIT (64 families), CC-BY-4.0 (59), Apache-2.0 (19). Attribution belongs to the original authors of each source listed above. Our packaging, checkers and generators are released under the same terms as the corresponding source.