No LLM generated, assisted/co-written, or edited work.
Read full explanation
Epistemic status: engineering writeup, not a research result. I'm not claiming any of the 158 "beats baseline" ideas are important — I'm claiming the pipeline's verdicts are honest, and I want feedback on whether that claim holds up under scrutiny, and on whether this kind of infrastructure is useful to anyone here.
Summary
SynthCore is a pipeline that reads new math papers on arXiv, has an LLM propose concrete ML applications, and then runs those proposals through a fixed, deterministic verification procedure before calling anything a win. The part I think is relevant to this forum isn't the ML ideas themselves — it's the verification design, which I built specifically so the LLM cannot grade its own homework.
Current numbers:
Stage
Count
Papers analyzed
13,175
Ideas extracted
2,975
Experiments run
1,276
Mechanisms confirmed (toy gate)
626
Beat tuned baseline (significant)
158
All ideas — including the ~2,800 that died somewhere in the funnel — are published with full reports, code, and the underlying math: https://synthcore.org/ideas. Methodology: https://synthcore.org/about.
Why I think this is on-topic here
A generic "LLM reads papers and generates ideas" pipeline is not alignment-relevant; it's just research automation. What made me want to post it here is a narrower question I ran into while building it: if you're going to let an LLM generate a large volume of claims, how do you stop the grading of those claims from inheriting the LLM's own biases and incentives? This is a small, concrete instance of a problem that shows up in scalable-oversight discussions — the verifier needs to be strictly separated from, and harder to fool than, the generator. I don't think I've solved anything deep here, but I did have to make a series of specific design choices to get even this narrow, low-stakes version of the problem right, and I'd like people who think about this more rigorously to poke at them.
Pipeline
Fetch. Pull new papers from arXiv math categories.
Extract (LLM). The LLM screens each paper for a mechanism it thinks is transferable to ML. If nothing looks applicable, the paper is dropped. If something is, the LLM writes a structured spec: the mechanism, the underlying math, and self-assessed usefulness/difficulty/novelty ratings. (Note: these self-ratings are advisory metadata for triage — they do not feed into the pass/fail verdict below.)
Mechanism gate (deterministic). A cheap, controlled toy experiment checks whether the claimed mathematical effect reproduces at all, and whether it matches the predicted quantitative behavior — not just the right sign. This is meant to be a harsh, cheap filter, and most ideas die here on purpose.
Benchmark (deterministic). Ideas that survive the gate are implemented on a real (small) neural-net task and compared against a tuned baseline — same training budget — over 8 paired seeds. Significance is computed via a permutation test, and I report the minimum detectable effect alongside every result so a null isn't silently read as "no effect."
The verdict — helps / hurts / no effect — is emitted by a fixed piece of test code that consumes the paired-seed statistics. The LLM that proposed the idea never sees or influences this step, and there is no LLM-as-judge anywhere in the scoring path.
Where I expect this to be gameable, and why I'm publishing failures
I don't think "the LLM never grades its own homework" is sufficient on its own — there are at least three softer failure modes I'm aware of and haven't fully solved:
Idea-selection bias. The LLM chooses which papers look promising before any testing happens, so the funnel is shaped by whatever the extraction step finds legible, not by what's actually most promising.
Benchmark gaming via scale/budget choice. "Beats a tuned baseline" is scoped to this benchmark, this scale, this tuning budget. It's a signal, not evidence the effect survives at scale — I say this explicitly on the site rather than let "158 wins" imply more than it does.
Toy-gate false positives. A mechanism reproducing at toy scale with the right quantitative signature is evidence, not proof, that it's the same mechanism doing the work at benchmark scale.
Publishing the ~2,800 non-wins alongside the 158 wins is the main mitigation I have for the first two: if the failure base rate and the failure reasons are visible, the 158 number is harder to launder into something it isn't.
Questions for this community
Is "deterministic verifier, LLM never sees its own grade" the right minimal bar for this kind of setup, or is there an obvious hole I'm not seeing (e.g., the LLM shaping the benchmark task itself during extraction, which would let selection bias re-enter through the back door)?
Does anyone have pointers to prior work on verifier/generator separation in automated-research contexts specifically (as opposed to RLHF/RLAIF reward-modeling literature, which I've read)?
Is the toy-mechanism gate doing real epistemic work here, or is it mostly theater that makes the funnel look more rigorous than it is?
Happy to go into more detail on any specific stage, or on specific ideas in the published set.
Epistemic status: engineering writeup, not a research result. I'm not claiming any of the 158 "beats baseline" ideas are important — I'm claiming the pipeline's verdicts are honest, and I want feedback on whether that claim holds up under scrutiny, and on whether this kind of infrastructure is useful to anyone here.
Summary
SynthCore is a pipeline that reads new math papers on arXiv, has an LLM propose concrete ML applications, and then runs those proposals through a fixed, deterministic verification procedure before calling anything a win. The part I think is relevant to this forum isn't the ML ideas themselves — it's the verification design, which I built specifically so the LLM cannot grade its own homework.
Current numbers:
Stage
Count
Papers analyzed
13,175
Ideas extracted
2,975
Experiments run
1,276
Mechanisms confirmed (toy gate)
626
Beat tuned baseline (significant)
158
All ideas — including the ~2,800 that died somewhere in the funnel — are published with full reports, code, and the underlying math: https://synthcore.org/ideas. Methodology: https://synthcore.org/about.
Why I think this is on-topic here
A generic "LLM reads papers and generates ideas" pipeline is not alignment-relevant; it's just research automation. What made me want to post it here is a narrower question I ran into while building it: if you're going to let an LLM generate a large volume of claims, how do you stop the grading of those claims from inheriting the LLM's own biases and incentives? This is a small, concrete instance of a problem that shows up in scalable-oversight discussions — the verifier needs to be strictly separated from, and harder to fool than, the generator. I don't think I've solved anything deep here, but I did have to make a series of specific design choices to get even this narrow, low-stakes version of the problem right, and I'd like people who think about this more rigorously to poke at them.
Pipeline
The verdict — helps / hurts / no effect — is emitted by a fixed piece of test code that consumes the paired-seed statistics. The LLM that proposed the idea never sees or influences this step, and there is no LLM-as-judge anywhere in the scoring path.
Where I expect this to be gameable, and why I'm publishing failures
I don't think "the LLM never grades its own homework" is sufficient on its own — there are at least three softer failure modes I'm aware of and haven't fully solved:
Publishing the ~2,800 non-wins alongside the 158 wins is the main mitigation I have for the first two: if the failure base rate and the failure reasons are visible, the 158 number is harder to launder into something it isn't.
Questions for this community
Happy to go into more detail on any specific stage, or on specific ideas in the published set.